mongodb 没有原生 update 后钩子，因其无状态、非事件驱动设计，update 操作仅返回结果而不广播事件；changestreams 为异步延迟通知，无法替代同步业务逻辑，事务内也不支持自动触发钩子。
MongoDB 本身不提供原生的“更新后触发钩子”机制，所有类似 afterUpdate 的逻辑必须由应用层主动实现，不能依赖服务端自动回调。
为什么 MongoDB 没有 update 后钩子？
MongoDB 是一个无状态、面向文档的数据库，设计上不包含事件驱动模型。像 updateOne、updateMany 这类操作只返回写入结果（如 nMatched、nModified），不会广播事件或调用回调函数。
- 官方驱动（如 Node.js 的
mongodb、Go 的mongo-go-driver）均未暴露 post-update hook 接口 -
change streams可监听变更，但它是异步、延迟、非事务性通知，不能用于同步业务逻辑（比如更新后立刻校验并抛错） - 所谓“钩子”只能是代码层面的封装，不是数据库能力
如何在 Go 项目中模拟 update 后钩子？
如果你用的是 go-zero 生成的 MongoDB 模型，最直接的方式是在调用 Update 方法前后手动插入逻辑 —— 但要注意：这不是拦截器，而是显式调用。
- 不要试图修改底层 driver，而应在 service 层包装
Update调用 - 例如：先执行
model.Update(ctx, id, data)，再调用afterUpdateHook(id, data) - 若需保证原子性（比如更新失败时钩子也不执行），必须把钩子逻辑放在同一个事务里 —— 但 MongoDB 的事务不支持跨集合触发动作，且钩子本身通常涉及日志、缓存、通知等外部操作，天然不适合放进事务
- go-zero 模板中提到的
FindHook是查询钩子，它不适用于更新场景；强行复用会破坏职责分离，且Update方法默认不接受钩子参数
change stream 能替代 update 后钩子吗？
能监听到更新，但不能当作“同步钩子”使用。
-
change stream延迟通常在毫秒级，但不可预测；网络抖动、副本集同步延迟都可能导致事件晚于业务逻辑执行 - 它监听的是 oplog，所以无法捕获
upsert: true时到底是 insert 还是 update ——operationType字段在 upsert 场景下统一为update - 如果钩子要修改同一集合（比如更新后补全字段），可能引发二次 change stream 触发，导致无限循环
- 示例监听片段：
pipeline := []bson.D{{{"$match", bson.D{{"operationType", "update"}}}}} changeStream, err := collection.Watch(ctx, pipeline)—— 这只是消费端，不参与主流程控制
真正容易被忽略的点是：很多人以为加个 defer 或包装一层函数就等于有了“钩子”，但没考虑错误路径 —— 比如 Update 失败时，钩子是否该跳过？是否要重试？这些必须显式判断，没有魔法。
