必须用ISO周标准（如MySQL的YEARWEEK(date,1)、PG的TO_CHAR(date,'IYYY-IW')、SQL Server的DATEPART(isoyy)+DATEPART(isowk)）并显式带上年份，否则跨年周（如2023-12-31）易错归，导致统计偏差高达30%。
直接用 WEEK() 或 DATEPART(week, ) 分组，90% 的情况会把跨年周（比如 2023-12-31）错归到前一年，统计偏差可能高达 30%；必须显式对齐 ISO 周标准，并带上年份维度。
MySQL：YEARWEEK(date, 1) 是唯一稳妥的周分组方式
默认 WEEK(date) 用 mode=0（周日开头、第1周含1月1日），和国内业务习惯冲突。例如 '2024-01-01'（周一）会被算作 2024 年第 1 周，但 '2023-12-31'（周日）却属于 2023 年第 52 周——而业务上它们本该同属 2024 年第 1 周。
- 固定写
YEARWEEK(order_time, 1)：周一为每周起点，第1周需含4天及以上（ISO 兼容） - 绝对不要只用
WEEK(order_time)或WEEK(order_time, 0)，它不带年份，跨年时必然混组 - 别用
DATE_FORMAT(order_time, '%Y-%u')：2024-12-30 会拼成'2024-01'，实际属于 2025 年第 1 周 - 字段是字符串（如
'2024/03/15'）？先转类型：STR_TO_DATE(order_time, '%Y/%m/%d')，否则YEARWEEK()返回NULL - 大表性能差？加生成列：
ADD COLUMN yw INT GENERATED ALWAYS AS (YEARWEEK(order_time, 1)) STORED，再建索引
PostgreSQL：用 TO_CHAR(date, 'IYYY-IW') 或 EXTRACT 组合
DATE_PART('week', date) 只返回纯数字 1–53，不带年份，2023-12-31 和 2024-01-07 都可能被分进 week=1，直接 GROUP BY 就混了。
- 首选
TO_CHAR(created_at, 'IYYY-IW')：输出如'2024-01'，自动按 ISO 周处理跨年（2023-12-31 →'2024-01'） - 或用
EXTRACT(ISOYEAR FROM created_at)+EXTRACT(ISOWEEK FROM created_at)组合，语义更清晰 - 避免
date_trunc('week', created_at)：它虽返回周一时间戳，但不同 PG 版本对“周一截断”的实现有差异（v12 vs v15） - 别用
EXTRACT(YEAR FROM created_at) || '-' || LPAD(EXTRACT(WEEK FROM created_at)::text, 2, '0')：这是日历年周，不是 ISO 周
SQL Server：必须用 DATEPART(isoyy, ) + DATEPART(isowk, )
DATEPART(week, order_time) 默认以周日为起点，且第1周定义为“含1月1日的那一周”，和 ISO 完全不一致。比如 2024-01-01 是周一，但它可能被归入 2024 年第 1 周；而 2023-12-31（周日）反而属于 2023 年第 53 周——但业务上它应属 2024 年第 1 周。
- 强制用
DATEPART(isowk, order_time)（ISO 周数）+DATEPART(isoyy, order_time)（ISO 年），二者必须同时出现 - 别用
DATEPART(year, order_time)替代isoyy：2023-12-31 的year是 2023，但isoyy是 2024 - 别依赖
SET DATEFIRST 1：它只改每周起点，不改第1周判定逻辑，仍可能跨年错乱 - 如果版本低于 2012（不支持
isoyy/isowk），就别硬凑，改用应用层对齐或升级
真正容易被忽略的是：所有数据库的周计算都受时区影响。如果原始时间字段是 TIMESTAMP WITH TIME ZONE 或 UTC 存储，必须先统一转换到业务时区（如 AT TIME ZONE 'Asia/Shanghai'），再做周截断——否则凌晨 00:03 的订单，在 UTC 时间下可能是前一天，周归属直接翻车。
