LocalSend局域网传输实测：千兆有线78.5MB/s，2.5GB文件40秒传完

局域网传文件这件事，说小很小，说大能让人抓狂。微信传大文件被压缩、网盘限速、数据线找不到、U盘插来插去还怕中毒——这些场景但凡经历过一次，就会开始琢磨有没有更省心的办法。LocalSend 就是在这个背景下被我反复安利的一款工具：开源、跨平台、不依赖外网、点对点直传。这次我拿它做了一轮完整实测，重点看两件事——千兆有线环境下到底能跑多快，以及一个 2.5GB 的大文件从点击发送到落地完成需要多久。实测结果：千兆有线跑到 78.5MB/s，2.5GB 文件约 40 秒传完。这个数字背后有不少值得拆开讲的细节，比如为什么跑不满千兆的理论值、无线和有线差距有多大、大文件传输时哪些设置会拖后腿。下面把整个实测过程、原理分析和踩过的坑一次说清楚，适合想用 LocalSend 替代传统传输方式、或者已经装了但速度不理想的读者参考。

1. 为什么我最终选了 LocalSend 而不是其他方案

1.1 传统传输方式的三个硬伤

在讲 LocalSend 之前，先把替代方案的痛点摆清楚，这样后面讲它的设计取舍才有参照系。日常传文件无非几条路：即时通讯工具、网盘/云盘、U 盘/移动硬盘、系统自带共享（如 SMB）、以及各类第三方传输工具。它们各有各的硬伤。

即时通讯工具的问题最直接——大文件压缩和大小限制。图片视频发过去画质掉一档，超过一定体积直接不让发，或者要求开会员。网盘的问题在于"上传—等待—下载"这条链路太长，中间还夹着限速，传一个 2.5GB 的文件，上传半小时、下载再半小时是常态，而且文件在第三方服务器上过了一遍，隐私上总归多一层顾虑。

U 盘和移动硬盘看似最原始可靠，但实际操作成本高：找盘、插口、拷贝、拔盘、再插到另一台机器，中间还要担心文件系统格式不兼容（比如大文件在 FAT32 上直接卡在 4GB 上限）、以及交叉感染的风险。系统自带共享配置门槛不低，跨操作系统时更是各种权限和协议折腾。

提示：如果你的需求只是偶尔传几十兆的文档，即时通讯工具其实够用；LocalSend 的价值主要体现在大文件、跨设备、频繁传输、以及不想让文件经过第三方服务器的场景。

1.2 LocalSend 的核心设计：点对点 + 局域网发现

LocalSend 的思路很干净：设备之间在同一个局域网内互相发现，文件直接从 A 设备传到 B 设备，不经过任何中转服务器。它用的是本地网络发现加 HTTPS 传输的组合——发现阶段靠组播/广播在局域网里"喊话"，传输阶段走加密的 HTTP 连接。这意味着两件事：第一，只要两台设备连在同一个路由器/交换机下，哪怕外网断了也能传；第二，文件全程不落第三方，隐私边界清晰。

跨平台是它另一个关键优势。Windows、macOS、Linux、Android、iOS 都有对应客户端，甚至还有命令行版本。这对混合设备环境特别友好——比如 Windows 台式机传文件给 Android 手机，或者 Mac 传给 Linux 服务器，不需要为每种组合找不同的工具。

它的工作模式可以粗略理解为：发送端在局域网内广播自己的存在，接收端监听并响应，双方建立连接后通过 HTTPS 把文件流式传过去。接收端可以选择"自动接收"或"手动确认"，后者会在收到请求时弹窗让你点接受。这个设计在公共网络里很重要，避免被人偷偷塞文件。

1.3 什么场景下它真的比网盘省事

我自己的高频场景有三个。一是家里台式机和笔记本之间同步素材，动辄几个 GB 的视频工程文件，网盘上传下载的时间成本完全不可接受。二是手机拍的照片视频往电脑上倒，数据线经常找不到，用 LocalSend 在同一 Wi-Fi 下直接推过去，几十秒的事。三是给同事临时传个大安装包或者数据集，双方连同一个办公网，不用加好友、不用建群、不用等上传。

