http.FileServer 不支持上传，因其仅处理 GET 请求，无法解析 POST 表单或 multipart 数据；需自定义 handler 实现分片、路由与元数据管理。
为什么直接用 http.FileServer 做分布式上传会失败
因为 http.FileServer 只是静态文件服务，不处理 POST 请求、不解析 multipart/form-data、也不支持分片、断点续传或跨节点存储。你一发 curl -F "file=@a.txt" http://node1/upload，它直接返回 405 Method Not Allowed。
真正要做的，是自己写上传 handler，并决定文件存哪、元数据记哪、怎么协调多个节点：
- 单节点上传 → 本地磁盘 + JSON 记录（适合开发测试）
- 多节点但无共享存储 → 需引入一致性哈希或路由规则，比如按
fileID % N分发到node0～nodeN-1 - 带容错/高可用 → 必须加元数据服务（如 etcd 或 PostgreSQL），否则节点挂了就查不到文件在哪
multipart.ReadForm 和 ParseMultipartForm 的区别与选法
这两个都用来解析表单上传，但行为差异极大，选错会导致内存暴涨或解析失败：
r.ParseMultipartForm(32 ：限制整个表单最大 32MB，内部调用 <code>ReadForm，但会把所有非文件字段全读进内存 —— 如果你上传 1GB 文件 + 100 个文本字段，它先分配 100KB 内存存字段，再报http: request body too largemultipart.ReadForm(32 ：只限制 <code>maxMemory，且仅对非文件字段生效；文件部分默认流式写入临时磁盘（/tmp），更安全
生产环境推荐显式用 multipart.NewReader(r.Body, boundary) + 手动 NextPart()，这样能逐个判断字段类型、跳过无用字段、控制文件写入路径和命名：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
part, err := mr.NextPart()
if err == io.EOF { break }
if part.FormName() == "file" {
dst, _ := os.Create("/data/uploads/" + uuid.New().String())
io.Copy(dst, part)
}
如何避免多个节点重复保存同一份文件
用户可能同时往 node1 和 node2 发相同文件，或者重试导致多次上传。靠文件名去重不可靠（用户可改名），必须基于内容：
- 客户端计算
sha256并作为X-File-Hashheader 传入，服务端先查元数据库是否已存在该 hash - 服务端收到后，不急着保存，先
io.Copy(ioutil.Discard, part)流式算 hash，再决定是硬链接已有文件，还是真正写入新副本 - 注意：不要在
ReadForm后再算 hash —— 此时文件可能已在临时目录，但 part 已关闭，无法重读
如果用对象存储（如 MinIO），可以直接用 PutObject 的 metadata["hash"] 字段存摘要，再配合 StatObject 查询，比自建元数据表更轻量。
上传完成后的通知与状态同步难点
上传成功只是第一步。下游服务（比如缩略图生成、病毒扫描、CDN 刷新）需要知道“这个文件已就绪”，但不能每个节点都各自触发 —— 容易重复或漏掉。
可行做法只有两种：
- 中心化事件总线：上传节点写一条
upload.success消息到 Redis Stream 或 Kafka，由独立消费者统一处理后续动作 - 轻量轮询+幂等标记：上传成功后，在元数据里设
status = "uploaded"，另起一个 goroutine 每 5 秒查一次未处理的记录，调用processFile(id)并更新为"processed"—— 注意加SELECT ... FOR UPDATE或 Redis 锁防并发
别用 HTTP 回调（比如上传完立刻 http.Post 到 scanner 服务），网络失败就丢失状态，且难以重试对齐。
