在 Go 项目里，时间差计算几乎无处不在：统计函数耗时、判断请求是否超时、检查缓存或任务是否过期，都会碰到 time.Duration。问题不在于能不能算出来，而在于代码写出来之后，别人一眼能不能看懂、自己半年后回头会不会犹豫“这里到底是谁减谁”。
如果你还在频繁写 time.Now().Sub(start) 或靠 Add 配合比较来判断截止时间，这篇文章要解决的就是这个阅读和维护成本问题。下面按旧写法、新写法和实际收益三个层次展开，最后给出一个足够明确的使用建议。
传统写法：time.Sub 与 time.Add 的问题在哪
在 Go 1.8 之前，时间差计算主要依赖 time.Time 的 Sub 方法：
start := time.Now()
heavyTask()
duration := time.Now().Sub(start)Sub 接收一个时间参数，返回两个时间点之间的 time.Duration。如果只是临时写一个小例子，这种方式当然能用；但一旦代码出现在真实业务里，理解成本就开始冒出来了。
例如，向未来推进一个截止时间，通常会这样写：
deadline := time.Now().Add(5 * time.Minute)再配合当前时间去比较，就能判断是否已经过期。问题在于，这套写法更偏“机械正确”，不是“语义清楚”。阅读 time.Now().Sub(start) 时，开发者要先确认参数顺序；看到 Add 时，还要分辨传入的是正数还是负数，才能知道时间是在向前还是向后移动。
这些细节在短代码里不明显，但只要逻辑稍微复杂一些，比如把时间计算放进条件判断、重试逻辑、超时控制或并发流程里，心智负担就会上来。代码并没有错，只是不够顺手，也不够“见名知意”。
Go 1.8 之后：用 time.Since 与 time.Until 直接表达意图
Go 1.8 引入了 time.Since 和 time.Until，就是为了解决这种语义不直观的问题。
// time.Since: 计算从过去某个时间点到现在的时间间隔
start := time.Now()
doWork()
elapsed := time.Since(start)// time.Until: 计算从现在到未来某个时间点的间隔
deadline := time.Now().Add(5 * time.Second)
remaining := time.Until(deadline)它们的函数签名也很简单：
func Since(t Time) Duration
func Until(t Time) Duration对应关系可以直接记成下面两句：
time.Since(t)等价于time.Now().Sub(t)time.Until(t)等价于t.Sub(time.Now())
但真正重要的不只是“等价”，而是表达方式变了。Since 读起来就是“自从某个时间到现在”；Until 读起来就是“距离某个时间还有多久”。这让时间计算从“需要脑内翻译”的 API，变成“看字面就知道意思”的 API。
为什么这套新写法更值得推广
语义更直观，减少阅读停顿
// 旧写法：需要思考"谁减谁"
elapsed := time.Now().Sub(start)
// 新写法：语义自解释
elapsed := time.Since(start) // "自从 start 到现在"这类差异看起来像是“少敲几个字”和“换个名字”，实际上影响的是代码审查和日常维护效率。time.Since(start) 不需要额外解释，读到这里的人可以立刻把注意力放回业务逻辑，而不是停下来确认时间方向。
在超时判断里更简洁
超时场景能更明显看出两种写法的差别：
// 旧写法
if time.Now().Sub(deadline) > 0 {
// 处理超时
}
// 新写法
if time.Until(deadline) < 0 {
// 处理超时
}time.Until(deadline) < 0 这句的意思非常直接：距离截止时间已经是负数了，说明截止点已经过去。相比之下，time.Now().Sub(deadline) > 0 虽然逻辑等价，但表达上更绕一步。
更不容易把方向写反
时间计算常见问题不是算法难，而是顺序写反。比如下面这个 bug：
// 错误：Sub 的参数顺序写反了
duration := start.Sub(time.Now()) // 得到负数！这种错误在 review 时未必一眼能发现，尤其当变量名不够明确、上下文又比较长的时候。改成 time.Since(start) 后，方向是固定的，误用空间会小很多。
这里还要顺手记住一个行为特征：time.Since 计算的是“从指定时间到现在”的间隔。如果传入过去时间，返回正值；如果传入未来时间，返回负值。time.Until 则刚好相反，也就是：
time.Until(t) == -time.Since(t)理解这一点之后，很多边界判断会更稳，也更容易写出一致的条件表达式。
更容易统一团队风格
在多人协作项目中，时间计算方式如果混着写，读代码的人就要不断切换理解模式。有的地方用 Now().Sub(...)，有的地方用 Sub(Now())，还有的地方把 Add 和比较条件拼在一起，逻辑虽然都成立，但整体风格会显得零散。
time.Since 和 time.Until 提供了一套更稳定的表达约定：过去到现在，优先用 Since；现在到未来，优先用 Until。约定一旦形成，团队沟通成本会明显下降，代码审查也更容易聚焦真正的业务问题。
实际项目里该怎么选
如果你的目标只是“功能正确”，那么 Sub、Add 当然仍然有效，它们并没有过时。问题是，在绝大多数“计算耗时”“判断剩余时间”“检查是否过期”的场景里，Since 和 Until 能把同样的逻辑写得更清楚。
可以按下面的原则快速判断：
- 统计从某个开始时间到现在的耗时，用
time.Since(start) - 计算距离某个截止时间还有多久，用
time.Until(deadline) - 需要表达“已经超时”或“已经过期”，优先围绕
time.Until(...)的正负来写条件 - 只有在确实需要做两个任意时间点之间的通用差值计算时，再直接使用
Sub
换句话说，Sub 更像底层能力，Since 和 Until 更像面向常见开发场景的语义化封装。它们不是替代所有时间运算，而是在最常见的场景中，把代码从“能运行”推进到“更好读”。
结语：这类小改进，往往最能体现 Go 的取舍
从 time.Sub / time.Add 到 time.Since / time.Until，表面看只是 API 形式变化，实际上体现的是 Go 一贯的设计倾向：让常见场景拥有更直接、更稳妥的表达方式。
这套写法的价值可以归纳为四点：语义更明确，阅读负担更低，参数顺序错误更少，团队代码风格也更容易统一。因此，在实际项目中，一个非常实用的建议是：能用 time.Since 和 time.Until 的地方，就尽量不要回到 time.Sub 的手工表达。
当你下一次再写耗时统计或超时判断时，可以先问一句：这里是在表达“自从某时到现在”，还是“距离某时还有多久”？如果答案很明确，那对应的 API 通常也已经替你选好了。
