CASE WHEN 必须在SELECT和GROUP BY中严格一致地重复书写，不可仅依赖别名；分支顺序需由细到粗以防短路，数值区间推荐左闭右开写法。
CASE WHEN 必须出现在 SELECT 和 GROUP BY 两个位置，且表达式要严格一致
想用业务语言（比如“新客”“复购用户”“沉睡客户”）代替原始字段值做分组，不能只在 SELECT 里写 CASE WHEN 然后指望 GROUP BY 自动识别。数据库执行顺序是先分组再投影，GROUP BY 阶段看不到 SELECT 里的别名（除非你用 MySQL 8.0+ 或 PostgreSQL 且显式命名并引用）。最稳妥、兼容性最好的做法是：在 SELECT 中定义分类逻辑，并在 GROUP BY 中原样复写整个 CASE WHEN 表达式。
- MySQL 5.7 严格模式下，
GROUP BY category（其中category是CASE的别名）会报错Unknown column 'category' in 'group statement' - PostgreSQL 和 SQL Server 允许引用别名，但前提是该别名在 SELECT 中已定义且无歧义；一旦 SELECT 中有多个
CASE或嵌套，就容易出错 - 复写表达式虽然冗长，但语义明确、跨库稳定，连 Oracle 和老版本 SQLite 都能跑通
漏写 ELSE 会让部分数据无声归入 NULL 组
业务分类常带主观边界，比如把注册时间 created_at IS NULL 的脏数据，或字段本身允许 NULL。这时候不写 ELSE，所有不匹配行都会被归进一个隐式的 NULL 分组——它不会报错，但你在结果里看不见这组，前端可能直接过滤掉，导致总数对不上。
- 显式写
ELSE 'unknown'或ELSE 'unclassified'，比留空更利于排查 - 如果业务上 NULL 有含义（如“未完成注册流程”），就单独加一条
WHEN created_at IS NULL THEN 'incomplete_reg'，别塞进 ELSE 里模糊处理 - 用
HAVING COUNT(*) > 0无法捞出 NULL 组，得靠WHERE ... OR created_at IS NULL配合判断
分支顺序必须由细到粗，否则条件会短路
CASE WHEN 按从上到下的顺序匹配，遇到第一个为 true 的分支就返回，后面全跳过。比如想区分“高价值复购”（近30天下单≥2次且总金额＞5000）和“普通复购”（近30天下单≥2次），如果把普通条件写在前面，高价值用户永远进不了第二条分支。
- 优先写约束更强的条件，例如先判
order_count >= 2 AND total_amount > 5000，再判order_count >= 2 - 数值区间推荐左闭右开写法：
score >= 90 AND score ，比 <code>BETWEEN 90 AND 99更少受类型隐式转换影响 - 字符串匹配注意大小写和空格，必要时加
TRIM(UPPER(status))统一处理后再比较
真正难的不是写对语法，而是把模糊的业务规则翻译成无歧义、全覆盖、可验证的 CASE 分支——每加一条 WHEN，都要反问：有没有数据会掉进缝隙？有没有本该归入 A 类的被 B 类提前截走了？
