time.Parse 解析失败主因是模板必须使用固定参考时间“Mon Jan 2 15:04:05 MST 2006”的字面值，而非语义化占位符；需严格匹配格式、时区标识及空格标点，并务必检查错误。
time.Parse 无法解析你的时间字符串，大概率不是格式写错了，而是 Go 的时间格式模板和常见认知相反——它用的是固定参考时间 "Mon Jan 2 15:04:05 MST 2006"，而不是 "YYYY-MM-DD HH:mm:ss" 这类占位符。
为什么 time.Parse 总返回 “parsing time …” 错误？
Go 不用语义化占位符（如 "%Y-%m-%d" 或 "yyyy-MM-dd"），而是硬编码“参考时间”的字面值。比如年份必须写成 "2006"，月份必须是 "Jan" 或 "01"（取决于你想要英文缩写还是数字），小时必须是 "15"（24 小时制），"03" 才是 12 小时制。
常见踩坑点：
- 把
"2006-01-02 15:04:05"写成"2024-01-01 12:30:45"—— 模板里不能出现实际值，只能是那个固定参考时间的字面形式 - 混淆
"MST"和时区偏移：模板中"MST"是占位符，不代表必须有缩写时区；若输入含"+0800"，模板对应位置就得是"+0700"（参考时间在 Mountain Standard Time，UTC-7） - 忽略空格或标点：模板中每个字符（包括空格、冒号、短横）都必须与输入严格匹配
解析常见格式：ISO 8601、RFC 3339、MySQL DATETIME
别自己拼模板，优先用 Go 内置常量：
立即学习“go语言免费学习笔记（深入）”；
-
time.RFC3339→ 匹配"2006-01-02T15:04:05Z07:00"或"2006-01-02T15:04:05+08:00" -
time.ISO8601→ Go 1.20+ 新增，支持更宽松的 ISO 格式（如无 T、带毫秒） -
"2006-01-02 15:04:05"→ 对应 MySQLDATETIME字符串（注意：没有时区，解析后为Local时区） -
"2006-01-02"→ 纯日期，解析后时间为当天 00:00:00 Local
示例：
t, err := time.Parse("2006-01-02 15:04:05", "2024-05-20 14:30:15")
if err != nil {
log.Fatal(err) // 注意：不处理 err 会导致静默失败
}
带时区的时间字符串怎么安全解析？
输入含时区（如 "2024-05-20 14:30:15 +0800" 或 "2024-05-20T14:30:15+08:00"）时，模板必须显式包含时区部分，否则 time.Parse 会按本地时区解释。
- 用
time.RFC3339解析带Z或+08:00的字符串最稳妥 - 若输入是
"+0800"（无冒号），模板对应位置必须是"+0700"，不能是"+07:00" - 想强制指定时区（如全部当 UTC 处理），可用
time.ParseInLocation，传入time.UTC：
t, err := time.ParseInLocation("2006-01-02 15:04:05", "2024-05-20 14:30:15", time.UTC)
注意：ParseInLocation 第三个参数是 *time.Location，不是字符串名；time.LoadLocation("Asia/Shanghai") 才能加载命名时区。
性能与复用：别在循环里反复调用 time.Parse
time.Parse 内部会做字符串扫描和时区计算，开销不小。如果解析同一格式的大量时间字符串（如日志行、API 响应数组），应该：
- 提前定义好格式字符串常量，避免拼接或重复书写
- 对高频解析场景，考虑用
func(string) (time.Time, error)封装并复用，甚至缓存time.Location实例 - 极端性能敏感时（如百万级/秒），可预编译正则提取字段 + 手动构造
time.Date，但绝大多数情况没必要
最容易被忽略的一点：错误处理不是可选项。Go 的 time.Parse 在格式不匹配时返回 nil time.Time（即零值 0001-01-01 00:00:00 +0000 UTC），这个值看起来“合法”，但语义完全错误——务必检查 err，不要只看返回的 time.Time 是否非零。