这几个场景的共同点是：设备在同一网络、文件偏大、追求即时性。反过来说，如果两台设备不在同一局域网（比如一个在公司一个在家），LocalSend 就不适用了，这种跨网络场景还是得靠网盘或者别的中转方案。搞清楚它的适用边界，比盲目吹捧有用得多。

2. 实测环境与测试方法：把变量控制住

2.1 硬件与网络配置清单

速度测试最怕变量失控，所以先把环境交代清楚。这次实测的核心链路是两台机器通过千兆交换机直连组成的局域网，具体配置如下表。

两端都走有线、都接在同一台千兆交换机上，排除了无线干扰和跨网段路由的影响。存储都用固态，避免磁盘读写成为瓶颈——这一点很关键，如果接收端是机械硬盘，写入速度可能只有 100MB/s 出头，虽然理论上还够，但遇到小文件多的场景就会明显拖慢。

2.2 测试文件的选择逻辑

测试文件我准备了两个：一个是单个 2.5GB 的大文件（一个视频素材包），用来测持续传输带宽；另一个是一批总量相近但数量众多的小文件（几百个几 MB 的文档和图片），用来测小文件场景下的表现。为什么要分开测？因为大文件传输考验的是持续带宽，而小文件传输考验的是连接建立、请求往返的开销，两者的瓶颈完全不同。很多人只测一个大文件就下结论，结果实际传照片时发现慢得离谱，就是因为忽略了小文件场景。

2.3 测量方式：怎么读才准

速度数据我用了两个来源交叉验证：一是 LocalSend 客户端自身显示的传输速率，二是接收端系统层面的网络流量监控。客户端显示的是应用层速率，系统监控看到的是网卡实际吞吐，两者对比能判断有没有额外的协议开销。计时用秒表配合文件系统的时间戳，从点击发送开始，到接收端文件完整落盘、大小校验一致为止。

注意：测速时务必关闭两端正在进行的其他大流量任务，比如系统更新、云同步、视频会议。这些后台流量会直接吃掉带宽，让测试结果失真。我第一次测的时候就忘了关一个后台同步，结果只跑到 50 多 MB/s，排查半天才发现是它在抢带宽。

3. 千兆有线实测：78.5MB/s 是怎么来的

3.1 实测数据全记录

先上结果。单个 2.5GB 大文件，从点击发送到接收端校验完成，总耗时约 40 秒，平均速率 78.5MB/s。这个数字需要放到千兆网络的理论框架里看才有意义。

78.5MB/s 换算成比特率大约是 628Mbps，相对千兆的 1000Mbps 理论值，达成率在六成出头。这个成绩在真实环境里属于正常偏好水平，既不是"跑满千兆"的夸张宣传，也不是"名不副实"的翻车。

3.2 为什么跑不满千兆：一层层拆开销

很多人看到千兆网卡就以为能跑到 125MB/s，实际几乎不可能。原因是一层层协议开销叠加。

第一层是单位换算。千兆指的是 1000Mbps（兆比特每秒），换算成字节要除以 8，理论峰值就是 125MB/s。这一层很多人已经知道，但只是起点。

第二层是协议开销。以太网帧有帧头帧尾，IP 层有 IP 头，TCP 层有 TCP 头，HTTPS 还叠了 TLS 加密的记录层开销。这些头部信息都要占带宽，实际能承载用户数据的比例通常在 90% 出头。再算上 TCP 的确认机制、慢启动、拥塞控制，持续传输时能稳定在理论值的七八成已经不错。

第三层是应用层和存储层的开销。LocalSend 走 HTTPS，加密解密要消耗 CPU；文件写入磁盘有文件系统开销；如果文件被分块传输，每块还有额外的元数据。这些叠加起来，把 125MB/s 的理论值压到 78.5MB/s 就完全说得通了。

