触发器不支持参数，需通过NEW/OLD行数据、会话变量或配置表实现动态逻辑；跨会话控制应使用@@session变量或trigger_config表，避免同表查询和不可靠的函数调用。
触发器里根本不能用参数，所谓“参数控制”得换思路
SQL 触发器（如 BEFORE INSERT、AFTER UPDATE）本身不支持传入参数——这是绝大多数人踩坑的起点。你没法像写存储过程那样写 CREATE TRIGGER ... (p_mode VARCHAR)。所谓“通用型”，实际是靠读取运行时上下文（比如新旧行值、会话变量、系统表或临时表）来动态分支逻辑。
用 NEW / OLD 行数据做条件判断最可靠
在 INSERT 或 UPDATE 触发器中，NEW 和 OLD 是唯一稳定可用的“上下文变量”。它们不是参数，但能反映当前操作的真实数据，是实现分支逻辑的基石。
-
INSERT触发器只有NEW可用，OLD为NULL -
DELETE触发器只有OLD可用，NEW为NULL -
UPDATE触发器两者都可用，适合对比字段变化（比如只在status从 'draft' → 'published' 时发通知） - 避免在触发器里查同表（会导致
Can't update table 'xxx' in stored function/trigger错误），要用INSERT ... SELECT或写到其他表
示例：仅当插入的 priority > 10 时才写审计日志
CREATE TRIGGER t_insert_audit
BEFORE INSERT ON tasks
FOR EACH ROW
BEGIN
IF NEW.priority > 10 THEN
INSERT INTO audit_log (table_name, action, row_id)
VALUES ('tasks', 'INSERT_HIGH_PRIO', NEW.id);
END IF;
END;
想跨会话传“配置开关”，得靠 session_variables 或专用配置表
如果真需要外部控制触发器行为（比如灰度开启某校验），不能靠触发器参数，而要借助 MySQL 的会话级变量或独立配置表。注意：全局变量对触发器不可见，必须用 @@session.xxx。
- 设置开关：
SET @trigger_skip_validation = 1; - 触发器内检查：
IF @trigger_skip_validation IS NULL OR @trigger_skip_validation = 0 THEN ... - 更健壮的做法是建一张
trigger_config表，按表名+触发器名存启用状态，用SELECT enabled FROM trigger_config WHERE table_name = 'orders'查询（记得加SELECT ... INTO @enabled避免直接用于表达式） - 别在触发器里调用函数去查配置表并返回布尔值——MySQL 不允许触发器中调用含
SELECT的函数（除非是READS SQL DATA且显式声明，但极易出错）
PostgreSQL 用户注意：它支持触发器函数带参数，但和你想的不一样
PostgreSQL 的 CREATE TRIGGER ... EXECUTE FUNCTION fn_name(param1, param2) 看似有参数，其实这些“参数”是静态字符串字面量，在创建触发器时就固化了，运行时无法更改。它们常用于传递配置键名（如 'audit_enabled'），真正逻辑仍需在函数体内查表或读配置。
- 参数本质是
pg_trigger.tgargs字节数组，只能是字符串，不能传变量或表达式 - 函数内用
tg_argv[0]读取第一个参数，但无法做类型转换（全是 text） - 如果你依赖这个“参数”做关键分支，上线后改配置就得
DROP/CREATE TRIGGER，不适合高频调整场景
所以 PostgreSQL 下也建议把动态开关放表里，而不是塞进触发器参数。
真正难的不是写通用模板，而是想清楚：哪些逻辑必须塞进触发器（比如强一致性约束），哪些其实该挪到应用层或定时任务里。越想让它“通用”，越容易在事务边界、锁行为、错误传播上翻车。
