IIF不是CASE的替代品，而是有严格限制的语法糖；仅当判断为单布尔表达式、输入非NULL或明确归入false分支、两分支均为轻量无副作用表达式、类型兼容时才安全；否则应优先使用CASE。
IIF确实能写得更短，但**它不是 CASE 的替代品，而是有严格限制的语法糖**。用错场景反而埋坑，尤其在生产环境里。
什么时候 IIF 真正安全可用？
只有同时满足以下全部条件时，IIF 才比 CASE 更清晰、风险更低：
- 判断逻辑是单个布尔表达式，比如
status = 'A'或amount > 1000，不带AND/OR - 输入字段确定不为
NULL；若可能为NULL，你已确认它该归入false_value分支（因为IIF(NULL, 'Y', 'N')返回'N'） - 两个分支都是轻量表达式：不含子查询、不含除零风险、不含
GETDATE()这类副作用函数 - 返回值类型兼容，避免隐式转换截断，例如
IIF(1=1, 'yes', 123)返回varchar，但IIF(1=1, 123, 'no')可能把123转成'123'
IIF 为什么执行报错或性能异常？
最常被忽略的关键点：两个分支都会求值，不是短路计算。SQL Server 不跳过任一分支，无论条件真假。
-
IIF(@flag = 1, (SELECT COUNT(*) FROM orders), 0)—— 即使@flag是 0，子查询仍执行 -
IIF(1=0, 1/0, 999)—— 直接抛出Divide by zero error -
IIF(1=1, GETDATE(), NEWID())—— 两个函数都调用，时间戳和 GUID 都生成，只返回前者结果
嵌套 IIF 超过 10 层就失败
IIF 在内部被 SQL Server 完全重写为 CASE，而 CASE 最大嵌套深度就是 10 层。
- 像
IIF(a>1,'1',IIF(a>2,'2',IIF(a>3,'3',...)))这种写法，第 11 层会报错Incorrect syntax near 'IIF' - 一旦需要三选一（比如 “高/中/低”），必须改用
CASE，IIF无法扩展 - Azure Synapse Analytics 专用 SQL 池不支持
IIF，而CASE全平台通用
别把它当成 ISNULL 或 NULLIF 的快捷写法
IIF 解决的是布尔分支问题，不是空值处理问题。
-
ISNULL(col, 'default')只检测col是否为NULL；IIF(col IS NULL, 'Y', 'N')是完整布尔表达式，可写任意条件 -
NULLIF(a, b)是“相等即转NULL”，IIF(a = b, NULL, a)效果类似但多一次计算，且无法利用NULLIF的索引友好特性 -
IIF(col > 100, 'high', 'low')这类阈值判断，才是IIF的不可替代场景
真正关键的不是“能不能写”，而是“值不值得写”。只要分支里有任何不确定性——可能 NULL、可能慢查询、可能出错——就该直接用 CASE。简洁不该以隐蔽风险为代价。
