SQL Server 的 DATEPART(week, ...) 跨年跳变因按日历年重置周数，1月1日所在周恒为第1周；改用 DATEPART(iso_year, date) 和 DATEPART(iso_week, date) 可遵循 ISO 8601 实现周序连续。
为什么 DATEPART(week, ...) 跨年时周数会跳变？
SQL Server 的 DATEPART(week, ...) 默认按日历年计算，1 月 1 日所在周固定为第 1 周，不考虑 ISO 8601 标准。比如 2023-12-31 是周日，属于 2023 年第 52 周；而 2024-01-01 是周一，直接变成 2024 年第 1 周——中间没有第 53 周，但实际那七天是连续的 ISO 周（2023-W52 → 2024-W01）。这种“重置”导致按年+周分组后，跨年处出现断层，无法直接用 ORDER BY year, week 补全。
关键不是周数本身错，而是你聚合时用了 YEAR(date) 和 DATEPART(week, date) 两个独立字段，它们各自截断、各自归零。
用 ISO_WEEK + ISO_YEAR 替代原生 week/year
SQL Server 2022+ 支持 DATEPART(iso_week, date) 和 DATEPART(iso_year, date)，它们严格遵循 ISO 8601：每年第一周必须包含该年第一个周四，且周一是每周起点。这样 2023-12-31 属于 2024-ISO_YEAR 的第 1 周（即 2024-W01），而 2024-01-01 也是 2024-W01，周序自然连续。
实操建议：
- 把聚合字段从
YEAR(date), DATEPART(week, date)换成DATEPART(iso_year, date), DATEPART(iso_week, date) - 确保时间范围覆盖完整周期（例如要补 2023-W52 到 2024-W02，就得查 2023-12-25 至 2024-01-14 的原始数据）
- 旧版本 SQL Server（DATEADD(day, -((DATEPART(weekday, date) + @@DATEFIRST - 2) % 7), date) 算周一，再推导 ISO 年和周
用 LEFT JOIN 补全缺失周（非窗口函数方案）
即使用了 ISO 字段，原始数据仍可能缺某周（如没订单）。补全不能只靠 GROUP BY，得构造完整周序列再左连。
典型做法：
- 用 CTE 或临时表生成目标时间范围内所有 ISO 周：例如
SELECT DISTINCT iso_year, iso_week FROM (VALUES (2023,52),(2024,1),(2024,2)) t(iso_year,iso_week) - 把你的业务数据按
iso_year/iso_week分组聚合后，LEFT JOIN这个完整周表 -
ISNULL(sum_value, 0)填 0，避免 NULL
注意：别用 GENERATE_SERIES 直接按数字递增生成周号——ISO 周跨年不连续（2023 最大 ISO 周可能是 53，2024 最小是 1），必须结合日期推算。
PostgreSQL / MySQL 用户注意函数名差异
PostgreSQL 没有 DATEPART，用 EXTRACT(ISOYEAR FROM date) 和 EXTRACT(WEEK FROM date) ——这两个天然就是 ISO 兼容的，无需额外处理。
MySQL 8.0+ 用 YEARWEEK(date, 3)（mode=3 表示周一为周首、ISO 风格），返回整数如 202401；再用 FLOOR(yw/100) 和 yw % 100 拆解年与周。但注意：MySQL 的 YEARWEEK 在 2023-12-31 返回 202401，和 ISO 一致，可直接用于补全逻辑。
跨年周补全真正的难点不在语法，而在确认你用的“周定义”是否和业务对齐——销售周期、财务结算、日志归档，各自可能采用不同周起始和年度归属规则。先定标准，再选函数，否则补出来的“连续”只是自洽的幻觉。
