直接用md5或sha256哈希值做GridFS秒传不可靠，因GridFS不存储文件哈希，files.md5字段是旧版驱动生成的弱校验且已弃用；必须上传前流式计算完整文件哈希（如sha256），显式存入metadata并为其建立索引才能安全复用。
为什么直接用 md5 或 sha256 哈希值做 GridFS 秒传不可靠
GridFS 本身不存储文件哈希，files 集合里的 md5 字段是旧版驱动自动生成的弱校验（仅对 chunk 拼接后整体计算），且 MongoDB 4.4+ 已弃用该字段。实际上传时若分块策略不同、驱动版本不同、或启用了压缩/加密，md5 就会失效。真正能用于秒传的，是你自己计算并显式存入的完整文件哈希（如 sha256），且必须在上传前完成。
如何在上传前安全计算大文件的 sha256 并写入 GridFS metadata
不能把整个文件读进内存再哈希——尤其 GB 级文件会 OOM。要用流式计算，并在 put() 时把哈希塞进 metadata：
- Node.js 示例：用
fs.createReadStream()+crypto.createHash('sha256')流式更新哈希，最后hash.digest('hex') - Python 示例：用
hashlib.sha256()配合fileobj.read(8192)分块更新，避免一次性 load - 务必在调用
gridfs_bucket.upload_from_stream()（或等价方法）时，把哈希值作为metadata参数传入，例如metadata={'sha256': 'a1b2c3...'} - 不要依赖
files.md5字段做查询——它可能为空、过时或根本不存在
如何用哈希值快速判断文件是否已存在（避免重复上传）
查的是 fs.files 集合，不是 fs.chunks。关键点是：必须为 metadata.sha256 建索引，否则每次 find() 都是全表扫描：
db.fs.files.createIndex({ "metadata.sha256": 1 })
查询逻辑很简单：
- 先执行
db.fs.files.findOne({ "metadata.sha256": "a1b2c3..." }) - 如果返回文档，说明文件已存在，直接复用它的
_id（即file_id），无需上传 - 如果返回
null，才走正常上传流程 - 注意：MongoDB 对
metadata字段的查询要求路径精确，"metadata.sha256"不能写成"metadata.sha256.value"或漏掉引号
秒传后如何正确复用已有文件（避免“硬链接”陷阱）
GridFS 没有硬链接概念。所谓“秒传复用”，本质是跳过上传，但业务侧仍需生成一条新记录指向已有内容——常见做法是插入一条新 files 文档，其 file_id 指向原 chunks 数据，同时更新自己的 metadata（比如添加用户 ID、上传时间）。但注意：
- 不能手动插入
fs.chunks—— 它由 GridFS 驱动管理，结构敏感 - 不能只复制
files文档并改_id——length、chunkSize、uploadDate等字段必须与原文件一致，否则驱动读取会失败 - 更稳妥的做法：用
copyTo()或download_to_stream()+upload_from_stream()快速中转，虽然多一次 I/O，但语义清晰、无兼容风险 - 真正零拷贝复用只适合元数据级场景，比如你只需要返回一个已存在文件的
file_id给前端，由前端直接请求下载 URL
哈希计算和索引这两步漏掉任意一个，秒传就退化成“假装秒传”。尤其多人并发上传同文件时，没索引的查询会成为性能瓶颈，而哈希算错会导致误判——这两个点最容易被跳过。
