Go time.Time.AddDate 跨月计算为什么不是固定24小时

Go 的 time.Time.AddDate 不是把“一个月”换算成固定小时数。它按日历字段计算，并使用原时间的 Location 解释日期，所以跨月时可能触发日期归一化，遇到夏令时还可能出现 23 小时或 25 小时的绝对时间差。需要固定经过时长时用 Add；需要“下个月同一日历位置”时才用 AddDate。

官方文档：https://pkg.go.dev/time#Time.AddDate

记住一句话：Add 面向时间线，AddDate 面向日历。账期、生日、自然月提醒优先考虑 AddDate；超时、缓存 TTL、重试间隔则使用 Add。

先分清 AddDate 和 Add 的问题模型

Add(d) 只关心一个 time.Duration，例如 24*time.Hour 就是时间线上明确的 24 小时。AddDate(years, months, days) 则修改年、月、日字段，结果仍由原来的时区解释。

package main

import (
    "fmt"
    "time"
)

func main() {
    loc := time.FixedZone("业务时区", 8*60*60)
    start := time.Date(2026, time.January, 31, 10, 0, 0, 0, loc)

    // Add 表示时间线上固定经过 24 小时。
    afterDuration := start.Add(24 * time.Hour)
    // AddDate 表示日历字段增加一天，结果仍使用 start 的 Location。
    afterCalendarDay := start.AddDate(0, 0, 1)
    // AddDate 的月份参数不是“约等于多少小时”。
    afterCalendarMonth := start.AddDate(0, 1, 0)

    fmt.Println(afterDuration)
    fmt.Println(afterCalendarDay)
    fmt.Println(afterCalendarMonth)
}

这三种结果回答的是三个不同问题：经过多久、日历上后一天、日历上后一个月。不要因为示例中某个日期的结果看起来相同，就把两组 API 当成可互换写法。

跨月时为什么会从 11 月 31 日变成 12 月 1 日

AddDate 会按 time.Date 的规则归一化结果，而不是自动把日期截到目标月份的最后一天。因此从 10 月 31 日增加一个月，内部形成的目标字段相当于 11 月 31 日，归一化后会落到 12 月 1 日。

package main

import (
    "fmt"
    "time"
)

func main() {
    start := time.Date(2026, time.October, 31, 9, 30, 0, 0, time.UTC)

    // 这里测试的是日历月份移动，不是“保留在目标月最后一天”。
    nextMonth := start.AddDate(0, 1, 0)
    fmt.Println("start:", start.Format("2006-01-02"))
    fmt.Println("next:", nextMonth.Format("2006-01-02"))
}

如果业务要求“下个月最后一天”，不要直接依赖 AddDate(0, 1, 0) 的归一化结果。可以先把日期移动到目标月份的第一天，再减去一天，或者把“月末策略”写成单独函数，并用 1 月、2 月、闰年和 12 月做表格化测试。

同样加一天，为什么可能不是 24 小时

日期和时区是绑定的。AddDate 使用 Time 自带的 Location 来解释日历周期；跨越夏令时切换时，本地钟表仍然从某个时刻的 12:00 走到下一天的 12:00，但两者之间的绝对时长可能是 23 小时或 25 小时。

package main

import (
    "fmt"
    "time"
)

func main() {
    zurich, err := time.LoadLocation("Europe/Zurich")
    if err != nil {
        // 时区数据不可用时不要静默改用本地时区。
        panic(err)
    }
    start := time.Date(2026, time.March, 28, 12, 0, 0, 0, zurich)

    // 这是“本地日历上的下一天”。
    calendarNext := start.AddDate(0, 0, 1)
    // 这是“时间线上固定经过 24 小时”。
    durationNext := start.Add(24 * time.Hour)

    fmt.Println("calendar:", calendarNext)
    fmt.Println("duration:", durationNext)
    fmt.Println("elapsed:", calendarNext.Sub(start))
}

示例的关键不在于某个地区的固定输出，而在于检查点：calendarNext 保持本地日历时间，durationNext 保持绝对时长。若业务不能接受时区数据库缺失，应该让 LoadLocation 的错误向上返回，而不是偷偷使用 time.Local。

按业务目标选择写法

最小回归检查至少覆盖：月末跨月、闰年 2 月、时区切换日前后、UTC 与业务时区对照，以及比较 Sub 得到的绝对时长。测试断言要写清是比较日期字段，还是比较时间线上的持续时间，避免把两类目标混在一个断言里。

常见问题

AddDate(0, 0, 1) 能当成 24 小时吗？

不能。它代表本地日历上的下一天，夏令时切换时对应的绝对时长可能不是 24 小时。

怎样保证“下个月最后一天”？

把月末规则单独表达出来，不要把 AddDate(0, 1, 0) 的归一化结果当成月末算法，并为不同月份补回归用例。

什么时候应该直接用 UTC？

如果业务只关心统一的时间线间隔，UTC 配合 Add 更直接；如果读者看到的是某个地区的自然日和账期，则应保留明确的业务 Location。

总结：Add 解决“经过多久”，AddDate 解决“日历上移动到哪里”。跨月归一化和时区切换都是 API 契约的一部分，先写清业务语义，再选择函数，时间计算就不会被“一个月等于多少小时”的假设带偏。