time.Parse 和 time.ParseInLocation 返回错误最常见原因是时区和格式字符串不匹配；必须严格按参考时间 "Mon Jan 2 15:04:05 MST 2006" 匹配，错一位即失败；解析本地时间须用 ParseInLocation 并传 time.Local。
time.Parse 和 time.ParseInLocation 为什么总返回错误？
最常见原因是时区和格式字符串不匹配。Go 的 time.Parse 不接受任意格式，必须严格匹配预定义的参考时间 "Mon Jan 2 15:04:05 MST 2006"（即 Unix 时间戳对应值）。写错一个数字、多一个空格、漏掉时区缩写都会导致 parse error。
- 用
time.RFC3339解析"2024-05-20T14:30:00+08:00"这类标准 ISO 时间，别手写格式 - 解析本地时区时间（如
"2024-05-20 14:30:00"）必须用time.ParseInLocation，传入time.Local，否则默认按 UTC 解析，结果偏移 8 小时 - 从 HTTP Header 或 JSON 取出的时间字符串若含
"GMT"或"UTC"，注意 Go 不识别"GMT"为有效时区名，需提前替换为"MST"或改用time.LoadLocation("GMT")
time.Timer 和 time.Ticker 在长期运行服务中怎么避免泄漏？
time.Timer 和 time.Ticker 都持有 goroutine 和系统资源，没显式停止就会一直占用，尤其在循环重建或 HTTP handler 中反复创建时极易泄漏。
- 每次
time.NewTimer后，只要没触发C通道，就一定要调用timer.Stop()；Stop()返回false表示已触发，此时无需再处理 -
time.Ticker必须在不再需要时调用ticker.Stop()，且建议配合select使用case + <code>case 实现可控退出 - 不要在 for 循环里反复
time.NewTicker(time.Second)—— 应复用单个 ticker，或用time.AfterFunc替代一次性延时
如何安全地做“每天凌晨 2 点执行”的定时逻辑？
直接用 time.Now().Hour() == 2 轮询既耗 CPU 又不准；用 time.Ticker 每分钟检查又容易错过跨天瞬间。正确做法是计算下次触发时间点，用 time.Timer 单次触发后重新调度。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先用
time.Now().Truncate(24 * time.Hour)截断到当日零点，再加2 * time.Hour得到今日凌晨 2 点 - 如果当前已过 2 点，就加 24 小时得到明日 2 点
- 启动
time.NewTimer(下次时间.Sub(time.Now()))，触发后立刻重算下一次时间并重置 timer - 务必用
time.LoadLocation("Asia/Shanghai")显式指定时区，避免服务器系统时区变更导致误判
time.Format 输出的中文星期/月份为什么显示成问号或乱码？
Go 的 time.Time.Format 不支持 locale，所有文字（如 "Monday"、"January"）固定输出英文。想输出中文必须手动映射，不能依赖格式字符串里的 Mon 或 Jan。
立即学习“go语言免费学习笔记（深入）”；
- 用
t.Weekday().String()得到英文名，再查 map 转中文：map[time.Weekday]string{time.Monday: "星期一", ...} - 月份同理：
t.Month().String()→ 查map[time.Month]string{time.January: "一月", ...} - 如果项目需多语言，建议封装成方法，把时区、语言、格式都作为参数，避免散落各处的硬编码转换
时区和格式字符串是 time 库里最容易出错的两个点，而且错误往往不报 panic，只默默给出错误时间值——上线后才发现定时任务全跑偏了，或者日志时间比实际晚 8 小时。
