time.Sub()计算时间差必须确保两时间点时区一致，否则结果为UTC偏移差而非钟表时间差；Duration支持纳秒级精确运算但不提供年月方法，因日历逻辑复杂；解析字符串需显式指定时区，推荐用ParseInLocation；判断相对日期应优先用AddDate而非Sub后换算。
直接用 time.Sub()，但时区必须一致
Go 计算两个时间点的物理时间差，唯一可靠的方式就是 time.Sub()，它返回 time.Duration —— 一个以纳秒为单位的整数差值。但关键陷阱在于：如果两个 time.Time 值来自不同时区（比如一个 time.Local，一个 time.UTC），Sub() 算出来的不是你肉眼看到的“钟表时间差”，而是它们各自在 UTC 下的纳秒偏移之差，结果可能多出或少掉几小时。
- ✅ 正确做法：统一用
time.UTC构造，或都用time.Local；解析字符串时显式指定时区，别依赖默认 - ❌ 错误示例：
t1 := time.Now()（Local）和t2, _ := time.Parse("2006-01-02", "2025-01-01")（无时区 → 默认 UTC）相减，结果偏差 8 小时（东八区） - ? 提示：用
t.Location().String()打印时区名，调试时立刻确认是否一致
Duration 能精确到纳秒，但“年”“月”不能直接算
time.Duration 是线性、等长的时间跨度（1 小时永远是 3600 秒），所以 .Hours()、.Minutes()、.Seconds() 都是安全可靠的；但“一年多少天”取决于闰年，“一月多少天”取决于月份——Go 标准库刻意不提供 .Years() 或 .Months()，因为语义模糊且易出错。
- ✅ 想要总天数：用
int(d.Hours() / 24)（向下取整）或int(math.Round(d.Hours() / 24))（四舍五入） - ✅ 想要“几天几小时几分”这种人类可读格式：先算总秒数，再逐级取余，别用
.Hours()减法链（浮点误差会累积） - ❌ 别写
d / (365 * 24 * time.Hour)估算年份——2024 是闰年，365 天就错了
解析字符串时间？必须带时区，否则 Sub() 结果不可信
从日志、API 或配置里拿到的字符串（如 "2025-03-15T14:22:00"），用 time.Parse() 解析后若未指定时区，Go 默认设为 time.UTC。而你本地 time.Now() 是 time.Local，两者相减就跨时区了。
- ✅ 推荐方式：强制统一到 UTC：
t, _ := time.ParseInLocation("2006-01-02T15:04:05", s, time.UTC) - ✅ 或明确按本地时区解析：
t, _ := time.ParseInLocation("2006-01-02T15:04:05", s, time.Local)，再确保另一个时间也用time.Local - ⚠️ 注意：
time.Parse()和time.ParseInLocation()的错误处理不能忽略，空值或格式错会导致t是零值时间（1970-01-01），Sub()结果巨大且误导
需要“相对时间描述”？别自己拆 Duration，用 AddDate() 反推更稳
比如判断“这个订单是不是 7 天前下的”，很多人会算 now.Sub(orderTime).Hours() > 7*24。这看似合理，但遇到夏令时切换（如 3 月最后一个周日凌晨 2 点跳到 3 点）、跨月/跨年边界时，Duration 的线性模型会漏掉日期逻辑（比如 1 月 31 日加 1 个月是 2 月 28 日，不是 31 日）。
立即学习“go语言免费学习笔记（深入）”；
- ✅ 更健壮的做法：用
orderTime.AddDate(0, 0, 7)得到“7 天后”的准确时间点，再和now比较：now.After(orderTime.AddDate(0, 0, 7)) - ✅ 同理，“1 个月前”用
now.AddDate(0, -1, 0)，它自动处理 31→28/29/30 的逻辑 - ? 关键区别：
Sub()算的是“物理经过时间”，AddDate()处理的是“日历上的日期偏移”——用途不同，别混用
真正容易被忽略的，是时区一致性这个前提——它不出错则已，一出错就是静默偏差，日志看着正常，业务逻辑却悄悄偏了几个小时。每次调 Sub() 前，花两秒确认 t1.Location() == t2.Location()，比后期排查省十倍力气。
