应使用事务控制可见性：测试开头BEGIN，结尾ROLLBACK；INSERT后立即SELECT验证拦截效果；PostgreSQL需BEGIN...EXCEPTION捕获RAISE EXCEPTION；覆盖触发器依赖的字段组合边界；避免在测试中拼写DDL，改用预部署触发器；日志类触发器优先测通知是否漏发。
怎么用 SQLite 或 PostgreSQL 的事务模拟触发器的“前/后状态”
触发器本质是依赖上下文执行的逻辑，单元测试里没法靠 SELECT 看中间态——必须用事务控制可见性。PostgreSQL 支持 SAVEPOINT，SQLite 支持 SAVEPOINT 和 ROLLBACK TO，但 MySQL 8.0+ 才稳定支持，5.7 及之前只能靠完整事务回滚，测多步链式触发会串扰。
实操建议：
- 在测试函数开头显式开启事务（
BEGIN），结尾统一ROLLBACK，不依赖框架自动清理 - 想验证触发器是否“阻止了插入”，得在
INSERT后立刻SELECT，再ROLLBACK；不能等事务外查，否则看不到被拦截的效果 - PostgreSQL 中若触发器含
RAISE EXCEPTION，需用BEGIN ... EXCEPTION块捕获，否则整个事务中断，后续断言无法执行
INSERT/UPDATE/DELETE 触发器要分别覆盖哪些数据组合
边界不是指“空值”或“超长字符串”这种通用校验，而是触发器逻辑本身依赖的字段组合。比如一个 UPDATE 触发器只在 status 从 'pending' 变为 'done' 时扣库存，那必须测：status 不变、status 反向变（'done' → 'pending'）、status 变但其他字段也改（触发器是否误读 OLD 值）。
常见错误现象：
-
BEFORE UPDATE触发器里修改了NEW.amount，但测试只检查最终表数据，没验证触发器是否真改了它（要用RETURN NEW后再SELECT当前行） - 对
INSERT触发器测NULL输入，却漏掉DEFAULT列（如created_at TIMESTAMP DEFAULT NOW()）——触发器可能读不到预期的默认值 - 批量操作（
INSERT INTO ... SELECT）下，某些数据库（如 MySQL）的行级触发器会按行触发，但OLD/NEW仍是单行，别误以为能拿到整个结果集
怎么让测试代码不和触发器 SQL 强耦合
直接在测试里拼接 CREATE TRIGGER 语句，等于把 DDL 当业务逻辑写死，一旦触发器重命名或条件改写，所有测试全挂。更稳的方式是：测试只调用已部署的触发器，重点验证输入输出，而非定义本身。
实操建议：
- 测试前确保目标表和触发器已存在（CI 环境走迁移脚本加载，本地用固定 SQL 文件初始化）
- 用独立 schema 或临时表（
CREATE TEMP TABLE）隔离测试，避免和其他测试用例的触发器互相干扰 - 不要在测试里
DROP TRIGGER再重建——PostgreSQL 允许CREATE OR REPLACE FUNCTION，但触发器不支持OR REPLACE，强行删重建会破坏依赖顺序
为什么日志类触发器最难测，以及怎么绕过它
带 INSERT INTO audit_log 的触发器，本质是跨表副作用，测它就得连审计表一起查。但审计表往往有自增 ID、时间戳、session_id 等不可预测字段，导致断言难写死。
性能与兼容性影响：
- 审计触发器若用
AFTER INSERT，且审计表没索引，大批量导入时会拖慢主表写入——测试时用EXPLAIN ANALYZE跑单条语句看不出问题，得压测 1000 行以上 - 有些团队用
pg_notify或外部队列解耦审计，这时触发器本身只发消息，测试重点就变成验证通知内容，而不是查表 - 真正该测的是“是否漏发”：比如主表事务因约束失败回滚，触发器里的
NOTIFY是否也被回滚？PostgreSQL 中NOTIFY不受事务控制，这点容易被忽略
复杂点在于，触发器不是纯函数——它活在数据库的事务生命周期里，而测试框架通常活在应用层。你得接受一部分逻辑永远无法“完全隔离”地测，能控住输入、看清输出、守住关键路径，就已经踩住底线了。
