RAISERROR严重级别必须≥11才能触发CATCH，0–10仅为信息性消息；msg_str需用N'xxx'声明Unicode；推荐severity=16、state=1–127；应使用THROW替代msg_id方式；事务需手动ROLLBACK。
RAISERROR 严重级别必须 ≥11 才能触发 CATCH
很多人写完 RAISERROR 却发现 CATCH 块没执行，根本原因是严重级别（severity）设成了 10 或更低。SQL Server 规定：只有 severity 在 11–19 范围内，才会中断执行并跳转到 CATCH；0–10 属于“信息性消息”，仅输出，不中断流程。
常见错误写法：RAISERROR('Invalid input', 10, 1) —— 这条语句会打印消息，但后续代码照常运行，CATCH 完全不会被进入。
- 要用在事务回滚或逻辑终止场景，
severity至少填11，推荐用16（用户定义错误的标准级别） -
state必须是 1–127 的整数，填0或128会直接报语法错误 - 不要依赖
@@ERROR判断自定义错误——它只捕获上一条语句的错误号，且在RAISERROR后可能被覆盖；改用ERROR_NUMBER()更可靠
msg_str 格式字符串必须用 N'xxx' 声明 Unicode
如果你传入中文、特殊符号或长度超过几百字符的动态消息，却看到乱码或被截断成问号，大概率是忘了加前缀 N。SQL Server 的 msg_str 参数类型是 nvarchar，普通单引号字符串（如 '用户不存在'）会被当作 varchar 处理，隐式转换可能丢失字符。
正确写法：RAISERROR(N'用户 %s 不存在', 16, 1, @username)；错误写法：RAISERROR('用户 %s 不存在', 16, 1, @username)。
- 消息总长上限为 2047 字符，超长时只显示前 2044 字符 + 省略号
- 格式占位符（如
%s、%d）个数必须与后续参数一一对应，否则报错Msg 10005, Level 15 - 避免在
msg_str中拼接变量——用参数化方式传入，既安全又避免 SQL 注入风险
别再用 msg_id 自定义错误号，Azure 和新项目都不支持
有些老教程教你在 sys.messages 里用 sp_addmessage 注册错误号（比如 50001），然后写 RAISERROR(50001, 16, 1)。这条路现在基本走不通：
- Azure SQL 数据库和 Azure SQL 托管实例 **不支持**
sp_addmessage，调用直接失败 - 微软明确建议：“新应用程序应使用
THROW而不是RAISERROR”，msg_id方式属于遗留路径 - 本地 SQL Server 虽然支持，但需要 DBA 权限注册，上线部署易出权限问题
务实做法：统一用 msg_str 形式，靠消息内容区分错误类型，例如：RAISERROR(N'[BusinessRule] 余额不足：%d', 16, 1, @balance)。日志里一眼就能识别业务上下文。
RAISERROR 不受 SET XACT_ABORT ON 控制，事务需手动处理
RAISERROR 有个关键限制：它**不尊重** SET XACT_ABORT ON 设置。这意味着即使你开了这个选项，RAISERROR 抛出后，事务仍可能处于未提交/未回滚的悬挂状态，容易引发死锁或数据不一致。
正确模式永远是显式控制：
- 在
TRY块中执行业务逻辑 - 在
CATCH块开头先检查XACT_STATE()：值为-1表示不可提交事务，必须ROLLBACK；值为1表示可提交，按需COMMIT或ROLLBACK - 不要假设
RAISERROR会自动回滚——它只是抛错，事务生命周期由你全权管理
最易忽略的一点：在嵌套存储过程中，外层 TRY…CATCH 可能捕获不到内层 RAISERROR，除非内层没自己 CATCH 或显式 THROW 向上传播。调试时务必确认错误是否真的冒泡上来了。
