Go 的 time.Parse 失败主因是 layout 格式错误，因其仅认参考时间“Mon Jan 2 15:04:05 MST 2006”对应格式，如“2006-01-02 15:04:05”正确，而“YYYY-MM-DD HH:mm:ss”非法；还需注意空白/BOM、时区匹配及优先使用 RFC3339 等预定义常量。
time.Parse 用错 layout 格式字符串是最大原因
Go 的 time.Parse 不接受常见的 "YYYY-MM-DD HH:mm:ss" 这类占位符，它只认 Go 自己定义的参考时间：Mon Jan 2 15:04:05 MST 2006（即 Unix 时间戳 1136239445 的文字表示）。任何 layout 字符串都必须严格对应这个参考时间中各字段的位置和大小写。
-
"2006-01-02 15:04:05"✅ 正确 —— 年份、月份、日期、小时（24 小时制）、分钟、秒都按参考时间对齐 -
"YYYY-MM-DD HH:mm:ss"❌ 错误 —— 这是其他语言（如 Python、JS）的习惯，Go 会直接返回parsing time ... as "YYYY-MM-DD ...": cannot parse "Y" as "2" -
"2006/01/02 3:04:05 PM"✅ 可用 —— 对应参考时间中的Jan 2 15:04:05，注意3是小时（12 小时制），后面必须带PM或AM - 月份用
01（带前导零）而非1；星期用Mon而非Monday；时区缩写用MST（不是UTC或GMT）——这些细节错一个就解析失败
输入字符串含不可见字符或多余空格导致解析静默失败
比如从 HTTP header、JSON 字段、数据库 TEXT 字段读出的时间字符串，可能开头/结尾有空白、BOM（\uFEFF）、全角空格（\u3000）等。而 time.Parse 遇到 layout 无法匹配的字符就立即报错，不会跳过或 trim。
- 务必在解析前用
strings.TrimSpace清理首尾空白 - 若怀疑 BOM，可用
bytes.TrimPrefix([]byte(s), []byte("\uFEFF"))剥离 - 打印原始字符串的 rune 列表可快速定位异常字符：
fmt.Printf("%q\n", []rune(s)) - 例如：
" 2023-05-10T12:34:56Z "直接传给time.Parse("2006-01-02T15:04:05Z", s)会失败；必须先 trim
时区信息缺失或不匹配引发意外结果
layout 中没写时区标识（如 Z、MST、-0700），但输入字符串带时区，或者反过来，都会导致解析失败或结果偏差。
- 输入为
"2023-05-10T12:34:56+0800"，layout 必须包含"2006-01-02T15:04:05-0700"（注意-0700是固定格式，不能写成+0800） - 输入为 UTC 时间字符串
"2023-05-10T12:34:56Z"，layout 必须用"2006-01-02T15:04:05Z"，不能漏掉末尾的Z - 如果输入无时区（如
"2023-05-10 12:34:56"），但你希望按本地时区解释，需用time.ParseInLocation显式指定：loc, _ := time.LoadLocation("Asia/Shanghai") t, err := time.ParseInLocation("2006-01-02 15:04:05", s, loc)
使用 time.RFC3339 等预定义常量能避免手写错误
Go 标准库提供了多个常用 layout 常量，比手写更安全，也更易读。尤其适合处理 HTTP、JSON、日志等标准格式时间。
-
time.RFC3339→"2006-01-02T15:04:05Z07:00"（ISO 8601 子集，最常用） -
time.RFC3339Nano→ 带纳秒精度的 RFC3339 -
time.RFC1123→"Mon, 02 Jan 2006 15:04:05 MST"（HTTP Date 头） -
time.Kitchen→"3:04PM"（仅时间，美式） - 注意：这些常量不含时区名称（如
CST），只支持缩写（MST）或偏移（-0700、Z）；遇到"CST"这类模糊缩写，仍需自定义 layout 或预处理
真正麻烦的不是 layout 记不住，而是错误信息里不告诉你哪一位不匹配——它只报“cannot parse 'X' as 'Y'”，得靠比对参考时间逐字符检查。建议把常用 layout 写成常量集中管理，而不是每次临时拼字符串。
