触发器在测试中应被绕过而非模拟，因其隐式副作用会干扰断言边界；仅两类场景需针对性处理：隔离应用层逻辑验证（如禁用触发器）和直接验证触发器输出结果。
不需要频繁模拟触发器执行环境——绝大多数自动化测试场景下，模拟它反而是错的起点。
触发器在测试里不该“被模拟”，而该“被绕过”
触发器是数据库层的隐式逻辑，一旦进入测试流程，就会干扰断言边界：你本想验证应用层插入 orders 是否成功，结果触发器顺手更新了 products 库存、写了审计日志、还调用了存储过程。这些副作用让测试失败原因变得模糊。
- 真实故障常藏在“多了一行日志”或“少更新了一次统计值”这种非主路径上，但测试用例没覆盖
- MySQL 的
FOR EACH ROW在批量INSERT时逐行触发，测试数据量一上来就变慢，掩盖真正的性能瓶颈 - PostgreSQL 的
WHEN (condition)表达式若依赖当前时间或序列值，会导致测试不可重现
真正需要“模拟触发器行为”的只有两类情况
不是为了测触发器本身是否运行，而是为了隔离它对核心逻辑的影响。
-
测应用层写入逻辑时，确保不被触发器污染：在事务开始前执行
SET session_replication_role = 'replica'（PostgreSQL）或临时禁用触发器（MySQL 需ALTER TABLE ... DISABLE TRIGGER），比 mock 更干净 -
验证触发器输出是否符合预期：此时应直接测触发器注册状态和副作用结果，例如
SELECT COUNT(*) FROM information_schema.TRIGGERS WHERE TRIGGER_NAME = 'trg_order_audit'+SELECT * FROM order_audit_log ORDER BY id DESC LIMIT 1
用 INSERT SELECT 初始化数据时，为什么反而要删掉触发器？
因为 INSERT SELECT 是语句级批量操作，而触发器默认是行级——1000 行数据会触发 1000 次逻辑，可能锁表、拖慢导入、甚至因事务膨胀导致测试超时。
- 测试前执行
DROP TRIGGER IF EXISTS trg_after_insert_orders是常规操作，不是权宜之计 - 如果业务强依赖触发器逻辑（如必须生成唯一流水号），那就说明这个逻辑不该在触发器里，而该抽成应用层可测试函数
- 生产库导出的测试数据快照，必须确认是否已清除触发器副作用（比如审计表里混入了测试期间的脏记录）
最常被忽略的一点：测试环境里的触发器，哪怕只启用了一次，也可能留下未回滚的全局状态——比如 MySQL 的 sql_log_bin = 0 没恢复，后续测试产生的 binlog 就会缺失；PostgreSQL 的 SECURITY DEFINER 函数权限可能污染测试账户。这不是“模拟不到位”，而是“清理不彻底”。
