别再临时开 Python HTTP Server：用 Dufs 搭一个可控的文件交换站
在开发现场，“把这个构建产物给同事”“让测试机取一份日志”“从另一台电脑收一个复现包”都是小事，却经常以不太可控的方式解决：开一个 python -m http.server，把目录暴露在局域网里；或者在聊天工具里来回传压缩包。
前者只解决下载，后者没有稳定 URL、也不适合脚本化。更重要的是，临时目录里常混有 .git、环境文件、日志或尚未发布的构建产物。一个“先开起来再说”的文件服务，往往把访问边界交给了运气。
Dufs 是一个 Rust 文件服务器，项目采用 Apache-2.0 许可证。它把静态文件服务、上传、目录搜索、账号访问控制，以及一组可用 curl 调用的 HTTP/WebDAV 风格操作放在一个可执行程序里。它不替代对象存储，也不是团队永久网盘；它特别适合开发环境中的短周期文件交换。
先把需求拆开：读、写、暴露范围是三件事
“能上传”不应该自动等于“谁都能上传”，而“账号有读写权限”也不应自动打开服务端所有写操作。Dufs 的设计里有两个独立层次：
- 全局开关决定服务器是否允许上传、删除、搜索、打包或哈希查询；
--auth规则决定某个账号能访问哪些路径，以及该路径是只读还是读写。
这意味着可以先只开放上传，再对某个目录授予账号权限。官方文档也特别说明：即使账号规则标成 :rw，未启用 --allow-upload 时，账号仍不能上传。把这两个层次分开，能减少“为了让同事传一个文件，顺手把删除和搜索也打开”的误配置。
最简单的只读服务甚至只要：
dufs ./artifacts
默认端口是 5000。它适合在本机检查构建目录，或配合受控网络临时分发文件；不过一旦需要跨设备使用，就应显式指定监听地址、服务目录和权限，而不是把当前工作目录原样暴露出去。
用 Docker 建一个受账号保护的交换目录
下面的示例只挂载一个专门创建的目录，并把端口绑定到本机回环地址。这样先完成本机验证；如果确实要让局域网设备访问，再由反向代理、VPN 或防火墙明确决定网络入口。
mkdir -p "$HOME/dufs-share" printf 'build metadata\n' > "$HOME/dufs-share/README.txt" docker run --rm \ -v "$HOME/dufs-share:/data:rw" \ -p 127.0.0.1:5000:5000 \ sigoden/dufs /data \ --allow-upload \ -a 'editor:change-me@/:rw'
这里有几个值得保留的限制。第一，容器看到的只有 /data，而不是整个家目录。第二，127.0.0.1:5000:5000 不会直接监听所有网卡。第三，命令仅开启 --allow-upload，没有使用 -A；后者会一次性允许上传、删除、搜索、创建和编辑等全部操作，适合一次性演示，不适合作为默认配置。
若机器已直接安装 Dufs，也可以把镜像名和挂载参数去掉，使用同样的核心参数运行：
dufs "$HOME/dufs-share" \ -b 127.0.0.1 \ -p 5000 \ --allow-upload \ -a 'editor:change-me@/:rw'
Dufs 官方提供 Cargo、Homebrew、二进制发布包等安装路径。无论用哪一种，先运行 dufs --version 和 dufs --help，确认当前版本实际支持的参数，再写入自动化脚本。
用 curl 做一次可复现的收发验证
浏览器界面方便人工拖拽，但开发流程最好同时保留可脚本化的验证。服务启动后，先访问健康检查端点：
curl http://127.0.0.1:5000/__dufs__/health
再用 Basic Auth 读取初始文件、上传一个新文件，并立即回读内容：
curl --user editor:change-me \ http://127.0.0.1:5000/README.txt printf 'upload round-trip\n' > /tmp/upload.txt curl --user editor:change-me \ -T /tmp/upload.txt \ http://127.0.0.1:5000/upload.txt curl --user editor:change-me \ http://127.0.0.1:5000/upload.txt
curl -T 对应 HTTP 上传，最后一次读取是最小的端到端断言：它同时验证认证、写权限、挂载目录和文件可见性。CI 或测试脚本不必解析 HTML 页面，也能据此确认临时产物已经可取。
如果任务需要校验下载到的文件，Dufs 还提供 ?hash 查询以取得文件的 SHA-256 值，但要显式启用 --allow-hash：
dufs "$HOME/dufs-share" --allow-hash curl 'http://127.0.0.1:5000/README.txt?hash'
这个接口适合把“文件下载成功”扩展为“下载内容与服务器端哈希一致”。不过它不是签名机制：对于需要跨不可信网络传递的软件包，仍应使用发布方签名、可信校验和或制品库的完整性机制。
搜索、WebDAV 操作和删除权限要按需开启
Dufs 还支持以查询参数搜索目录，例如 ?q=Dockerfile；也可用 ?simple 只列出名称。搜索是便利功能，却会帮助访问者枚举目录内容，因此不要因为界面好用就默认开启 --allow-search。
同样，HTTP 方法可以创建目录：
curl --user editor:change-me \ -X MKCOL http://127.0.0.1:5000/incoming
这类能力适合受控上传区，不适合公共下载站。删除、移动、创建目录等写操作应遵循同一个原则：只有明确需要时才打开对应的全局允许项，并为不同角色划分路径。比如下载者只读 /releases，上传者仅可写 /incoming，再由人工或流水线将通过校验的文件移动到发布目录。
把临时服务变成可重复的操作步骤
一次性手工命令在故障排查时够用，但只要同一类文件交换每周都会发生，就值得把运行条件固化下来。最小清单可以包括服务目录、监听地址、允许操作、账号规则、健康检查和关闭时机。这样做的目标不是把 Dufs 包装成复杂平台，而是避免下一位执行者重新猜测“这个端口能否被外部访问”“上传目录是否会混入旧文件”。
一个实用的做法是每次任务创建独立目录，例如按构建编号建立 ~/dufs-share/build-20260802；上传完成后用脚本读取 ?hash 的结果，与发布流水线保存的 SHA-256 对比；任务结束后停止容器并删除交换目录。即使容器带有 --rm，宿主机挂载目录仍会保留，因此清理策略不能只依赖容器退出。
还应把认证失败和写入失败当作预期测试用例：用错误密码请求受保护文件应得到拒绝响应；未带 --allow-upload 时，同一账号的上传也应失败。这样的负向断言能确认权限开关没有因为升级镜像、复制命令或修改账号规则而失效。运行日志中只记录请求路径、状态码和校验结果，不要记录 Basic Auth 凭据或完整的敏感文件名。
如果需要把交换站接入 CI，建议由流水线临时生成随机密码，并仅通过受保护的环境变量传入启动命令和 curl --user。任务结束后撤销该凭据或销毁容器；不要复用个人账号，更不要把密码硬编码在仓库脚本中。这样即使临时服务的 URL 被构建日志保留，也不会自然变成长期有效的写入入口。
如果服务必须跨机器访问，先将 Dufs 绑定到明确的内网地址，确认该网段和防火墙规则，再向反向代理提供入口。HTTPS 也需要由部署者提供证书和私钥路径：Dufs 的 --tls-cert 与 --tls-key 参数可以启用 HTTPS，但它们不会自动签发或轮换证书。不要因为“只是临时传一下”就把监听地址改成 0.0.0.0，再把账号密码写进终端历史或聊天记录。
对于自动化，建议把健康检查、上传、回读和校验视为一组步骤，而不是只有上传命令。健康检查成功只说明进程可响应；回读证明权限和路径正确；哈希对比才覆盖内容完整性。三者分开记录，排错时能更快判断是服务没启动、认证失败、挂载错目录，还是传输内容出了问题；也便于把结果写入构建日志供后续追踪。
哪些情况下不该用 Dufs
Dufs 解决的是轻量、短生命周期的文件服务，不会替你处理长期存储治理。以下情况应改用更合适的系统：
- 需要审计留存、版本策略、对象级生命周期规则时，使用对象存储或制品库；
- 需要公开互联网分发时，放在 CDN、反向代理和专用认证体系之后，不要直接暴露临时服务器；
- 需要多人持续协作、冲突处理和文档权限时，使用团队文件平台；
- 需要传递敏感材料时，先考虑加密、网络隔离和访问日志，不能只依赖一个 Basic Auth 密码。
真正实用的临时文件服务，不是功能越多越好，而是默认暴露越少越好。Dufs 的价值正在于把“开个目录”变成可声明的服务：目录从哪里来、谁能读写、哪些操作被允许、脚本如何验证，都能写进命令和部署配置。对构建产物、日志收集和局域网调试来说，这通常比临时起一个无边界的 HTTP Server 更可靠。