传文件这件小事,为什么总在绕远路

手机里的照片要导进电脑,会议室里两台笔记本要互相拷素材,客户现场只有内网没有外网,却急着把一个几百兆的文件送出去。这些场景里,微信会压缩画质,网盘要先上传再下载,数据线又常常认不出设备。绕过这些弯路其实有个更直接的思路:既然两台设备就待在同一个局域网里,为什么不让它们直接对话。

LocalSend 就是顺着这个思路做出来的工具。它免费、开源、跨平台,用 REST API 加 HTTPS 完成传输,不依赖互联网,也不经过任何第三方服务器。

和常见方式比,差在哪里

对比项云盘中转聊天软件LocalSend 局域网直传
是否需要互联网需要需要不需要
文件是否被处理一般不压缩,但常限速图片视频默认压缩原文件直传
文件大小限制受会员额度约束有明确上限只受存储与带宽限制
数据经过哪里云服务商的服务器第三方服务器只在两台设备之间
速度上限上传与下载带宽下载带宽接近局域网的实际速率

一个容易被忽略的前提:它的快,来自局域网本身

先分清两个概念。局域网指同一个路由器下的小范围网络,家里、办公室、会议室的 Wi-Fi 都属于这一类;互联网则是这些局域网彼此连接起来的更大网络。LocalSend 只在前者里工作,数据不出这张网,所以既没有上传下载的两趟往返,也不受外网带宽的限制。

这也解释了一个现象:同一份文件,用网线连接的两台电脑之间能跑到每秒几十兆,而隔着几堵墙、信号只剩一格时就慢得让人想放弃。这里的瓶颈是无线电和网卡,不是软件。理解了这一点,后面遇到的速度问题大多能自己想通。

LocalSend 到底是什么

一句话定位

它是一款开源、免费、跨平台的局域网文件与文本传输工具,常被称作"开放版的 AirDrop"。同一网络里的设备可以互相发现,然后把文件、整个文件夹,甚至一段文本直接推过去,全程无需注册账号,也不需要任何中心服务器。

一组可以核对的事实

项目情况
开源许可证Apache-2.0,源码公开可审计
最新稳定版本1.18.2,发布于 2026 年 8 月
支持平台Windows、macOS、Linux、Android、iOS
通信端口TCP 与 UDP 的 53317
商业化无广告、无追踪、无会员,也没有账号体系

官方下载与安装

认准这两个官方渠道

安装包请从官方渠道获取。官网的下载页是 LocalSend 官方下载页,里面按系统列出了安装包与包管理器命令;源码和全部历史版本则放在 GitHub 仓库 与它的 Releases 页面。

需要留意的是,LocalSend 自身没有自动更新功能,所以官方更推荐从应用商店或系统自带的包管理器安装,后续升级会省事很多。另外,官方发布包体积不大,Windows 版通常十几兆,如果下到的文件明显偏大,就要多留个心眼。

各平台怎么装

平台推荐安装渠道最低系统要求
Windowswinget、Chocolatey、Scoop、微软商店,或官网的 exe 安装包与便携版 zipWindows 10;Windows 7 只能用 v1.15.4 及更早版本
macOSHomebrew,或官网的 dmg 镜像,或 Mac App StoremacOS 11 Big Sur
LinuxFlatpak、Snap、deb、rpm、AppImage主流发行版,需系统自带 xdg-desktop-portal 组件
AndroidGoogle Play、F-Droid,或官网的 apk 安装包Android 7.0;Android 5 与 6 最后支持到 v1.17.0
iOSApp StoreiOS 12.0

用一条命令装好

如果你习惯命令行,下面这几条可以按系统各取所需:

# Windows:用 winget 安装
winget install localsend

# macOS:用 Homebrew 安装
brew install --cask localsend

# Linux:用 Flatpak 安装
flatpak install flathub org.localsend.localsend_app

Linux 上如果下载的是 deb 包,sudo dpkg -i localsend_*.deb 就能装上;AppImage 版本则先赋予执行权限再双击运行。

它是怎么工作的

把"零配置"这三个字拆开看,其实就是三件事各自找到了省事的做法。

