go 的 time.parse 报“month out of range”错，根本原因是格式模板必须用具体时间“2006-01-02 15:04:05”而非占位符；时区缩写需预处理为“-0700”等标准格式；多格式解析应按精确度降序尝试；输出时须显式指定时区避免隐式转换。
Go 的 time.Parse 为什么总报错：parsing time "xxx": month out of range？
根本原因是 Go 的时间格式不是占位符（如 %Y-%m-%d），而是用一个**具体日期字符串作为模板**——"2006-01-02 15:04:05"。很多人误写成 "yyyy-MM-dd HH:mm:ss" 或 "%Y-%m-%d"，这会导致解析直接 panic。
正确做法是严格对照 Go 的参考时间（Mon Jan 2 15:04:05 MST 2006）来拼模板：
-
"2006"→ 年（4 位）；"06"→ 年（2 位，仅用于 00–99 年份） -
"01"→ 月（01–12）；"1"→ 月（1–12，无前导零） -
"02"→ 日；"2"→ 日（无前导零） -
"15"→ 小时（24 小时制）；"3"→ 小时（12 小时制）；"PM"或"pm"→ 上下午 -
"04"→ 分；"05"→ 秒；"000"→ 毫秒（三位）；"000000"→ 微秒 - 时区要用
"MST"、"-0700"或"-07:00"，不能写"UTC+8"或"CST"
例如解析 "2024/05/21 09:30:45.123 +08:00"，模板必须是 "2006/01/02 15:04:05.000 -07:00"。
处理带非标准时区缩写（如 CST、PDT）的字符串
Go 的 time.Parse 默认不识别 "CST" 这类模糊缩写（它可能是 China Standard Time，也可能是 Central Standard Time），直接解析会报 parsing time "...": unknown time zone CST。
安全做法是预处理字符串，把缩写替换成 RFC 3339 兼容格式：
- 用
strings.ReplaceAll替换常见缩写：strings.ReplaceAll(s, "CST", "+0800")、strings.ReplaceAll(s, "PDT", "-0700") - 更健壮的方式是用
time.LoadLocation加time.In转换：先按 UTC 解析（模板末尾用"Z"），再用目标时区转换 - 避免依赖系统时区数据库（
/usr/share/zoneinfo），因为容器或 Alpine 镜像可能缺失
示例：解析 "2024-05-21 10:30:00 PDT"，可先替换为 "2024-05-21 10:30:00 -0700"，再用模板 "2006-01-02 15:04:05 -0700" 解析。
解析多种格式的混合输入（如 API 返回不同 date 字段）
现实场景中，同一字段可能返回 "2024-05-21"、"2024-05-21T10:30:00Z"、"2024/05/21 10:30" 等多种格式。硬写 if-else 容易漏判，且性能差。
推荐做法是定义格式列表，顺序尝试解析：
- 把最具体的格式（含时分秒、时区）放在前面，最简格式（只有年月日）放最后
- 对每个格式调用
time.Parse，检查 err 是否为nil；一旦成功就返回 - 注意：空字符串、全空格、"null" 字符串需提前过滤，否则
Parse会返回 Unix 零值时间
示例代码片段：
func parseMultiFormat(s string) (time.Time, error) {
s = strings.TrimSpace(s)
if s == "" || s == "null" {
return time.Time{}, fmt.Errorf("empty time string")
}
formats := []string{
"2006-01-02T15:04:05Z",
"2006-01-02T15:04:05.000Z",
"2006-01-02T15:04:05-0700",
"2006-01-02 15:04:05",
"2006/01/02 15:04",
"2006-01-02",
}
for _, f := range formats {
if t, err := time.Parse(f, s); err == nil {
return t, nil
}
}
return time.Time{}, fmt.Errorf("unable to parse time: %q", s)
}
输出时如何避免时区丢失或意外转换？
调用 t.Format(...) 时，Go 默认使用 t.Location() 输出对应时区的时间。如果原始时间是 UTC，但 t.Location() 是本地时区（比如 Local），就会发生隐式转换，导致小时错乱。
关键判断点：
- 用
t.UTC().Format(...)强制输出 UTC 时间（适合日志、API 响应） - 用
t.In(loc).Format(...)显式切换到目标时区（loc来自time.LoadLocation("Asia/Shanghai")） - 避免直接用
time.Now().Format(...)—— 它依赖运行环境的系统时区，CI/容器里极易出错 - JSON 序列化时，
time.Time默认输出 RFC 3339 格式（含时区），但如果结构体字段加了json:"-,omitempty"或自定义 MarshalJSON，要确认是否保留了时区信息
一个容易被忽略的细节：Unix 时间戳（t.Unix()）本身与时区无关，但如果你用它反推“今天 0 点”，必须明确指定时区，否则 time.Unix(sec, 0).Truncate(24*time.Hour) 会在本地时区计算，不是你想要的“UTC 今日零点”。
