WINDOW子句为窗口定义命名以供复用，必须位于SELECT后、ORDER BY/LIMIT前，语法为WINDOW w1 AS (PARTITION BY ... ORDER BY ...)；OVER w1合法，OVER (w1)非法，且别名仅在当前查询有效。
WINDOW子句的语法结构和基本写法
PostgreSQL 中的 WINDOW 子句不是给窗口函数本身起别名，而是为**窗口定义（window definition）** 命名，后续可在多个窗口函数中复用。它必须出现在查询的 SELECT 列表之后、ORDER BY / LIMIT 等子句之前。
正确写法是：SELECT ..., ROW_NUMBER() OVER w1 FROM t WINDOW w1 AS (PARTITION BY category ORDER BY score)。注意 WINDOW 关键字后直接跟别名（如 w1），再用 AS 引出完整窗口定义，不能省略 AS，也不能把别名放在括号里。
为什么不能在OVER()里直接写别名
常见错误是试图写成 ROW_NUMBER() OVER w1 却没声明 WINDOW 子句，此时 PostgreSQL 报错：ERROR: window w1 does not exist。还有一种误写是 ROW_NUMBER() OVER (w1)——括号里只能是窗口定义或已声明的窗口名，但加了括号反而让解析器认为你在写内联定义，导致语法错误。
关键点：
-
OVER w1合法，前提是前面有WINDOW w1 AS (...) -
OVER (w1)非法，括号仅用于包裹内联定义，不能套窗口别名 - 同一个窗口别名可在多个函数中重复使用，比如
AVG(x) OVER w1和ROW_NUMBER() OVER w1
WINDOW子句和内联窗口定义的性能与可读性差异
当多个窗口函数需要完全相同的分区、排序、帧子句时，用 WINDOW 子句比重复写内联定义更安全：避免手误导致细微差异（比如一个漏了 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW），也便于后期统一调整。
但要注意：
-
WINDOW子句只作用于当前查询层级，子查询中不可见 - 别名不支持参数化，无法动态切换
PARTITION BY字段 - 如果窗口定义本身很短（如仅
ORDER BY id），内联写法反而更直观，不必额外引入WINDOW增加认知负担
嵌套查询中WINDOW子句的作用域限制
WINDOW 子句不能跨查询层级生效。例如在 CTE 或子查询中定义的窗口别名，在外层查询中不可用。典型报错是：ERROR: window w1 does not exist，即使看起来“已经定义过了”。
解决办法只有两个：
- 把
WINDOW子句移到最外层查询，并确保所有引用它的OVER都在外层 - 或者放弃别名，在子查询中改用内联窗口定义
这点容易被忽略——尤其在调试复杂分析查询时，以为 CTE 里的 WINDOW 是“全局可用”的。实际上 PostgreSQL 的窗口别名作用域和表别名一样严格，仅限声明它的那条 SELECT 语句。
