IIF 仅在字段非空、条件单一、类型一致时更简洁，但存在非短路执行、嵌套限深、类型隐式转换等风险，CASE 更安全通用。
IIF 确实能写出更短的 SQL，但「更简洁」不等于「更安全」或「更适合所有场景」。它只在明确的二选一、非空字段、无副作用的简单判断中成立；其他情况用 CASE 反而更稳。
什么时候 IIF 真正省事？
适用于字段确定不为 NULL、条件单一、返回值类型一致的场景，比如状态映射、数值阈值分界：
-
IIF(OrderStatus = 'Completed', '成功', '失败')—— 字段已知非空，逻辑干净 -
IIF(Amount > 1000, '大额', '小额')—— 数值比较，无隐式转换风险 -
IIF(IsDeleted = 1, '已删', '正常')—— 布尔型字段，类型明确
注意：如果 OrderStatus 可能为 NULL，IIF 会直接走 false_value 分支（即返回 `'失败'`），这不是“空值处理”，而是布尔表达式求值结果为 UNKNOWN → 视同 FALSE。
IIF 的两个分支都会执行，这点必须警惕
它不是短路计算，true_value 和 false_value 都会被 SQL Server 求值一次。这会导致：
- 子查询无条件执行：
IIF(@flag = 1, (SELECT COUNT(*) FROM huge_table), 0)即使@flag <> 1，子查询照跑 - 除零报错：
IIF(1=0, 1/0, 999)直接抛出Divide by zero error - 函数被调用两次：
IIF(1=1, GETDATE(), GETDATE())返回两个不同时间戳
而 CASE WHEN 是真正短路的，只有匹配分支才执行对应表达式。
嵌套超过 10 层就失效
IIF 在内部被 SQL Server 重写为 CASE，而 CASE 最大嵌套深度是 10 层。所以：
-
IIF(a>1, '1', IIF(a>2, '2', IIF(a>3, '3', ... )))嵌套到第 11 层会报错 - 多分支场景（如分数分级）硬用
IIF嵌套，可读性差、易超限、难维护 - 需要加注释、后续可能扩展分支时，不如一开始就写
CASE
另外，IIF 在 Azure Synapse Analytics 专用 SQL 池中不支持，而 CASE 全平台通用。
IIF 和 ISNULL 不是一回事
常见误用：IIF(col IS NULL, 'Y', 'N') 看似像 ISNULL，但语义完全不同：
-
ISNULL(col, 'default')只检测col是否为NULL，不是NULL就原样返回 -
IIF(col IS NULL, 'Y', 'N')是完整布尔表达式，可写任意条件，但代价是两边都求值 - 想实现
ISNULL(col, 'default')，别用IIF，直接用ISNULL或COALESCE
类型隐式转换也容易踩坑：IIF(1=1, 'yes', 123) 返回字符串，但 IIF(1=1, 123, 'no') 可能返回 '123'（因字符串优先级高），导致截断或意外类型。
真正省事的前提，是你清楚它不省资源、不省兼容性、也不省心智负担——只是少打了几个字母而已。
