gridfs不支持change streams直接监听文件变更，因其将文件操作拆分为fs.files和fs.chunks的多次非原子写入，导致事件漏发、乱序且语义不清；需应用层统一收口，通过事务化写入file_events集合实现可靠监听。
GridFS 本身不支持 Change Streams 直接监听文件变更。你无法对 fs.files 或 fs.chunks 集合调用 watch() 并稳定获取“上传/删除/更新文件”这类语义事件——因为 GridFS 是客户端库封装的逻辑，不是原子操作，底层会拆成多条 write（insert into fs.files + 多次 insert into fs.chunks），Change Streams 只能看到这些碎片化操作，无法还原成“一个文件被写入”。
为什么直接 watch fs.files 会漏事件、乱序、难判断
GridFS 写入一个文件，实际触发至少两次独立写操作：
- 先 insert 一条元数据到
fs.files（含_id、filename、length等） - 再分片 insert 多条 chunk 到
fs.chunks（每条 chunk 的files_id指向上面那个_id）
Change Streams 会分别捕获这两类 insert 事件，但：
- 没有事务保证：如果写入中途失败，
fs.files已写入但fs.chunks不全，Change Streams 却已发出“文件元数据已创建”事件 - 无因果顺序保障：网络延迟或副本集同步差异可能导致
fs.chunks事件先于fs.files到达监听端 -
operationType: "insert"无法区分是“真正的新文件”还是“某个大文件的中间 chunk”
可行方案：在应用层统一收口文件操作
绕过 GridFS 底层细节，把所有文件写入/删除逻辑集中到你的业务代码中，并在成功完成 GridFS 操作后，主动写一条轻量级控制文档到专用集合（例如 file_events），再让 Change Streams 监听这个集合。
- 上传成功后：
db.file_events.insert({ type: "file_uploaded", fileId: ObjectId("..."), filename: "report.pdf", ts: new Date() }) - 删除成功后：
db.file_events.insert({ type: "file_deleted", fileId: ObjectId("..."), ts: new Date() }) - 确保这一步与 GridFS 操作在同一个事务里（MongoDB 6.0+ 支持跨集合事务），或至少用幂等写+重试兜底
然后监听：db.file_events.watch([ { $match: { operationType: "insert" } } ])。这样每条事件都明确对应一次用户级文件动作。
必须开启 pre/post images 才能安全关联文件元数据
如果你仍想从 fs.files 入手（比如已有遗留系统无法改写入逻辑），那至少得让 fs.files 集合启用变更前后像，否则 update/delete 事件里拿不到完整上下文：
- 执行：
db.runCommand({ collMod: "fs.files", changeStreamPreAndPostImages: { enabled: true } }) - 监听时加选项：
{ fullDocument: "required", fullDocumentBeforeChange: "required" } - 这样在
delete事件中，fullDocument就是你能拿到的最后完整元数据（含filename、uploadDate等），而不仅是documentKey
注意：fs.chunks 集合通常不需要开启 pre/post images，它本身不含业务语义字段。
真正难的不是监听，而是定义清楚“什么才算一次文件变更”。GridFS 没有原子文件事件，所有基于它的监听都得靠应用层补语义——这点容易被忽略，直到上线后发现 PDF 上传成功却没触发通知，或者删了文件却收到两条重复 delete 事件。
