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 时区名。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 方案一：字符串预处理，把 "PST" 替换为 "-0800"，再用
Parse解析 - 方案二（推荐）：用
time.LoadLocation("America/Los_Angeles")加载 IANA 时区，再调用ParseInLocation - 注意：
LoadLocation可能返回 error（如系统无对应时区数据），不能忽略
time.Time 比较、加减、取整时有哪些隐藏陷阱？
比较操作符（==, ）本身安全，但要注意 <code>time.Time 包含纳秒精度，而数据库或前端常只存到秒级，直接比较可能因精度丢失失败。
- 跨系统比较前先对齐精度：
t1.Truncate(time.Second).Equal(t2.Truncate(time.Second)) -
AddDate(0,0,1)和Add(24*time.Hour)行为不同：前者按日历加一天（考虑闰月、月末），后者严格加 24 小时（可能跨两天） -
Truncate(time.Hour)向下取整到小时，但Round(time.Hour)是四舍五入，别混用
真正难的从来不是调哪个函数，而是意识到时间值自带上下文（时区、精度、表示方式），而 Go 的 time 包把选择权全交给你——不显式声明，它就用默认，而默认往往不是你想要的。
