2026/9/19 1:12:00
FEATURED · 精选文章 
工位上这台统信UOS台式机网口千兆、27寸屏、键盘手感也好唯一让我别扭的地方是手机里的东西进不来。拍的产品图要用微信文件传输助手倒一手得先登录、再下载、偶尔还给你压一遍用U盘吧插来插去五分钟起步。后来同事在群里丢了句用localsend啊我才算彻底解决了这件事。localsend这个开源小工具干的活很朴素——在同一个局域网里把文件从A设备直接送到B设备不经过任何服务器不用注册账号也不用扫码绑定。但真正用久了你会发现只在传文件这个维度看它其实浪费了它一半的能力。在统信UOS上它可以变成本地剪贴板、变成多设备之间的中转站、变成给好几台机器推配置的通道。下面这些东西是我自己从装、到用、到踩坑、再到折腾配置文件一整条路走下来攒的适合刚上手的新人也适合已经装了但只会拖文件的老用户。1. 先把工具看透它凭什么不需要账号和服务器1.1 两台设备是怎么看见彼此的大部分人第一次用localsend时的反应都是这么简单——打开软件设备列表里就自动蹦出旁边那台手机。这个自动发现不是魔法它靠的是mDNS也就是组播DNS在局域网里往一个固定的组播地址广播我在这里、我叫什么、我用什么端口。同一网段里的其他设备收到这条广播就把它画进列表里。整个发现过程完全在本地网络内完成不查任何外部域名也不上报任何数据。这一步很关键它决定了后面所有玩法能不能成立。因为设备发现依赖组播所以一旦你的网络环境屏蔽了组播——比如公司Wi-Fi开了客户端隔离或者路由器把无线和有线划在了不同子网——设备列表就会一片空白。这不是软件坏了是网络不让它们互相听见。我后面单独用一节讲怎么排查这里你先记住一个结论localsend能不能用第一关永远在网络层不在软件层。再说传输。真正发文件的时候接收端会在53317端口上起一个本地HTTP服务发送端把文件用POST推过去接收端确认收完再落盘。中间走的是标准HTTP语义所以它天然支持分块、支持断点重试也天然可以被抓包分析——这点对排查问题特别有用后面会用到。1.2 53317和mDNS记住这两个东西一半的坑提前躲掉如果你想在这套工具上少走弯路就把这两个数字刻在脑子里组播5353端口53317。5353是mDNS的默认端口决定能不能互相看见53317是localsend自己起服务的端口TCP和UDP两个协议都要放行UDP负责发现TCP负责真正搬数据。很多人遇到的能看见设备但一发就失败十有八九就是只放行了UDP忘了TCP。我自己在这上面栽过一次。当时UOS上开了防火墙规则只加了UDP手机能看到电脑点发送就转圈最后超时报错。加上TCP之后秒过。这种事情在文档里通常不会写因为文档默认你的网络是敞开的但现实里的办公网、宿舍网、实验室网恰恰不敞开。还有一个常被误解的点localsend走的是自签名证书的HTTPS通道所以浏览器里打开https://设备IP:53317会看到证书告警这是正常的。它这么做是为了让传输内容在局域网上不至于完全裸奔但也别指望它提供企业级的安全防护——它的安全模型建立在你信任当前这个局域网之上出了这个前提后面的建议都不成立。2. 在统信UOS上装稳包管理、依赖和开机常驻2.1 deb、AppImage、应用商店三条路怎么选统信UOS底层是Debian系的包管理所以localsend的安装有三条路各有各的脾气。我的建议是分场景选而不是无脑选一个。安装方式优点代价适合谁应用商店安装一键装、自动处理依赖、跟着系统更新版本可能偏旧功能滞后只想安安静静传文件的人deb包安装版本新、进系统菜单、能apt统一管理依赖偶发缺失需要手动补想用新特性、愿意折腾的人AppImage免安装、可放U盘、换机器即用需要FUSE支持托盘行为偶有异常临时用、或者多台机器来回跑的人deb包的安装命令没什么花头注意路径要对cd ~/Downloads sudo apt install ./LocalSend-x.x.x-linux-x86_64.deb如果你的UOS是ARM平台比如某些国产整机一定要下arm64那个包装错了会直接报架构不匹配。用uname -m确认一下比猜靠谱。万不得已用dpkg硬装装完记得补依赖sudo dpkg -i LocalSend-xxx.deb sudo apt install -fAppImage的话先给执行权限再直接跑。UOS上比较常见的问题是FUSE版本不匹配导致挂载失败这时候加个参数绕过去chmod x LocalSend-x.x.x-linux-x86_64.AppImage ./LocalSend-x.x.x-linux-x86_64.AppImage --appimage-extract-and-run--appimage-extract-and-run这个参数值得记住它把AppImage先解压再运行绕开FUSE依赖代价只是启动慢个一两秒。很多国产Linux发行版上跑AppImage报错用这一招都能救回来。2.2 托盘图标不显示基本是缺了这套依赖localsend在Linux上是Flutter打包的它把图标放进系统托盘走的是libappindicator那一套新版本可能是ayatana分支。UOS默认桌面是DDE托盘区域是有的但如果系统里缺了对应的库就会出现程序在跑、进程也在、就是托盘里看不见的情况。这对localsend来说挺致命——你没办法从托盘点开窗口只能去任务管理器杀进程。补依赖就这么一条sudo apt install libayatana-appindicator3-1如果提示找不到包再试老名字sudo apt install libappindicator3-1装完注销重登一次托盘图标基本就回来了。这算是我在UOS上遇到的第一个文档里不写、但一定会踩的点。2.3 让它开机就在autostart的正确写法localsend这类工具的价值在于随手可用如果每次都要去菜单里翻出来打开用两天你就懒得用了。UOS上做开机自启最稳的方式是往~/.config/autostart/里放一个desktop文件mkdir -p ~/.config/autostart nano ~/.config/autostart/localsend.desktop内容大致是这样[Desktop Entry] TypeApplication NameLocalSend CommentLocal network file and text transfer Exec/opt/LocalSend/localsend_app Iconlocalsend Terminalfalse StartupNotifyfalse X-GNOME-Autostart-enabledtrueExec那一行一定要填你机器上真实的可执行文件路径别照抄。deb装的话通常在/opt/LocalSend/下面AppImage就是你放AppImage的那个位置。不确定就先which localsend或者用文件管理器找到那个文件、右键看属性里的完整路径。顺带一个小经验如果你用AppImage并且加了--appimage-extract-and-run那Exec要写成Exec/path/to/AppImage --appimage-extract-and-run参数是要带的否则开机时会静默失败你还以为是自启没生效。3. 隐藏玩法一把它当局域网剪贴板用3.1 文本消息功能的真实定位localsend界面上有个发送文本的入口很多人压根没点过或者点了一次觉得这不就是个聊天框吗就放弃了。它的定位确实不是聊天——没有历史记录、没有消息状态、发完就没了。但它有一个聊天软件给不了的东西它不需要登录、不需要好友关系、不需要经过任何服务器两台在同一Wi-Fi下的设备粘上文字点发送对面上直接就收到了。这个特性在什么场景下最值我自己的高频场景是这几类一是临时要把一段长命令从电脑挪到手机或者反过来微信复制过去会被自动识别成链接、加一堆格式二是要给同事的一台临时设备发个验证码、一串序列号、一段配置三是在没有外网的实验环境里两台机器之间要传一段JSON。这三种情况下localsend的文本发送比任何IM都快因为它没有发送—服务器—接收—下载这条链就一步。当然它也有边界。实测下来几KB到几十KB的文本毫无压力但如果是要粘贴一整份几百KB的日志还是老老实实当文件发更稳毕竟文本消息是放在HTTP body里传的本身不是为大块内容设计的。另外要提醒一句localsend不会自动同步你的系统剪贴板它不是那种复制即同步的神器你必须手动粘进去再点发送。接受这个前提它的效率依然吊打大部分方案。3.2 我的局域网剪贴板工作流我现在的习惯是这样你可以直接抄手机端在浏览器或者任何App里选中文字通过系统的分享菜单直接分享到localsend选目标设备发送。电脑端localsend弹出接收提示点接受文字就落在窗口里我CtrlA、CtrlC粘进终端或者编辑器。反过来电脑上遇到要挪到手机的内容我直接CtrlC切到localsend窗口CtrlV进输入框回车发送。这里面有几个细节能明显提速。第一给每台设备改一个能一眼认出来的名字。默认名字通常是型号随机串家里设备一多列表里三台Linux你根本分不清哪台是自己面前的。设置里改成工位台式客厅笔记本测试机A一次配置长期受益。第二如果只在自己设备之间传打开自动接受或者快速保存省掉每次点确认那一下——别看只省一次点击一天来回几十次体感差别很大。第三也是我觉得最值的一个技巧把localsend的文本输入框当成一个临时暂存区。比如我在一台机器上整理了一份配置片段要分几次粘到另一台机器上我就先整段发过去对面接收后落在窗口里我按需一段一段复制。这比来回切窗口靠谱得多。3.3 图片当剪贴板用截图直传这条路文本之外图片其实是更高频的剪贴板需求。你在电脑上截了个图要发到手机上给人看或者反过来手机上看到个有意思的东西截屏了要放到电脑的文档里。走IM软件要么压缩画质要么得等上传下载localsend在这件事上是压倒性的同一局域网内走的是本地带宽原图不改。具体操作上有个小优化把默认保存目录固定到一个你常用的位置比如~/Pictures/来自手机这样收进来的图不用你再去文件管理器里翻。设置一次后面每次接收都是静默落盘你直接去那个文件夹拿就行。这个改动看起来很小但它把收图这件事从三步变成了一步。另外提一下localsend本身不带截图功能。想要截图即发送的顺畅体验得靠系统截图工具加一次拖拽或者用命令行把截图存到固定目录再手动发。这一块它确实比不上某些深度集成的商业方案但对绝大多数人来说多拖一步换取不压缩、不过服务器、不要账号账是划算的。4. 隐藏玩法二多设备联动把UOS台式机变成中转站4.1 手机拍完就到电脑这条链路怎么铺我这台UOS台式机在局域网里的角色其实慢慢变成了一个中转站——手机、平板、旧笔记本都往它这儿汇总。原因很实际它的硬盘大、有线连接稳、一直开着机。手机这条链路是最有代表性的。安卓端localsend可以注册到系统分享菜单里任何App里的图片、文件、文字分享菜单里都能直接选localsend。用起来就是拍完照、打开相册、选中、分享、选设备、发送五秒内电脑上就出现了原图。这条链路完全不依赖外网所以出差住酒店、在客户现场没网、在实验室内网隔离环境里都一样能用。这一点是它和所有云盘方案的硬差距也是我最看重的部分。实际配置上有两个建议。第一手机端把自动保存到相册打开这样收到的图直接进系统相册不用再进App里找。第二如果你家里设备多给台式机单独设置一个固定的接收目录按设备或者按类型分文件夹长期下来不会乱。4.2 固定下载目录加自动保存省掉每次点确认这一条是我认为localsend最被低估的配置项。默认情况下每次有人给你发东西你都得点一下确认再选保存位置。自己设备之间传这个确认纯粹是浪费时间。不同版本的localsend设置项名字略有出入大意都是这几项一个接收文件的总开关一个自动接受/无需确认的选项还有一个接收目录的路径。把接收目录改成类似~/Downloads/LocalSend这样的固定路径再把自动接受打开前提是你信任当前网络里的人整个接收流程就变成无感了。发过去对面叮一声文件已经在目录里躺好了。需要提醒的是这个开关是有安全前提的——它意味着同一局域网里任何知道设备的人都能往你硬盘里塞东西。我只在家里、在公司自己那台测试机的独立网段里开这个。在咖啡厅、酒店、会议中心的公共Wi-Fi上我一定把它关掉改回手动确认。这个取舍后面单独讲。4.3 断网也能用内网互传真正的价值场景localsend最容易被忽视的一点是它不联网也能用。这句话听起来像是废话但你想想日常有多少传文件的需求其实根本不需要经过互联网——同事之间传个设计稿、手机和电脑之间挪张照片、几台测试机之间同步个安装包。这些事情走云端除了多一层隐私风险还多了上传和下载两段等待。我参与过一个完全离线的部署环境机房内网、没有外网出口几十台机器之间要同步安装包和配置。当时的做法就是拿一台笔记本当分发节点localsend开着自动接收其他机器需要什么就找它要比拿U盘一台一台插快得多。这类场景里localsend的定位就不再是传文件工具而是一个轻量的、零依赖的局域网分发节点。5. 隐藏玩法三当配置分发和产物回收的通道5.1 给多台机器推脚本和配置延续上面的思路localsend在运维类的重复劳动里很好用。举个我自己的例子我手上有一套三台机器的测试环境经常要给它们塞同一份配置文件。以前的做法是scp但前提是SSH通、密钥配好、知道IP、防火墙放行还得一台一台敲。换成localsend之后流程变成在台式机上把配置文件拖进去勾选三台目标设备一次发送三台同时收到都落在相同的固定目录里。它的好处在于降低了对目标机器的要求。你不需要在目标机器上开SSH、不需要配密钥、不需要知道它的IP地址只要它开着localsend并且在同一局域网内就能收。这在给非技术同事的机器传东西时特别明显——你没法要求人家开SSH但让人装个localsend点两下谁都做得到。需要注意的是localsend只负责送到,不负责执行。也就是说推过去的脚本还是得手动跑。想要推完自动执行那得另外想办法localsend本身不提供这个能力别指望它。5.2 回收日志与测试产物分发是单向的一半另一半是回收。测试跑完之后扔出来的一堆日志、截图、报告从多台机器集中到一台机器上localsend同样能干。具体做法是在每台测试机上把输出目录固定成同一个路径跑完测试之后手动把整个目录拖进localsend发到主力机主力机的接收目录也固定。几次下来你就有了一套结果自动归位的流程不需要U盘、不需要共享盘挂载、不需要配SSH。对于规模不大的场景三五台机器、每天跑几轮这套东西的搭建成本几乎为零。这里给一个小提醒发送整个目录之前先看一眼里面有没有大的临时文件、core dump、或者几百MB没清理的原始数据。localsend是逐文件传的目录里塞了个大文件整个发送时间就会被拖长而且中途如果网络抖一下你还得重来。养成先清理再发送的习惯能省掉很多等待。5.3 什么时候该用共享文件夹而不是它localsend不是万能的有些场景它确实不如传统的局域网共享。最典型的是多台机器要长期访问同一份文件——比如一个团队共用一套素材库大家随时读写。这种情况应该用SMB或者NFS共享挂载localsend这种一次性的点对点传输反而不合适你得反复传。我的判断标准很简单**一次性、点对点、不需要长期同步的用localsend长期共享、多人随时读写的用共享挂载。**这两者的边界其实很清楚用错了会觉得工具难用用对了会觉得省事。6. 搜不到设备、传一半断、速度慢三条踩坑链路6.1 设备列表空白按这个顺序查设备列表空白是最常见的问题也是最多人卡住的地方。我的排查顺序是固定的从网络层往应用层走一般五分钟内能定位。现象优先怀疑怎么验证两台设备都开着列表都空不在同一子网或开了客户端隔离各看一遍ip a核对网段是否一致只有某一台看不见另一台那台机器防火墙拦了UDPsudo ufw status或查firewalld规则以前能用突然不行了网络切换后组播被限换回原网络试试或重启路由器列表偶尔出现又消失无线信号弱、丢包换有线试试观察是否稳定具体命令上先确认端口有没有在监听ss -tulnp | grep 53317正常情况下应该能看到TCP和UDP都有。如果什么都没有说明localsend的服务压根没起来那问题在软件本身不在网络。再确认组播是不是通的可以用avahi的工具看一眼avahi-browse -a -t如果你的网络里能看到其他mDNS服务但看不到localsend的广播那大概率是防火墙拦了5353。放开UDP的5353之后设备列表通常立刻就满了。还有一种情况值得单独说有线网卡和无线网卡同时开着。UOS上如果同时连了网线和Wi-Fi而这两个接口分属不同网段localsend的组播可能会从错误的接口发出去导致明明在同一个网里却互相看不见。解决办法是临时禁用其中一个接口或者给两个接口配到同一网段。这个坑我踩过排查了很久才想到是双网卡的问题。6.2 传一半中断的三种典型原因传输中断比搜不到更烦人因为它通常发生在传了几百MB之后。我遇到过三种成因完全不同。第一种是发送端或接收端休眠。笔记本合盖、屏幕锁定后系统进入省电模式网络接口被挂起传输自然断。解决办法是在系统设置里把息屏后不挂起网络打开或者传大文件的时候干脆别让屏幕锁。这条在UOS的电源管理里找。第二种是Wi-Fi信号抖动导致TCP超时。无线传输大文件时如果信号在两个AP之间来回切或者中间隔了两堵墙丢包率一高传输就会卡住甚至中断。判断方法是换成有线再传一遍如果稳如老狗问题就在无线侧。第三种是接收端磁盘空间不足或者权限不对。这个最阴险因为软件不一定给出清楚的提示。接收目录如果指向了一个只读位置或者所在分区快满了传输会在最后一步失败。养成习惯接收目录别放在系统分区单独挂一个数据盘空间留足。6.3 速度实测对比与提升点localsend的速度上限取决于你的物理链路软件本身几乎不是瓶颈。我在自己这套环境里实测过几组数字仅供参考你的环境会有差异链路类型实测速度传1GB大概耗时千兆有线直连同一交换机100~112 MB/s约10秒Wi-Fi 6同房间60~90 MB/s约12~17秒Wi-Fi 5隔一堵墙30~50 MB/s约20~35秒百兆有线10~12 MB/s约90秒从这个表能看出两件事。第一有线永远是首选尤其是台式机插根网线能省掉一大半等待。第二如果速度明显低于上表对应档位先别怀疑软件去看看是不是磁盘在拖后腿——机械硬盘的写入速度有时候会成为瓶颈尤其是小文件很多的时候。还有一个容易忽略的点传大量小文件比传一个大文件慢得多。因为每个文件都要走一次请求确认开销被放大了。如果你要传的是几百个小文件先打个压缩包再发速度能快好几倍这是我强烈建议养成的一个习惯。7. 配置文件怎么改哪些开关只在可信网络开7.1 配置文件在哪儿哪些字段值得动localsend的界面设置已经覆盖了大部分需求但有些东西改配置文件更直接。不同安装方式deb、AppImage、Flatpak配置文件的落点不一样最稳的找法是直接搜find ~ -name settings.json -path *ocalSend* 2/dev/null一般会在.config或者.local/share下面的LocalSend目录里。找到之后先备份再改cp settings.json settings.json.bak值得关注的字段大致是这几类设备名改成人能看懂的、接收目录固定到你的数据盘、自动接受相关开关自己设备之间开、公共网络关、以及是否启用HTTPS。改动之前一定先备份并且改完重启一次程序。不同版本之间字段名会有出入遇到不认识的键不要乱删留着也不影响。有个细节要注意如果你同时装了deb版和留了个AppImage它们可能各自读各自的配置导致你改了A的设置、用的却是B。确认自己平时启动的是哪一个只维护那一份配置。7.2 哪些开关只在可信网络开最后这一节我觉得比前面所有技巧都重要。localsend的安全边界就一句话它信任当前局域网。这意味着任何和你在同一网段里的设备理论上都能发现你、并且在你开了自动接受的情况下往你硬盘里写文件。在家里、在自己公司的独立网段、在实验室的内网这个前提是成立的在咖啡厅、酒店、展会、共享办公空间的公共Wi-Fi上这个前提不成立。所以我的做法是分两套配置按场景切在家和在公司测试网段自动接受打开、接收目录固定、开机自启出门在外自动接受关掉、每次手动确认、用完就退。切换成本只有几次点击但换来的是不用担心硬盘被塞东西。另外别把localsend当成穿透复杂网络的方案它本质上就是个局域网工具跨网段、跨路由、跨公网都不是它的活。想清楚这一点你对它的预期就不会跑偏用起来也就顺了。这套东西我用了大半年从最开始只敢用它传传图片到现在剪贴板、配置分发、日志回收都走它中间踩的坑基本都写在上面的章节里了。真要说还有什么建议那就是别急着一次性把所有配置都打开——先把能搜到设备、能稳定传文件这一层跑通再慢慢加文本、加自动接收、加开机自启。每加一项都验证一下出了问题你知道是哪一步引入的比一口气配完然后到处找原因要轻松得多。
统信UOS玩转LocalSend：局域网剪贴板、多设备中转与配置分发
工位上这台统信UOS台式机网口千兆、27寸屏、键盘手感也好唯一让我别扭的地方是手机里的东西进不来。拍的产品图要用微信文件传输助手倒一手得先登录、再下载、偶尔还给你压一遍用U盘吧插来插去五分钟起步。后来同事在群里丢了句用localsend啊我才算彻底解决了这件事。localsend这个开源小工具干的活很朴素——在同一个局域网里把文件从A设备直接送到B设备不经过任何服务器不用注册账号也不用扫码绑定。但真正用久了你会发现只在传文件这个维度看它其实浪费了它一半的能力。在统信UOS上它可以变成本地剪贴板、变成多设备之间的中转站、变成给好几台机器推配置的通道。下面这些东西是我自己从装、到用、到踩坑、再到折腾配置文件一整条路走下来攒的适合刚上手的新人也适合已经装了但只会拖文件的老用户。1. 先把工具看透它凭什么不需要账号和服务器1.1 两台设备是怎么看见彼此的大部分人第一次用localsend时的反应都是这么简单——打开软件设备列表里就自动蹦出旁边那台手机。这个自动发现不是魔法它靠的是mDNS也就是组播DNS在局域网里往一个固定的组播地址广播我在这里、我叫什么、我用什么端口。同一网段里的其他设备收到这条广播就把它画进列表里。整个发现过程完全在本地网络内完成不查任何外部域名也不上报任何数据。这一步很关键它决定了后面所有玩法能不能成立。因为设备发现依赖组播所以一旦你的网络环境屏蔽了组播——比如公司Wi-Fi开了客户端隔离或者路由器把无线和有线划在了不同子网——设备列表就会一片空白。这不是软件坏了是网络不让它们互相听见。我后面单独用一节讲怎么排查这里你先记住一个结论localsend能不能用第一关永远在网络层不在软件层。再说传输。真正发文件的时候接收端会在53317端口上起一个本地HTTP服务发送端把文件用POST推过去接收端确认收完再落盘。中间走的是标准HTTP语义所以它天然支持分块、支持断点重试也天然可以被抓包分析——这点对排查问题特别有用后面会用到。1.2 53317和mDNS记住这两个东西一半的坑提前躲掉如果你想在这套工具上少走弯路就把这两个数字刻在脑子里组播5353端口53317。5353是mDNS的默认端口决定能不能互相看见53317是localsend自己起服务的端口TCP和UDP两个协议都要放行UDP负责发现TCP负责真正搬数据。很多人遇到的能看见设备但一发就失败十有八九就是只放行了UDP忘了TCP。我自己在这上面栽过一次。当时UOS上开了防火墙规则只加了UDP手机能看到电脑点发送就转圈最后超时报错。加上TCP之后秒过。这种事情在文档里通常不会写因为文档默认你的网络是敞开的但现实里的办公网、宿舍网、实验室网恰恰不敞开。还有一个常被误解的点localsend走的是自签名证书的HTTPS通道所以浏览器里打开https://设备IP:53317会看到证书告警这是正常的。它这么做是为了让传输内容在局域网上不至于完全裸奔但也别指望它提供企业级的安全防护——它的安全模型建立在你信任当前这个局域网之上出了这个前提后面的建议都不成立。2. 在统信UOS上装稳包管理、依赖和开机常驻2.1 deb、AppImage、应用商店三条路怎么选统信UOS底层是Debian系的包管理所以localsend的安装有三条路各有各的脾气。我的建议是分场景选而不是无脑选一个。安装方式优点代价适合谁应用商店安装一键装、自动处理依赖、跟着系统更新版本可能偏旧功能滞后只想安安静静传文件的人deb包安装版本新、进系统菜单、能apt统一管理依赖偶发缺失需要手动补想用新特性、愿意折腾的人AppImage免安装、可放U盘、换机器即用需要FUSE支持托盘行为偶有异常临时用、或者多台机器来回跑的人deb包的安装命令没什么花头注意路径要对cd ~/Downloads sudo apt install ./LocalSend-x.x.x-linux-x86_64.deb如果你的UOS是ARM平台比如某些国产整机一定要下arm64那个包装错了会直接报架构不匹配。用uname -m确认一下比猜靠谱。万不得已用dpkg硬装装完记得补依赖sudo dpkg -i LocalSend-xxx.deb sudo apt install -fAppImage的话先给执行权限再直接跑。UOS上比较常见的问题是FUSE版本不匹配导致挂载失败这时候加个参数绕过去chmod x LocalSend-x.x.x-linux-x86_64.AppImage ./LocalSend-x.x.x-linux-x86_64.AppImage --appimage-extract-and-run--appimage-extract-and-run这个参数值得记住它把AppImage先解压再运行绕开FUSE依赖代价只是启动慢个一两秒。很多国产Linux发行版上跑AppImage报错用这一招都能救回来。2.2 托盘图标不显示基本是缺了这套依赖localsend在Linux上是Flutter打包的它把图标放进系统托盘走的是libappindicator那一套新版本可能是ayatana分支。UOS默认桌面是DDE托盘区域是有的但如果系统里缺了对应的库就会出现程序在跑、进程也在、就是托盘里看不见的情况。这对localsend来说挺致命——你没办法从托盘点开窗口只能去任务管理器杀进程。补依赖就这么一条sudo apt install libayatana-appindicator3-1如果提示找不到包再试老名字sudo apt install libappindicator3-1装完注销重登一次托盘图标基本就回来了。这算是我在UOS上遇到的第一个文档里不写、但一定会踩的点。2.3 让它开机就在autostart的正确写法localsend这类工具的价值在于随手可用如果每次都要去菜单里翻出来打开用两天你就懒得用了。UOS上做开机自启最稳的方式是往~/.config/autostart/里放一个desktop文件mkdir -p ~/.config/autostart nano ~/.config/autostart/localsend.desktop内容大致是这样[Desktop Entry] TypeApplication NameLocalSend CommentLocal network file and text transfer Exec/opt/LocalSend/localsend_app Iconlocalsend Terminalfalse StartupNotifyfalse X-GNOME-Autostart-enabledtrueExec那一行一定要填你机器上真实的可执行文件路径别照抄。deb装的话通常在/opt/LocalSend/下面AppImage就是你放AppImage的那个位置。不确定就先which localsend或者用文件管理器找到那个文件、右键看属性里的完整路径。顺带一个小经验如果你用AppImage并且加了--appimage-extract-and-run那Exec要写成Exec/path/to/AppImage --appimage-extract-and-run参数是要带的否则开机时会静默失败你还以为是自启没生效。3. 隐藏玩法一把它当局域网剪贴板用3.1 文本消息功能的真实定位localsend界面上有个发送文本的入口很多人压根没点过或者点了一次觉得这不就是个聊天框吗就放弃了。它的定位确实不是聊天——没有历史记录、没有消息状态、发完就没了。但它有一个聊天软件给不了的东西它不需要登录、不需要好友关系、不需要经过任何服务器两台在同一Wi-Fi下的设备粘上文字点发送对面上直接就收到了。这个特性在什么场景下最值我自己的高频场景是这几类一是临时要把一段长命令从电脑挪到手机或者反过来微信复制过去会被自动识别成链接、加一堆格式二是要给同事的一台临时设备发个验证码、一串序列号、一段配置三是在没有外网的实验环境里两台机器之间要传一段JSON。这三种情况下localsend的文本发送比任何IM都快因为它没有发送—服务器—接收—下载这条链就一步。当然它也有边界。实测下来几KB到几十KB的文本毫无压力但如果是要粘贴一整份几百KB的日志还是老老实实当文件发更稳毕竟文本消息是放在HTTP body里传的本身不是为大块内容设计的。另外要提醒一句localsend不会自动同步你的系统剪贴板它不是那种复制即同步的神器你必须手动粘进去再点发送。接受这个前提它的效率依然吊打大部分方案。3.2 我的局域网剪贴板工作流我现在的习惯是这样你可以直接抄手机端在浏览器或者任何App里选中文字通过系统的分享菜单直接分享到localsend选目标设备发送。电脑端localsend弹出接收提示点接受文字就落在窗口里我CtrlA、CtrlC粘进终端或者编辑器。反过来电脑上遇到要挪到手机的内容我直接CtrlC切到localsend窗口CtrlV进输入框回车发送。这里面有几个细节能明显提速。第一给每台设备改一个能一眼认出来的名字。默认名字通常是型号随机串家里设备一多列表里三台Linux你根本分不清哪台是自己面前的。设置里改成工位台式客厅笔记本测试机A一次配置长期受益。第二如果只在自己设备之间传打开自动接受或者快速保存省掉每次点确认那一下——别看只省一次点击一天来回几十次体感差别很大。第三也是我觉得最值的一个技巧把localsend的文本输入框当成一个临时暂存区。比如我在一台机器上整理了一份配置片段要分几次粘到另一台机器上我就先整段发过去对面接收后落在窗口里我按需一段一段复制。这比来回切窗口靠谱得多。3.3 图片当剪贴板用截图直传这条路文本之外图片其实是更高频的剪贴板需求。你在电脑上截了个图要发到手机上给人看或者反过来手机上看到个有意思的东西截屏了要放到电脑的文档里。走IM软件要么压缩画质要么得等上传下载localsend在这件事上是压倒性的同一局域网内走的是本地带宽原图不改。具体操作上有个小优化把默认保存目录固定到一个你常用的位置比如~/Pictures/来自手机这样收进来的图不用你再去文件管理器里翻。设置一次后面每次接收都是静默落盘你直接去那个文件夹拿就行。这个改动看起来很小但它把收图这件事从三步变成了一步。另外提一下localsend本身不带截图功能。想要截图即发送的顺畅体验得靠系统截图工具加一次拖拽或者用命令行把截图存到固定目录再手动发。这一块它确实比不上某些深度集成的商业方案但对绝大多数人来说多拖一步换取不压缩、不过服务器、不要账号账是划算的。4. 隐藏玩法二多设备联动把UOS台式机变成中转站4.1 手机拍完就到电脑这条链路怎么铺我这台UOS台式机在局域网里的角色其实慢慢变成了一个中转站——手机、平板、旧笔记本都往它这儿汇总。原因很实际它的硬盘大、有线连接稳、一直开着机。手机这条链路是最有代表性的。安卓端localsend可以注册到系统分享菜单里任何App里的图片、文件、文字分享菜单里都能直接选localsend。用起来就是拍完照、打开相册、选中、分享、选设备、发送五秒内电脑上就出现了原图。这条链路完全不依赖外网所以出差住酒店、在客户现场没网、在实验室内网隔离环境里都一样能用。这一点是它和所有云盘方案的硬差距也是我最看重的部分。实际配置上有两个建议。第一手机端把自动保存到相册打开这样收到的图直接进系统相册不用再进App里找。第二如果你家里设备多给台式机单独设置一个固定的接收目录按设备或者按类型分文件夹长期下来不会乱。4.2 固定下载目录加自动保存省掉每次点确认这一条是我认为localsend最被低估的配置项。默认情况下每次有人给你发东西你都得点一下确认再选保存位置。自己设备之间传这个确认纯粹是浪费时间。不同版本的localsend设置项名字略有出入大意都是这几项一个接收文件的总开关一个自动接受/无需确认的选项还有一个接收目录的路径。把接收目录改成类似~/Downloads/LocalSend这样的固定路径再把自动接受打开前提是你信任当前网络里的人整个接收流程就变成无感了。发过去对面叮一声文件已经在目录里躺好了。需要提醒的是这个开关是有安全前提的——它意味着同一局域网里任何知道设备的人都能往你硬盘里塞东西。我只在家里、在公司自己那台测试机的独立网段里开这个。在咖啡厅、酒店、会议中心的公共Wi-Fi上我一定把它关掉改回手动确认。这个取舍后面单独讲。4.3 断网也能用内网互传真正的价值场景localsend最容易被忽视的一点是它不联网也能用。这句话听起来像是废话但你想想日常有多少传文件的需求其实根本不需要经过互联网——同事之间传个设计稿、手机和电脑之间挪张照片、几台测试机之间同步个安装包。这些事情走云端除了多一层隐私风险还多了上传和下载两段等待。我参与过一个完全离线的部署环境机房内网、没有外网出口几十台机器之间要同步安装包和配置。当时的做法就是拿一台笔记本当分发节点localsend开着自动接收其他机器需要什么就找它要比拿U盘一台一台插快得多。这类场景里localsend的定位就不再是传文件工具而是一个轻量的、零依赖的局域网分发节点。5. 隐藏玩法三当配置分发和产物回收的通道5.1 给多台机器推脚本和配置延续上面的思路localsend在运维类的重复劳动里很好用。举个我自己的例子我手上有一套三台机器的测试环境经常要给它们塞同一份配置文件。以前的做法是scp但前提是SSH通、密钥配好、知道IP、防火墙放行还得一台一台敲。换成localsend之后流程变成在台式机上把配置文件拖进去勾选三台目标设备一次发送三台同时收到都落在相同的固定目录里。它的好处在于降低了对目标机器的要求。你不需要在目标机器上开SSH、不需要配密钥、不需要知道它的IP地址只要它开着localsend并且在同一局域网内就能收。这在给非技术同事的机器传东西时特别明显——你没法要求人家开SSH但让人装个localsend点两下谁都做得到。需要注意的是localsend只负责送到,不负责执行。也就是说推过去的脚本还是得手动跑。想要推完自动执行那得另外想办法localsend本身不提供这个能力别指望它。5.2 回收日志与测试产物分发是单向的一半另一半是回收。测试跑完之后扔出来的一堆日志、截图、报告从多台机器集中到一台机器上localsend同样能干。具体做法是在每台测试机上把输出目录固定成同一个路径跑完测试之后手动把整个目录拖进localsend发到主力机主力机的接收目录也固定。几次下来你就有了一套结果自动归位的流程不需要U盘、不需要共享盘挂载、不需要配SSH。对于规模不大的场景三五台机器、每天跑几轮这套东西的搭建成本几乎为零。这里给一个小提醒发送整个目录之前先看一眼里面有没有大的临时文件、core dump、或者几百MB没清理的原始数据。localsend是逐文件传的目录里塞了个大文件整个发送时间就会被拖长而且中途如果网络抖一下你还得重来。养成先清理再发送的习惯能省掉很多等待。5.3 什么时候该用共享文件夹而不是它localsend不是万能的有些场景它确实不如传统的局域网共享。最典型的是多台机器要长期访问同一份文件——比如一个团队共用一套素材库大家随时读写。这种情况应该用SMB或者NFS共享挂载localsend这种一次性的点对点传输反而不合适你得反复传。我的判断标准很简单**一次性、点对点、不需要长期同步的用localsend长期共享、多人随时读写的用共享挂载。**这两者的边界其实很清楚用错了会觉得工具难用用对了会觉得省事。6. 搜不到设备、传一半断、速度慢三条踩坑链路6.1 设备列表空白按这个顺序查设备列表空白是最常见的问题也是最多人卡住的地方。我的排查顺序是固定的从网络层往应用层走一般五分钟内能定位。现象优先怀疑怎么验证两台设备都开着列表都空不在同一子网或开了客户端隔离各看一遍ip a核对网段是否一致只有某一台看不见另一台那台机器防火墙拦了UDPsudo ufw status或查firewalld规则以前能用突然不行了网络切换后组播被限换回原网络试试或重启路由器列表偶尔出现又消失无线信号弱、丢包换有线试试观察是否稳定具体命令上先确认端口有没有在监听ss -tulnp | grep 53317正常情况下应该能看到TCP和UDP都有。如果什么都没有说明localsend的服务压根没起来那问题在软件本身不在网络。再确认组播是不是通的可以用avahi的工具看一眼avahi-browse -a -t如果你的网络里能看到其他mDNS服务但看不到localsend的广播那大概率是防火墙拦了5353。放开UDP的5353之后设备列表通常立刻就满了。还有一种情况值得单独说有线网卡和无线网卡同时开着。UOS上如果同时连了网线和Wi-Fi而这两个接口分属不同网段localsend的组播可能会从错误的接口发出去导致明明在同一个网里却互相看不见。解决办法是临时禁用其中一个接口或者给两个接口配到同一网段。这个坑我踩过排查了很久才想到是双网卡的问题。6.2 传一半中断的三种典型原因传输中断比搜不到更烦人因为它通常发生在传了几百MB之后。我遇到过三种成因完全不同。第一种是发送端或接收端休眠。笔记本合盖、屏幕锁定后系统进入省电模式网络接口被挂起传输自然断。解决办法是在系统设置里把息屏后不挂起网络打开或者传大文件的时候干脆别让屏幕锁。这条在UOS的电源管理里找。第二种是Wi-Fi信号抖动导致TCP超时。无线传输大文件时如果信号在两个AP之间来回切或者中间隔了两堵墙丢包率一高传输就会卡住甚至中断。判断方法是换成有线再传一遍如果稳如老狗问题就在无线侧。第三种是接收端磁盘空间不足或者权限不对。这个最阴险因为软件不一定给出清楚的提示。接收目录如果指向了一个只读位置或者所在分区快满了传输会在最后一步失败。养成习惯接收目录别放在系统分区单独挂一个数据盘空间留足。6.3 速度实测对比与提升点localsend的速度上限取决于你的物理链路软件本身几乎不是瓶颈。我在自己这套环境里实测过几组数字仅供参考你的环境会有差异链路类型实测速度传1GB大概耗时千兆有线直连同一交换机100~112 MB/s约10秒Wi-Fi 6同房间60~90 MB/s约12~17秒Wi-Fi 5隔一堵墙30~50 MB/s约20~35秒百兆有线10~12 MB/s约90秒从这个表能看出两件事。第一有线永远是首选尤其是台式机插根网线能省掉一大半等待。第二如果速度明显低于上表对应档位先别怀疑软件去看看是不是磁盘在拖后腿——机械硬盘的写入速度有时候会成为瓶颈尤其是小文件很多的时候。还有一个容易忽略的点传大量小文件比传一个大文件慢得多。因为每个文件都要走一次请求确认开销被放大了。如果你要传的是几百个小文件先打个压缩包再发速度能快好几倍这是我强烈建议养成的一个习惯。7. 配置文件怎么改哪些开关只在可信网络开7.1 配置文件在哪儿哪些字段值得动localsend的界面设置已经覆盖了大部分需求但有些东西改配置文件更直接。不同安装方式deb、AppImage、Flatpak配置文件的落点不一样最稳的找法是直接搜find ~ -name settings.json -path *ocalSend* 2/dev/null一般会在.config或者.local/share下面的LocalSend目录里。找到之后先备份再改cp settings.json settings.json.bak值得关注的字段大致是这几类设备名改成人能看懂的、接收目录固定到你的数据盘、自动接受相关开关自己设备之间开、公共网络关、以及是否启用HTTPS。改动之前一定先备份并且改完重启一次程序。不同版本之间字段名会有出入遇到不认识的键不要乱删留着也不影响。有个细节要注意如果你同时装了deb版和留了个AppImage它们可能各自读各自的配置导致你改了A的设置、用的却是B。确认自己平时启动的是哪一个只维护那一份配置。7.2 哪些开关只在可信网络开最后这一节我觉得比前面所有技巧都重要。localsend的安全边界就一句话它信任当前局域网。这意味着任何和你在同一网段里的设备理论上都能发现你、并且在你开了自动接受的情况下往你硬盘里写文件。在家里、在自己公司的独立网段、在实验室的内网这个前提是成立的在咖啡厅、酒店、展会、共享办公空间的公共Wi-Fi上这个前提不成立。所以我的做法是分两套配置按场景切在家和在公司测试网段自动接受打开、接收目录固定、开机自启出门在外自动接受关掉、每次手动确认、用完就退。切换成本只有几次点击但换来的是不用担心硬盘被塞东西。另外别把localsend当成穿透复杂网络的方案它本质上就是个局域网工具跨网段、跨路由、跨公网都不是它的活。想清楚这一点你对它的预期就不会跑偏用起来也就顺了。这套东西我用了大半年从最开始只敢用它传传图片到现在剪贴板、配置分发、日志回收都走它中间踩的坑基本都写在上面的章节里了。真要说还有什么建议那就是别急着一次性把所有配置都打开——先把能搜到设备、能稳定传文件这一层跑通再慢慢加文本、加自动接收、加开机自启。每加一项都验证一下出了问题你知道是哪一步引入的比一口气配完然后到处找原因要轻松得多。 
