first_value() 默认拿不到分组第一行，因其窗口帧为range between unbounded preceding and current row，仅覆盖分区开头至当前行；需显式指定rows between unbounded preceding and unbounded following并确保order by稳定。
为什么 FIRST_VALUE() 拿不到分组第一行？
因为默认窗口帧是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ，不是整组。哪怕你写了 PARTITION BY user_id ，它也只从分区开头算到当前行，导致中间行的 FIRST_VALUE() 返回的是“到当前位置为止”的第一个值，而非整个分组的第一行。
实操建议：
- 必须显式指定窗口帧为
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING - 同时确保
ORDER BY有明确、稳定的排序依据（比如带时间戳或唯一 ID），否则“第一行”结果不可靠 - 如果只是想取分组固定首尾（不依赖排序），
FIRST_VALUE()不是最佳选择——考虑用子查询或JOIN配合GROUP BY+MIN()/MAX()更稳妥
LAST_VALUE() 总返回当前行？
这是最常踩的坑： LAST_VALUE() 在默认窗口帧下，等价于“当前行的值”，因为它只看到从开头到当前行的数据，当前行自然就是“最后”。它不像 FIRST_VALUE() 那样有“直觉上的首”， LAST_VALUE() 必须配合完整帧才能生效。
实操建议：
- 强制写全帧：
LAST_VALUE(col) OVER (PARTITION BY x ORDER BY y ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) - 注意
ORDER BY的语义：按时间升序时，LAST_VALUE()取的是最新一条；按降序则取最早一条——别光看函数名，要看排序方向 - 某些旧版 Hive 或 Spark SQL 对
UNBOUNDED FOLLOWING支持不一致，测试时务必验证边界数据（如单行分组）
PostgreSQL / MySQL 8.0+ 中的兼容性差异
MySQL 8.0+ 和 PostgreSQL 都支持标准语法，但默认行为一致不代表实际表现一致。关键是排序字段存在重复值时，不同引擎对“相等行的相对顺序”处理不同，可能让 FIRST_VALUE() 指向非预期行。
