time.Now() 默认返回本地时区时间，非 UTC；ParseInLocation 可指定时区解析，而 Parse 总用本地时区；Format 不改变时间值，时区不匹配会导致显示偏差；Duration 精确但 After 有调度延迟；推荐内部统一用 UTC。
time.Now() 返回的是本地时区还是 UTC？
默认返回本地时区时间，不是 UTC。Go 的 time.Now() 会读取系统时区设置（如 /etc/localtime 或环境变量 TZ），并构造带本地时区信息的 time.Time 值。这意味着同一段代码在不同时区机器上运行，time.Now().String() 输出格式相同但实际时刻不同。
- 若需确定性行为（如日志、测试、分布式系统），应显式转为 UTC：
now := time.Now().UTC()
- 用
time.Now().In(time.UTC)效果等价，但.UTC()更轻量（不触发时区查找） - 注意：
time.Now().Zone()返回当前时区名和偏移秒数，可用于调试时区是否被正确识别
Parse 和 ParseInLocation 区别在哪？
time.Parse() 总是按本地时区解析字符串；time.ParseInLocation() 允许指定目标时区，这才是处理跨时区时间字符串的正确方式。
- 错误用法（以为字符串含时区就自动生效）：
time.Parse("2006-01-02T15:04:05Z", "2024-03-15T10:30:00+08:00") // ❌ 解析失败，因为 layout 中没写 +08:00 - 正确做法：先定义匹配格式，再选时区
t, err := time.ParseInLocation("2006-01-02T15:04:05-07:00", "2024-03-15T10:30:00+08:00", time.Local) - 若字符串末尾是
Z，layout 必须用Z（不能用-07:00），且结果时区为 UTC；若字符串含+08:00，layout 就得用-07:00占位
Format 输出时间为什么总是少 8 小时或错乱？
根本原因：格式化输出本身不改变时间值，只影响字符串表现。如果你看到“少了 8 小时”，大概率是原始 time.Time 值本身就在 UTC，而你期望它代表东八区时间，却直接 Format 了 —— 这时显示的是 UTC 时间，自然比北京时间晚 8 小时。
- 确认当前值的时区：
fmt.Println(t.Location().String(), t.Zone()) // 输出类似 "CST" "CST" 或 "UTC" "UTC"
- 要以北京时间输出，必须先切换时区：
beijing, _ := time.LoadLocation("Asia/Shanghai") tInBJ := t.In(beijing) fmt.Println(tInBJ.Format("2006-01-02 15:04:05")) - 避免硬编码偏移（如
time.FixedZone("CST", 8*60*60)），因为夏令时、历史时区变更会导致偏差；优先用 IANA 时区名（Asia/Shanghai）
Duration 和 time.After 为什么有时不准？
time.Duration 是纳秒级整数，本身精确；但 time.After()、time.Sleep() 等依赖系统调度和底层 timer 实现，实际等待可能略长（尤其在高负载或虚拟机中），绝不会提前。
立即学习“go语言免费学习笔记（深入）”；
- 不要用
time.After(1 * time.Second)做精确定时任务，它适合“至少等 1 秒”的场景（如超时控制） - 需要周期性执行，请用
time.Ticker，但注意：如果Tick处理耗时超过周期，后续 tick 会堆积（不会跳过），必要时应加锁或丢弃过期 tick - 测试中避免依赖真实时间，用
github.com/benbjohnson/clock或 Go 1.20+ 的time.Now = func() time.Time { ... }替换（需构建时注入）
时区转换和格式化逻辑容易在开发机与生产机之间因系统配置差异暴露问题，尤其当代码混用 Local、UTC 和固定偏移时 —— 最稳妥的做法是：内部统一用 UTC 存储和计算，仅在展示层按需转本地时区。
