直接在触发器里修改自身监听表必然出问题：mysql语法级报error 1442，sql server静默递归致卡死，postgresql默认递归需用pg_trigger_depth()>1手动拦截；数据库开关如recursive_triggers对自引用无效，唯一可靠解法是运行时标记（如sql server的context_info）或深度控制。
直接在触发器里改自己监听的表，一定会出问题——MySQL 报 ERROR 1442，SQL Server 静默递归卡死，PostgreSQL 默认放行但必须手动拦。靠数据库开关（比如 RECURSIVE_TRIGGERS）基本无效，真正能落地的解法是运行时标记或深度控制。
MySQL 触发器里 UPDATE 自己表会怎样？
不是“可能死循环”，而是语法级拒绝：只要触发器体里出现对本表的 UPDATE/INSERT/DELETE，立刻报错 ERROR 1442。哪怕加了 IF OLD.status != NEW.status 判断也没用。
-
BEFORE触发器安全做法：用SET NEW.col = ...修改即将写入的值，不碰原表 -
AFTER触发器真要落库（如记日志、同步状态），必须拆到中间表：INSERT INTO trigger_queue (table_name, pk, action) VALUES ('users', NEW.id, 'update') - 跨库操作不等于安全：
UPDATE other_db.users如果目标库该表也有触发器，照样递归 - 调试时别依赖日志表是否写入成功，先确认
log_warnings = 2和log_error路径是否可写
SQL Server 为什么 CONTEXT_INFO 比 @@NESTLEVEL 更可靠？
@@NESTLEVEL 不区分“合法嵌套”和“自调用”，在视图触发、存储过程调用等路径下行为不稳定；CONTEXT_INFO 是 128 字节二进制会话变量，每个连接独享，且不会被嵌套覆盖。
- 业务 SQL 执行前设标记：
SET CONTEXT_INFO 0x54524947474552（即 "TRIGGER" 的 ASCII 十六进制） - 触发器开头立即检查：
IF CONTEXT_INFO() = 0x54524947474552 RETURN - 避免用
CONVERT(VARCHAR, CONTEXT_INFO())比较——编码或截断会导致失效 - 若触发器被存储过程调用，过程开头设标记、结尾清空：
SET CONTEXT_INFO 0x0
PostgreSQL pg_trigger_depth() 为什么不能只看数值？
pg_trigger_depth() 返回的是当前触发器嵌套层数（首次为 1），但它只反映层级，不校验事件类型。如果触发器调用了函数，而函数里又间接更新了本表，仍可能绕过判断。
- 基础防护：
IF pg_trigger_depth() > 1 THEN RETURN; END IF; - 精细控制需组合
TG_OP：IF pg_trigger_depth() > 1 AND TG_OP = 'UPDATE' THEN RETURN; - 注意：该函数只对当前触发器生效，无法拦截由函数间接引发的再触发
最易被忽略的点是：所有运行时标记方案都依赖执行上下文的一致性——SQL Server 的 CONTEXT_INFO 要求业务层主动设/清，MySQL 的 max_sp_recursion_depth 必须在每次获取连接后重置，PostgreSQL 的 pg_trigger_depth() 在函数内嵌 DML 时会失效。没有银弹，只有匹配场景的轻量守卫。
