秒传依赖文件内容哈希而非路径或大小，需流式计算sha256避免阻塞；用io.Copy直接写入hash.Hash实现零拷贝；服务端用Redis SET做O(1)哈希查重。
为什么直接比对文件路径或大小无法实现秒传
秒传不是跳过上传，而是服务端发现“这个文件我早就存过了”，就跳过实际数据传输。只比对 os.Stat().Size 或文件名，碰撞率极高——两个不同文件完全可能大小相同；只看路径更不可靠，用户改个名字就失效。真正可靠的依据是文件内容的唯一指纹，也就是哈希值。
常见错误是：在上传前用 os.Open 读全量文件算 sha256.Sum256，结果大文件（比如 2GB 视频）卡住几秒，用户体验和“秒”字毫无关系。
- 必须流式计算哈希，边读边算，不缓存全文
- 哈希算法选
sha256而非md5：后者已不安全，且在服务端校验时容易被恶意构造碰撞 - 不要在 HTTP handler 里同步读整个文件——会阻塞 goroutine，压测时迅速耗尽
net/http默认的 10K 连接池
如何用 io.Copy 和 hash.Hash 实现零拷贝哈希计算
Go 标准库的 hash.Hash 接口实现了 io.Writer，可以直接作为 io.Copy 的目的地。这意味着你不需要自己写 for-loop 读 chunk，更不需要把文件内容复制进内存切片。
h := sha256.New()
f, _ := os.Open("video.mp4")
defer f.Close()
io.Copy(h, f) // 流式读取 + 哈希计算，全程无中间 []byte 分配
fileHash := fmt.Sprintf("%x", h.Sum(nil))
这个写法的关键在于：io.Copy 内部使用固定大小（32KB）的 buffer 复用，避免高频小内存分配；sha256.New() 返回的对象本身维护内部状态，不依赖外部数据缓存。
立即学习“go语言免费学习笔记（深入）”；
- 如果上传走 HTTP multipart，可直接从
*multipart.Part读取并io.Copy(h, part) - 别用
h.Write(buf)手动分块——除非你要在每段后插入日志或进度回调，否则纯属增加复杂度 - 注意：
h.Sum(nil)返回的是追加结果后的切片，要转字符串必须用fmt.Sprintf("%x", ...)或hex.EncodeToString(...)，不能直接string(h.Sum(nil))
服务端如何高效查重：哈希值该存在哪
秒传体验是否成立，取决于“查哈希是否存在”这步是否足够快。本地用 map[string]bool 存哈希？上线后多实例部署立刻失效；用 MySQL 查 SELECT 1 FROM files WHERE hash = ?？单次查询几十毫秒，高并发下 DB 成瓶颈。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
生产环境推荐两级结构：
- 第一级：Redis 的
SET结构存所有已存在哈希，EXISTS file_hash:sha256_xxx—— O(1)，平均响应 - 第二级：MySQL 或 PostgreSQL 存完整元数据（用户ID、文件名、存储路径、创建时间），仅在 Redis 未命中且确认要落盘时才写入
- 注意 Redis key 命名：别用裸哈希值做 key（如
abc123...），加前缀避免和其他业务 key 冲突，例如file_hash:sha256:xxx
另外，Redis 不要设置过短 TTL——哈希本质是内容指纹，只要文件没被主动删，它就永远有效。TTL 只用于兜底防内存泄漏，设 30 天足够。
客户端上传前如何安全获取哈希而不卡 UI
浏览器端 JS 计算大文件哈希会阻塞主线程，导致页面假死。解决方案不是“用 Web Worker”，而是“根本不在前端算”。正确做法是：客户端先发一个轻量请求（如 POST /api/v1/file/check），携带文件元信息（大小 + 名称 + 修改时间），服务端根据这三个字段快速查一次“大概率重复”的候选集（比如同名同大小的最近 10 个文件），返回它们的哈希列表；客户端再用 Web Crypto API 并行计算这几个候选哈希，匹配成功即秒传，失败再走正常上传。
Go 后端对应逻辑很简单：
func (h *Handler) CheckFile(w http.ResponseWriter, r *http.Request) {
var req struct {
Name string `json:"name"`
Size int64 `json:"size"`
MTime int64 `json:"mtime"`
}
json.NewDecoder(r.Body).Decode(&req)
// 查同名同大小的最近几个文件哈希
hashes, _ := db.QueryHashesByNameAndSize(req.Name, req.Size, 5)
json.NewEncoder(w).Encode(map[string]interface{}{"hashes": hashes})
}
这个设计把“可能重复”的概率从 1/N（N 是总文件数）提升到接近 1/5，极大降低客户端真实计算哈希的频率。真正的难点不在哈希计算本身，而在如何让服务端和客户端在“少传、快判、不误判”之间取得平衡。
