Go time包解析失败常静默返回零值，因布局须严格匹配参考时间”2006-01-02″；格式化应优先用RFC3339等预定义常量；时区须显式指定，避免依赖默认本地时区。
Go 的 time 包不是“用起来就对”的那种——时间解析失败不报错但返回零值、时区处理默认本地却常被忽略、Parse 和 ParseInLocation 行为差异极易踩坑。核心原则是：**所有涉及字符串 ↔ 时间转换的操作，必须显式指定时区；所有格式化输出，优先用 Go 预定义常量而非手写布局串。**
为什么 time.Parse(“2006-01-02”, “2023-10-05”) 有时返回零时间？
最常见原因是布局字符串（layout）写错。time.Parse 的第一个参数不是格式模板，而是「参考时间」：Go 固定用 "Mon Jan 2 15:04:05 MST 2006" 这个具体时间点作为布局锚点。任何偏差都会导致解析失败并静默返回 time.Time{}（即零值），且错误为 nil。
- 错误写法：
time.Parse("yyyy-MM-dd", "2023-10-05")→ 布局非法，返回零时间 +nil错误 - 正确写法：
time.Parse("2006-01-02", "2023-10-05")（年份必须是 2006，月份必须是 01） - 更安全做法：用
time.ParseInLocation显式传入time.UTC或time.Local，避免依赖默认时区
time.Now().Format(“2006-01-02 15:04:05”) 输出的时区是什么？
取决于 time.Now() 返回值的时区字段——默认是本地时区（由系统环境决定），不是 UTC。如果后续要存数据库或跨服务传输，这个隐含时区极易引发时间错乱。
- 明确转 UTC 再格式化：
time.Now().UTC().Format("2006-01-02 15:04:05") - 用预定义常量更可靠：
time.Now().Format(time.RFC3339)（输出带时区偏移，如"2023-10-05T14:30:00+08:00"） - 避免手写布局串中的时区部分（如
"MST"），它不会自动替换为当前时区名，而是字面匹配
如何安全地解析带时区缩写的字符串（如 “2023-10-05 PST”）？
time.Parse 不识别 PST/EST/CST 等缩写（它们有歧义且非标准），直接解析会失败。Go 官方建议用固定偏移或 IANA 时区名。