提示：如果你看到有人宣称局域网传输"跑满千兆 125MB/s"，基本可以判断要么是短时峰值、要么是缓存命中、要么是测量口径有问题。持续传输能稳定在 80MB/s 上下，在千兆有线环境里已经是很好的成绩。

3.3 40 秒的时间都花在哪了

2.5GB 除以 78.5MB/s 大约是 32.6 秒的纯传输时间，但实测总耗时约 40 秒，中间差了七八秒。这段时间花在几个地方：连接建立（局域网发现、握手、TLS 协商）、传输前的文件元信息交换、传输结束后的落盘刷写和校验。大文件传输时这部分开销占比不高，但如果传的是几百个小文件，每次都要走一遍请求往返，这部分开销就会被放大，这也是为什么小文件场景要单独测。

从体验上说，40 秒传完 2.5GB 已经完全脱离了"等待"的心理阈值——点完发送去倒杯水，回来就好了。对比网盘上传下载动辄十几二十分钟，差距是数量级的。

4. 无线对比与影响速度的关键变量

4.1 同一文件在 Wi-Fi 下的表现

为了给出参照，我把接收端切到 Wi-Fi（同一路由器的 5GHz 频段）重测了同一个 2.5GB 文件。结果速率掉到 30MB/s 上下，总耗时拉长到一分半左右。差距主要来自无线链路的半双工特性、信号衰减、以及同频段其他设备的干扰。2.4GHz 频段更惨，实测只有十几 MB/s，传大文件会明显感到等待。

这个对比说明一个很实际的问题：如果条件允许，大文件传输优先走有线。无线胜在方便，但有线的稳定性和速度是无线比不了的。手机传照片这种几十上百 MB 的场景，Wi-Fi 完全够用；但几个 GB 的工程文件，插根网线能省一半以上时间。

4.2 影响速率的五个变量

实测下来，影响 LocalSend 传输速度的变量主要有五个，按影响从大到小排列：

• 物理链路类型：有线千兆 > 5GHz Wi-Fi > 2.4GHz Wi-Fi，这是决定性因素。
• 存储读写速度：接收端磁盘写入慢会直接卡住传输，机械硬盘和低速 U 盘是常见瓶颈。
• 文件数量与大小分布：单个大文件效率最高，海量小文件因请求开销而变慢。
• 两端 CPU 性能：HTTPS 加密解密吃 CPU，老旧设备上可能成为瓶颈。
• 网络中的其他流量：后台同步、更新、视频流都会抢带宽。

把这五个变量对照自己的环境过一遍，基本就能判断速度上不去是卡在哪一环。

4.3 一个容易被忽略的细节：防火墙与发现失败

比速度更常见的问题是"根本发现不了对方设备"。LocalSend 靠局域网广播发现设备，如果系统防火墙拦截了相关端口，或者路由器开启了"AP 隔离"（客户端之间不能互访），就会出现两端都开着软件却互相看不见的情况。排查顺序建议是：先确认两台设备在同一网段（比如都是 192.168.1.x），再检查防火墙是否放行了 LocalSend，最后看路由器有没有开客户端隔离。这三步能解决绝大多数"发现不了"的问题。

5. 从安装到传完：一次完整操作的实操路径

5.1 安装与首次配置

各平台的安装都很直接，从官方渠道下载对应安装包即可。首次启动后有几项配置值得先调好，能省掉后面很多麻烦。

第一项是接收模式。默认可能是"手动确认"，也就是每次有人发文件都弹窗。在自己家的可信网络里，可以改成"自动接收"或者设置成仅对特定设备自动接收，省去每次点确认。但在公共网络（比如咖啡厅 Wi-Fi）里，务必保持手动确认，防止被人乱塞文件。

第二项是设备名称。默认名称往往是一串随机字符，改成能一眼认出的名字（比如"客厅台式机""工作笔记本"），在多设备环境里选择目标时不会选错。

