CASE WHEN 是表达式而非语句，必须置于SELECT、WHERE等支持表达式的位置且以END结尾；分简单CASE（仅等值匹配）和搜索CASE（支持任意布尔条件）；所有THEN/ELSE返回值类型须一致；执行顺序从上到下、命中即止；常见错误包括漏写END、AS位置错、类型混用及空值处理差异。
直接说结论：CASE WHEN 不是语句，是表达式，必须出现在 SELECT、WHERE、ORDER BY 等能接收表达式的位置，且必须以 END 结尾——漏写 END 或错放 AS 位置，90% 的语法错误都出在这儿。
简单 CASE：等值匹配时用，别硬套在范围判断上
适用于单字段与固定值一一对应，比如状态码转义、性别编码映射。它本质是隐式等于判断，不支持运算符或函数参与比较。
-
CASE status WHEN 'active' THEN '已激活' WHEN 'inactive' THEN '未激活' ELSE '未知' END合法；但CASE age WHEN > 18 THEN '成人'会报错 - 所有
THEN和ELSE返回值类型必须一致：全是字符串，或全是数字。混用'优'和0在 Oracle/PostgreSQL 里直接抛[Err] ORA-00932 - 执行顺序是从上到下，命中第一个就停，后面条件不再检查。所以
WHEN score >= 60放在WHEN score >= 90前面，会导致高分永远进不了“优秀”分支
搜索 CASE：复杂逻辑的唯一选择，条件可任意组合
这才是日常用得最多的形态。每个 WHEN 后跟完整布尔表达式，支持 AND、OR、函数（如 DATE_SUB(NOW(), INTERVAL 7 DAY)）、子查询（需注意性能）。
CASE WHEN age >= 18 AND city = 'Shanghai' THEN '本地成年用户' WHEN age 是典型用法-
ELSE虽可省略，但强烈建议显式写出，否则无匹配时返回NULL，可能影响后续GROUP BY或前端展示 - 嵌套
CASE是允许的，但超过两层就该考虑拆成视图或应用层处理，SQL 可读性会急剧下降
WHERE 和 ORDER BY 里也能用，但逻辑要更谨慎
CASE 在 WHERE 中用于动态过滤，在 ORDER BY 中用于自定义排序优先级，但它们的行为和 SELECT 中不同：不生成新列，只参与计算。
-
WHERE CASE WHEN type = 'vip' THEN expire_date > NOW() ELSE 1 END = 1实现 VIP 过期检查 + 普通用户无条件通过，但注意 MySQL 对这种写法优化不佳，可能全表扫描 -
ORDER BY CASE WHEN status = 'urgent' THEN 0 ELSE 1 END, created_at DESC把 urgent 排最前，其余按时间倒序——这里CASE返回的是数字，不是字符串，类型必须明确 - 在
WHERE中用CASE替代OR有时能提升可读性，但不会提升性能；真要优化，得靠索引覆盖对应字段
容易被忽略的坑：END 位置、类型隐式转换、数据库差异
看似简单的语法，实际踩坑点集中在三处：一是 END 必须紧贴最后一个 ELSE 或 THEN 后，不能缩进错位；二是不同数据库对类型兼容性处理不同；三是空值传播逻辑不一致。
-
SELECT ..., CASE WHEN col IS NULL THEN 'N/A' ELSE col END AS label—— 如果col是整型，'N/A'会被某些数据库（如 PostgreSQL）强制转为TEXT，而 MySQL 可能静默转成0，导致数据失真 - SQLite 不支持
CASE在WHERE子句中返回非布尔值，必须包裹在= 1或类似判断里 - 所有主流数据库都遵循“从上到下、一命中即退出”规则，但 Oracle 对空值判断（
NULL = NULL）默认为FALSE，所以WHEN col = NULL永远不成立，得写WHEN col IS NULL
