数据库触发器不支持异常捕获与降级，必须在BEFORE阶段用SIGNAL/RAISERROR/RAISE_APPLICATION_ERROR主动报错；MySQL需显式设MESSAGE_TEXT且SQLSTATE用'45000'；SQL Server需RAISERROR配ROLLBACK且severity≥16；Oracle错误号限-20000~-20999、消息≤2048字节；复杂逻辑应移至应用层预检。
不能“优雅抛出”，只能“提前中断并附带可读消息”——所有数据库的触发器都不支持异常捕获与降级，你必须在 BEFORE 阶段主动判断、主动 SIGNAL/THROW/RAISE_APPLICATION_ERROR，否则错误就是系统级的模糊报错。
MySQL 触发器里用 SIGNAL 报错，客户端收不到中文？
不是客户端不支持，是你没写对 MESSAGE_TEXT。SIGNAL 必须显式赋值，否则 MySQL 默认返回空消息或 SQLSTATE '45000' 对应的英文占位符。
-
SIGNAL SQLSTATE '45000'是标准写法，'45000'表示通用用户错误，别用'23000'（那是约束错误专用），否则前端无法区分是业务校验失败还是外键崩了 - 必须紧跟着
SET MESSAGE_TEXT = '该邮箱已被注册'，中间不能换行、不能有注释、不能漏等号 - 确保你的客户端驱动（如 Python 的
pymysql、Java 的JDBC）启用了 SQLSTATE 解析——多数现代驱动默认支持，但老版本 PDO 可能需要手动检查$e->getSQLState()是否为'45000' - 别在 SIGNAL 前查无索引字段，比如
IF EXISTS (SELECT 1 FROM users WHERE SUBSTRING(email, 1, 10) = NEW.email)，这会全表扫描，写入直接卡住
SQL Server 触发器里 RAISERROR 后前端还是收到 500？
因为 RAISERROR 不自动回滚，也不强制中断事务流，上层应用看到的是“语句执行完了但数据不对”，而不是“校验失败”。更糟的是，如果没设对 severity，C# 或 Java 根本捕获不到这个异常。
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
-
RAISERROR('用户名已存在', 16, 1)中的16是关键：必须 ≥ 11 才进 CATCH，≥ 16 才被 .NET 的SqlException捕获；用10就等于静默日志，前端啥也收不到 - 必须配
ROLLBACK TRANSACTION，且要放在 RAISERROR 同一作用域内，例如：IF EXISTS (SELECT 1 FROM users WHERE username = @username) BEGIN ROLLBACK TRANSACTION; RAISERROR('用户名已存在', 16, 1); RETURN; END - 别依赖 TRY…CATCH 包裹整个触发器逻辑——触发器本身就是一个批处理单元，BEGIN TRY 和 BEGIN CATCH 必须连续，中间插个
GO或动态 SQL 就失效 - 应用层要检查
SqlException.Number：SQL Server 自定义错误号从50000起，别把547（外键错误）也当成业务提示处理
Oracle 触发器里 RAISE_APPLICATION_ERROR 总编译失败？
Oracle 对错误号和消息长度卡得极死，不是语法错，是硬性数值限制，编译器直接拒绝。
立即学习“前端免费学习笔记（深入）”；
- 错误号只能是
-20000到-20999之间的整数，传-1000或-30000会报PLS-00302，不是运行时报错，是建触发器时就失败 -
MESSAGE_TEXT实际是第二个参数，必须非空字符串，写成RAISE_APPLICATION_ERROR(-20001, '')会报ORA-20000（只剩一个冒号） - 消息内容超 2048 字节会静默截断，不报错也不警告，所以别堆砌上下文，一句话说清：“订单金额超出单日限额”比“根据风控策略第3.2条……”更可靠
- 不能在 SQL 表达式里调用，比如
SELECT * FROM orders WHERE RAISE_APPLICATION_ERROR(-20001, 'no') = 1是非法的，只能放在 PL/SQL 块里（即触发器BEGIN ... END;内）
真正容易被忽略的是：触发器没有“异常处理层”，它不是函数也不是存储过程。你写的每一条校验，都得假设它一定会被执行、一定会中断、一定不能被绕过——所以复杂逻辑（比如跨库查、调外部 API、多步状态校验）根本不该放触发器里，而该移到应用层做预检。触发器只适合做“原子级、索引友好、无副作用”的守门人。
