go 的 time.parse 必须使用固定参考时间 "mon jan 2 15:04:05 mst 2006" 作为 layout 模板，因其字段位置和含义被硬编码；时区、空格、数字位数等任何偏差都会导致解析失败。
Go 的 time.Parse 不是“按常规理解的格式字符串”来解析时间，而是强制要求使用固定参考时间（Mon Jan 2 15:04:05 MST 2006）作为模板 —— 这是唯一合法的 layout 字符串，写错一个字符、多一个空格、时区缩写不匹配都会直接 panic 或返回错误。
为什么必须用 "Mon Jan 2 15:04:05 MST 2006" 作 layout
Go 设计者故意选了一个真实存在的 Unix 时间点（2006-01-02 15:04:05 MST）作为参考，把每个字段位置和含义硬编码进解析逻辑。这不是惯例，是强制协议。
-
"2006-01-02"是合法 layout，"2006-01-01"就非法 —— 因为参考时间里是2，不是1 -
"3:04PM"合法，"03:04PM"也合法（小时字段允许 1 位或 2 位），但"15:04"要求 24 小时制，"3:04"默认 12 小时制 - 时区部分必须严格匹配：参考时间用
MST，那输入字符串里写PST或UTC就会失败，除非 layout 写成"MST"且输入恰好含MST；更稳妥的是用Z或-0700表示偏移量
常见错误：解析 "2023-10-05T14:30:45+0800" 失败
这个字符串带时区偏移，但很多人直接套用 "2006-01-02T15:04:05Z" 却忽略：Z 只匹配字面量 Z（即 UTC），不匹配 +0800。
- 正确 layout 应为
"2006-01-02T15:04:05-0700"（注意是-0700，不是-07:00） - 如果输入是
"2023-10-05T14:30:45Z"，才用"2006-01-02T15:04:05Z" - 若不确定时区格式，可先用
strings.ReplaceAll统一处理：比如把"+08:00"换成"+0800"，再用-0700解析
time.Parse 和 time.ParseInLocation 的关键区别
time.Parse 返回的时间值默认使用本地时区解释（即按当前系统时区解读字符串），而 time.ParseInLocation 允许你指定 location，更可控。
- 当输入是
"2023-10-05 14:30:45"且无时区信息时，time.Parse("2006-01-02 15:04:05", s)会把它当成「本地时间」；如果你本意是 UTC，结果就偏了 - 更安全的做法是显式指定：
time.ParseInLocation("2006-01-02 15:04:05", s, time.UTC) - 如果要解析带时区缩写的字符串（如
"Oct 5 2023 14:30:45 PST"），layout 必须含MST，且输入中的PST必须被 Go 识别为已知缩写（PST 是内置的，CST则可能被误判为 China Standard Time 或 Central Standard Time）
性能与复用建议：别每次都调用 time.Parse
time.Parse 内部会编译 layout 字符串，高频调用时开销明显。实际项目中应预定义解析函数。
- 用
var parseRFC3339 = func(s string) (time.Time, error) { return time.Parse(time.RFC3339, s) }封装，比每次传 layout 更快 - 对固定格式（如
"2006-01-02"），直接定义变量：const dateLayout = "2006-01-02"，然后time.Parse(dateLayout, s) - 注意：layout 字符串不能拼接或运行时构造，否则无法被编译器优化，且易出错
真正难的不是记住那串“魔数时间”，而是意识到 layout 是模式匹配的骨架 —— 它不关心你输入多好看，只认位置、长度、字面量是否严丝合缝。少一个空格、多一个冒号、时区偏移少一位数字，time.Parse 都不会给你模糊匹配，只会返回 error 或 panic。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
