正确使用 time.Sub 需确保两 time.Time 同一时区，优先统一为 UTC；Duration 比较用 == 而非浮点方法；Sub 仅返回纳秒差，日历差需手动计算；高并发下避免频繁 .In()。
time.Sub 计算两个时间差值的正确姿势
直接用 time.Sub 就行，但必须确保两个 time.Time 值来自同一时区上下文，否则结果可能和你预期的“物理时间差”不一致。
常见错误是拿本地时间（time.Now()）和 UTC 时间（time.Now().UTC()）直接相减，看似没问题，实则隐含时区偏移干扰 —— 比如在中国，time.Now().Sub(t.UTC()) 会多出 8 小时的 offset 抵消项。
- 始终用
t1.Sub(t2)，别写成t2.Sub(t1)（符号反了） - 如果两个时间来自不同来源（比如数据库存的是 UTC，日志打的是本地时间），先统一用
.In(loc)转到同一*time.Location - 不要依赖
time.Now()的默认时区做跨服务时间对比，显式指定time.Now().In(time.UTC)
Duration 输出格式容易踩的坑
time.Duration 本质是纳秒整数，打印或比较时默认按“最简单位”显示（比如 5*time.Second 显示为 5s），但内部值不变；而 .Hours()、.Minutes() 这类方法返回的是浮点数，精度可能丢失。
典型问题：用 d.Hours() == 24 判断是否一整天 —— 实际上 24 * time.Hour 是精确的 86400e9 纳秒，但 d.Hours() 返回 float64，存在浮点误差，比较应改用 d == 24*time.Hour。
立即学习“go语言免费学习笔记（深入）”；
- 做相等判断一律用
==比较Duration值本身，别转 float - 要取整小时数且容忍微小误差？用
int64(d / time.Hour)，更安全 -
.String()只适合日志或调试，不适合解析或计算
跨天/跨月时间差不能只靠 Sub
time.Sub 只给纳秒差，它不管“几天几小时”这种人类语义。比如 1 月 31 日中午减 1 月 1 日中午，Sub 返回的是 2,592,000 秒（30 天），但如果你想要“30 天 0 小时”，就得自己拆解；更麻烦的是 1 月 31 日减 2 月 1 日，结果还是负的秒数，但没人说“-1 天”，而是想表达“上个月最后一天”。
这时候得用 time.Date 手动计算年月日偏移，或者借助第三方库如 github.com/armon/go-metrics（不推荐）或自己封装逻辑。标准库没提供“日历差”函数。
- 需要“X 年 Y 月 Z 日”格式？必须自己用
t1.YearDay() - t2.YearDay()+ 年份差校正，注意闰年 - 涉及夏令时切换（如美国 EDT → EST）时，
Sub结果仍准确（纳秒级），但“显示为 23 小时”可能是对的（因为少了一小时） - 别试图用
Sub结果除以time.Hour得“自然小时数”，它不处理 DST 跳变
性能与并发场景下的注意事项
time.Sub 本身极快（就是一次 int64 减法），但很多人忽略 time.Time 值携带的 *time.Location 引用 —— 如果你在高并发中频繁调用 t.In(someLoc) 再 Sub，会触发 location 查表和时区计算，开销明显上升。
尤其在 HTTP 中间件里对每个请求都做 reqTime.In(time.Local).Sub(startTime.In(time.Local))，不如一开始就统一用 UTC 存储所有时间点。
- 高频场景下，所有时间统一用
time.UTC，避免.In()调用 -
time.Time是值类型，传参或赋值无额外开销，但别反复调用.Local()或.UTC() - 测试中 mock 时间？用
func() time.Time注入，别直接调time.Now()
真正难的从来不是怎么调 Sub，而是搞清你到底要“物理时间差”还是“日历时间差”，以及上下游系统约定的是什么时区。这两个点没对齐，后面所有计算都是空中楼阁。
