LocalSend：没有中心服务器的局域网文件传输方案
LocalSend 通过本地网络在附近设备之间传输文件和消息，无需中央服务器。
秒懂
- 它是什么？
- LocalSend 是一个基于 REST API 与 HTTPS 的跨平台文件传输工具，所有通信都在本地网络完成，不依赖互联网或第三方服务器。本文从架构、运行方式、平台适配和实际限制几个角度评估它是否适合你的使用场景。
- 适合谁用？
- LocalSend 适合经常在可信局域网内跨设备传输文件、又不想依赖云服务的个人用户和小团队。它不适合需要跨网段传输、要求集中管理或审计的场景，也不适合对实时性要求极高的消息通信。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Dart（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题
局域网内传文件，常见做法是开一个共享文件夹，或者用聊天软件中转。前者依赖操作系统权限设置，后者要求双方都有互联网连接。LocalSend 的目标是让同一局域网内的设备直接互传文件和消息，不需要互联网，也不需要任何中央服务器。它的适用人群很明确：在办公室、实验室或家庭网络里，经常在手机、电脑、平板之间交换文件的人。这类人往往受够了蓝牙的速度和配对流程，又不愿意把文件传到云端再下载。LocalSend 用 REST API 和 HTTPS 加密通信，避免了明文传输的风险。它不是一个通用的消息应用，它的核心场景就是文件传输，消息只是附带功能。
通信机制：REST API 加 HTTPS
LocalSend 的通信机制在 README 里写得很清楚：设备之间通过 REST API 交换数据，传输层使用 HTTPS 加密。这意味着每台设备既是客户端又是服务器，发送方和接收方都运行着同一个应用，各自暴露一个 HTTPS 端点。当设备 A 向设备 B 发送文件时，A 直接向 B 的本地 IP 地址发起请求，B 验证后接受或拒绝。整个过程不经过任何中转节点，所以没有单点故障，也没有服务商能窥探传输内容。这个设计有一个直接后果：所有设备必须在同一个可路由的局域网内，跨网段或跨 VLAN 的场景很难工作。另外，HTTPS 需要证书，LocalSend 如何处理证书信任关系，README 没有详细说明，这是采用前需要自己验证的部分。
安装与运行：多渠道但无自动更新
LocalSend 的安装方式覆盖了主流平台。Windows 上可以用 winget、Scoop、Chocolatey，或者从 GitHub Releases 下载 EXE 安装包和便携版 ZIP。macOS 用户可以从 App Store 或 Homebrew 安装，也有 DMG 安装包。Linux 发行版用户有 Flathub、Snap、AUR、Nixpkgs 等多个选择，还能下载 TAR、DEB、AppImage 格式。Android 用户可以从 Play Store、F-Droid 或直接安装 APK，iOS 用户只能走 App Store。README 特别提醒：应用没有自动更新机制，建议从应用商店或包管理器安装，以便获得版本更新。这在安全方面是个实际问题，因为如果依赖 GitHub Releases 手动下载，很容易错过安全修复。
平台兼容性：从 Android 5 到 Windows 7 的边界
兼容性表给出了明确的下限。Android 最低支持 5.0，iOS 要求 12.0，macOS 要求 11 Big Sur，Windows 要求 10。这里有一个值得注意的细节：Windows 7 的最后一个支持版本是 v1.15.4，之后的新版本不再支持 Win7，README 提到未来可能会有针对 Win7 的 backport，但这不是承诺。Linux 没有版本下限，但有依赖要求：Gnome 桌面需要 xdg-desktop-portal 和 xdg-desktop-portal-gtk，KDE 需要 xdg-desktop-portal 和 xdg-desktop-portal-kde。这意味着在精简版 Linux 系统上，如果缺少这些 portal 组件，文件传输可能无法正常工作。macOS 用户如果使用旧款 Mac，可能需要借助 OpenCore Legacy Patcher 才能满足系统要求。
命令行接口：自动化场景的可能性
README 的目录里有一个 Command Line Interface 章节，但提供的材料被截断了，没有给出具体命令示例。这本身就是一个信息缺口。从项目性质推断，CLI 可能允许用户在脚本里触发文件发送或接收，这对于服务器或 NAS 上的自动化任务有价值。但因为没有具体文档，我不能确认 CLI 支持哪些参数，是否支持批量发送，或者是否能作为后台服务运行。如果你有这类需求，需要直接查看仓库里的文档或源码。这个不确定性也提醒我们：LocalSend 的图形界面是主要交互方式，CLI 更像是一个附加功能，而不是核心能力。
防火墙与网络配置：最常见的故障点
README 在 Setup 一节提到，大多数情况下应用开箱即用，但如果发送或接收文件失败，可能需要配置防火墙允许 LocalSend 在本地网络通信。这句话背后是一个实际限制：LocalSend 依赖设备间的直接 TCP 连接，任何拦截局域网流量的安全软件都会阻断它。企业网络通常有严格的防火墙策略，个人电脑上的第三方安全套件也可能默认阻止未知应用的入站连接。这意味着在受管网络环境中，LocalSend 可能根本无法工作，除非管理员放行相关端口。另外，由于没有中心服务器，设备发现机制也是基于局域网广播或类似方式，如果网络禁用了广播或多播，设备可能互相看不到。具体使用哪些端口和协议，README 没有列出，需要从源码或问题追踪中查证。
维护成本与许可证
LocalSend 使用 Apache-2.0 许可证，这是一个宽松的开源许可证，允许商用、修改和再分发，只要保留版权声明。项目的活跃度可以从最近的发布记录看出：v1.18.2 在 2026 年 8 月 21 日发布，v1.18.1 和 v1.18.0 分别在 8 月 12 日和 10 日发布，说明维护节奏较快。但维护成本不在项目方，而在使用者。因为没有自动更新，你需要自己跟踪新版本，或者依赖包管理器。对于个人用户，这不算大问题；对于企业部署，这意味着需要建立手动更新流程。另外，官方明确警告有一个非官方的 MSIX 预览构建站点，稳定性不保证，这说明社区有第三方构建，但你应该避免在生产环境使用。
替代方案与适用边界
与 LocalSend 形成对比的典型工具是 Snapdrop，它同样通过浏览器在局域网内传输文件，但依赖 WebRTC 和信令服务器（虽然可以自托管）。两者的核心差异在于：LocalSend 是原生应用，设备之间直接建立 HTTPS 连接，不需要浏览器，也不依赖 WebRTC 的协商过程；Snapdrop 则更轻量，无需安装应用，但需要所有设备都能访问同一个信令服务器。如果你的设备上不方便安装应用，Snapdrop 可能更合适；如果你需要离线环境或完全避免外部服务器，LocalSend 更符合要求。另一个替代方案是使用操作系统自带的文件共享，比如 SMB 或 AirDrop，但前者配置复杂，后者仅限苹果生态。LocalSend 的跨平台特性是它的主要优势，但这也意味着它无法像 AirDrop 那样深度集成系统级能力。
编辑结论
LocalSend 适合经常在可信局域网内跨设备传输文件、又不想依赖云服务的个人用户和小团队。它不适合需要跨网段传输、要求集中管理或审计的场景，也不适合对实时性要求极高的消息通信。采用前应确认：目标设备系统版本是否满足最低要求，尤其是 Windows 7 用户只能停留在 v1.15.4；Linux 桌面需要安装 xdg-desktop-portal 相关组件；防火墙必须放行本地网络通信。另外，项目没有自动更新机制，需要通过应用商店或包管理器手动维护版本。如果你能接受这些条件，LocalSend 是一个结构简单、协议透明的选择；如果你需要跨公网传输，则应该考虑其他工具。
社区笔记