根本原因是触发器执行时机晚于主语句的外键约束检查，导致依赖未提交主键值的操作失败；PostgreSQL可用DEFERRABLE INITIALLY DEFERRED推迟校验，MySQL需在BEFORE触发器中预设主键（如UUID）以规避问题。
为什么触发器里 INSERT/UPDATE 会报 FOREIGN KEY constraint failed
根本原因是触发器执行时机晚于主语句的约束检查。比如你在 AFTER INSERT 里去插入子表记录，但此时父表新行还没真正落盘（或事务未提交），外键校验已提前触发失败。SQLite 默认在语句级做约束检查，而 PostgreSQL/MySQL 的行为则取决于触发器类型和约束定义方式（DEFERRABLE 或非延迟）。
-
AFTER触发器无法绕过主语句的外键预检，尤其当插入依赖尚未 commit 的主键值时 - 若触发器试图用
NEW.id插入子表，但该id尚未通过外键合法性验证（如引用了不存在的父记录），就会直接报错 - MySQL 中
BEFORE INSERT可修改NEW值，但不能解决跨表插入引发的外键冲突
PostgreSQL：用 DEFERRABLE INITIALLY DEFERRED 推迟外键检查
这是最干净的解法——把外键约束从“语句后立刻检查”改为“事务提交前再检查”，给触发器留出操作窗口。
ALTER TABLE child_table
DROP CONSTRAINT fk_child_parent,
ADD CONSTRAINT fk_child_parent
FOREIGN KEY (parent_id) REFERENCES parent_table(id)
DEFERRABLE INITIALLY DEFERRED;- 必须在触发器执行前建好带
DEFERRABLE INITIALLY DEFERRED的外键，普通NOT VALID或默认约束无效 - 触发器中可安全使用
INSERT INTO child_table (parent_id) VALUES (NEW.id)，只要事务最终满足约束即可 - 注意：所有依赖该外键的 DML 都会受此影响，需确认业务能接受延迟校验（例如允许中间态不一致）
MySQL：改用 BEFORE 触发器 + 手动维护关联逻辑
MySQL 不支持延迟外键，且 AFTER 触发器无法规避约束报错。只能把关联动作前置，并确保主键可用。
- 如果父表主键是自增，
BEFORE INSERT里无法获取NEW.id（它还是 0 或 NULL），必须改用AFTER INSERT并接受风险，或换 UUID - 更稳妥的做法是：在应用层生成唯一 ID（如
UUID()），在BEFORE INSERT中赋给NEW.id，再让触发器用这个值写子表 - 示例：
CREATE TRIGGER parent_insert_before BEFORE INSERT ON parent_table FOR EACH ROW SET NEW.id = UUID();
然后AFTER INSERT触发器才能可靠引用NEW.id
通用避坑点：别在触发器里做跨事务操作或调用不可控函数
很多看似合理的写法会在高并发或特定隔离级别下崩掉，比如：
- 在触发器里调用
NOW()、RAND()、UUID_SHORT()等非确定性函数，可能被优化器误判或导致复制异常 - 试图在触发器里
COMMIT或START TRANSACTION—— MySQL 直接报错，PostgreSQL 不允许 - 触发器里查自己正在修改的表（如
SELECT * FROM parent_table WHERE id = NEW.id），在 MySQL 中会报Can't update table 'parent_table' in stored function/trigger - SQL Server 用户注意：
INSTEAD OF触发器能完全接管操作，但需手动实现原 INSERT 逻辑，容易漏字段
外键冲突表面是语法问题，实际常暴露的是数据模型耦合过紧——触发器成了补丁，而不是设计的一部分。真要频繁靠触发器维系父子一致性，不如回头看看能不能合并表、加物化视图，或者把逻辑提到应用层统一管控。
