sql server触发器必须显式检查inserted/deleted表中字段是否为空，因不支持声明式非空约束；insert查inserted，update需校验新值，delete一般不强制；须用exists+ltrim/rtrim+raiserror+rollback确保事务安全。
不能直接在触发器里做“非空校验”并抛出通用错误——必须明确检查 inserted 和 deleted 表中对应字段的值，再用 RAISERROR 或 THROW 中断执行。
为什么 UPDATE/INSERT 必须显式检查原因字段是否为空
SQL Server 触发器不支持像 CHECK 约束那样声明式地限制“某列非空才允许写入”。即使你在表结构里没设 NOT NULL，业务上要求每次修改都填 reason（比如 modify_reason），就得靠触发器拦截非法操作。关键点在于：inserted 表只在 INSERT 和 UPDATE 时有数据，deleted 表只在 DELETE 和 UPDATE 时有数据；而 UPDATE 是唯一同时涉及两者的操作，所以必须分开判断。
- 对
INSERT：只查inserted.modify_reason是否为NULL或空字符串 - 对
UPDATE：要查inserted.modify_reason是否为空（因为新值在这张表），且通常忽略deleted.modify_reason - 对
DELETE：一般不强制填原因，但如果业务真有此要求，就查deleted.modify_reason—— 但注意：这其实不合理，因为删除前用户未必填过该字段
如何写一个带原因校验的 AFTER UPDATE/INSERT 触发器
假设目标表是 orders，要求每次 INSERT 或 UPDATE 都必须提供非空的 modify_reason 字段（类型为 VARCHAR(200)）：
CREATE TRIGGER tr_orders_require_reason
ON orders
AFTER INSERT, UPDATE
AS
BEGIN
IF EXISTS (
SELECT 1 FROM inserted
WHERE modify_reason IS NULL
OR LTRIM(RTRIM(modify_reason)) = ''
)
BEGIN
RAISERROR('modify_reason 字段不能为空或仅含空白字符', 16, 1);
ROLLBACK TRANSACTION;
RETURN;
END
END;
说明：
- 用
LTRIM(RTRIM(...)) = ''排除纯空格输入，比只判IS NULL更严格 -
RAISERROR级别设为 16 是用户可捕获的错误级别，不会被当作系统严重错误中断连接 - 必须紧跟
ROLLBACK TRANSACTION，否则事务继续，校验形同虚设 - 这个触发器对
UPDATE生效，但只校验新值；如果原记录没填原因、新记录也没填，它会拦住；如果原记录有原因、新记录清空了它，也会被拦住
容易踩的坑：误用 deleted 表、忽略多行影响、漏掉空格校验
常见错误现象包括：
- 在
INSERT触发器里引用deleted表：语法合法但返回空结果集，导致校验永远通过 - 用
IF @reason IS NULL这种标量变量方式处理 ——inserted是表，不是单值，必须用EXISTS或COUNT(*) > 0 - 只判
IS NULL，放行了' '（空格字符串），业务上等于没填 - 在触发器里调用
PRINT或写日志表却不ROLLBACK：用户看不到报错，还以为成功了 - 没考虑批量操作：一次
UPDATE改 1000 行，只要其中任意一行modify_reason为空，整个事务就得回滚 —— 这是设计使然，不是 bug
INSTEAD OF 触发器能绕过这个限制吗
不能，而且更危险。虽然 INSTEAD OF 允许你完全接管逻辑，但如果你在其中漏掉对 modify_reason 的检查，或者忘记把它写进实际 INSERT/UPDATE 语句，那校验就彻底失效。更麻烦的是：INSTEAD OF 不自动参与外键约束和级联操作，容易破坏数据一致性。除非你明确需要重写整条语句（比如把 JSON 字段拆成多列入库），否则坚持用 AFTER + ROLLBACK 是最直白、最可控的方式。
真正难的不是写触发器，而是让所有开发人员理解：这个字段不是“建议填写”，而是数据库层的硬性守门员。一旦上线，任何绕过它的 ORM 批量更新、SSIS 包、甚至临时写的 UPDATE 脚本，都会失败 —— 所以文档和沟通成本，往往比代码本身还高。
