触发器逻辑必须挪到应用层，因跨数据库兼容性差（如MySQL的ERROR 1442、SQL Server的TRY CATCH在PostgreSQL中不存在、金仓不支持@@ERROR），硬改语法成本高且易漏；而应用层可统一事务、加日志、做幂等、接监控，并规避数据库限制。
为什么触发器逻辑必须挪到应用层
不是所有数据库都允许你随便改触发器，尤其跨厂商迁移时——MySQL 不让触发器更新本表（ERROR 1442），SQL Server 的 TRY CATCH 在 PostgreSQL 里根本不存在，金仓虽支持 sql_compatibility = 'SQLSERVER'，但遇到 @@ERROR 或游标就直接编译失败。硬改 SQL 语法成本高、易漏、难测试，而把逻辑提到应用层，既能绕过所有数据库限制，又能统一事务边界、加日志、做幂等、接监控。
哪些触发器逻辑适合搬，哪些不该搬
适合搬的：业务强关联、需调用外部服务、涉及多表一致性校验、依赖应用上下文（如当前登录用户、请求 ID）、需要重试或降级策略的逻辑。比如“订单插入后发 Kafka 消息并更新库存”或“用户注册后调用微信模板消息接口”。
不该搬的：纯数据清洗类（如自动补全 created_at）、极低延迟要求（微秒级）、无状态字段默认值填充（uuid()、NOW()）。这类逻辑留在数据库反而更轻量、更可靠。
- 判断标准很简单：如果逻辑里出现
INSERT INTO event_queue、curl、send_email()、current_user_id()，那就该搬 - 如果只有
SET NEW.status = 'pending'或NEW.updated_at = NOW()，留着就行
搬的时候怎么保证事务一致性
不能简单把触发器 SQL 剪切粘贴进业务代码里就完事。原触发器在数据库事务内自动生效，而应用层操作若没包进同一事务，就会出现“订单写了，但库存没扣”的脏状态。
- 必须用同一个数据库连接执行 INSERT + UPDATE，不能用两个独立
db.Exec() - 避免在事务中调外部 HTTP 接口——超时或失败会导致整个事务回滚，影响主流程；应拆成“写本地事务表 + 异步消费”两阶段
- MySQL 8.0+ 支持
XA分布式事务，但实际项目中极少启用；更推荐用event_queue表 + 定时任务/消息队列兜底 - PostgreSQL 可用
LISTEN/NOTIFY在 commit 后发通知，比轮询更高效
迁移后如何验证逻辑没丢、没重复
最容易被忽略的是“旧触发器还在跑”。导出 SQL 时若没加 --skip-triggers，或者目标库没清空 information_schema.TRIGGERS，老触发器可能和新应用代码同时生效，造成双倍更新、状态错乱。
- 上线前务必执行：
SELECT TRIGGER_NAME, EVENT_OBJECT_TABLE FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = 'mydb';，确认结果为空 - 在应用日志里埋点，记录每次“订单创建 + 库存更新”是否在同一 trace ID 下完成
- 对关键字段（如
stock_count）做抽样比对：查历史订单对应的库存变更时间戳，是否与应用日志里记录的操作时间一致
真正麻烦的从来不是怎么写新代码，而是怎么确保旧机制彻底停运、新路径完全接管——这点不盯死，再严谨的迁移也会在凌晨三点爆出来。
