我想把手机里的几张图片和一些资料传到电脑上。手机和电脑连着同一个 Wi-Fi，本来觉得这应该是件很简单的事，找起工具来却有点犯难。
如果两边都是苹果设备，用 AirDrop 就很方便。但手机和电脑只要有一边换成其他系统，这个办法就用不上了。发给自己再去电脑下载当然也行，只是两台设备明明就在手边，还得多绕一步。我想找一个能在同一网络下直接传文件、用起来又省事的工具。
顺着这个需求调研了一下，我找到了 LocalSend。它专门做局域网文件传输，图片、视频、文档都能传，客户端覆盖 Android、iOS、Windows、macOS 和 Linux。我用 Mac 和 iPhone 试了它的 Web 客户端，两边打开网页，找到对方，再选文件发送，用下来挺顺手，实际操作截图也放在了后面。
试完以后，我又有点好奇。设备出现在列表里，看起来很自然，但它们究竟是怎么找到对方的？文件从哪边发起连接，接收方点下同意以后，又发生了什么？于是我接着翻了项目的源码，有了这篇文章。
下文看的版本是 v1.18.2，重点拆解原生客户端在局域网内的 v2 直传，以及应用里单独的浏览器分享入口。后面的 Web 客户端实测单独说明。
设备出现在列表前，先回了一次话
电脑在家里网络中的地址可能会变。如果每次传照片都要先查地址、再手动输入，还是有点麻烦。LocalSend 的原生应用会主动向附近设备报上自己的名字和连接方式，让同一局域网里的其他应用发现它。
收到消息的设备还会尝试连回来，确认这条路能走通。使用加密连接时，也会核对对方的证书是否与刚才报上的信息一致。确认之后，设备才会出现在列表中。名字主要是方便你认出设备，并不能证明它属于谁。
把这个过程拆开看，列表里的一个名字，背后其实已经有过一来一回。
所以连着同一个 Wi-Fi，也要确认设备之间能互相访问。找不到对方时，可以按文末的常见问题逐项检查。
先问收不收，再传文件
假设手机已经看见电脑，准备发两张照片和一段视频。手机会先把文件清单交给电脑，电脑可以在文件内容传过来之前，决定收哪些。如果设置了接收口令，也会先检查口令。
接收方同意后，会给这批传输一个编号，并给每个获准接收的文件一份临时凭证。手机拿着这些凭证，才开始发送对应文件。这样就能把「你同意接收的那份文件」和后面的上传对应起来。
完整过程里，有两种等待要分清。前面在等设备回应，后面在等接收方确认。
文件送来时，电脑还会核对发送来源、这批传输的编号，以及文件有没有开始接收。重复上传同一个文件的请求会被挡住。如果双方提供并启用了完整性检查，电脑还会检查收到的内容是否与发送方申报的一致。
加密连接、临时凭证、内容检查解决的是不同问题。加密保护传输过程，凭证限制这次允许上传的文件，内容检查则用来发现文件是否有变化。
v1.18.2 还有一个使用上的限制。接收方一次只接待一台发送设备，等待用户确认时也算占用。同一批里的不同文件可以同时传，另一台设备却要等前一批结束。家里偶尔互传影响不大，多人轮流给一台电脑交素材时，就需要排队。
用应用，还是用网页？先分清入口
LocalSend 有几种容易混淆的用法。两边安装应用、应用生成浏览器分享链接，以及两边直接打开 Web 客户端，是三个不同入口。后面的手机截图展示的是第三种。
先按你手边的设备和使用场景选入口，会更容易理解后面的区别。
两边都能安装应用时，可以用应用直接互传。对方只是临时来拿一份文件时，也可以由发送方在应用里开启浏览器分享，把局域网链接交给对方。对方打开链接下载，少了安装这一步。
这里有个要留意的默认设置。我对照了 v1.18.2 的源码和测试用例，应用内的浏览器分享默认使用 HTTP，也就是连接本身没有加密。它另外提供加密开关，打开后使用 HTTPS，但浏览器可能提示不信任证书，需要额外处理。
设置接收口令可以限制谁能开始下载，却不会自动给 HTTP 连接加密。分享前看一眼地址以 http:// 还是 https:// 开头，比只看能不能扫码打开更有用。我这里核对了源码和测试用例，没有实际抓取两台设备之间的网络流量。
官网提供的 Web 客户端则是另一个入口。下面的实测只说明它的操作体验，不能把应用内分享链接的默认设置套到它身上。
Mac 与手机上的 Web 客户端实测
下面这组实际操作截图来自 LocalSend Web 客户端：Mac 和 iPhone 连着同一个 Wi-Fi，两边在浏览器中打开 Web 页面。它与前文安装在设备上的原生应用使用不同的连接方式，这里主要看实际操作过程。
Mac 上先打开页面时，设备列表还是空的，页面提示在另一台设备上打开 LocalSend。
手机也打开页面后，Mac 的列表中出现了手机端的 Gorgeous Coconut，卡片标注为 iOS · Safari。
手机上也能看到 Mac 的 Energetic Cherry，卡片标注为 macOS · Chrome。点击设备卡片后，可以从照片图库、拍照或录像、选取文件三个入口挑选内容，选好后进入「发送文件中」状态。下图从左到右依次是发现 Mac、选择文件、发送进度；最后一张截到的是发送刚开始的画面，进度还是 0 B。
常见问题
下面按官方故障排除说明整理，主要针对安装版应用。先保持两端应用打开，用一个小文件试传；网页端与应用的发现方式不同，不能直接套用全部设置。
同一个 Wi-Fi，为什么找不到对方？
| 检查项 | 可能原因与处理办法 |
|---|---|
| 路由器隔离设备 | 访客网络或「AP 隔离」会禁止设备互相访问。在自己管理的可信网络中，检查并关闭这项隔离设置。 |
| Windows 网络类型 | 公用网络的访问限制可能更严格。在可信的家庭网络中，将当前连接设为「专用网络」，并允许 LocalSend 通过防火墙。默认使用的端口是 53317，需要允许 TCP 和 UDP 通信。 |
| Mac、iPhone 本地网络权限 | 在系统设置的「隐私与安全性 → 本地网络」中允许 LocalSend 访问。已经允许却仍异常时，可尝试关闭再开启权限，然后重开应用。具体入口名称可能随系统版本变化。 |
| VPN 或代理影响连接 | 先暂停两端的梯子再试，或在代理工具中允许局域网访问、绕过本地地址。无需假定所有代理模式都会阻断连接。 |
| 自动发现失败 | 尝试「手动发送」，输入接收端的局域网 IP 地址。如果能连上，可以加入收藏夹，方便后续直接探测；如果仍连不上，继续检查网络隔离和防火墙。手动输入地址不能绕过访问限制。 |
我这次用 Web 客户端测试时，就遇到过一端开着梯子、两边都看不到对方的情况，关闭两端梯子后恢复了。发现和连接需要有来有回，一端的网络路线或访问规则发生变化，另一端也可能等不到回应，因此双方都可能没有结果。不过这只能确认代理影响了本次连接，具体卡在哪一步，还需要网络记录才能判断。
另外，2.4 GHz 和 5 GHz 是不同的 Wi-Fi 频段，不代表设备一定不能互通。如果路由器正常转发，两边仍可连接；需要检查的是它们是否被分到互相隔离的网络。
能传文件，但为什么很慢？
先试着靠近路由器，并在信号良好的位置使用 5 GHz Wi-Fi。2.4 GHz 更容易受到周围设备干扰，但 5 GHz 也会受距离和墙体影响，不能只看频段名称判断速度。
官方还列出了一项对照办法，在两端同时关闭传输加密，观察速度是否改善。加密会增加处理负担，但不一定是你这次慢的原因。只在可信网络、使用非敏感测试文件时做这项比较，测试后恢复加密，也不要把关闭加密理解成保证提速的设置。
如果是 Android 接收慢，官方另有一条文件读写性能问题的记录，关联到 saf_stream 的性能讨论。简单理解，时间可能耗在把收到的数据写入手机，而不全是 Wi-Fi 慢。不过这个问题已被标记完成并关闭，是否仍影响你安装的 LocalSend 版本，还要看它使用的组件和实际表现。可以先更新应用，再用同一个文件对比其他接收设备，缩小排查范围。
如果两台设备各在不同网络，或者希望对方晚点再取，选择能暂存文件的网盘或其他分享方式会更合适。LocalSend 适合的是两台设备都在场、网络能互通的时候，选好文件就直接传过去。
