time.Parse失败主因是layout与输入字符串不匹配，须用“2006-01-02 15:04”格式；LoadLocation失败多因zoneinfo.zip缺失；In转换不改内部UTC值；ParseInLocation第三参数必须为*Location而非字符串。
time.Parse 解析失败：字符串格式不对，不是时区问题
绝大多数 time.Parse 报错，比如 parsing time "2024-03-15 14:22" as "2006-01-02": cannot parse " 14:22" as ""，根本原因不是时区，而是布局字符串（layout）和输入字符串不严格匹配。Go 的 layout 必须用固定参考时间 "Mon Jan 2 15:04:05 MST 2006" 的格式来写，不能套用常见的 "YYYY-MM-DD HH:mm:ss"。
- 错误写法：
time.Parse("YYYY-MM-DD HH:mm", s)——YYYY、HH都不是合法 layout 元素 - 正确写法：
time.Parse("2006-01-02 15:04", s)—— 年份是2006，小时是15（24 小时制），分钟是04 - 秒、毫秒、时区字段必须显式写出；缺一个字符，就 panic
- 如果输入带时区偏移（如
"+0800），layout 里也得有MST或-0700，否则解析失败
time.LoadLocation 失败：文件路径或时区名拼错，不是代码逻辑问题
time.LoadLocation("Asia/Shanghai") 返回 nil 且报错 unknown time zone Asia/Shanghai，通常是因为 Go 编译时没嵌入时区数据，或运行环境缺少 $GOROOT/lib/time/zoneinfo.zip。
- 静态编译（
CGO_ENABLED=0）默认不打包 zoneinfo，需加-tags timetzdata - Linux/macOS 下检查：
ls $GOROOT/lib/time/zoneinfo.zip；Windows 下看%GOROOT%\lib\time\zoneinfo.zip - 临时绕过：用
time.FixedZone("CST", 8*60*60)手动构造固定偏移时区（无夏令时） - 别信网上“改系统时区就能解决”的说法——Go 不读系统 /etc/localtime
time.In 转换后时间显示不变？你看到的是 Format 输出结果，不是内部值
执行 t.In(loc).Format("2006-01-02 15:04") 显示时间没变，不代表转换失败。Go 的 time.Time 内部始终以 UTC 存储，In 只改变其关联的 location，不修改秒数。
- 验证是否真转换成功：打印
t.In(loc).Hour()和t.UTC().Hour()对比 - 常见误操作：先
Format成字符串，再试图用Parse回去——这时已丢失原始 location 信息 - 跨时区比较应统一转成 UTC：
t1.UTC().Before(t2.UTC())，而非直接比t1.In(loc1)和t2.In(loc2) - 注意
time.Now().In(loc)每次调用都生成新对象，不改变原time.Time
time.ParseInLocation 解析本地时间却按 UTC 处理？location 参数位置错了
time.ParseInLocation 第三个参数是 *time.Location，不是时区字符串。传错会导致解析出的时间被当成 UTC 时间再转到目标时区，结果偏移 8 小时（或其它值）。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
time.ParseInLocation(layout, s, "Asia/Shanghai")—— 第三个参数类型不对，会静默转为time.UTC - 正确写法：
loc, _ := time.LoadLocation("Asia/Shanghai"); time.ParseInLocation(layout, s, loc) - 如果只是想把字符串当作本地时间（即本机
time.Local）解析，第三个参数必须是time.Local，不能省略或填字符串 - 生产环境慎用
time.Local：容器或跨机器部署时，time.Local行为不可控
时区转换真正的复杂点不在 API 调用，而在你是否清楚每一步的输入代表什么时间基准——字符串是哪个时区的？layout 是否覆盖了所有字段？location 是加载成功还是 fallback 到 UTC？这些细节一错，后面全错。
