SQL Server触发器中字符串拼接遇NULL即整结果为NULL，需对每个可能为空字段用ISNULL单独包裹；UPDATE触发器须对比DELETED与INSERTED判断空值变化；ISNULL第二参数类型须兼容第一参数，否则隐式转换报错。
触发器里直接用 + 拼接字段，空值会让整个结果变 NULL
SQL Server 触发器中，如果对可能为 NULL 的字段做字符串拼接（比如 INSERTED.name + ' - ' + INSERTED.code），只要任意一端是 NULL，整条表达式就返回 NULL——不是空字符串，是真正的 NULL，后续逻辑很可能崩。
这不是 bug，是 SQL 标准行为。但业务上往往希望“空就当空字符串处理”，这时候不能靠 COALESCE 或 ISNULL 临时裹一层完事，得想清楚在哪裹、裹几层。
-
ISNULL是 SQL Server 特有函数，性能略优于COALESCE（不进行类型推导），且只接受两个参数，适合简单兜底 - 必须对每个可能为空的参与运算字段单独包裹，比如
ISNULL(INSERTED.name, '') + ' - ' + ISNULL(INSERTED.code, '') - 别在触发器外层统一
ISNULL整个表达式——没用，NULL + 'xxx'在进入ISNULL前就已经是NULL了
UPDATE 触发器里误用 INSERTED 忽略 DELETED，导致空值判断错位
更新操作中，字段可能从非空变成 NULL，也可能从 NULL 变成非空。如果只查 INSERTED，就漏掉了变化源头。比如你想记录“code 字段被清空”，就得对比 DELETED.code 和 INSERTED.code。
常见错误是写成 WHERE INSERTED.code IS NULL，这只能捕获新值为空，但无法区分是用户主动设空，还是字段本来就是空、根本没变。
- 真正需要的是
WHERE DELETED.code IS NOT NULL AND INSERTED.code IS NULL - 如果字段允许为空，又想对“首次设空”和“重复设空”做不同处理，得加时间戳或版本字段辅助判断
-
ISNULL(DELETED.code, '') != ISNULL(INSERTED.code, '')这种写法看似简洁，但会把''和NULL当作等价，掩盖语义差异，慎用
ISNULL 的第二个参数类型必须兼容第一个参数，否则隐式转换出问题
ISNULL 返回值类型完全由第一个参数决定，第二个参数只是兜底值，不会改变类型。如果字段是 INT，你写 ISNULL(age, 'N/A')，SQL Server 会尝试把 'N/A' 转成 INT，直接报错：Conversion failed when converting the varchar value 'N/A' to data type int.
这个错误在开发环境可能被忽略，因为测试数据全是数字；上线后一旦遇到真实空值，触发器就挂掉，且不会提示具体哪一行。
- 数值字段兜底用
0，日期字段用'1900-01-01'或GETDATE()，字符串才用'' - 不要为了“统一”强行用字符串兜底所有字段，类型错配比空值更难排查
- 如果真要统一返回字符串（比如日志拼接），先显式转类型：
ISNULL(CAST(INSERTED.age AS VARCHAR), '0')
触发器里嵌套调用函数或视图，ISNULL 无法阻止上游传来的 NULL
有些触发器逻辑会调用自定义函数（如 dbo.GetFullName(@id)）或 JOIN 视图，而这些对象内部没做空值防护。这时你在触发器里对函数结果套 ISNULL(dbo.GetFullName(id), '')，看似稳妥，实则无效——如果函数内部因某字段为 NULL 直接返回 NULL，那已经晚了。
空值问题会沿着调用链向上渗透，ISNULL 只能截断最后一环。
- 空值防护必须下沉到最靠近数据源的位置：函数内部、视图定义、甚至基础表的默认约束
- 触发器里调用外部逻辑前，先用
EXISTS或COUNT验证关键 ID 是否有效，比事后ISNULL更可靠 - 如果函数不可改，至少加注释说明：“此函数不保证非空，调用方需自行兜底”，避免后续维护者误以为安全
事情说清了就结束。空值不是值，是“未知”的标记；触发器里每多一层计算、一次调用、一个隐式转换，都可能让这个“未知”突然变成错误。
