Go 的 time.Parse 和 time.Format 必须严格使用参考时间 “Mon Jan 2 15:04:05 MST 2006” 的字面值格式，如 “2006-01-02” 而非 “yyyy-MM-dd”，错一位即解析失败或静默异常。
time.Parse 和 time.Format 的格式字符串不是常见的时间模板，而是 Go 特定的参考时间（Mon Jan 2 15:04:05 MST 2006）——用错格式会静默失败或 panic，必须严格对齐。
为什么 time.Parse 总是返回错误或解析出错？
Go 不接受 "yyyy-MM-dd HH:mm:ss" 这类通用模板。它要求格式字符串必须和参考时间 "Mon Jan 2 15:04:05 MST 2006" 的**字面值完全一致**（大小写、空格、缩写、顺序都不能错）。
-
"2006-01-02"✅ 对应年月日（不能写成"%Y-%m-%d"或"yyyy-MM-dd"） -
"15:04:05"✅ 对应 24 小时制时分秒（"HH:mm:ss"❌） -
"02/01/2006"✅ 是美式日期，"01/02/2006"是另一套（月份在前） - 时区部分要小心：
"MST"是占位符，实际输入可以是"UTC"、"CST"、"+0800"，但格式串里必须写"MST"或"-0700"才能匹配
示例错误：用 time.Parse("2006-01-02 15:04:05", "2023-10-05 14:30:00") 是对的；但写成 time.Parse("Y-m-d H:i:s", ...) 会直接返回 parse error。
time.Format 输出不符合预期，比如年份变成 0006？
time.Format 的行为和 time.Parse 对称：它也依赖同一套参考时间格式。如果你传入的格式串里写了 "06"，它就输出两位年份（如 "23"）；写了 "2006"，才输出四位（"2023"）。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
t.Format("2006-01-02")→"2023-10-05" -
t.Format("06-01-02")→"23-10-05"（不是 bug，是设计） - 中文环境常用
"2006年01月02日 15:04:05"，其中汉字是字面量，不影响解析，但必须确保数字部分严格按参考时间对齐 - 如果输出时区偏移为
+0800，格式串要用"-0700"；若要带冒号如+08:00，得用"-07:00"
如何安全处理带时区或 UTC 时间的解析？
默认 time.Parse 解析后的时间对象是本地时区（由系统决定），容易导致跨环境行为不一致。生产中建议显式指定时区。
- 用
time.ParseInLocation+time.UTC强制按 UTC 解析：time.ParseInLocation("2006-01-02T15:04:05Z", "2023-10-05T06:30:00Z", time.UTC) - 解析带
+0800的字符串时，格式串中对应位置必须是"-0700"（参考时间是 -0700），否则匹配失败 - 如果输入可能含多种时区标识（
Z、+0800、CST），建议先正则提取时区部分，或统一转成 RFC3339 格式再解析 - 注意：RFC3339 是标准子集，推荐优先使用
time.RFC3339常量，比如time.Parse(time.RFC3339, "2023-10-05T14:30:00+08:00")
性能与可维护性提醒
频繁调用 time.Parse 时，不要每次都拼接格式字符串。把常用格式定义为常量，避免拼错或重复计算。
- 定义：
const LayoutISO = "2006-01-02T15:04:05Z" - 避免在循环里反复调用
time.Parse("2006-01-02", s)，可考虑预编译正则提取日期再构造time.Date（极端性能场景） - 测试时务必覆盖边界值：闰年 2 月 29 日、夏令时切换日、时区缩写歧义（如 CST 可能指 China Standard Time 或 Central Standard Time）
- JSON 中的时间字段默认用 RFC3339，
time.Time结构体已内置支持，无需手动Parse/Format
最易被忽略的是：格式字符串里的空格、中英文标点、大小写全都是硬性要求，哪怕多一个空格或错一个字母，Parse 就失败，且错误信息不提示具体哪错了——建议把格式常量化并加注释说明来源。
