Change Streams 无法直接监听 GridFS 文件变动，因GridFS是fs.files与fs.chunks两个集合协同实现的抽象层，其操作被拆解为底层CRUD但无文件级语义事件；监听底层集合事件粒度细、顺序不可靠、缺乏业务字段，需应用层通过审计集合封装语义。
Change Streams 无法直接监听 GridFS 文件变动，因为 GridFS 本身不是普通集合，而是由 files 和 chunks 两个底层集合协同实现的抽象层；MongoDB 不为 GridFS 操作生成独立的变更事件，所有写入都拆解为对这两个集合的常规 CRUD，但这些操作不触发语义级的“文件上传/删除”事件。
为什么 collection.watch() 对 fs.files / fs.chunks 收不到预期事件
GridFS 的文件写入本质是：先向 fs.files 插入元数据文档，再向 fs.chunks 批量插入分块文档；删除则是先删 fs.chunks、再删 fs.files。这些操作确实会触发 insert 和 delete 类型的 Change Stream 事件，但存在严重问题：
- 事件粒度太细：一个 10MB 文件上传会生成上百条
insert事件（每个 chunk 一条），且无上下文关联，无法还原为“文件已上传” - 顺序不可靠：
fs.files和fs.chunks写入不在同一事务中（GridFS 不支持跨集合事务），无法保证原子性或时序一致性 - 缺乏语义标识：事件里没有
filename、contentType等业务字段，只有原始 BSON，需额外查表拼接 -
fs.chunks的insert事件不带fullDocument（因 WiredTiger 对小文档默认不存完整快照），只返回_id和files_id
想监听“文件级”变更，必须自己封装语义层
可行路径是放弃监听底层集合，改为在应用层统一收口所有 GridFS 操作，并在成功后主动写入一条带业务语义的审计文档到独立集合（如 gridfs_audit），再监听该集合：
- 上传完成时：
db.gridfs_audit.insertOne({ action: "upload", filename: "report.pdf", size: 10485760, uploadedAt: new Date(), fileId: ObjectId("...") }) - 删除完成时：
db.gridfs_audit.insertOne({ action: "delete", filename: "report.pdf", deletedAt: new Date(), fileId: ObjectId("...") }) - 监听该集合：
db.gridfs_audit.watch([ { $match: { operationType: { $in: ["insert"] } } } ]) - 确保
gridfs_audit集合启用前像/后像（如需获取旧值），并配置writeConcern: "majority"
如果硬要监听 fs.files，注意三个关键限制
即使你坚持监听 fs.files，也必须接受以下现实约束：
-
fs.files的insert事件只代表“元数据已写入”，不代表文件内容已全部写完——fs.chunks可能还在持续写入中，此时读取文件会失败 -
fs.files的delete事件发生时，fs.chunks可能尚未清理完毕，下游若立即清理本地缓存会导致 404 - MongoDB 5.0 默认禁用
preAndPostImages，若想从update事件中拿到修改前的length或md5，必须显式开启：db.runCommand({ collMod: "fs.files", changeStreamPreAndPostImages: { enabled: true } })，且数据库级参数也要同步设置
真正可靠的方案永远是控制写入口，而不是逆向解析底层行为；GridFS 的设计本就不是为变更通知而生，把它当黑盒用，比试图监听它更省心。
