触发器适用于数据层确定性副作用，如自动生成时间戳、写审计日志、更新本地统计；联动外部系统应通过outbox表异步解耦；须严格文档化、统一管理和定期巡检。
用触发器做轻量级业务解耦
触发器不是万能的，但在特定场景下，它能帮你把核心业务逻辑和周边操作（比如日志记录、状态同步、缓存更新）隔离开。关键不在于“能不能用”，而在于“用在哪、怎么用才不埋雷”。
只在数据层做确定性副作用
触发器适合执行那些结果可预期、无外部依赖、失败不影响主事务的操作。比如：自动生成创建时间、更新修改时间戳、写入审计日志表、统计计数器累加。
- ✅ 推荐：INSERT 后写操作日志到本地 audit_log 表
- ✅ 推荐：UPDATE 订单状态时自动更新 order_summary 的待发货数
- ❌ 避免：调用 http 接口、发 MQ 消息、读写其他数据库实例
- ❌ 避免：涉及复杂条件分支或需要查大量关联表的逻辑
用“异步化+补偿”替代强依赖触发
如果必须联动外部系统（如通知下游服务），别让触发器直接调用。改成：触发器只写一条待处理记录到本地 outbox 表；由独立的后台任务轮询该表，执行外发动作并标记完成。这样主流程不卡顿，失败可重试，也方便监控和人工干预。
- outbox 表字段建议包含：id、event_type、payload（jsON）、status（pending/processing/success/failed）、created_at、processed_at
- 后台任务每秒拉取最多 N 条 status = ‘pending’ 的记录，成功后更新 status 和 processed_at
- 失败时记录 error_message，留作排查依据，支持手动重推
明确归属与维护边界
触发器本质是隐式逻辑，容易被忽视。上线前必须做到：文档注明触发时机、影响范围、是否可禁用；dba 或后端负责人统一管理 DDL；禁止开发人员私自增删改，全部走 sql 变更评审流程。
- 所有触发器命名带业务前缀，如 tr_order_status_change_audit
- 注释里写清：“本触发器仅用于写审计日志，不参与业务判断”
- 定期巡检：是否有未注释、长期未触发、或已失效（如引用字段被删）的触发器
基本上就这些。触发器不是黑魔法，而是可控的“数据钩子”。用对地方，它能让耦合变松；滥用，反而会把问题藏得更深。