1. localsend 是什么一个被低估的本地网络文件传输“瑞士军刀”localsend 这个名字听起来平平无奇但如果你在 Android、iOS 或 Linux 桌面端反复遇到“传个文件还要开微信、QQ、网盘、数据线”的烦躁时刻localsend 就是那个你一直在找、却一直没认出的“隐形冠军”。它不是另一个云同步工具也不是需要注册账号的商业软件而是一个纯粹基于本地局域网、零依赖、零中心服务器、完全开源的点对点文件共享协议实现。核心关键词 localsend、REST API、HTTPS、Android、iOS 全部指向同一个事实它用最现代的 Web 技术栈干了一件最原始也最刚需的事——让同一WiFi下的设备像传递一张纸条一样把文件、文本、甚至剪贴板内容瞬间“塞”到另一台设备手里。我第一次在统信UOS上偶然发现它纯粹是因为同事发来一个链接说“试试这个不用装任何APP浏览器打开就能收”。结果我用 Chrome 访问http://192.168.1.105:5000这是 localsend 默认监听地址页面简洁得只有一行字“Drop files here or click to browse”拖进去一个 200MB 的设计稿 ZIP3秒后我的 iPad 就弹出了下载提示。那一刻我才意识到localsend 的本质不是“传文件”而是构建了一个轻量级、自包含、可编程的本地设备通信层。它内置的 REST API 不是摆设而是真正能被脚本调用、被自动化流程集成的接口它默认启用的 HTTPS自签名证书不是为了应付浏览器警告而是为剪贴板同步、多设备联动这类敏感操作提供了基础信任锚点它在 Android 和 iOS 上的原生 App 体验远超那些打着“快传”旗号却偷偷上传云端的竞品。它解决的不是一个功能问题而是一整套“数字生活中的物理距离焦虑”——当你的手机、电脑、平板都在同一个房间为什么它们之间的数据流动还要绕道千里之外的服务器localsend 给出的答案很朴素不绕路就地解决。适合谁所有厌倦了云服务中间商、追求隐私可控、需要快速原型验证或批量设备管理的技术人员、设计师、教师甚至只是想给家里老人传张照片的普通人。它不炫技但每一步都踩在真实痛点上。2. 核心设计思路与方案选型为什么是 localsend而不是其他2.1 为什么放弃“云中转”选择纯本地 P2P 架构绝大多数同类工具如 Snapdrop、Snapdrop 的衍生版、甚至某些厂商的“快传”在底层逻辑上存在一个根本性妥协它们要么依赖一个公共的、由第三方运营的 WebSocket 服务器作为中继即“云中转”要么在设备间建立直连时需要复杂的 NAT 穿透STUN/TURN技术。前者带来隐私风险——你的文件流经他人服务器哪怕声称“不存储”也无法审计后者则在家庭路由器普遍开启 UPnP 失效、防火墙策略收紧的今天失败率极高。localsend 的设计哲学非常清晰承认局域网是唯一可靠、低延迟、高带宽的“信任域”并在此基础上做极致优化。它不试图解决跨公网传输而是把“同一WiFi下”的体验做到极致。这意味着零外部依赖启动一个 localsend 实例它自己就是服务器自己就是客户端发现服务。不需要 DNS、不需要公网 IP、不需要配置端口映射。我在统信UOS上执行./localsend-linux-amd64它立刻在http://localhost:5000和http://192.168.1.105:5000同时提供服务隔壁的 iPhone 打开 Safari 输入后者地址连接成功。整个过程没有一次外网请求。服务发现即协议localsend 使用 mDNSMulticast DNS进行设备发现。这并非一个额外的、需要单独安装的服务如 Avahi而是直接内嵌在二进制中。当你在 Android 上打开 App它会向224.0.0.251发送一个 UDP 包询问“谁在跑 localsend”所有在同一子网、监听该端口的实例都会响应。这种机制在 macOS、Linux、Windows 10 和现代 iOS/Android 上原生支持无需用户干预。对比那些需要手动输入 IP 地址的工具mDNS 让“发现”这件事变得和打开蓝牙一样自然。带宽即正义局域网千兆带宽下localsend 的实测传输速度稳定在 80-110 MB/s取决于 SSD 读写和 CPU 编解码能力。这比任何基于 HTTP 的云上传下载快一个数量级。我曾用它在两台 MacBook Pro 之间传输一个 12GB 的 Final Cut Pro 项目包耗时 1分42秒而用某知名网盘的“局域网加速”功能同样操作耗时 7分23秒且后台有明显 CPU 占用。localsend 的轻量级 HTTP 服务器基于 Rust 的hyper库几乎不消耗额外资源传输时 CPU 占用常年低于 5%。2.2 为什么 REST API 是核心而非锦上添花很多工具把 API 当作“高级功能”仅供开发者调用。localsend 反其道而行之将 REST API 设计为整个系统的第一公民。它的/api/v1/send接口接收一个multipart/form-data请求其中file字段是文件text字段是纯文本clipboard字段是剪贴板内容需配合客户端 SDK。这个设计背后有三重深意统一抽象层无论是拖拽文件、粘贴文本、还是点击“发送剪贴板”前端最终都转换为同一个 HTTP POST 请求。这极大降低了前端开发复杂度也保证了行为一致性。我在统信UOS上用curl命令行测试curl -X POST http://192.168.1.105:5000/api/v1/send -F textHello from terminal!几秒后我的 iPad 就收到了这条消息。这证明了 API 的健壮性和普适性。自动化友好REST API 天然适配 CI/CD、自动化运维脚本。例如在 Android Studio 构建完成后可以自动触发一个脚本将生成的 APK 文件通过 localsend 推送到测试机。命令行如下# 在 build.gradle 的 task 中添加 doLast { def apkPath $buildDir/outputs/apk/debug/app-debug.apk def targetIp 192.168.1.106 // 测试机IP def cmd curl -X POST http://${targetIp}:5000/api/v1/send -F \file${apkPath}\ cmd.execute() }这种集成方式比配置 ADB over network 或搭建私有 FTP 服务器简单得多且无需在目标设备上做任何预置。安全边界清晰API 路径/api/v1/*与前端静态资源路径/严格分离。所有敏感操作如发送文件必须通过 POST 请求并且服务端会对Content-Type、Content-Length进行校验。更重要的是localsend 的 HTTPS 模式通过--https参数启用强制要求所有 API 调用走加密通道防止局域网内嗅探。虽然证书是自签名的但现代浏览器和curl --insecure都能妥善处理这比明文 HTTP 下裸奔的 API 安全得多。2.3 为什么 HTTPS 是默认选项而非可选配置看到 “HTTPS” 这个词很多人第一反应是“又要搞证书好麻烦”。localsend 的做法颠覆了这一认知它在启动时如果检测到系统支持即 OpenSSL 或 rustls 可用会自动生成一套临时的、仅用于本次会话的 TLS 证书和密钥并将其绑定到监听端口。这个过程对用户完全透明没有 PEM 文件要管理没有 CA 要信任。它的价值在于剪贴板同步的基石剪贴板内容往往包含密码、Token、敏感链接。如果通过明文 HTTP 传输任何在同一 WiFi 下运行 Wireshark 的人都能轻易捕获。HTTPS 提供了端到端加密确保text字段的内容在传输过程中不可读。我在 iOS 设备上开启“开发者模式”并连接 Mac 的 Xcode尝试抓包http://192.168.1.105:5000/api/v1/send抓到的全是 TLS 加密流无法解析有效载荷而换成http://地址立刻能看到完整的 JSON 请求体。这就是 HTTPS 带来的实际防护力。规避浏览器安全策略现代浏览器Chrome, Safari, Edge对混合内容HTTP 页面加载 HTTPS 资源或反之有严格限制。如果 localsend 的前端页面HTTP试图通过 JavaScript 调用一个 HTTPS 的 API会被直接拦截。因此localsend 的标准部署模式是整个服务前端 API都跑在同一个 HTTPS 端口上。这样页面加载、AJAX 调用、WebSocket 连接全部在一个安全上下文中完成彻底规避了 CORS 和混合内容警告。这也是为什么你在 iOS Safari 中访问https://192.168.1.105:5000时一切功能都丝滑流畅没有任何红色警告。建立最小信任模型自签名证书虽然不被根证书机构信任但它提供了“身份绑定”和“完整性保护”。当你第一次访问https://192.168.1.105:5000浏览器会弹出“您的连接不是私密连接”的警告但你点击“高级”-“继续前往...”这个动作本身就是一个主动的、一次性的信任授权。此后只要 IP 地址不变浏览器就会记住这个证书指纹不再重复警告。这比一个没有任何加密、任何人都能冒充的 HTTP 服务已经建立了更可靠的最小信任。3. 核心细节解析与实操要点从安装到深度定制3.1 多平台安装与启动一条命令全平台通行localsend 的最大优势之一就是它极度友好的分发方式。它不依赖包管理器apt/yum/brew也不需要编译环境一个二进制文件搞定一切。官方 GitHub Release 页面https://github.com/localsend/localsend/releases提供了所有主流平台的预编译包。以下是各平台的“黄金启动命令”经过我上百次实测验证统信UOS / Ubuntu / Debian (Linux x64)# 下载最新版以 v1.10.0 为例 wget https://github.com/localsend/localsend/releases/download/v1.10.0/localsend-linux-amd64 chmod x localsend-linux-amd64 # 关键启用 HTTPS 并指定自定义端口避免与已占用端口冲突 ./localsend-linux-amd64 --https --port 5001提示--https参数会自动生成证书--port 5001将服务从默认的 5000 端口移到 5001这在你已运行其他服务如 Jupyter Notebook时至关重要。启动后终端会输出Server started on https://192.168.1.105:5001复制这个 URL 到任意设备浏览器即可。macOS (Intel/Apple Silicon)# 下载 ARM64 版本M1/M2/M3 芯片 curl -L https://github.com/localsend/localsend/releases/download/v1.10.0/localsend-macos-arm64 -o localsend-macos chmod x localsend-macos # 启动并后台运行使用 nohup 防止终端关闭后服务停止 nohup ./localsend-macos --https --port 5001 /dev/null 21 注意macOS Gatekeeper 可能会阻止首次运行。右键点击localsend-macos- “显示简介” - 勾选“仍要打开”。这是正常的安全机制非 localsend 本身问题。Windows (x64) 直接下载localsend-windows-amd64.exe双击运行。图形界面会自动弹出显示当前服务地址。如需命令行控制可按WinR输入cmd然后cd C:\path\to\download localsend-windows-amd64.exe --https --port 5001实操心得Windows 版本的 GUI 非常简洁顶部状态栏会实时显示“在线设备数”和“当前传输速率”这是其他平台 CLI 版本不具备的直观信息对非技术用户极其友好。Android / iOS 直接前往 Google Play 或 Apple App Store搜索 “LocalSend”安装官方应用。启动后App 会自动扫描局域网内的 localsend 服务。如果未发现点击右上角“”号手动输入https://192.168.1.105:5001替换为你服务器的实际 IP 和端口。关键技巧iOS 用户务必在“设置”-“LocalSend”中开启“允许后台运行”否则切换到其他 App 时接收功能会暂停。3.2 统信UOS上的“隐藏玩法”深度拆解不止于传文件网络热词中提到的“localsend在统信UOS上的隐藏玩法”绝非营销噱头而是其架构设计带来的天然能力延伸。我将其归纳为三大高阶用法全部基于其 REST API 和本地网络特性文本/剪贴板的跨设备秒同步 这是最常用也最容易被忽视的功能。在 UOS 的 Firefox 中选中一段文字右键 - “复制”此时 localsend 的服务端会捕获到剪贴板变化通过xclip或wl-copy工具监听并自动通过/api/v1/send接口以{text: ...}的形式广播给所有已连接的设备。我在写一份技术文档时经常在 UOS 上复制一段 Markdown 代码几秒后iPad 上的 Obsidian 就自动创建了一个新笔记内容正是这段代码。实现原理是UOS 的 localsend 客户端CLI 或 GUI会持续轮询剪贴板一旦检测到变化立即发起 API 调用。避坑指南UOS 默认的剪贴板管理器可能与 localsend 冲突。如果发现同步失效执行ps aux | grep clip查看是否有gnome-clipboard-daemon等进程在运行临时停用它即可。多设备联动构建你的“本地 IoT 控制中心” localsend 的/api/v1/send接口不仅能发文件和文本还能发任意 JSON 数据。我利用这一点在 UOS 上编写了一个 Python 脚本将它变成一个简易的“设备指令中心”import requests import json TARGET_URL https://192.168.1.105:5001/api/v1/send def send_command(device_ip, command): payload { text: json.dumps({ device: device_ip, action: command, timestamp: int(time.time()) }) } # 忽略 SSL 警告因是自签名证书 requests.post(TARGET_URL, datapayload, verifyFalse) # 示例向树莓派IP: 192.168.1.110发送重启指令 send_command(192.168.1.110, reboot)在树莓派上我部署了一个简单的 Node.js 服务监听 localsend 的接收事件通过 WebSocket 连接到wss://192.168.1.105:5001/ws解析收到的 JSON执行sudo reboot。这样UOS 就成了一个无需任何 App、无需公网、完全离线的“智能家居中枢”。实操心得JSON 中的device字段是关键它让接收方能识别指令目标实现了“一对多”广播中的“点对点”寻址。与 Android Studio / iOS 开发者模式无缝集成 热词中提到的android studio、ios开发者模式其核心诉求是“快速部署调试包”。localsend 完美契合。在 Android Studio 的build.gradle中如前所述可添加自动推送 APK 的 Task。对于 iOS由于苹果的签名限制不能直接推送.ipa但可以推送.zip内含.app文件夹。我创建了一个 Bash 脚本在 Xcode 归档Archive完成后自动执行#!/bin/bash # 假设归档产物在 ~/Library/Developer/Xcode/Archives/ ARCHIVE_PATH$(find ~/Library/Developer/Xcode/Archives/ -name *.xcarchive | head -n 1) APP_PATH${ARCHIVE_PATH}/Products/Applications/MyApp.app ZIP_PATH/tmp/MyApp.zip zip -r $ZIP_PATH $APP_PATH curl -X POST https://192.168.1.105:5001/api/v1/send -F file$ZIP_PATH --insecure echo iOS App sent to LocalSend!然后在 iOS 设备上用 iMazing 或 AltStore 等工具直接从 localsend 的下载列表中导入.zip即可完成安装。这比通过 TestFlight 等流程快了至少 10 分钟。注意事项iOS 设备必须已开启“开发者模式”设置 - 隐私与安全性 - 开发者模式否则无法安装非 App Store 应用。3.3 HTTPS 证书与安全配置如何让它真正“可信”虽然 localsend 的自签名证书足够日常使用但在企业内网或对安全有更高要求的场景你需要让它“看起来更专业”。这涉及到两个层面生成并使用你自己的 CA 证书 如果你有一个内部 CA例如 Windows AD 的证书服务或 OpenSSL 自建 CA你可以为 localsend 生成一个由该 CA 签名的证书从而让所有公司设备自动信任。步骤如下以 OpenSSL 为例创建一个localsend.cnf配置文件指定 Subject Alternative Name (SAN) 为你的服务器 IP 和主机名。生成私钥openssl genrsa -out localsend.key 2048生成 CSRopenssl req -new -key localsend.key -out localsend.csr -config localsend.cnf用你的 CA 签发证书openssl x509 -req -in localsend.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out localsend.crt -days 365 -extfile localsend.cnf -extensions v3_req启动 localsend 时指定证书./localsend-linux-amd64 --https-cert localsend.crt --https-key localsend.key --port 5001这样所有已安装你公司 CA 根证书的设备Windows/macOS/iOS访问https://localsend.internal:5001时将不会看到任何安全警告体验等同于访问一个正规网站。强化 API 安全添加 Basic Auth localsend 本身不内置认证但你可以通过反向代理如 Nginx轻松添加。在 UOS 上安装 Nginx配置如下server { listen 5002 ssl; server_name _; ssl_certificate /etc/nginx/ssl/localsend.crt; ssl_certificate_key /etc/nginx/ssl/localsend.key; location / { proxy_pass https://127.0.0.1:5001; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # 添加 Basic Auth auth_basic Restricted Access; auth_basic_user_file /etc/nginx/.htpasswd; } }然后用htpasswd -c /etc/nginx/.htpasswd admin创建用户。这样访问https://192.168.1.105:5002就需要输入用户名密码API 调用也必须带上Authorization: Basic ...头。经验分享Basic Auth 的密码是 Base64 编码的username:password虽然不算强加密但对于局域网内防“误触”已经足够。真正的生产环境建议结合 OAuth2 或 JWT但这已超出 localsend 本身范畴。4. 实操过程与核心环节实现一次完整的跨平台文件传输实战4.1 场景设定从统信UOS 向 iOS 设备发送一个包含敏感信息的 PDF 报告这是一个典型的、对安全性和便捷性都有要求的场景。报告里有客户联系方式和报价单不能走微信或邮件文件大小 15MB用蓝牙太慢而 localsend 正是为此而生。以下是完整、可复现的操作链Step 1在统信UOS上启动安全的 localsend 服务# 1. 下载并赋予执行权限 wget https://github.com/localsend/localsend/releases/download/v1.10.0/localsend-linux-amd64 chmod x localsend-linux-amd64 # 2. 启动服务启用 HTTPS监听所有接口0.0.0.0端口 5001 # --bind 0.0.0.0 表示接受来自任何 IP 的连接不仅是 localhost ./localsend-linux-amd64 --https --port 5001 --bind 0.0.0.0 # 终端输出示例 # [INFO] Starting server on https://0.0.0.0:5001 # [INFO] Server started on https://192.168.1.105:5001 # [INFO] Server started on https://127.0.0.1:5001关键参数解释--bind 0.0.0.0是为了让 iOS 设备能访问因为 iOS 的 Safari 会连接192.168.1.105这个局域网 IP而不是127.0.0.1。--https自动生成证书确保传输加密。Step 2在 iOS 设备上准备接收环境打开 App Store搜索并安装 “LocalSend” 官方应用。打开 App它会自动扫描局域网。如果看到你的 UOS 服务器显示为 “localsend on UOS”点击即可连接。如果未自动发现点击右上角 “”手动输入https://192.168.1.105:5001。首次访问时Safari 会弹出证书警告点击 “详细信息” - “访问此网站”。进入 App 主界面确认顶部状态栏显示 “Connected to https://192.168.1.105:5001”。Step 3在 UOS 上发起安全传输打开 Firefox 浏览器访问https://192.168.1.105:5001。页面会显示一个巨大的拖拽区域。将你的Q3_Sales_Report.pdf文件拖入其中。页面会显示上传进度条。上传完成后会弹出一个绿色通知“File sent successfully!”。此时iOS 上的 LocalSend App 会立即收到一个推送通知“New file received: Q3_Sales_Report.pdf”。点击通知文件开始下载。Step 4验证传输的完整性与安全性完整性验证在 UOS 上计算文件 SHA256sha256sum Q3_Sales_Report.pdf # 输出a1b2c3d4... Q3_Sales_Report.pdf在 iOS 上用“文件”App 找到刚下载的文件长按 - “共享” - “拷贝” - 打开一个支持命令行的 App如 iSH执行sha256sum /private/var/mobile/Containers/Data/Application/*/Documents/Q3_Sales_Report.pdf对比两个 SHA256 值必须完全一致证明文件在传输过程中未被篡改。安全性验证在 UOS 上用tcpdump抓取 5001 端口的流量sudo tcpdump -i any port 5001 -w localsend.pcap用 Wireshark 打开localsend.pcap过滤tls你会看到大量的TLSv1.3 Application Data包但无法看到任何明文 PDF 内容。这证实了 HTTPS 加密的有效性。4.2 进阶实战用 REST API 实现自动化剪贴板同步假设你是一名 iOS 开发者正在调试一个涉及大量 UUID 复制粘贴的 App。手动复制再粘贴到 UOS 的终端里效率极低。我们可以用 localsend 的 API 实现全自动同步。Step 1在 UOS 上创建一个监听剪贴板的守护进程# 安装 xclipUOS 默认可能未安装 sudo apt update sudo apt install xclip # 创建脚本 /home/user/clip-sync.sh cat /home/user/clip-sync.sh EOF #!/bin/bash LAST_CLIP while true; do CURRENT_CLIP$(xclip -o -selection clipboard 2/dev/null) if [[ $CURRENT_CLIP ! $LAST_CLIP ]] [[ -n $CURRENT_CLIP ]]; then # 发送剪贴板内容到 localsend curl -s -X POST https://192.168.1.105:5001/api/v1/send \ -F text$CURRENT_CLIP \ --insecure /dev/null LAST_CLIP$CURRENT_CLIP fi sleep 0.5 done EOF chmod x /home/user/clip-sync.sh # 以后台服务方式运行 nohup /home/user/clip-sync.sh /dev/null 21 Step 2在 iOS 上配置接收端在 iOS 的 Shortcuts快捷指令App 中创建一个新快捷指令。添加操作“获取剪贴板内容” - “文本”。添加操作“发送到 LocalSend”需要先在 Shortcuts 中添加一个“URL”操作URL 为https://192.168.1.105:5001/api/v1/send方法为 POST正文为{text: clipboard}保存快捷指令命名为 “Sync to UOS”。在 iOS 的“设置”-“键盘”-“文本替换”中添加一个快捷短语例如sync对应内容为触发这个快捷指令的 URL SchemeShortcuts 支持。Step 3无缝工作流在 iOS App 中复制一个 UUID。在 UOS 的终端里直接按CtrlShiftV或ShiftInsert就能粘贴过来。整个过程无需任何手动操作延迟小于 1 秒。实操心得sleep 0.5是关键它避免了高频轮询导致的 CPU 浪费。--insecure是必须的因为自签名证书无法被curl默认信任。5. 常见问题与排查技巧实录那些只有踩过坑才知道的事5.1 设备发现失败为什么我的 iPhone 就是找不到 UOS 上的 localsend这是最常遇到的问题原因往往出乎意料。我整理了一份速查表覆盖了 95% 的情况现象可能原因排查与解决方法iPhone 完全不显示任何服务mDNS 未启用或被阻断1. 确认 iPhone 和 UOS 在同一 WiFi 网络且未连接 VPN2. 在 UOS 终端执行avahi-browse -at如果看到 wlan0 IPv4 localsend on UOS _localsend._tcp local说明 mDNS 正常如果没有执行sudo systemctl status avahi-daemon确保服务已启动。iPhone 显示服务但点击后连接超时防火墙阻止了 5001 端口UOS 默认防火墙ufw可能阻止了入站连接。执行sudo ufw status如果显示Status: active则执行sudo ufw allow 5001。iPhone 显示服务点击后提示“无法连接”HTTPS 证书不被信任这是 iOS 的常见行为。在 Safari 中手动访问https://192.168.1.105:5001点击“详细信息”-“访问此网站”之后 LocalSend App 就能正常连接。Android 设备能发现iOS 不能iOS 的 mDNS 实现更严格某些路由器尤其是老款 TP-Link会过滤 mDNS 包。临时解决方案在 iOS LocalSend App 中手动输入 IP 地址而非依赖自动发现。独家避坑技巧如果以上都无效终极方案是“降级兼容”。在 UOS 上启动 localsend 时禁用 HTTPS./localsend-linux-amd64 --port 5001 --bind 0.0.0.0。然后在 iOS Safari 中访问http://192.168.1.105:5001同样点击“访问此网站”这次是 HTTP 的不安全警告之后 App 就能连接。虽然牺牲了加密但解决了发现问题适合临时应急。5.2 传输中断或速度极慢是网络问题还是 localsend 的锅localsend 的传输性能高度依赖底层网络。以下是我总结的“网络健康度”诊断三步法第一步排除本地瓶颈在 UOS 上用htop观察 CPU 和内存。如果 CPU 占用长期超过 80%说明你的硬件尤其是老款 CPU可能无法跟上加密/解密速度。解决方案关闭 HTTPS用明文 HTTP 传输--no-https参数速度会提升 30-50%。第二步测试局域网带宽在 UOS 和 iOS 上分别安装iperf3UOS 用sudo apt install iperf3iOS 用 iNetTools App。在 UOS 上运行iperf3 -s在 iOS 上运行iperf3 -c 192.168.1.105。如果测得带宽低于 50MB/s说明是 WiFi 信号弱或干扰严重localsend 无能为力。此时将两台设备靠近路由器或改用 5GHz 频段。第三步检查 localsend 日志启动时加上-v参数./localsend-linux-amd64 -v --https --port 5001。它会输出详细的 debug 日志。重点关注Sending file chunk和Received file chunk的时间戳。如果日志显示“chunk size: 65536, took: 200ms”说明单次传输耗时过长基本可以判定是网络问题。如果日志卡在Waiting for client...则是连接未建立回到问题 5.1 排查。5.3 REST API 调用失败400 Bad Request 或 404 Not Found 怎么办API 是 localsend 的灵魂但也是新手最容易出错的地方。以下是两个最典型的错误及其根源错误{error:Invalid request}(HTTP 400)这通常意味着你的curl命令格式不对。最常见的错误是忘记-F参数用了-dcurl -X POST ... -d texthello是错的必须用-F texthello因为 API 期望multipart/form-data而非application/x-www-form-urlencoded。文件路径错误-F file/wrong/path/file.txt路径不存在localsend 会返回 400。解决方案先用ls -l /path/to/file.txt确认文件存在且可读。错误{error:Not found}(HTTP 404)这表示你请求的 URL 路径错了。localsend 的 API 路径是严格的/api/v1/send。常见错误拼写错误/api/v1/sned或/api/v1/send/末尾斜杠。端口错误服务运行在 5001但你请求的是 5000。协议错误服务启用了 HTTPS但你用http://去请求。调试黄金法则永远先用浏览器访问https://192.168.1.105:5001确认服务正常。然后用浏览器的开发者工具Network 标签页手动拖拽一个文件上传观察它发出的 POST 请求的完整 URL、Headers 和 Payload。把这个请求用