Go时区转换依赖time包正确用法而非学习技巧：必须用IANA标准标识符（如"Asia/Shanghai"）加载时区，用.In()切换时区，用.ParseInLocation解析带偏移字符串，避免硬编码偏移或误用.Format()。
Go 语言本身不提供“语言学习技巧”来处理时区转换——这是个概念混淆。时区转换靠的是 time 包的正确用法，不是记忆口诀或类比学习。直接上手用对 API 才是关键。
为什么 time.LoadLocation 不能随便传字符串
很多人以为写 time.LoadLocation("GMT+8") 或 "CST" 就能加载东八区，结果 panic：unknown time zone GMT+8。Go 的时区数据库（IANA TZDB）不支持偏移量缩写或模糊名称，只认标准地域标识符，比如 "Asia/Shanghai" 或 "America/New_York"。
-
time.LoadLocation("UTC")可以，因为它是 IANA 官方保留名 -
time.LoadLocation("Asia/Chongqing")和"Asia/Shanghai"实际指向同一时区规则（但推荐用后者，更通用） - 别硬编码
+0800偏移量去“伪造”时区——它只是固定偏移，无法处理夏令时或历史规则变更
time.In() 不是格式化函数，是时区切换核心操作
常见错误：把 .Format() 当成时区转换，结果输出时间看起来对，但底层 time.Time 值仍是原时区，后续计算会出错。真正切换时区必须用 .In()，它返回一个新 time.Time，其内部纳秒时间戳不变，仅改变时区关联。
- 错误写法：
t.Format("2006-01-02 15:04:05 MST")—— 只改显示，没改时区语义 - 正确写法：
t.In(loc).Format("2006-01-02 15:04:05")，其中loc是time.LoadLocation("Europe/London")返回的值 - 注意：
.In()返回新值，原t不变；Go 的time.Time是不可变类型
解析带时区字符串时，time.ParseInLocation 比 time.Parse 更可靠
从日志、API 或用户输入拿到类似 "2024-05-20T13:45:00+09:00" 这种带偏移的字符串，用 time.Parse 会默认按本地时区解释，容易偏差。应优先用 time.ParseInLocation，并传入 time.UTC 或明确时区作基准。
立即学习“go语言免费学习笔记（深入）”；
- 安全做法：
time.ParseInLocation(time.RFC3339, s, time.UTC)—— 把字符串按 UTC 解析，再用.In()转目标时区 - 如果字符串自带偏移（如
+09:00），time.Parse其实也能提取，但它会把该偏移当作固定时区（无夏令时感知），慎用于跨年数据 - 避免用
time.Now().Local().String()生成时间字符串——它包含模糊缩写（如CST），其他程序很可能无法解析
真正的难点不在语法，而在理解：Go 的 time.Time 总是带时区语义的，哪怕它底层用 Unix 时间戳（UTC）。一次错误的 In() 或误用 Parse，会让时间在服务间传递时悄悄偏移一小时——尤其在夏令时切换前后，这种 bug 很难复现。
