不能直接在CASE WHEN的THEN或ELSE分支中写窗口函数，因窗口函数依赖查询执行后期的分区/排序上下文，而CASE是早期标量表达式，需即时返回确定值；必须让二者平级共存，如先用CASE构造排序键再供ROW_NUMBER()使用。
不能直接在 CASE WHEN 的 THEN 或 ELSE 分支里写窗口函数（如 ROW_NUMBER()、SUM() OVER 等），否则会报错或结果不可控。 因为窗口函数必须在查询的逻辑执行阶段“可见且已定义”，而 CASE WHEN 是标量表达式，其每个分支要求返回确定值——窗口函数却依赖于整个结果集的排序、分区等上下文，无法在标量计算时完成。
为什么 CASE WHEN 里直接写 ROW_NUMBER() 会失败
常见错误现象包括：Window function is not allowed in this context（SQL Server）、cannot use window function here（PostgreSQL）、MySQL 8.0 报 Invalid use of window function。根本原因不是语法不支持，而是 SQL 执行顺序：窗口函数在 SELECT 阶段后期才求值，而 CASE WHEN 的每个分支需在更早的标量计算阶段就得出结果。
- 窗口函数不能作为
CASE的“输入值”，只能作为“输出列”或与CASE并列出现在SELECT列表中 - 即使你写成
CASE WHEN x=1 THEN ROW_NUMBER() OVER (ORDER BY y) ELSE 0 END，数据库也会拒绝——因为ROW_NUMBER()没有绑定明确的OVER上下文，或该上下文在当前作用域不可见 - 某些方言（如旧版 MySQL）甚至不允许窗口函数出现在
CASE同一层，无论是否在分支内
CASE WHEN 和窗口函数的正确协作方式
真正可行的模式是让两者“平级共存”，而非嵌套包含。核心思路是：先用 CASE WHEN 构造出用于排序、分组或过滤的中间列，再让窗口函数基于它计算；或反过来，先算好窗口结果，再用 CASE WHEN 对结果做条件分类。
- ✅ 正确：用
CASE生成排序键，喂给ROW_NUMBER() OVER (ORDER BY sort_key) - ✅ 正确：先算
AVG(sales) OVER (PARTITION BY region)，再用CASE WHEN sales > avg_sales THEN 'high' ELSE 'low' END - ✅ 正确：在
PARTITION BY中使用CASE，如PARTITION BY CASE WHEN status IN ('paid','shipped') THEN 'active' ELSE 'other' END - ❌ 错误：把
ROW_NUMBER() OVER (...)直接塞进THEN里 - ❌ 错误：在
WHERE或GROUP BY中引用未定义的窗口函数别名（即使它来自前面的CASE）
容易被忽略的兼容性细节
不同数据库对“窗口函数能否参与表达式计算”的容忍度不同，但底线一致：它不能是标量上下文中的子表达式。
- PostgreSQL 要求窗口函数必须出现在顶层
SELECT列或ORDER BY中，不允许出现在任何函数参数、CASE分支、聚合函数内部 - SQL Server 允许在
SELECT列中并列写CASE和窗口函数，但若你在UPDATE的SET子句里尝试类似写法，会立刻报错 - MySQL 8.0+ 支持在
SELECT中混合使用，但若CASE出现在HAVING或子查询的ON条件里，窗口函数依然不可见 - 所有数据库都禁止在
WHERE中直接调用窗口函数——哪怕你只是想筛ROW_NUMBER() = 1，必须用派生表或 CTE 提前物化
最常被绕过的复杂点是：你以为自己只是“加个判断”，实际上触发了执行计划中两个不同阶段的耦合。窗口函数不是普通函数，它没有独立生命周期——它依附于查询的整体结构。一旦你想把它当“值”来传递，就等于试图把河流装进瓶子里倒给别人，而不是告诉别人去河边取水。
