time.parse 是参考时间对齐工具，非格式化函数；layout 必须严格匹配 "mon jan 2 15:04:05 mst 2006" 的位置含义，错误 layout 静默返回零值，需检查 err；解析无时区时间应优先用 parseinlocation 显式指定时区。
time.Parse 不是格式化函数，而是“参考时间对齐”工具；用错 layout 会静默返回零值时间（0001-01-01），且不报错——除非你检查 err。
layout 字符串必须严格对应参考时间 "Mon Jan 2 15:04:05 MST 2006"
Go 的 time.Parse 不接受 "%Y-%m-%d" 这类占位符，也不允许把 layout 写成实际时间（比如 "12/8/2015 12:00:00"）。它只认一个固定“锚点”：参考时间中每个字符的位置和含义是硬编码的。
例如：
-
2表示“日”，不是“数字 2”——所以"1/2/2006"对应"12/8/2015"，而非"12/08/2015"（后者要用"1/02/2006"） -
15表示“24 小时制小时”，无论输入是"09"还是"23"，layout 中都必须写"15"，不能替换成"09"或"23" -
MST是时区缩写的通用占位符，输入是"UTC"、"CST"或"PDT"，layout 中仍应写"MST"，而不是改成对应字符串
解析带时区缩写但无偏移的时间字符串（如 "Tue Nov 27 09:09:29 UTC 2012"）
这类字符串常见于日志或旧系统输出，容易因 layout 中误写时区而失败。
正确做法是保留参考时间中的 MST 占位符，并确保其余字段顺序和分隔符完全一致：
- 错误 layout：
"Mon Jan 02 09:04:05 UTC 2006"（改了15 → 09，且把MST换成UTC） - 正确 layout：
"Mon Jan 2 15:04:05 MST 2006"（仅调整空格和缩写形式以匹配输入） - 实际适配示例：
time.Parse("Mon Jan 2 15:04:05 MST 2006", "Tue Nov 27 09:09:29 UTC 2012")
注意：如果输入中月份是全称（如 "November"），layout 中就得用 "January"；如果是缩写（"Nov"），就用 "Jan" ——大小写和长度必须一致。
time.Parse 默认按本地时区解释无时区时间，但服务器上 local 往往是 UTC
这是最隐蔽的坑：调用 time.Parse("2006-01-02 15:04:05", "2024-01-01 12:00:00") 看似成功，但返回的 Time 的 Location() 很可能是 UTC（尤其在 Docker 容器或 Linux 云主机上），而非你期望的 Asia/Shanghai。
解决方式只有两个：
- 用
time.ParseInLocation(layout, value, loc)显式指定时区，例如：shanghai, _ := time.LoadLocation("Asia/Shanghai"); t, _ := time.ParseInLocation("2006-01-02 15:04:05", "2024-01-01 12:00:00", shanghai) - 避免依赖
time.Local：它由系统环境决定，生产环境不可靠；优先用time.UTC或显式LoadLocation
别忘了：Go 内部所有 Time 都以 UTC 纳秒存储，In() 只影响显示和部分方法行为（如 Hour()），不影响 Unix() 返回值。
预定义常量能省事，但别迷信 RFC3339 或 ANSIC
time.RFC3339、time.ANSIC 等常量只是常用 layout 的快捷方式，它们对输入格式极其敏感。
-
time.RFC3339要求带纳秒（"2006-01-02T15:04:05Z"或"2006-01-02T15:04:05.123456789Z"），缺小数点或 Z 就失败 -
time.ANSIC是"Mon Jan _2 15:04:05 2006"，注意日期前是空格不是02，输入为"02"就会解析失败 - 建议先用
time.Now().Format(预定义常量)打印出样例，再比对你的输入字符串是否完全一致
真正复杂的场景（比如混合中文、毫秒精度、自定义分隔符），还是得手写 layout ——核心就一条：对齐参考时间，一个字符都不能错。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
