Go中计算本周一应使用t.AddDate(0,0,-int(t.Weekday())+1)，该公式基于ISO标准（周一为每周起点），需显式处理时区并避免依赖默认本地时间导致跨天错误。
Go 里 time.Weekday 的周一是 1，但默认周起始是 Sunday
Go 的 time 包里，time.Monday 确实是 1，但 time.Now().Weekday() 返回的是枚举值，不是偏移量；更重要的是：time.Date 和 time.AddDate 不关心“本周从哪天开始”，它只认你传的年月日。所以直接用 Weekday() 算周一，得自己处理“本周从周日还是周一算起”这个隐含前提——Go 默认按 ISO 标准不强制，但 time.ISOWeek() 返回的周数是按周一为每周起点的，这点容易混淆。
- 如果你要的是「ISO 周定义下的周一」（即和
time.ISOWeek()对齐），那本周一就是离今天最近的、且在本周范围内的Monday - 如果业务要求“周日为每周第一天”，那本周一就得往前推 1 天再算，不能硬套
Monday == 1 - 别依赖
time.Now().Weekday() == time.Sunday来判断是否周日——它返回的是time.Sunday类型值，不是整数0，比较要用== time.Sunday，不是== 0
用 time.AddDate(0, 0, -int(wd)+1) 算本周一最稳
核心逻辑：拿到今天是星期几，然后往回减掉“今天到周一的天数差”。注意 wd := t.Weekday()，time.Sunday 是 0，time.Monday 是 1……time.Saturday 是 6。所以从周日（0）到周一（1）要 +1 天？不对——我们要的是“往前找本周一”，所以对周日要减 6 天，对周一减 0 天，通用公式就是 -int(wd) + 1（因为周一本身是 1，差值为 0）。
- 正确写法：
t.AddDate(0, 0, -int(t.Weekday())+1)，适用于所有 Go 版本（包括 1.20+） - 错误写法：
t.AddDate(0, 0, -int(t.Weekday()-time.Monday))—— 因为time.Monday是常量1，但Weekday()返回的是类型，减法虽能编译，但语义不清且易错 - 别用
time.Truncate配合秒级计算，精度损失风险高，还绕远
时区没处理好，周一可能错一天
time.Now() 返回的是本地时区时间，但如果你服务部署在 UTC 服务器、又用本地时区解析用户请求（比如前端传了带 tz 的字符串），Weekday() 结果可能和用户预期不一致。比如用户在北京（CST），你用 time.Now() 在 UTC 服务器上跑，得到的是 UTC 时间的周一，比北京时间早 8 小时，很可能跨天。
- 统一用
time.Now().In(loc)显式指定时区，loc可以是time.Local或time.LoadLocation("Asia/Shanghai") - 如果输入是字符串时间（如
"2024-06-10"），务必用time.ParseInLocation，而不是time.Parse，否则默认解析成time.UTC - 测试时用固定时间点（如
time.Date(2024, 6, 10, 0, 0, 0, 0, loc)）代替Now()，避免测试结果随真实时间漂移
想兼容“周日为每周第一天”的业务怎么办
有些老系统或财务场景把周日当第 1 天，那本周一其实是“上周日 + 1 天”。这时候不能硬套前面的公式，得先算出本周日，再加 1 天。
立即学习“go语言免费学习笔记（深入）”；
- 本周日 =
t.AddDate(0, 0, -int(t.Weekday()))（因为 Sunday 是 0，减 0 天就是当天；Monday 是 1，减 1 天回到上周日） - 本周一（按周日为首日）=
sunday.AddDate(0, 0, 1) - 更直白的写法：
t.AddDate(0, 0, -int(t.Weekday())+1+7*(t.Weekday()==time.Sunday ? -1 : 0))—— 不推荐，可读性差，建议拆成两步 - 关键：这种逻辑必须在业务层明确注释，不能藏在工具函数里，默认行为应与 ISO 一致
