PRINT在触发器中无法到达客户端，因输出被事务缓冲且客户端默认忽略；唯一实时方案是RAISERROR(,0–10,1) WITH NOWAIT，需配合SSMS开启消息窗口，上线前须改用日志表记录。
PRINT在触发器里根本不会发到客户端
SQL Server 触发器中写 PRINT，应用程序（比如 C# 的 SqlCommand、Java 的 PreparedStatement）收不到，不是你代码漏了监听，而是 SQL Server 压根没把这消息推过去。它只往内部缓冲区塞字符串，等整个批处理结束才尝试刷新——而 DML 语句执行极快，事务一提交，缓冲区可能还没来得及清空，更别说传到应用层了。
RAISERROR WITH NOWAIT 是唯一能“推”出去的方式
想让调试信息穿透事务和网络到达客户端，必须用 RAISERROR 并满足三个硬性条件：
- 严重性级别必须 ≤ 10（推荐用
0或10），否则会中断事务并报错 - 状态值任意非零整数，惯例写
1 -
WITH NOWAIT必须显式写出，漏掉就退回缓冲模式，和PRINT一样不可见 - 消息字符串不能为
NULL，建议用ISNULL(@var, '')或CONCAT()防空
示例：RAISERROR('Inserted ID: %d', 0, 1, @id) WITH NOWAIT;
SSMS 设置不对，RAISERROR 也白搭
即使代码全对，下面任一条件不满足，你在 SSMS 里照样看不到输出：
- 没手动点开查询窗口底部的“消息”选项卡（它默认可能折叠）
- 查询 → 查询选项 → 执行 → 高级 → 未勾选“将 SET NOCOUNT 设为 False”
- 当前窗口处于“仅 SQLCMD 模式”，此时
RAISERROR ... WITH NOWAIT反而失效 - 用 F5 运行但“消息”窗口被最小化或焦点不在那儿，容易误判为“没输出”
上线前必须删掉所有 RAISERROR 调试语句
它走的是服务器消息协议栈，高频触发时会明显拖慢并发性能；事务回滚时，所有 RAISERROR 消息也会消失，无法追溯失败原因；某些 ORM（如 Entity Framework）会把 RAISERROR 当作异常捕获，导致业务逻辑意外中断。真正可落地的生产方案，是往轻量日志表（如 dbo.TriggerDebug）里插记录，而不是依赖任何实时输出机制。
