GridFS本身不支持秒传，因其不内置内容去重或哈希索引机制；实现秒传需上传前计算文件SHA256哈希并查库，命中则直接返回已有文件ID，否则正常上传，并在fs.files中添加带唯一索引的hash字段。
为什么 GridFS 本身不支持秒传
GridFS 是 MongoDB 的文件存储规范，它把大文件切块存进 fs.chunks 和元数据存进 fs.files，但不自带内容去重或哈希索引。所谓“秒传”，本质是上传前比对文件内容是否已存在——GridFS 默认不做这个判断，你发一个新文件，它就老老实实切块、插入、建索引，哪怕内容一模一样。
实现秒传必须自己加一层哈希校验
核心思路：上传前计算文件的强一致性哈希（如 sha256），查库确认该哈希是否已关联到某个 _id；若存在，直接返回已有文件的 _id 或访问路径，跳过上传。
- 哈希必须在客户端或网关层计算，不能依赖服务端读取完整文件再算——否则失去“秒”意义
- 哈希值要作为额外字段存进
fs.files，比如加个hash字段，并在该字段上建唯一索引：db.fs.files.createIndex({ hash: 1 }, { unique: true }) - 注意：不要用
filename或uploadDate做去重依据，它们不反映内容一致性 - 小文件可直接用 Node.js 的
crypto.createHash('sha256')流式计算；大文件需分片哈希或用fs.readFileSync+update()分批喂入
上传流程中容易漏掉的三个检查点
很多人写了哈希校验逻辑，但上线后仍重复存文件，问题常出在边界环节：
- 客户端上传时未携带哈希值，或字段名与服务端约定不一致（比如前端传
fileHash，后端却查hash字段） - 没处理哈希冲突场景：虽然
sha256理论碰撞概率极低，但万一两个不同文件算出相同哈希，唯一索引会报错E11000 duplicate key，需捕获并 fallback 到完整内容比对（极少需要，但逻辑要兜住） - 文件流被消费过一次后不可重用——比如你先用
stream.pipe(hasher)算哈希，再传给GridFSBucket.openUploadStream()，此时流已结束，上传会失败；正确做法是用stream.clone()（Node ≥18）或new PassThrough()复制一份
性能和兼容性要注意的硬约束
秒传不是加个哈希就完事，MongoDB 和驱动版本会影响实际表现：
-
fs.files.hash字段长度固定为 64（sha256十六进制），建索引无压力；但若用base64编码，长度变短但需统一编码方式，否则大小写、填充符差异会导致误判 - MongoDB 5.0+ 支持
$expr在查询中调用$function，但别在秒传路径里实时算哈希——那等于放弃客户端预计算优势 - 使用官方
mongodbNode 驱动时，确保GridFSBucket实例复用，避免每次新建导致连接开销掩盖哈希查询收益
真正卡住落地的，往往不是哈希算法选型，而是哈希值在请求链路中是否全程透传、是否被中间件截断或转义、以及索引有没有真正生效——上线前务必用 db.fs.files.explain("queryPlanner").find({ hash: "xxx" }) 确认走了索引。
