EchoFS：一个由 AI 从零编写的文件 HTTP 服务器
最近在整理 NAS 上的文件时，我遇到了一个老问题——想临时把某个目录通过局域网共享出去，让同事或朋友直接在浏览器里浏览和下载。试了几个方案，要么依赖太重，要么界面简陋，要么不支持预览。于是我决定让 AI 来写一个。
EchoFS 就是这样诞生的——一个完全由 AI 编写的、用 Rust 实现的单文件 HTTP 文件服务器。编译产物只有约 1.3MB，零配置即可运行，把它丢到任何目录下执行，就能立刻通过浏览器访问该目录下的所有文件。
它解决什么问题
你可能遇到过这些场景：
- 需要在局域网内快速共享一批文件给别人
- 想在手机或平板上浏览电脑里的照片和视频
- 部署一个临时的静态资源服务
- Python 的
http.server太简陋，Nginx 又太重
EchoFS 就是为这些场景设计的。一条命令启动，对方打开浏览器就能用。比如以下实际场景非常适合使用：
1. 跨设备临时文件传输（“隔空投送”替代品）
在办公室或家中，需要快速将电脑上的文件（文档、安装包、照片）发送给手机、平板或其他同事的电脑，但不想登录微信/QQ/网盘，或者文件太大导致传输慢。
- EchoFS 优势：
- 极速启动：在文件所在目录运行
./echofs，几秒钟内即可生成一个局域网链接。 - 多端兼容：接收方只需浏览器访问链接即可下载，无需安装任何客户端（特别适合 iOS 或非 Windows 设备）。
- 隐私安全：数据仅在局域网内传输，不经过第三方服务器。
- 极速启动：在文件所在目录运行
2. 家庭媒体中心 / 私人流媒体服务器
用户希望将存储在电脑或 NAS 上的电影、音乐、照片集，直接在智能电视、手机或平板上播放，而不进行完整的文件下载。
- EchoFS 优势：
- 原生流式播放：支持 HTTP Range 请求，视频可以直接拖动进度条，无需等待下载完成。
- 内置播放器：自带的现代化前端支持音频、视频和图片的直接预览，界面美观且支持深色模式，体验优于简陋的原生文件列表。
- 低资源占用：可在树莓派等低功耗设备上 24 小时运行，作为轻量级媒体库。
3. 开发与测试环境的数据 Mock
前端或移动端开发人员在开发过程中，需要模拟后端接口返回的静态资源（如测试用的大文件、特定格式的图片/视频），或者需要快速搭建一个静态资源服务器来测试 APP 的下载/预览功能。
- EchoFS 优势：
- 零配置：无需配置 Nginx 或 Apache 的复杂规则，一行命令即可启动服务。
- 单文件部署：方便集成到自动化测试脚本或 CI/CD 流程中，随用随启，用完即停。
4. 会议与教学演示共享 在会议室或教室中，演讲者需要将演示文稿、视频素材共享给所有参会者的设备，或者让参会者自行下载资料。
- EchoFS 优势：
- 无网络依赖：即使在没有外网（互联网）的内网环境中，只要设备连接同一 Wi-Fi 即可访问。
- 批量分发：相比逐个发送文件，提供一个二维码或短链接让所有人自取效率更高。
5. 旧设备复活与嵌入式应用
利用闲置的旧笔记本、树莓派或低功耗开发板，将其改造为临时的文件共享节点。
- EchoFS 优势：
- 极小的体积：编译后仅约 1.3MB，对存储空间要求极低。
- 高性能：基于 Rust 和 Tokio 异步架构，即使在低配硬件上也能维持较高的并发吞吐量。
6. 安全的内部数据交换（替代公共云盘）
在企业内网中，涉及敏感数据（如代码片段、设计稿、内部文档）的交换，严禁上传至公有云盘。
- EchoFS 优势：
- 数据不出域：完全本地化部署，杜绝数据泄露风险。
- 路径安全：内置防目录遍历攻击机制，防止恶意用户访问非共享目录的文件。
EchoFS 的核心定位是“轻量级的局域网文件瑞士军刀”。它不适合替代大型 NAS 系统（如群晖）或企业级文件服务器（缺乏用户权限管理、数据库支持等），但在临时性、点对点、媒体预览友好的场景下，它比传统的 Python http.server 更美观，比 Nginx 更简单，比商业软件更自由。
几个值得一提的特点
单文件，开箱即用。 整个程序就是一个二进制文件，没有外部依赖，不需要安装运行时。HTML、CSS、JavaScript 全部内嵌在二进制中，不会在你的目录里生成任何额外文件。
内置 SPA 前端。 自带一套完整的浏览器界面，支持暗色/亮色主题切换，响应式布局适配手机和桌面。目录浏览使用客户端路由，页面切换无刷新，体验流畅。
媒体预览。 图片、视频、音频可以直接在浏览器内预览播放，不需要先下载再打开。对于整理和分享媒体文件来说非常实用。
流式传输与断点续传。 文件通过流式方式传输，不会把整个文件加载到内存中。支持 HTTP Range 请求，大文件下载中断后可以续传，视频也可以随意拖动进度条。
安全方面有考虑。 所有用户传入的路径都会经过规范化校验，确保无法通过 ../ 之类的手段越过根目录访问系统其他文件。
Rust 编写。 基于 Tokio 异步运行时和 Axum Web 框架，资源占用低，并发性能好。适合在树莓派等低配设备上长期运行。
使用方式
# 共享当前目录，默认端口 8080
./echofs
# 指定目录和端口
./echofs --root /path/to/share --port 9000
# 启动后自动打开浏览器
./echofs --open
启动后终端会输出局域网 IP 地址，把地址发给对方就行了。
EchoFS serving /home/user/files on http://0.0.0.0:8080
Available on:
http://127.0.0.1:8080
http://192.168.1.42:8080
Listening on 0.0.0.0:8080
命令集合：
Usage: echofs [OPTIONS]
Options:
-r, --root <ROOT> 服务根目录 [默认: .]
-p, --port <PORT> 监听端口 [默认: 8080]
-b, --bind <BIND> 绑定地址 [默认: 0.0.0.0]
-o, --open 自动打开浏览器
-l, --log <LOG> 访问日志输出："stdout"、"off" 或文件路径 [默认: stdout]
-h, --help 打印帮助信息
关于 AI 编写这件事
EchoFS 的代码由 AI 从架构设计到具体实现全程生成，包括前端界面、后端逻辑、错误处理、单元测试和集成测试（共 80+ 个测试用例）。整个过程中人类主要负责提出需求和做最终审查。
这不是一个"AI 辅助补全了几行代码"的项目，而是一次完整的 AI 独立工程实践。从最终效果来看，代码结构清晰，模块划分合理，没有 unwrap() 滥用，错误处理通过统一的枚举类型转换为对应的 HTTP 状态码——这些都是 Rust 社区推崇的实践。
如果你恰好需要一个轻量级的文件共享工具，或者对 AI 写代码的实际水平感到好奇，不妨试试看。
项目地址： GitHub 开源，欢迎体验和反馈。github.com/dengsgo/ech…
贡献指南： 欢迎贡献代码，但有一个原则：提交的代码必须由 AI 生成。 这是一次 AI 优先开发的实验。手动编写的 Pull Request 将不会被接受。我们认为在 AI 时代，人工编码是低效且过时的方式，这不符合本项目的立意。
^_^
