go的time.parse默认将无时区时间按系统本地时区解析，而服务器常为utc；应使用parseinlocation显式指定时区，避免依赖易变的time.local。
Time.Parse 为什么总是解析成 UTC？
Go 的 time.Parse 默认把无时区信息的时间字符串当成本地时区解析，但如果你在服务器上跑（比如 Docker 容器或 Linux 云主机），Local 时区常常是 UTC —— 这不是 bug，是设计使然。
常见错误现象：Parse("2024-01-01 12:00:00", "2024-01-01 12:00:00") 返回的时间值看起来“对”，但调用 t.Location().String() 却是 UTC，后续做时区转换就全乱了。
- 明确指定时区：用
time.ParseInLocation，传入目标*time.Location，比如time.ParseInLocation(time.RFC3339, s, time.Local) - 避免依赖
time.Local：它受系统环境影响大；生产环境建议统一用time.UTC或显式加载时区：time.LoadLocation("Asia/Shanghai") - 注意格式字符串必须严格匹配：Go 不支持模糊匹配，
"2006-01-02"和"2006/01/02"是两个不同 layout，错一个字符就返回零值 + error
time.Now().In(location) 转时区后为什么还是不准？
表面上看 t.In(loc) 返回了新时间，但如果你拿它去算差值、存数据库、或者传给前端，可能发现“比预期快 8 小时”或“跨天出错”。根本原因是：Go 的 time.Time 内部始终以 UTC 纳秒存储，In() 只是改变显示和计算逻辑，不改变底层值 —— 但它会影响 Hour()、Date()、Unix() 等方法的行为。
-
Unix()永远返回 UTC 时间戳，跟当前Location无关；别用t.In(shanghai).Unix()以为能拿到东八区时间戳 - 跨时区比较安全：两个
time.Time直接用==或Before()是 OK 的，因为它们都基于 UTC 值 - 打印/序列化前务必确认时区：JSON 编码默认走
MarshalJSON，输出的是带时区偏移的 RFC3339 字符串；如果数据库字段是datetime（无时区），应先转成 UTC 再存
time.Ticker 和 time.AfterFunc 在容器里为啥经常不准？
Docker 容器或 Kubernetes Pod 启动时若未挂载宿主机时区文件（/etc/localtime 或 /usr/share/zoneinfo），time.Now() 仍能工作，但某些定时行为会受系统级 timerfd 或 clock_gettime 行为影响 —— 特别是当容器被休眠、CPU 节流或节点负载高时，Ticker.C 可能延迟数秒甚至丢 tick。
立即学习“go语言免费学习笔记（深入）”；
- 别依赖
Ticker做精确到秒级的业务调度：它适合“大概每 N 秒检查一次”的场景，而非 cron 替代品 - 用
time.Until(t)+time.Sleep替代固定间隔：比如“每天凌晨 2 点执行”，应计算下次触发时间，再 Sleep 到那个点，避免累积误差 - 容器启动时加参数：
-v /etc/localtime:/etc/localtime:ro，确保time.LoadLocation("")能读到正确时区，否则time.Now().In(loc)可能 panic
time.Format 输出的字符串为什么前端解析不了？
Go 的 time.Format 默认按 layout 字符串字面意思拼接，不自动补零、不处理时区缩写歧义。最典型的是用 "2006-01-02 15:04:05" 格式输出，前端 JS new Date(str) 在 Safari 或旧版 Chrome 上直接失败 —— 因为缺少时区信息，浏览器按本地时区解释，而 Go 输出没带 Z 或 +0800。
- 对外传输优先用
time.RFC3339：它强制包含时区偏移，JS、Python、Java 都能无歧义解析 - 避免自定义 layout 中混用中文或空格：比如
"2006年01月02日"看起来友好，但无法被标准库反向Parse，也不利于日志分析工具提取 - 如果必须用固定格式，记得手动附加时区：
t.In(time.UTC).Format("2006-01-02T15:04:05Z")，而不是靠t.Format("2006-01-02T15:04:05") + "Z"—— 后者在非 UTC 时区下会错
时区不是字符串标签，是参与所有时间运算的活数据；格式化不是为了人眼舒服，而是为了上下游能一致解读。这两点一旦忽略，问题往往出现在上线后第三天凌晨两点。
