触发器不能替代程序校验，仅作为数据一致性的兜底机制；它适用于无外部依赖的强一致性约束，如字段范围检查、审计字段填充、防误删及物化约束维护。
不能替代，只能补充——MySQL触发器不是校验层的“替身”，而是数据一致性的“兜底守门员”。
为什么触发器不能替代程序校验
触发器运行在数据库层，而程序校验发生在应用层（如Java/Python/Node.js），二者职责和能力边界完全不同：
-
触发器无法访问HTTP上下文、用户会话、缓存状态或外部API，比如“当前用户是否有权限修改该订单”这种业务判断，它根本看不到 -
触发器不支持事务外重试、异步补偿、日志分级或监控埋点，出错时只能中断并回滚，没法像应用层那样优雅降级或告警后人工介入 -
触发器无法对批量请求做统一预检（如一次导入1000条数据），它按行触发，性能差且逻辑割裂，而程序可先校验再批量提交 -
触发器报错信息模糊、堆栈不可追溯，比如SIGNAL抛出的SQLSTATE '45000'，前端拿到后很难映射到具体业务语义，而程序能返回{ code: "ORDER_AMOUNT_INVALID", message: "金额必须在0~99999之间" }
哪些场景下触发器反而更可靠
当校验逻辑只依赖本表字段、无外部依赖、且必须强一致性时，触发器比程序更难绕过：
-
BEFORE INSERT/UPDATE中限制字段取值范围（如age BETWEEN 0 AND 150） - 自动填充审计字段：
SET NEW.created_at = NOW(), NEW.updated_at = NOW() - 防止误删核心数据：
BEFORE DELETE ON config_table中用SIGNAL拦截非管理员操作 - 维护物化约束：如确保
end_time > start_time，哪怕应用层漏校验，数据库也拦得住
这类逻辑一旦写进触发器，就对所有接入方式（命令行、ORM、ETL工具、其他语言连接）一视同仁，真正实现“一次定义，全局生效”。
常见踩坑：你以为在补位，其实是在埋雷
很多团队用触发器“补程序校验的漏”，结果引发更隐蔽的问题：
-
在AFTER触发器里UPDATE同一张表→ 直接报错Can't update table 'xxx' in stored function/trigger，MySQL明确禁止 -
用AFTER UPDATE触发器同步冗余字段→ 若同步失败（如目标表字段变更），整个UPDATE语句回滚，业务感知为“莫名其妙失败” -
在触发器里调用存储函数或查询大表→ 行级触发+高并发=锁等待雪崩，TPS断崖下跌 -
未设<code>sql_mode = STRICT_TRANS_TABLES→ 字符串超长被静默截断，触发器里的IF LENGTH(NEW.name) > 20永远不生效
推荐分工：程序校验 + 触发器兜底
真实健壮的系统，应该这样分层防御：
程序层（第一道防线） ├─ 检查用户权限、业务状态、第三方服务可用性 ├─ 做格式转换（如时间字符串→datetime）、空值默认值填充 ├─ 批量预校验（如导入前检查1000条数据是否都满足规则） └─ 返回清晰、带上下文的错误码和提示 数据库层（最后一道防线） ├─ <code>BEFORE</code>触发器强制字段约束（非空、范围、枚举值） ├─ 自动填充<code>created_at</code>/<code>updated_at</code>/<code>version</code> ├─ <code>AFTER</code>触发器仅做轻量日志记录（INSERT INTO audit_log...） └─ 所有触发器逻辑控制在5行以内，不查表、不调函数、不跨库
记住：触发器不是让你少写几行代码的地方，而是当你怀疑“会不会有人绕过应用直接连库改数据”时，唯一能信得过的那把锁。它不解决复杂问题，只守住最基础、最不该破的底线。
