Go的time.Parse布局字符串必须是Mon Jan 2 15:04:05 MST 2006，因其是官方硬编码的参考时间，各字段值唯一且对应Unix时间戳1136239445，所有布局元素须来自预定义常量集，如01、02、15、2006等，否则解析失败或panic。
time.Parse 的布局字符串为什么必须是 Mon Jan 2 15:04:05 MST 2006
因为 Go 的 time.Parse 不用占位符（比如 %Y 或 yyyy-MM-dd），而是用「参考时间」做模板——Go 官方硬编码了这个特定时间点作为唯一合法布局格式。它不是随便选的，而是 Unix 时间戳 1136239445 对应的本地化字符串，且每个字段值都独一无二（比如 15 是 24 小时制唯一不重复的小时数）。
常见错误现象：time.Parse("2006-01-02", "2023-12-25") 看似合理，但实际能跑通；而 time.Parse("YYYY-MM-DD", "2023-12-25") 会 panic 报 parsing time "2023-12-25" as "YYYY-MM-DD": cannot parse "YYYY-MM-DD" as "YYYY"——因为 YYYY 不是有效布局元素。
- 所有布局字段必须来自 Go 定义的常量集：如
2006、01、02、15、04、05、MST、Jan、Monday等 - 月份必须用
01（不是1），日期必须用02（不是2），否则解析失败 - 时区缩写如
MST是占位符，不代表真实时区；若输入含CST或UTC，需额外处理或改用time.ParseInLocation
解析带时区的时间字符串，为什么 time.Parse 常出错
time.Parse 默认使用 time.UTC 作为基准位置（location），如果输入字符串含时区偏移（如 +0800、Z、UTC），而布局里没写对应字段，就会丢掉时区信息或直接报错。
使用场景：API 返回 "2023-12-25T14:30:00+0800"，想转成东八区本地时间。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误写法：
time.Parse("2006-01-02T15:04:05", s)—— 忽略了+0800，解析后时间被当作 UTC，结果错 8 小时 - 正确写法：
time.Parse("2006-01-02T15:04:05-0700", s)，其中-0700是布局占位符，匹配任意 ±HHMM - 若字符串含
Z（如"2023-12-25T14:30:00Z"），布局要用Z，不能用-0700；两者不兼容 - 更稳妥的方式是用
time.ParseInLocation显式指定目标时区，避免依赖输入字符串里的时区字段
Format 输出时间时，为什么年份/月份总不对
time.Time.Format 和 time.Parse 共享同一套布局规则，所以同样必须用 2006、01、02 等。新手常把 Python 或 JS 的习惯带进来，写成 "%Y-%m-%d" 或 "yyyy-MM-dd"，结果输出原样字符串，不是格式化后的时间。
性能影响：布局字符串是纯字面量，无运行时解析开销，但写错会导致返回空字符串或 panic（如果传了非法 layout）。
- 输出 ISO 8601 标准格式：
t.Format("2006-01-02T15:04:05Z07:00") - 输出中文日期：
t.Format("2006年01月02日 15:04:05")—— 非布局部分（如“年”“月”“日”）会被原样保留 - 注意
15是 24 小时制，3不合法；04是分钟，4也不合法；差一个前导零就完全不匹配
预定义常量够用吗？什么时候该自己写 layout
Go 提供了像 time.RFC3339、time.ISO8601、time.Kitchen 这些常量，但覆盖有限。比如 time.RFC3339 是 "2006-01-02T15:04:05Z07:00"，不支持毫秒；而 API 常返回 "2023-12-25T14:30:00.123Z"。
容易踩的坑：拼 layout 时复制粘贴出错，比如把 .000 写成 .123，或漏掉小数点前的 :。
- 带毫秒的 RFC3339：
"2006-01-02T15:04:05.000Z07:00"（注意是三个0，对应毫秒三位） - 数据库常用格式
"2006-01-02 15:04:05"，注意中间是空格，不是T - Unix timestamp 转字符串不用 layout：
strconv.FormatInt(t.Unix(), 10)更快更直接
布局字符串看着简单，但每个字符都是硬编码规则的一部分，错一位就全盘失效。最稳妥的做法是：从输入样本反推 layout，而不是凭记忆默写。
