触发器不能替代程序层校验，因其仅在SQL写入路径生效，无法覆盖直连修改、批量导入、多表事务协调等场景，且缺乏应用上下文、难以维护调试、存在性能与复制风险。
触发器能做基础校验，但不能替代程序层校验
MySQL 触发器（BEFORE INSERT、BEFORE UPDATE）确实可以拦截非法数据写入，比如拒绝空邮箱、校验手机号格式、阻止负库存扣减。但它只在 SQL 写入路径生效，对以下场景完全无感：
• 应用直接执行 UPDATE order SET status = 'paid' WHERE id = 123（绕过业务逻辑）
• 批量导入用 LOAD DATA INFILE 或 INSERT ... SELECT
• 其他服务直连数据库（如数据分析脚本、运维工具）
• 多表联合变更中，触发器无法跨语句感知事务全局状态（例如“用户注册成功后必须创建默认配置”，这需要应用控制流程）
触发器无法访问应用上下文和会话信息
触发器运行在存储引擎层，拿不到 HTTP Header、JWT 用户 ID、IP 地址、请求 traceID 这类信息。常见误用是想在 BEFORE INSERT 里自动填充 created_by 字段——除非应用显式传入（如 INSERT INTO user (name, created_by) VALUES ('a', @current_user_id)），否则触发器只能依赖 USER() 或 CURRENT_USER()，而这反映的是数据库账号，不是业务用户。
• USER() 返回连接时的用户名@host，可能为 'app@10.0.1.5'
• CURRENT_USER() 返回授权匹配的账号，常为 'app@%'
两者都和“张三（ID: 8891）在管理后台提交”毫无关系
复杂校验逻辑会让触发器难以维护和调试
一旦校验涉及多表 JOIN、子查询、函数调用或外部状态（如 Redis 缓存、HTTP 调用），触发器就会变成黑盒：出错时只报 ERROR 1422: Explicit or implicit commit is not allowed in stored function or trigger 或静默失败；日志只能靠 SELECT 输出到客户端（不推荐），没法打 trace 或集成 Sentry。
• 不支持 START TRANSACTION / COMMIT，无法控制事务边界
• 不能调用存储过程以外的外部服务（MySQL 8.0+ 仍不支持 HTTP 客户端）
• 错误处理仅限 SIGNAL SQLSTATE，无法返回结构化错误码或提示文案
• 多个触发器按定义顺序执行，但顺序难追踪，尤其跨表时易引发死锁或递归（如 A 表触发器改 B 表，B 表触发器又回写 A 表）
性能与兼容性风险比想象中高
每个触发器都会增加 DML 延迟，尤其是 BEFORE 触发器中做全表扫描或复杂计算时。更隐蔽的问题是复制兼容性：
• MySQL 主从复制中，基于语句复制（SBR）下，触发器在从库**不会再次触发**（只重放原始 SQL）；而基于行复制（RBR）下，触发器在从库**会重复触发**（重放变更后的行）——行为不一致，极易导致主从数据偏差
• 使用 GTID 时，若触发器内含非确定性函数（如 NOW()、RAND()、UUID()），会导致 binlog 无法安全重放
• 云数据库（如阿里云 RDS、AWS RDS）可能禁用触发器，或限制其权限（如禁止 CREATE TRIGGER）
真正该用触发器的地方很窄：审计字段自动填充（updated_at）、单表级约束增强（如确保 end_time > start_time）、防止误删（BEFORE DELETE 抛异常）。只要校验逻辑牵扯到业务规则、用户身份、外部系统或跨资源协调，就得交给应用代码——那里才有完整的上下文、可测的单元、可控的错误路径。
