ARTICLE · 1310110
安卓和 Windows 互传文件,别再发微信文件传输助手了
办公室里最常见的画面之一：同事手里是安卓手机，电脑是 Windows，两个之间传一个 300MB 的安装包。
可选方案就那么几个。数据线——找线、插上、系统不认、装驱动。微信文件传输助手——超过 100MB 传不了，而且文件要先上传到腾讯的服务器再回到你手上。网盘——先传上去，再等下下来，来回两趟。U 盘——那你得先找到 U 盘。
LocalSend 解决的就是这个场景。它的官方描述很直接：一份不依赖互联网、不依赖第三方服务器的局域网传文件工具。
01 一句话定位：它把 AirDrop 的做法开源了
技术上的说法是：LocalSend 用一套 REST API 在自己和对方设备之间建立一个点对点连接，走的是 HTTPS 加密，TLS 证书由每台设备在本地临时生成，不经过任何中间服务器。
翻译成人话：两台设备各自在自己家里开个门，直接对着传，中间没有快递站。
它支持 Windows、macOS、Linux、Android、iOS、Fire OS 六个平台，Apache-2.0 全开源，目前在 GitHub 上有 9.4 万星。
几个值得注意的事实：
- 通信端口是固定的 53317，TCP 和 UDP 都要开
。这是它最常见的翻车点，后面单独说； - 没有自动更新
。官方推荐用包管理器或应用商店安装，就是为了让更新走各自的渠道； - 要求不低
：Android 7.0+、iOS 13+、macOS 11 (Big Sur)+、Windows 10+。还在 Windows 7 上的话，最后一个支持版本是 v1.15.4。
还有一个时间线上的细节值得说。翻它的 Release 记录会发现：
v1.16.1 — 2024 年 11 月 - v1.17.0 — 2025 年 2 月
- v1.18.0 — 2026 年 8 月
v1.18.1 — 2026 年 8 月 - v1.18.2 — 2026 年 8 月 21 日（当前版本）
也就是说 v1.17.0 到 v1.18.0 之间有将近一年半的空档。项目没有停，但节奏明显是「平时修补、隔很久发一个大版本」。选它做日常依赖没问题，但别指望它像活跃项目那样每周出补丁。
02 实测：把它拆开，看看到底装了什么
这一节是我这次花时间最多的地方。我下载了官方 Release 里的 LocalSend-1.18.2-windows-x86-64.zip，先核对 Content-Length 确认没有下载截断，再逐条统计包内文件。
压缩包 24.9 MB，解压后 62.4 MB，59 个条目。体积构成如下：
图片说明：LocalSend Windows 版拆包实测的体积构成与文件数量。
这里有两个反常识的点。
第一，它是一个 Flutter 应用。flutter_windows.dll 19.85 MB、data/app.so 15.33 MB，这两个加起来就占了 56%。Flutter 的好处是一套代码跑六个平台，代价就是每个平台都要背一份渲染引擎——这也是它相比系统原生应用体积偏大的原因。
第二，网络协议层是独立编译的 Rust 动态库。rust_lib_localsend_app.dll 19.33 MB。也就是说这个软件是双运行时：界面走 Dart/Flutter，传文件这件事走 Rust。Rust 那部分负责的是局域网发现、TLS、流式传输这些真正吃性能的活。
这是好事也是代价：好处是传输层能做得足够硬；代价是包体积下不来，而且两个运行时各有一套。
顺手确认一件事：包里没有 Electron、没有内嵌浏览器内核、没有 node_modules。它的 62MB 全是自己的代码和 Flutter 运行时，不是「把网页打包成桌面应用」。这一点在同类工具里算相当干净了。
03 实测：在终端里起一个接收端
LocalSend 在 v1.18.2 的 Release 里还发了一个命令行版（LocalSend-CLI-1.18.2-windows-x86-64.exe，9.28 MB）。这个是这次实测里最有意思的部分。
一条命令就能起一个接收端：
localsend-cli.exe --alias recv-box --port 53318 \ --destination ./ls-recv跑起来之后它把该说的信息全说了：
图片说明：LocalSend CLI 实测启动输出，包含设备别名、端口、接收目录、配置路径与本机监听地址。
几个观察：
- 监听地址直接列出本机所有网卡的 IP
—— 192.168.1.151是局域网卡，192.168.56.1是虚拟网卡。这个输出非常有用于排障：如果你发现自己的局域网 IP 不在这个列表里，那说明它绑错网卡了； - 协议是 HTTPS
，不是 HTTP。TLS 证书本地生成，所以浏览器访问会报证书不受信任——这是设计如此，不是故障； - 配置文件放在
~/.config/localsend-cli，和桌面版各存各的，不会互相打架； 支持 W+S（分享给浏览器下载）和W+R（让浏览器上传）两个热键，也就是说它能临时变成一个网页收件箱，不用在对方设备上装软件。
措辞说明：本节是 CLI 真实运行的记录。桌面 GUI 版我没有在本机跑（这台机器没有可截图的桌面环境），所以关于界面的描述下面会明确标注来源。
04 实测：一次真实的失败，和它说明了什么
既然 CLI 能跑，我顺手试了一件事：在同一台机器上开两个实例，一个当发送端、一个当接收端，看能不能互传。
结论是：不成立。
发送端打开设备列表，里面是空的：
┌Devices──────────────────────────────────┐ │ Paired (none) │ │ Discovered (none) │ └──────────────────────────────────────────┘原因不难理解：LocalSend 的设备发现依赖局域网多播，而同一台机器上的两个进程不会互相收到对方的多播通告。这条路的正确用法是跨设备——手机和电脑、两台电脑之间。
顺着这个结果我又试了一件事：既然它对外是 HTTPS，那能不能用普通客户端直接怼它的接口？
也不能。用 curl -k 访问它的 53318 端口，TLS 握手阶段就被拒了；换 Python 的标准 ssl 库也是一样，连接被对端直接断掉。
这两个失败其实说清了 LocalSend 的定位：
它不是一个开放的 HTTP 接口，而是一套带证书校验的自有协议。对方必须是 LocalSend 客户端——或者至少是按它协议 v2 实现的客户端——才能对话。好处是外面随便扫端口的人摸不到你的东西；代价是「用脚本给它推文件」这条路基本走不通。
另外还发现一个文档上的落差：GitHub main 分支的 README 里写着 localsend-cli send --to "设备名" 文件 这种子命令写法，但我实测的 v1.18.2 命令行版并没有 --to 参数——它是用 -f 打开设备列表、按编号或回车选择。v1.18.2 那个 tag 的 README 里甚至还没有「命令行」这一整节。
结论：CLI 这块还在快速迭代，README 跑在发布版前面。照着文档敲命令报错，不一定是你的问题。
05 官方界面长什么样
下面是官方仓库 README 里引用的界面截图，来源是项目官网 localsend.org：
图片说明：LocalSend 官方产品截图（来源 localsend.org），桌面端主界面。
界面本身很朴素：上面是发送 / 接收两个入口，中间是发现到的设备列表，每台设备显示名称和系统图标。没有账号、没有登录、没有云同步入口。
「没有账号体系」这件事值得强调——它是这个工具最大的优点，也是最容易被忽略的取舍。好处是装完即用、没人记录你传了什么；代价是没有任何跨网络的能力。你和对方不在同一个局域网里，它就完全无能为力。
06 装之前要过的几道关
这部分是网上同类文章基本不写、但决定你能不能真正用起来的内容。
第一关：端口。 LocalSend 固定用 53317，而且 TCP 和 UDP 都要放行。防火墙只开 TCP 是最常见的错误——设备能看见但传不动，或者干脆互相发现不了。
入站 TCP+UDP 53317 Allow 出站 TCP+UDP Any Allow第二关：路由器的 AP 隔离。 很多路由器（尤其访客网络）默认开着「AP 隔离」，它会禁止同一个 WiFi 下的设备互相通信。这个开关会让 LocalSend 彻底不可用，因为它所有的通信都是设备到设备。表现是：两台设备都在线，但互相看不见。
第三关：Windows 的网络类别。 Windows 对「公用网络」比「专用网络」严格得多。如果当前 WiFi 被识别成公用网络，入站连接会被挡。把网络改成「专用」是最直接的解法。
第四关：VPN。 有 VPN 在跑的时候，很多客户端会默认屏蔽局域网流量。表现同样是设备互相看不见。要么临时关掉，要么在 VPN 里放行局域网。
第五关：加密带来的速度损失。 官方 troubleshooting 里自己承认了两条：推荐用 5GHz；以及两边都关掉加密会更快。也就是说，加密不是免费的，它在传输速度上有明确成本。
另外两个实用设置：
- 便携模式
：在可执行文件同一个目录里放一个空的 settings.json，配置就会存到那里而不是系统目录——这是把 LocalSend 放 U 盘里随身带的正确姿势； - 启动即隐藏
： localsend_app.exe --hidden可以只驻留托盘，不开窗口。
07 什么时候别用它
第一，跨网络它就是废的。 不在同一个局域网（你在公司、对方在家）时，LocalSend 完全帮不上忙。它解决的是「离得近」这件事，不是「离得远」。需要跨网传文件请另找方案。
第二，不要拿它传敏感数据给不该拿的人。 它的传输是加密的、不经过服务器，这点很好；但接收端由对方控制，文件落到哪里、留多久，都不是你能决定的。
第三，企业网络里可能直接被禁。 多播发现 + 固定端口，是很多企业网络策略里重点管控的行为。你在公司能不能用，取决于网管，不取决于工具。
第四，没有自动更新带来的是责任转移。 官方明确推荐走 Winget / Scoop / Chocolatey / 应用商店安装，原因就是它自己不更新。直接下 zip 用的人需要自己盯版本——安全修复不会自动到你手上。
第五，Android 端的传输速度有已知问题。 官方 troubleshooting 表里直接挂了一条「Speed too slow / Android」，链接指向一个 Flutter 侧的 issue。也就是说安卓接收大文件慢，是已知的、尚未解决的问题，不是你手机的问题。
第六，它不适合当同步工具。 LocalSend 是「选中一批文件、发过去、结束」的一次性动作，没有双向同步、没有增量、没有断点续传的自动恢复。你想要的是同步，该看的是 Syncthing 那一类。
08 总结评价
推荐指数：⭐⭐⭐⭐☆（4.5/5）
扣的半星在两点：Android 端传输速度的已知问题，以及跨网络完全不可用。
一句话评价：在「两台设备就在旁边、要传个几百兆」这个具体场景里，LocalSend 是体验最干净的那一个——不登录、不上传、不中转。
适用人群：
安卓和 Windows / macOS / Linux 之间需要频繁互传文件的 对「文件不经过第三方服务器」有实际要求的 想在多台设备（含手机）上装同一个工具、不想学两套操作的 需要在别人的设备上临时建一个网页收件箱、又不想让人装软件的
不适用人群：
需要跨网络传文件（异地、跨公司）的 想要的是双向同步、自动增量备份的 对更新节奏和安全补丁有严格合规要求的团队 还在 Windows 7 或 Android 6 这类老系统上的（已停止支持）
资料来源：
LocalSend 项目仓库：https://github.com/localsend/localsend （Apache-2.0，Dart，94,336 星 · 2026-10-14 复核） LocalSend Release v1.18.2：https://github.com/localsend/localsend/releases/tag/v1.18.2 LocalSend 协议文档：https://github.com/localsend/protocol 官方界面截图来源：https://localsend.org/img/screenshot-pc.webp 本文实测环境：Windows 11；实测内容为官方 Windows 包拆解与官方 CLI 二进制真实运行
💬 你现在手机和电脑之间传文件用什么？有没有过那种「明明在同一个 WiFi 却传不动」的经历？留言区聊聊。
如果这篇对你有用，点个赞和在看，转给那个还在用数据线传文件的同事。