设备发现:在同一张网里互相喊话

每台运行 LocalSend 的设备都会定期向局域网内发送一条小小的广播包,里面带着自己的名字、类型和端口,相当于在同一个频道里喊了一声"我在这儿"。听到喊声的设备就把对方加进"附近设备"列表,整个过程不需要扫码,也不需要手动输入 IP。

问题在于,不是所有网络都放行这种广播。公司统一发的访客网络、某些手机热点,常常把组播报文拦得干干净净,这时候就会看到设备列表空着。LocalSend 为此准备了兜底手段:直接扫描本网段内的常见地址主动探测,实在不行还可以手动填写对方的 IP 与端口,或者用一端生成二维码、另一端扫描的方式建立直连。这正是它的设计目标——发现失败不等于传输失败。

传输通道:自签证书也很认真

设备互相看见之后,真正的文件传输走 HTTPS 加密通道。这里的证书不是由权威机构签发的,而是每台设备启动时现场生成的。很多人一看到"自签名"就皱眉,其实 HTTPS 的安全性并不取决于证书由谁签发,而在于密钥是否掌握在自己手里、传输是否加密、身份能否被验证。

LocalSend 的做法是三者都占:私钥留在本机不出门,传输内容全程加密,设备之间在建立连接前会比对证书指纹,指纹对不上就拒绝连接。换句话说,加密这一步不需要联网去验证身份,这也是它"断网也能安全传文件"的底气。

引擎:界面归 Flutter,重活归 Rust

界面层由 Flutter 负责,这保证了五个平台上的操作逻辑和长相基本一致;而底层网络与文件读写的核心在 1.18.0 版本完成了 Rust 重写,实测传输速度有明显提升。Rust 的异步运行时把加密这类耗时计算放到后台,文件也不是整块读进内存再发送,而是分块流式传输——所以传一个几 GB 的镜像文件,内存占用依然很低,中低端手机也不会卡顿。

第一次互传:四步走通

  1. 在收发两端都装好 LocalSend,并连上同一个 Wi-Fi 或同一个路由器
  2. 首次运行时允许应用访问局域网;Windows 弹出防火墙询问时选择允许,或在防火墙里放行 TCP 与 UDP 的 53317 端口
  3. 在发送端点"发送",添加文件,或把文件直接拖进窗口,然后在下方的"附近设备"列表里点选目标设备
  4. 接收端弹出确认框,点接受后开始传输,界面会实时显示进度与速度

反方向操作完全一样。手机传电脑、电脑传手机、电脑传电脑,角色随场景切换,没有主从之分。

几个真正好用的功能

整个文件夹直接发

LocalSend 把文件夹当作可发送单元,选中整个目录就能发,接收端会保留原有的目录结构。传一批照片或者一个完整项目目录时,省掉了先压缩、再解压的一来一回。

对方不装软件也能收到你的文件

1.18.0 版本加入了"通过链接接收"。接收端点一下这个按钮,会生成一个地址或二维码;发送方只要有浏览器,打开地址、把文件拖进去就能上传,对方根本不用安装 LocalSend。临时给访客、给只有一台没装软件的手机传东西,这个入口非常实用。

收藏设备自动接收

经常互传的两台设备可以互相收藏,收藏之后对方发来的文件会默认自动接收,省掉每轮都要点一次确认的麻烦。前提是你确定这台设备是自己常用的,在公共场所不要开这个功能,否则任何人都可能往你机器上塞东西。

命令行版本

1.18.0 版本首次发布了命令行客户端,用同一个 Rust 核心库实现,主要面向没有图形界面的场景——比如一台长期待机、根本没接显示器的旧笔记本,或者一台小型 Linux 主机。通过 SSH 连进去运行即可:

# 查看所有可用选项与快捷键
localsend-cli --help

# 发送多个文件或整个目录,运行时在设备列表里交互选择目标
localsend-cli send report.pdf photo.jpg ./project-backup

# 直接指定目标设备的别名或 IP,跳过交互式列表
localsend-cli send --to "Cute Tomato" report.pdf

