time.in() 不改变时间戳，仅切换时区解释方式；必须用 iana 时区名（如"asia/shanghai"）加载位置，解析字符串需用 parseinlocation 显式指定源时区，dst 等规则由 iana 数据自动处理。
time.In() 不是改时间，是换一种方式“读”同一个时间点——只要 time.LoadLocation 成功，后续所有格式化、取小时、计算日期都自动按目标时区解释。
time.LoadLocation 返回 nil 的真实原因
-
time.LoadLocation只认 IANA 时区名（如"Asia/Shanghai"、"America/New_York"），不支持：- 缩写：如
"CST"、"PST"、"GMT+8" - 偏移字符串：如
"+08:00"、"UTC+8"
- 缩写：如
-
"UTC"和"Local"是内置名，可直接用；但"Local"表示运行机器的本地时区，不可跨环境复现 - Linux/macOS 查可用时区：
timedatectl list-timezones | grep Shanghai
Windows 需手动映射，例如"Asia/Shanghai"对应中国标准时间（无夏令时）
time.In() 转换后，哪些值变了？哪些没变？
- ✅ 变了的：
-
.Format("15:04")输出的是目标时区时间（如"09:00"） -
.Hour()、.Date()、.Year()等方法返回目标时区对应值
-
- ❌ 没变的：
-
.Unix()、.UnixMilli()、.Equal()、.Before()、.Add()结果完全一致
（因为底层时间戳没动，只是换了*time.Location）
-
- ⚠️ 典型陷阱：用
userTime.Hour() == 9判断“是否早上九点发消息”，却忘了这个 9 是用户时区下的小时——如果用户时区加载失败（loc == nil），userTime.In(nil)会 panic；若误用time.Local且部署机时区不是预期值，逻辑就全偏了
解析字符串时，必须显式指定源时区
-
time.Parse("2006-01-02 15:04", "2024-05-23 10:00")默认按本地时区解析，极易出错 - 正确做法是用
time.ParseInLocation显式绑定源时区：- 若原始字符串是 UTC 时间：
time.ParseInLocation("2006-01-02 15:04", s, time.UTC) - 若原始字符串是北京时间（无夏令时）：
time.ParseInLocation("2006-01-02 15:04", s, time.Must(time.LoadLocation("Asia/Shanghai")))
- 若原始字符串是 UTC 时间：
- 错误示范：
time.Parse(...).In(loc)—— 先按 Local 解析再转，结果依赖部署机时区，不可靠
夏令时（DST）不是“额外功能”，而是 IANA 时区数据的自然行为
- 只要用对 IANA 名（如
"Europe/Berlin"、"America/Los_Angeles"），.In()、.Add()、.Sub()全部自动适配 DST 切换 - 示例：德国 2024 年 3 月 31 日 02:00 开始夏令时，
t.Add(60 * time.Minute)会跳过 02:00–03:00，得到 03:30，而非 02:30 -
time.FixedZone("CST", 8*3600)创建的是固定偏移，不支持 DST，仅适合纯 UTC±N 场景（如日志归档、简单偏移展示）
真正容易被忽略的点是：时区转换不是“把时间加减几小时”，而是切换一套完整的历法规则——包括 DST 规则、历史偏移变更、甚至政府公告调整。Go 把这套规则编译进了标准库，但前提是，你得用对名字。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
