add按纳秒偏移，适合精确时间间隔；adddate按日/月/年逻辑偏移，适合业务语义日期增减，如账单周期、生日提醒，且自动处理月末越界回滚。
Go 里 Add 和 AddDate 的核心区别在哪
不是“哪个更好”，而是“哪个该用”：Add 按纳秒偏移，AddDate 按日/月/年逻辑偏移。比如 1 月 31 日加 1 个月，AddDate(0,1,0) 得到 2 月 28 日（或 29），而 Add(720 * time.Hour) 会硬算到 3 月 2 日 —— 完全不是一回事。
常见错误现象：Add(24 * time.Hour) 处理跨夏令时日期时结果错位；用 Add 模拟“加一个月”导致每月天数不一致（如 1 月 31 日 + 31 天 = 3 月 3 日，但 2 月根本没 31 日）。
-
Add适合：精确时间间隔（倒计时、超时控制、日志时间戳微调） -
AddDate适合：业务语义上的日期增减（生日提醒、账单周期、报表周期） - 参数差异：
Add接time.Duration；AddDate接三个int（年、月、日），不支持小时/分钟
用 AddDate 加减月份时的隐含规则
Go 不会自动“归整”越界日期，而是按日历逻辑回滚：2023-01-31 加 1 个月 → 2023-02-28（不是 3 月 3 日）；再加 1 个月 → 2023-03-28。这个行为是确定的，但容易被当成 bug。
使用场景举例：用户订阅服务从 1 月 31 日起按月续费，系统必须在每月最后一天扣款，而不是固定“30 天后”。
- 如果希望强制落到当月最后一天，得手动判断：
t.AddDate(0,1,0).AddDate(0,0,-t.Day()+1).AddDate(0,0,-1)（先跳到下月 1 号，再减 1 天） - 跨年时注意负值：2023-03-15 调用
AddDate(-1,0,0)→ 2022-03-15，没问题；但AddDate(0,-1,0)对 2023-01-15 是合法的（→ 2022-12-15） - 性能无差异，两者都是纯计算，无 I/O 或内存分配
别用 Add 算“几天后”，除非你真要纳秒级精度
写 t.Add(3 * 24 * time.Hour) 看似简洁，实则埋雷：遇到夏令时切换（如美国 PDT → PST）会多/少 1 小时；遇到闰秒理论上也可能偏差（虽然 Go 运行时目前忽略闰秒）。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
错误信息示例：2023-11-05 01:30 -0700 PDT 加 24*time.Hour 后变成 2023-11-06 01:30 -0800 PST —— 表面看是“同时间”，实际物理间隔是 25 小时。
- 想表达“日历上三天后”，一律用
AddDate(0,0,3) - 想表达“严格 72 小时后”，才用
Add(72*time.Hour)，且需注明这是“绝对时长”，不保证对应日历日期 - 兼容性注意：所有 Go 版本行为一致，但依赖
time.LoadLocation时，系统时区数据库版本会影响夏令时计算结果
时区没处理好，Add 和 AddDate 都白搭
这两个方法本身不改时区，只在输入时间的 Location 下做运算。如果你传入的是 time.Now()（本地时区），加减后仍是本地时区；如果传入的是 time.Now().UTC()，结果就是 UTC 时间 —— 但很多人忘了这层。
常见错误现象：服务器在 UTC，用户在 CST，代码用 time.Now().AddDate(0,1,0) 算下月账单日，结果比用户预期早/晚 8 小时。
- 业务时间统一用 UTC 存储和计算，展示时再转本地时区
- 若必须按用户本地时间算，先用
t.In(loc)切换到目标时区，再调AddDate；不要对 UTC 时间直接AddDate后再转时区 -
Add对time.Time的Location透明，但结果的Hour()/Day()值会随Location变化 —— 这点常被忽略
事情说清了就结束。最麻烦的从来不是调哪个函数，而是搞清楚你到底想表达“物理时间流逝”还是“日历翻页”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