# 只发一段文本,接收后可直接粘贴使用
localsend-cli --text "这段内容会出现在对方的剪贴板里"

对这类无屏设备来说,它的价值很直接:以前想往里丢个文件只能靠远程拷贝命令,现在手机端像平常一样选中设备发送就行。

安全这件事,需要说清楚

一个已经修复的高危漏洞

2025 年公开的 CVE-2025-54792 值得单独提一句。在 1.16.1 及更早版本中,发现协议存在中间人攻击问题:同一局域网内的攻击者可以冒充合法设备,静默拦截、读取甚至篡改传输中的文件。该漏洞在 1.17.0 版本中被修复。

结论很简单:把 LocalSend 升级到 1.17.0 以上,最好直接用最新的 1.18.x。这不是软件本身"不安全",而是任何网络软件都会经历的常规修补,关键在于及时更新。

自签证书不等于不安全

前面已经解释过,自签证书只是身份验证方式不同,加密强度并不打折。它真正的薄弱环节在用户侧:如果第一次连接时懒得核对指纹,理论上存在被冒充的空间。在完全信任的家庭网络里,这个风险可以接受;在酒店、咖啡馆这类陌生网络里,多花两秒看一眼指纹是值得的。

局域网不等于安全网络

很多人默认"内网 = 安全",这是一个需要纠正的直觉。同一个 Wi-Fi 下可能坐着你不认识的设备,公司访客网络里更是鱼龙混杂。LocalSend 默认开启加密,正是为了应对这种情况。

还有一点经常被忽略:设置里提供了关闭加密的选项,关掉之后传输速度会有小幅提升。这个开关的价值在于,你可以在自己完全信任的、有线的家庭网络里打开它换一点性能;但在任何不确定的环境里,都别去碰它。

传不动时,按这个顺序排查

绝大多数问题卡在"设备列表是空的"这一步,先确认两台设备连的确实是同一个网络,再往下核对。

现象常见原因处理办法
设备列表空白两台设备不在同一网段确认连的是同一个 Wi-Fi 或同一个路由器
设备列表空白路由器开启了 AP 隔离或客户端隔离在路由后台关闭该选项,访客网络尤其常见
设备列表空白防火墙拦截了 53317 端口在系统防火墙里放行 TCP 与 UDP 的 53317
设备列表空白广播被网络策略阻断改用扫码,或手动填写对方 IP 与端口
Windows 收不到文件网络类型被设成了公用在系统设置里改为专用网络
Mac 与 iPhone 互相搜不到本地网络权限未开启在隐私设置里给 LocalSend 开启本地网络
传到一半失败链路波动,或中间设备有拦截策略改用有线,或靠近路由器重试
速度忽快忽慢处在拥堵的 2.4GHz 频段尽量使用 5GHz 频段或网线

速度预期,与它不适合的场景

在混合系统的实测里,LocalSend 的吞吐大约在每秒二十多兆到四十多兆之间;两端都是笔记本的组合能跑到四十几兆,而涉及手机的组合往往慢一些,这时瓶颈通常在手机的无线硬件上,而不是协议本身。有线千兆环境下,跑出更快的数字也不奇怪。作为对照,AirDrop 在苹果设备之间确实更快,因为它能建立设备之间的直连链路,但它出了苹果生态就用不了,这恰恰是 LocalSend 存在的理由。

至于它不适合什么场景,也说清楚:它不做跨公网的远程传输。给另一个城市的朋友发文件、需要生成一个长期有效的下载链接、或者要把文件集中归档到某台服务器,这些都不是它的任务范围,用云盘或对象存储更合适。它的定位很纯粹——把同一张网里的两台设备连起来,快、稳、不留痕。

结语

判断一款工具值不值得长期用,可以看它能不能让一个动作变得更短。LocalSend 把"传文件"这件事压缩成了三步:装好、连同一个网、点一下对方。没有账号要注册,没有上传要等待,没有压缩要忍受。对经常在手机、电脑、平板之间搬运素材的人来说,省下的不只是几分钟,还有反复切换工具的那份烦躁。

发表评论

验证码图片,点击可更换