LocalSend 是一个开源跨平台局域网文件传输工具解决的实际问题很明确多台设备接入同一个 Wi-Fi 后不依赖外部服务器、不需要注册账号、不需要把文件绕到公网再下载直接通过本地网络点对点传输。我在办公室、家庭网络和临时测试环境里重新完整跑了一遍它的安装、单文件传输、批量发送和故障排查下面按实际操作顺序展开。如果你经常在电脑、手机、平板之间互传文件又不想用数据线、不想传聊天工具二次转存这个项目值得认真试一次。1. 先搞清楚 LocalSend 解决的是哪一类问题1.1 它和网盘、聊天工具传文件的本质区别很多人第一次听说 LocalSend第一反应是“这跟微信、QQ、网盘有什么区别”。区别非常大。微信传文件需要两端在线、登录同一个账号体系文件先到服务器再转发网盘需要先上传再分享别人拿到链接后还要再从服务器拉一遍。在这个过程中文件数据会经过第三方服务器还可能受到单个文件大小、格式、下载速度的限制。LocalSend 的路径不是这样。它要求两台设备在同一局域网内可以互相访问发送端直接把数据推给接收端接收端确认后落到本地磁盘。整个过程不需要外部服务器中转。这也解释了为什么它的名字叫 Local Send重点在 Local。它不是一个云端同步盘也不是聊天软件的文件助手而是一个本地网络内的点到点传输工具。把这个定位看清楚后续很多设置和故障就好理解了。1.2 最适合它的三个场景我把平时使用中比较契合的场景分成三类。第一类是办公网络内传文件。同一个办公室、同一个 Wi-Fi 或同一台交换机下电脑和手机之间传一个不大不小、又不想走聊天工具的文件直接用 LocalSend 比较省事。文件不经过外部服务也不会有“下载还要登录”的尴尬。第二类是实验室或开发环境。测试机、开发机、服务器之间传配置文件、日志包、安装包机器都在同一个内网。使用 LocalSend 可以不用临时架一个 HTTP 服务传完即走。对于临时环境这个优势非常明显。第三类是家庭网络。手机拍了几十张照片或几段视频要导到电脑上整理数据线又不方便。两台设备连同一个路由器的 Wi-Fi用 LocalSend 批量接发比插线、开网盘都要直接。1.3 它不擅长的事情需要把话说在前面。LocalSend 只适合两端在同一局域网且都可以在线的场景。如果接收方不在线或者两台设备不在同一个可互通的网段它就不能保证完成任务。它不能替代离线存储也不能解决跨网段同步。如果你在地铁上想把文件传到家里的电脑这不在 LocalSend 的能力范围内。很多人误以为“不需要互联网”等于“不需要网络”其实它仍然需要本地网络可互通只是不需要外网。这个前提会在后面反复出现。换句话说它是一种“局域网内点对点”的方案不是远程访问工具也不是网盘方案。2. 安装和启动前准备不同设备怎么拿到客户端2.1 桌面端安装要点LocalSend 的客户端覆盖 Windows、macOS、Linux同时也覆盖 Android 和 iOS。桌面端安装时最需要注意的不是下载动作而是“包来源”和“运行权限”。正常情况下去应用商店或官方仓库的 Releases 页面下载对应系统的安装包即可。Windows 上如果本机开了 Windows 防火墙第一次启动可能会弹出允许网络访问的提示。这里不要直接取消应该允许应用在专用网络上通信。如果选错了后面会出现设备搜索不到或者能搜到但发送失败的情况。macOS 首次打开需要到“系统设置 → 隐私与安全性”中允许应用运行。原因很简单它需要监听本地网络端口来接收文件。如果你拒绝了这个权限程序可以打开但网络功能不生效。更麻烦的是有些用户会反复卸载重装但权限设置不一定被重置最后还是需要在系统设置里手动打开。Linux 环境更灵活但发行版众多依赖也可能不一致。一般从官方 Releases 下载 AppImage 或 deb 包执行时要确认文件有可执行权限。磁盘空间紧张时也要留意因为接收目录默认写在用户目录下长时间传输容易占用较多空间。2.2 手机端安装和权限确认手机端安装后第一次进入应用可能不会马上弹权限提示。真正发送或接收时系统会要求授予本地网络权限。Android 和 iOS 在权限管理上略有区别但方向一致必须允许应用访问本地网络。这里要特别提醒Android 12 以后系统对应用发现其他设备、创建本地连接的权限管理更严格iOS 从 14 开始也有“本地网络”权限弹窗。如果之前误点了拒绝需要去系统设置里找到 LocalSend手动打开本地网络权限。只卸载重装不一定有用因为权限设置有时会保留。更好的做法是先在系统设置中修改权限再回应用测试。注意如果在系统权限里之前点过“不允许”光重装应用不一定能解决问题去系统设置手动打开本地网络权限更直接。手机端还有一个常见问题后台限制。某些手机品牌为了省电会把长时间后台运行的应用杀掉。LocalSend 在接收文件时如果应用被系统杀死任务就会失败。要做批量接收或大文件接收建议保持应用在前台或者把 LocalSend 加入后台运行白名单。这是很多人在传输中途失败后最容易忽略的原因。2.3 从源码构建的路径只建议两种人使用从源码构建只建议两种人尝试一种是想在官方包不支持的平台上使用另一种是开发者想改功能或研究协议。如果只是普通使用没必要折腾源码。源码构建需要先准备好 Flutter 开发环境再拉取官方仓库最后执行flutter run在当前设备上运行。整个过程对网络、依赖版本都有要求。官方仓库地址以 GitHub 上的 localsend/localsend 为准Clone 之后先看 README 和当前分支说明再按文档构建。如果 Flutter 环境没配好很容易卡在依赖下载环节而且报错不一定是应用本身的问题。单纯为了传文件下载官方安装包比构建源码快得多。3. 第一次局域网传输从小文件到全流程验证3.1 两个设备连同一个 Wi-Fi 是前提开始第一次传输之前我建议先做一个非常基础的判断发送端和接收端是否在同一个局域网内。最简单的判断方法是在两台设备上分别查看 IP 地址确认前三位网段是否一致。比如一台是192.168.1.10另一台是192.168.1.23通常说明它们在同一个局域网。如果一个是192.168.1.x另一个是10.0.0.x即使连的是同一个路由器也可能因为不同网段导致发现失败。这里顺便提一个容易被误解的点手机热点也可以作为局域网环境。手机和电脑都连同一个热点只要热点没有开启“AP 隔离”之类的设备隔离功能两台设备之间就能互通。但如果用的是公共 Wi-Fi、公司访客网络很多路由器会隔离终端设备之间不能互相访问LocalSend 就会找不到目标。出现这种情况时不要一上来就怪应用先确认网络能否互通。3.2 最小流程二维码扫描、发送、接收、确认第一次验证我建议拿一个很小的文件比如一张手机截图或 1MB 以内的任意文件先把全流程跑通。具体步骤可以这样安排。第一步在发送端打开 LocalSend选择要发送的文件界面会进入等待接收方确认的状态同时显示一个二维码和本机设备名/IP。第二步在接收端打开 LocalSend如果系统没有禁用摄像头权限通过“扫描二维码”功能扫描发送端的二维码。扫描成功后接收端会看到发送方的设备信息匹配到对应的发送请求。第三步接收端确认接收。这里有一个很关键的设计接收方不是收到文件后自动乱存而是会看到一个接收确认请求确认后文件才会保存。这么做虽然在体验上多了一步但能避免同一局域网下其他设备往你手机里塞文件。第四步等待进度条走完。发送端会看到完成状态接收端会在对应目录里看到文件。到这里第一次传输就成功了。3.3 文件传完之后要确认哪些信息成功不等于结束。我一般会在传完第一个文件后额外做三件小事。第一检查接收文件的大小是否和源文件一致特别是图片、压缩包这类二进制文件。如果大小对不上说明传输过程可能有截断或异常。第二确认文件被保存到了哪个目录。LocalSend 默认通常放在系统下载目录下的 LocalSend 文件夹里但如果你在设置里改过接收目录路径可能不同。不确认路径后面找文件时会浪费时间。第三再看一眼传输耗时。如果 1MB 的文件耗了几分钟基本可以判断 Wi-Fi 协商速率、信号强度或设备磁盘写速有问题。这个时候应该继续排查网络而不是急着发大文件。这一轮全部通过说明安装、权限、网络和基本协议都没有问题。接下来再处理批量文件会顺畅很多。4. 关键参数和设置别只装完就传4.1 设备名称、接收目录和快速保存正常使用前可以把几个关键设置过一遍避免后面每次传输都被同一件事卡住。设备名称在设置里改成自己能认出来的名字比如“Windows 办公机”“iPhone 14”“实验室 Linux”。因为局域网的发现列表显示的是设备名如果所有设备都叫默认名字传文件时很容易选错接收方。这不仅是体验问题也是防止误传的关键。接收目录设置里可以指定保存位置。桌面端建议放到一个用户目录明显的位置比如 Downloads/LocalSend。手机端也建议先想清楚默认目录。接收目录如果指向系统保护的路径或没有写权限的路径传输会一直处于接收中最后超时失败。这个问题在 Mac 上尤其明显很多人会把目录指向 iCloud 同步目录结果文件写入了但同步延迟还以为传输失败。快速保存这个选项适合自己可控的设备之间开启。打开后接收端不用手动点击确认收到请求就直接保存。它的好处是快坏处是局域网上其他设备也能直接给你推文件。如果是在办公室或公共环境不建议开启。我自己一般在“家庭内部设备”或“测试机之间”使用这个功能。4.2 端口、传输协议和“谁负责谁”的关系LocalSend 在启动后需要监听一个本地端口默认端口通常为 53317。这个信息普通用户不需要背下来但排查问题时会用到。如果端口被占用或者防火墙拦截了监听接收端就无法接收任务。遇到“能看到设备但发不过去”的情况可以先看看日志里是否提到端口绑定失败。传输过程不是靠广播把文件发给所有人。发送端先通过发现机制找到接收端的地址和端口然后向接收端发起请求接收端确认后再由发送端把数据传输过去。也就是说发送端和接收端之间建立的是点到点连接。理解了这一点你就知道为什么接收端不能完全离线因为文件不是先放在某个中间服务器上等接收方上线后再下载。4.3 发现机制为什么能看到设备为什么看不到LocalSend 的设备发现方式同时依赖局域网广播和本机信息查询。因此如果你能通过 IP 直连但不能通过发现列表看到设备不一定是应用坏了更可能是网络中的广播报文没有到达对方设备。常见原因有几个第一设备不在同一 VLAN 或网段广播隔离导致发现失败。第二交换机或路由器开启了端口隔离。第三系统防火墙拦截了相关协议。第四手机系统权限没开。建议排查顺序是先看两台设备 IP 是否同网段再关一方防火墙测试再看系统隐私权限最后看网络设备是否隔离终端。对于 Windows 机器尤其要注意“网络配置文件类型”。如果连接被系统识别为“公用网络”默认防火墙策略更严格把网络配置文件切换为“专用网络”LocalSend 接收请求被拦截的概率会小很多。不要一看到防火墙弹窗就点允许然后发现问题依旧因为问题可能出在公/专用网络分类上。4.4 每次传输前的选择文本、文件还是批量LocalSend 不只是发文件。它支持发送文本片段、文件以及多个文件界面里通常会有对应入口。第一次使用的时候可以把文本发送也测一遍。这个场景很实用临时从电脑发一段 Wi-Fi 密码、一段命令、一个网址给手机省得打开聊天软件或者手输一遍。发送文本和发送文件在流程上基本一致但接收端收到文本后不是保存成文件而是直接在界面上展示内容。如果文本内容较长注意接收端屏幕展示和复制是否正常。批量发送则是把多个文件一次提交给接收端。这里我建议先传 2 到 3 个小文件确认接收端能按顺序接收并保存再增加数量。不要一上来就发几十个文件或者一个大文件夹。LocalSend 的单任务处理能力在多数场景下足够但大批量传输对接收端的磁盘写入、内存、系统休眠策略都有要求。尤其当接收端是低配置手机或旧电脑时连续大量保存容易让系统进入高负载状态。5. 批量文件、多设备和扩展用法5.1 多文件发送的正确方式多文件发送时建议在发送端选择完文件后先核对一下文件名列表再点确认发送。我见过很多次因为文件名重复或包含特殊字符接收端保存时出现同名覆盖、后缀异常的问题。如果两个文件同名接收端可能会自动改名也可能报错具体要看版本和系统文件策略。更稳妥的做法是发送前在源目录里统一重命名或者把文件先打包成一个压缩包再发送。接收端这边批量文件会按顺序保存。如果接收目录空间不足任务会卡在某个文件上。所以在批量任务开始前先查看接收设备剩余存储空间。特别是手机剩余空间不足时大文件传输很容易失败而且不一定每次都会给出明确提示。注意批量发送不是同步复制所有文件都依赖接收端逐份接收。发送前先检查接收端磁盘剩余空间和系统休眠策略能减少一半的失败概率。5.2 多设备同时传输时的优先级同一台设备同时接收多个发送端的文件理论上可以但实际体验要看设备和网络条件。如果接收设备是电脑一般问题不大如果接收设备是手机多个请求同时进来界面会堆很多确认弹窗手动确认时容易点错。这里我建议把多设备传输拆成“先后顺序”。可以先让 A 设备发送完成再让 B 设备发送。如果是同一批设备之间的固定任务可以考虑开启快速保存但要先确认接收端不会收到无关设备推送。否则自动化带来的便利可能变成误收文件的风险。5.3 给开发者准备的扩展思路如果你想在自己的小程序、脚本或企业内部系统里集成文件接收能力LocalSend 也留了扩展空间。它本身是开源项目核心协议可以阅读源码理解。对普通开发者最直接的方式是查看官方仓库里的接口说明和配置定义了解设备发现、传输请求、状态码这些内容然后写脚本模拟发送端或接收端。不过我不建议新手从零去抓协议。更现实的路径是先把官方客户端用熟再考虑用命令行、脚本或 API 方式集成。官方文档更新得比较快具体接口定义要以你当前使用的版本文档为准。如果你只是要在公司内网批量推送安装包可以先测试手动的批量发送是否稳定再考虑封装成工具。6. 常见故障排查按现象找原因6.1 设备搜不到网段、AP 隔离、权限、防火墙设备搜不到是最常见的问题。按优先级排查顺序是先确认两台设备在同一 Wi-Fi 下且 IP 网段一致再确认网络不是公共 Wi-Fi 访客网络或局域网设备隔离没有开启接着检查接收端系统防火墙和本地网络权限最后看应用是否在后台被系统杀掉。有一个容易忽略的测试方法如果两台设备都能联网可以通过查看路由器后台的设备列表确认两台设备的 IP 地址。如果其中一个设备连在访客网络另一个连在主人网络它们大概率不能互通。普通用户直接看应用日志会更友好。Windows 上如果搜不到先到防火墙设置里看 LocalSend 是否有“允许公用网络”的权限如果之前弹窗时选了取消需要手动添加允许规则或卸载重装。6.2 文件一直卡住或失败磁盘、路径、系统休眠文件传输到一半卡住优先怀疑四个地方接收端磁盘空间不足、接收目录权限不对、系统休眠导致网络连接中断、文件名路径不兼容。先看磁盘空间最简单。再确认接收目录是否有写权限。Windows 下如果接收目录指向一个需要管理员权限才能写入的文件夹LocalSend 可能一直保存失败。macOS 如果接收目录被放在 iCloud 同步目录也可能出现写入延迟。最后再看系统休眠策略。如果你用的是一台笔记本电脑盖子一合或系统进入睡眠传输必定中断。接收大文件时我通常会临时把电源计划设为从不睡眠或者至少在传输期间盯着屏幕。6.3 速度很慢Wi-Fi 频段、信号强度、干扰速度慢不是 LocalSend 的锅大多是网络质量问题。先看 Wi-Fi 信号满不满。如果设备与路由器之间隔墙速率会掉得很明显。再看是 2.4GHz 还是 5GHz 频段。2.4GHz 穿墙好但速率低还容易受蓝牙和其它家电干扰5GHz 速率高但距离稍远就可能信号不稳定。如果两台电脑之间传文件速度只有一两 MB/s先换一个位置把两台设备都放在离路由器更近的地方再观察。不要一直调 LocalSend 参数应用层面并没有“加速”开关。真正决定传输速度的是两端网卡协商速率和网络链路质量。这里可以打开路由器管理界面看当前连接速率和设备信号强度帮助定位是距离问题还是频段问题。6.4 程序报错日志、端口、版本如果 LocalSend 直接报错或闪退先看应用自带日志。很多桌面端版本在设置里能看到日志目录或导出日志按钮。报错信息里如果出现端口相关说明监听端口被占用或防火墙拦截。如果出现 SSL 或证书相关不用太紧张本地点到点加密偶尔会因为系统时间不对或证书缓存产生问题先同步系统时间然后再试。最后再检查版本。不同平台的版本更新节奏未必一致旧版本连不上新版本的情况也会出现。如果涉及跨版本互传优先把两端都升级到当前最新稳定版再重新测试。确定依赖版本后再考虑是不是系统权限或网络环境问题。7. 边界、坑点和长期使用建议7.1 哪些网络环境不适合 LocalSend以下几种环境LocalSend 使用体验不会好。第一公共 Wi-Fi 或公司默认访客网络。这类网络通常禁止终端互访开启隔离后设备之间连不上。第二网络里有多层 NAT设备连接在不同路由器下面虽然看起来都连着网但实际不在一个可互通的局域网。第三接收端设备不允许驻留后台比如手机息屏后应用被杀任务便会中断。第四对文件保密性要求极高的环境即使 LocalSend 有点到点加密你仍然需要确认接收端设备和网络环境可靠。本地点对点传输不代表可以乱收文件。把这些边界看清楚你就不会把 LocalSend 当成万能传文件工具。它的优势只在“局域网内、设备在线、网络可互通”这个范围里。7.2 低配置、老系统、多设备并存怎么看低配置设备能不能用我的判断是能启动就能做基本传输但不要期望它同时处理大量高并发任务。旧手机、老笔记本用来传几个文件没问题但连续传几十个文件时磁盘 I/O 和内存占用会明显上升。遇到设备卡住时先看 CPU、内存和磁盘占用而不是只盯着传输进度条。老系统方面如果是官方支持的平台和系统版本按官方要求安装即可。如果是非官方支持的老版本系统可以从源码构建或使用兼容版本但稳定性要自己承担。很多问题看起来是应用 bug实际是系统 TLS 库、防火墙策略或文件系统兼容性导致的。多设备并存时建议给每台设备设置独立且能识别的名称。传输任务多的时候先在接收端确认设备名再发送。不要靠 IP 猜尤其是在 DHCP 分配地址容易变化的环境里。7.3 我对它是否适合日常使用的最终判断如果只给一个结论我认为 LocalSend 适合作为日常局域网传文件的常规工具。原因是它把“发现设备、建立连接、传输文件、接收确认”这个流程做得很完整而且跨平台覆盖广。虽然它不是网盘、不是云同步但在“电脑传给手机、手机传给电脑、笔记本传给另一台台式机”这些高频场景里比数据线、聊天工具或临时搭 HTTP 服务方便很多。长期使用时建议把设备命名、接收目录、快速保存开关和防火墙权限提前设置好。真正落地时最该盯住的不是功能列表而是接收端是否在线、存储路径是否可写、网络是否允许设备互访。这些基础条件管理好LocalSend 在大多数局域网环境里都能稳定完成任务。