用net/http实现轻量对象存储服务，核心是安全处理PUT/GET请求：路径必须clean并白名单校验，限制上传大小，避免越权访问，禁用http.ServeFile，手动控制文件读写与Content-Type。
用 net/http 搭一个能存取文件的 HTTP 服务就行
Go 实现对象存储服务，不等于从零造 MinIO。多数场景下，你只需要一个支持 PUT 和 GET、带路径隔离、能防覆盖或做基础校验的轻量服务。核心就是用 http.ServeMux 绑定两个 handler：一个接收上传，一个提供下载。
关键不是“多像 S3”，而是“别让文件写到 /etc/passwd”。所以路径必须做清理，不能直接拼接用户输入的 key。
- 所有上传路径先过
filepath.Clean()，再检查是否以"."开头或含".." - 建议把根目录设为绝对路径（如
/var/data/oss），避免相对路径越权 - 不要用
os.Create()直接打开用户传的路径；先构造完整路径，再判断是否在允许目录内 - 示例中用
strings.HasPrefix(cleanedPath, allowedRoot)做白名单校验，比正则更稳
PUT /object/:bucket/:key 怎么安全接收文件流
对象存储的上传本质是接收 HTTP body 流并落地为文件。Go 的 http.Request.Body 是 io.ReadCloser，可直接传给 os.OpenFile 的 io.Copy，但要注意几个边界：
- 必须设置
MaxBytesReader限制上传大小，否则恶意大文件会吃光内存：req.Body = http.MaxBytesReader(w, req.Body, 100<code>1024</code>1024) // 100MB
- 用
os.O_CREATE | os.O_WRONLY | os.O_TRUNC打开文件，避免追加写入导致脏数据 - 上传成功后返回
ETag（如md5.Sum计算值），方便客户端校验完整性 - 如果要支持分片上传，就别在这层实现——那是业务逻辑，先保证单次
PUT可靠
GET /object/:bucket/:key 如何避免读取任意文件
下载 handler 最容易出漏洞：用户改 URL 路径就能读 /etc/shadow。解决方法不是“禁止某些文件名”，而是彻底切断路径逃逸可能。
- 从 URL 解析出
bucket和key后，立刻用filepath.Join(bucket, key)构造路径，再filepath.Clean() - 然后检查 clean 后的路径是否仍在预设根目录下：
absPath, _ := filepath.Abs(filepath.Join(rootDir, cleanedSubPath))<br>if !strings.HasPrefix(absPath, rootDir) {<br> http.Error(w, "access denied", http.StatusForbidden)<br> return<br>} - 用
http.ServeFile不安全，它不做路径净化；应手动os.Open+io.Copy，并显式设置Content-Type（如根据扩展名查mime.TypeByExtension） - 对不存在的 key，返回
http.StatusNotFound，别暴露文件系统结构
为什么不用 gorilla/mux 或 chi？
路由库能简化路径提取，但引入依赖前先问：你真需要 :bucket 和 :key 这种命名参数吗？http.ServeMux 完全能处理 /object/*，再用 strings.SplitN(r.URL.Path, "/", 4) 拆出 bucket 和 key —— 更少依赖、更少攻击面、启动更快。
-
gorilla/mux的正则路由在高并发下有性能开销，且默认不限制 URL 长度，易被长路径耗尽 CPU - 如果你已用
chi，没问题；但新项目为“对象存储”单独加它，属于过度设计 - 真正要关注的是磁盘 I/O 稳定性（比如用
sync.Pool复用bytes.Buffer缓冲区），不是路由语法糖
路径净化和权限隔离这两步，漏掉任何一环都可能让服务变成公开文件浏览器。实际部署时，记得用非 root 用户运行进程，并把数据目录 chown 给它——代码再严，也防不住 chmod 777。
