在局域网里临时共享文件，通常不值得搭建完整的 NAS、对象存储或网盘服务。echoFS 提供了一个更轻量的选择：它是基于 Rust 的单文件 HTTP 静态资源服务器，编译后不到 2 MB，可以在几乎没有准备工作的情况下，把任意目录变成可通过浏览器访问的文件中心。
它的价值不只是“能下载文件”。目录浏览、图片视频音频预览和断点续传组合在一起后，电脑、开发板、家庭服务器之间的临时文件交换会变得简单很多。
一个目录，立即变成网页文件中心
echoFS 的基本使用方式可以保持在一个命令内。下面的示例假设 echofs 已经安装并位于 PATH 中：
mkdir -p "$HOME/lan-share"
printf 'hello from echoFS\n' > "$HOME/lan-share/readme.txt"
echofs "$HOME/lan-share"
启动后，用同一局域网内设备的浏览器打开服务地址即可浏览共享目录。具体监听端口、绑定地址以及可用选项应以当前版本的帮助信息为准：
echofs --help
如果需要共享当前项目的构建产物，也可以直接执行：
cd ./dist
echofs "$PWD"
这种使用方式适合临时传输安装包、日志、照片、测试数据和前端构建产物。服务退出后，共享目录仍然保留，文件不会被复制到额外的存储位置。
浏览器预览比“下载后再打开”更省事
传统静态文件服务器通常只负责返回文件。echoFS 额外提供了面向文件浏览的 Web UI，能够自动列出共享路径下的内容，并在浏览器中直接预览常见媒体文件：
- 图片可以直接查看；
- 视频可以在页面中播放；
- 音频可以直接试听；
- 普通文件仍然可以下载或打开。
这对手机访问尤其方便。比如相机拍摄的照片或录屏文件放进共享目录后，其他设备可以先在网页里筛选和预览，再决定是否下载，不必反复处理文件名和本地缓存。
目录浏览也降低了临时共享的沟通成本。发送者只需要提供服务地址，接收者可以自行找到目标文件，而不需要发送者逐个生成下载链接。
大文件传输需要断点续传
大文件传输最麻烦的情况不是速度慢，而是连接中断后必须从头开始。echoFS 提供断点续传能力，适合传输镜像、视频、压缩包等体积较大的文件。
客户端也可以使用 HTTP Range 请求继续下载。例如，用 curl 下载一个较大的文件时，可以使用 -C -：
curl -C - -o linux-image.iso http://192.168.1.20:PORT/linux-image.iso
将 192.168.1.20 替换为运行 echoFS 设备的局域网地址，将 PORT 替换为实际端口。如果下载中断，重新执行同一条命令，curl 会尝试从已有文件的大小处继续请求。
也可以先查看响应头，确认服务是否返回了适合续传的 HTTP 信息：
curl -I http://192.168.1.20:PORT/linux-image.iso
实际续传效果还取决于客户端、网络环境以及文件在传输期间是否发生变化。共享目录中的文件最好在传输期间保持稳定，避免源文件被覆盖后继续拼接旧内容。
适合什么场景，不适合什么场景
echoFS 适合“马上共享、用完即停”的场景：
- 在家庭局域网中给手机或电视提供照片、视频；
- 在开发机和测试设备之间传输构建产物；
- 临时共享日志、安装包和压缩文件；
- 在没有完整文件服务基础设施的机器上快速提供只读浏览入口。
它不应被直接当作完整网盘或公网文件服务。单文件体积小、启动简单是优势，但也意味着使用者需要自行考虑访问控制、网络边界、HTTPS、审计和长期存储策略。尤其是在公共网络或端口转发环境中，不要默认“知道地址的人才能访问”就是充分的安全措施。
实践时可以遵循这份检查清单：
- 只共享明确的目录，避免把整个用户主目录作为根路径。
- 确认服务只暴露在可信的局域网中。
- 共享完成后及时停止进程。
- 传输敏感文件时，额外考虑加密压缩包或其他身份认证方案。
- 传输大文件前确认磁盘空间，并在中断后使用断点续传。
- 将端口、监听地址等参数以
echofs --help和实际版本行为为准。
结语：把临时文件服务降到一条命令
echoFS 的核心吸引力在于部署成本低：一个小型 Rust 单文件程序，加上目录浏览、媒体预览和断点续传，就覆盖了大量局域网文件交换需求。它不试图替代成熟的 NAS、网盘或企业文件平台，而是把“我现在需要让另一台设备拿到这个目录”这件事变得足够直接。
对于开发、测试和家庭局域网场景，先用 echoFS 快速验证需求，再决定是否值得引入更复杂的长期服务，通常是更经济的路径。