手机里有一段 210MB 的录像要挪到电脑上，微信发过去糊得没法看，数据线不知道塞在哪个抽屉，走网盘等于让文件跑两趟。这种事一个月总要碰上几回，我一直想要的就是「两端装上、连同一个 WiFi、选完就发」的东西：不注册、不登录、文件不经别人的服务器。
LocalSend 是这个思路里做得最干净的一个。Apache-2.0 开源，Windows、macOS、Linux、Android、iOS 都有客户端，GitHub 上已经 9.6 万星。收发全程在局域网里完成，官方写得很明白：不需要联网，也不需要第三方服务器。我在一台 Windows 机器上把图形版和命令行版都跑了一遍，顺手抓了它找设备用的广播包，下面这些数字和坑都是自己量的。
它凭什么不登录也能找到对方
LocalSend 走两条腿：一条是 UDP 组播，一条是 HTTPS 的 REST 接口。设备一打开就往 224.0.0.167 这个组播地址、53317 端口周期性地喊一声「我在」，包里是设备名、协议版本、设备类型、证书指纹，以及它实际监听的端口。
我把监听挂上去数了一下：间隔稳定在 2 秒出头（两次实测 2006ms 和 2002ms），每个包 233 字节，内容长这样：{"alias":"客厅台式机","version":"2.2","deviceModel":"CLI","deviceType":"headless",...}。指纹是 64 位十六进制，接收方靠它认人，所以第一次连接不需要任何账号。
这套设计的好处很直接：断网也能用，宽带断了都不影响两台设备互传。代价是它高度依赖组播——路由器一旦开了 AP 隔离（访客网络基本默认都开），两边明明都正常在线，却永远互相看不见。
体积不算小，但有个 9MB 的版本
先说清楚，这东西在手机上不算轻。同一版本 1.18.2 的安装包：arm64 的 APK 44.4MB，32 位 37.5MB，Google Play 那个版本为了兼容所有机型把架构全打进去，122.3MB。
Windows 便携包 24.9MB，解开 63MB。有意思的是主程序 localsend_app.exe 只有 216KB，真正的引擎在别处：flutter_windows.dll 和 rust_lib_localsend_app.dll 各 20MB，data 目录 21MB。图形版空转的时候工作集 125.6MB、私有内存 129.2MB、53 个线程、497 个句柄——对一个只负责传文件的小工具来说，这个开销偏大。
命令行版：0.1 秒起来，只占 15MB
同一个项目还发了个命令行版，Windows 下就是一个 9.27MB 的单文件，不用装运行时。参数只有三个：--alias（设备名）、--port、--destination（收到的东西放哪），也认 LOCALSEND_ALIAS、LOCALSEND_PORT、LOCALSEND_DESTINATION 三个环境变量。
我连着起了三次，从进程启动到打出「Ready to accept requests」分别是 132ms、86ms、128ms。空闲时工作集 15.7MB、私有 4.1MB、14 个线程、231 个句柄；有一个传输请求挂着等确认时是 16.6MB。同样干收发文件的活，内存只有图形版的八分之一，很适合扔在一台常年开着的机器上。
它还带了两个不太出现在说明书里的用法：W+S 把选中的文件变成浏览器能直接下载的链接，W+R 反过来，让同一个网段里的浏览器往这台机器上传。这两个快捷键要真终端才认，我试着挂到管道里喂按键，它读不到。
想用脚本调它的接口，先过证书这关
53317 端口看着像普通的 HTTPS 服务，其实不是。我第一次直接请求，TLS 握手就被打回来了：tlsv13 alert certificate required——它要求客户端也出示证书，是双向认证。
补一张自签证书再请求 GET /api/localsend/v2/info，才拿到正常结果：设备名、版本 2.2、deviceModel 是 Windows、deviceType 是 desktop，外加那个 64 位指纹。所以如果你想写个小脚本往手机推文件，光有 IP 和端口不够，还得先有一份它能接受的证书。
接收端必须有人点一下
协议本身是 prepare-upload 先报文件清单，接收方同意后再逐个 upload。我按这个流程用脚本推了一个 200MB 的测试文件，接收端立刻列出「1 个文件，209.7 MB」，接着是那句 Accept? Y/N/P：Y 接受，N 拒绝，P 接受并配对。
问题就在这里，命令行版没有免确认的开关。它的 config.toml 里只有 alias、port、destination 三项，参数表里也翻不到类似快速保存的选项。想做成无人值守的自动收件箱，目前这条路是堵死的，只能自己照着协议实现一个接收端。
手机上真正容易卡住的几处
- 系统版本：Android 7.0 起，5 和 6 最后支持到 v1.17.0；iOS 13 起。
- 后台被杀：国产系统的电池优化会清掉长期在后台的接收端，接收前把它设成「不受限制」，否则对方已经发起，你这边就是不弹窗。
- 防火墙：53317 的 TCP 和 UDP 都要放行。我换成自定义端口跑的时候，广播包仍然从 53317 发出去，只开自定义那一个端口，很容易变成「显示在线但发现不了」。
- 多网卡和 VPN：它会把每张网卡的地址都监听起来，我这台机器一次列出了三个地址。同时开着 VPN 或虚拟网卡时，广播常常从错的那张网卡走，表现就是两端都开着却互相看不见。
什么时候该用它
同一个 WiFi 下、文件几十兆到几个 G、不想让文件经过任何服务器，这三点满足就用它，比在聊天软件里发大文件靠谱得多，速度也不受宽带上行限制，快慢只取决于路由器和你两端的硬盘。反过来，两端不在同一个网段，或者对面是个不愿意装 App 的人，还是老老实实用网盘省事。
你们在家里是怎么把手机里的东西挪到电脑上的？