week() 默认模式以周日为起点且第1周须含1月1日，与iso 8601冲突；仅用week()分组会混同年份相同周数，应改用yearweek(date,1)或weekofyear()确保年周绑定。
WEEK() 默认模式把周日当起点，且第1周必须含1月1日
MySQL 的 WEEK() 不传第二个参数时，默认用模式 0：周日为每周第一天，且“包含1月1日的那一周”算作第1周。这和 ISO 8601（周一为起点、第1周需含1月4日）冲突。比如 2024-01-01 是周一，WEEK('2024-01-01') 返回 1；但 2023-12-31 是周日，WEEK('2023-12-31') 返回 53——它实际属于 2024 年第 1 周，却被硬绑在 2023 年下。
只用 WEEK() 分组会把不同年份的同周数混在一起
WEEK() 返回的是纯数字 0–53，不带年份信息。当你写 GROUP BY WEEK(created_at)，2023-12-31（2023年第53周）和 2024-01-01（2024年第1周）可能都被归到 WEEK() = 1 或 WEEK() = 53，结果错乱。
- 错误示例：
WHERE WEEK(create_time) = WEEK(NOW())—— 跨年时去年末尾一周和今年开头一周可能返回相同值 - 正确做法：必须搭配年份判断，如
YEAR(create_time) = YEAR(NOW()) AND WEEKOFYEAR(create_time) = WEEKOFYEAR(NOW()) - 更稳妥：直接用
YEARWEEK(create_time, 1)，它返回类似202401的整数，天然绑定年+周
WEEKOFYEAR() 和 WEEK(date, 3) 才真正遵循 ISO 标准
WEEKOFYEAR() 等价于 WEEK(date, 3)：周一为起点，且第1周必须包含当年至少4天（即含1月4日）。这是大多数报表、BI 工具默认采用的逻辑。
-
WEEK(date, 1)虽然也是周一为起点，但不强制第1周含4天——2025-01-01（周三）会被算作第1周，而该周前3天属2024年 -
WEEK(date, 0)或WEEK(date)都是周日起点，易导致周一至周五的数据被拆到两个周组里 - 别用
DATE_FORMAT(created_at, '%Y%u')：它用的是日历年 + MySQL 默认周，跨年时%Y和%u不同步
跨年边界测试不能只看12月31日
真正容易出问题的是每年 1 月 1–3 日和 12 月 29–31 日。例如：
-
2024-12-30是周一，属于 2025 年第 1 周（ISO），但YEAR('2024-12-30') = 2024，WEEK('2024-12-30') = 1→ 错归为 2024 年第 1 周 -
2025-01-01是周三，仍属 2025 年第 1 周，但若用YEAR() + WEEK()拼接，可能得到20251，而YEARWEEK()返回202501（补零对齐） - 测试时务必覆盖
2023-12-31、2024-01-01、2024-12-30这三个点，验证周归属是否符合 ISO 8601
跨年周的本质不是计算错误，而是年份与周数的语义没对齐——WEEK() 只负责“当年第几周”，不回答“这周属于哪一年”。要解决，就得换函数，而不是修参数。