第三项是保存目录。默认保存位置可能在一个不太方便找的文件夹里，建议改成自己常用的下载或素材目录，传完就能直接找到。

5.2 发送与接收的完整流程

操作流程本身很简单，但有几个细节值得说。发送端打开后，界面会列出局域网内发现的其他设备，选中目标设备，然后把文件拖进去或者点选择文件，确认发送。接收端如果设了手动确认，会弹出请求，点接受后开始传输，界面上能看到进度和实时速率。

传输过程中可以观察速率曲线：刚开始可能有一个爬升过程（TCP 慢启动），稳定后进入平台期。如果速率忽高忽低，通常是网络中有其他流量干扰，或者接收端磁盘在忙。传完后建议核对一下文件大小，尤其是大文件，确认落盘完整。

注意：传输大文件时尽量不要让接收端进入睡眠。部分系统的电源管理会在空闲时挂起网卡或降频，导致传输中断。可以在传输期间临时把睡眠关掉，或者插着电源操作。

5.3 传完之后：校验与清理

大文件传完，我习惯做一次大小比对，重要文件还会算一下哈希值对比。LocalSend 本身在传输层有完整性保障，但落到磁盘后做一次确认更安心，尤其是跨文件系统（比如从 Windows 的 NTFS 传到 Linux 的 ext4）时。清理方面，如果开了"自动接收"，注意定期看看保存目录，别让临时文件堆满磁盘。

6. 踩过的坑与几条实用经验

6.1 速度上不去的排查链路

有一次我怎么测都只有 40MB/s 出头，按下面的顺序排查才找到原因，这个链路可以直接复用：

1. 先看两端是不是都走了有线——结果发现接收端其实连的是 Wi-Fi，插上网线后恢复到 78MB/s。
2. 确认没有后台大流量任务——关掉一个正在同步的云盘客户端。
3. 检查接收端磁盘——如果是机械盘或 U 盘，写入速度可能就是瓶颈。
4. 看文件构成——如果是海量小文件，速率低是正常的，不是故障。
5. 最后才怀疑软件和系统——更新版本、检查防火墙。

这个顺序的逻辑是"从物理到应用"，先排除最底层也最常见的问题，避免一上来就折腾软件设置。

6.2 几个反直觉的结论

第一个反直觉：不是文件越大越慢，而是文件越碎越慢。单个 2.5GB 文件能跑 78.5MB/s，但同样总量拆成几百个小文件，平均速率可能掉到一半以下，因为每个文件都要走一遍请求和确认。

第二个反直觉：升级到更快的网络不一定有用。如果你的接收端是机械硬盘，就算上了 2.5G 网络，瓶颈也在磁盘写入上，网速再快也白搭。木桶效应在网络传输里体现得淋漓尽致。

第三个反直觉：自动接收不一定更快。手动确认多了一次点击，但能让你在传输开始前确认目标设备和保存位置，避免传错地方再重传，整体反而更省事。

6.3 适合长期使用的配置习惯

用久了会形成几个习惯，分享出来供参考。一是给常用设备起固定名字，多设备环境下不会选错。二是把保存目录设成固定位置，传完直接能找到，不用满盘搜。三是在可信网络里开自动接收、在公共网络里关掉，安全和便利兼顾。四是传大文件前先确认接收端磁盘空间和电源状态，避免传到一半失败。这几条都是踩过坑之后总结的，看着琐碎，但能省下不少返工时间。

最后说一句个人体会：LocalSend 这类工具的价值不在于参数多漂亮，而在于把"传文件"这件小事变得足够无感。78.5MB/s 和 40 秒的数字，放在日常使用里就是"点一下、等一会儿、好了"的体验。真正决定它好不好用的，往往不是峰值速度，而是发现稳不稳、配置顺不顺手、大文件会不会中途掉链子。把环境变量控制好，把几个常见坑避开，它就能稳定地替你省下大量等待时间。