time.LoadLocation 返回 nil 时 panic 是因忽略 error 后对 nil *time.Location 调用 In() 导致空指针解引用；必须检查 err，正确使用 IANA 标准时区名如 "Asia/Shanghai"。
time.LoadLocation 返回 nil 时为什么 panic？
因为 time.LoadLocation 在找不到指定时区名时返回 (nil, error)，但很多人直接忽略 error，直接用返回的 *time.Location 做 time.In()，结果触发 nil pointer dereference。
- 必须检查 error：如果
err != nil，说明时区名拼写错误、系统未安装该时区数据，或传入了空字符串 - 常见错误时区名：
"GMT+8"、"CST"、"UTC+8"—— 这些都不是 IANA 时区数据库标准名，LoadLocation不认 - 正确写法只接受形如
"Asia/Shanghai"、"America/New_York"、"UTC"的字符串
Linux/macOS 上时区数据路径影响 LoadLocation 行为
time.LoadLocation 依赖操作系统提供的 tzdata。Go 运行时会按顺序查找：/usr/share/zoneinfo → /etc/zoneinfo → $GOROOT/lib/time/zoneinfo.zip（仅当编译时嵌入）。
- Docker 容器里常缺失
/usr/share/zoneinfo，导致LoadLocation("Asia/Shanghai")失败 —— 解决方案是构建镜像时显式安装 tzdata（如apt-get install -y tzdata） - Windows 不依赖外部文件，自带时区映射表，但只支持有限别名（如
"China Standard Time"），且不保证和 IANA 名一致；跨平台代码应坚持用 IANA 名 - 若需完全脱离系统依赖，可用
go:embed+time.LoadLocationFromBytes()加载预打包的 zoneinfo 数据
time.In() 转换后的时间值是否“真的”变了？
没有。调用 t.In(loc) 只是返回一个新 time.Time，其内部 Unix 时间戳（纳秒数）完全不变，变的只是显示时区偏移和字符串格式化行为。
-
t.In(loc).Unix()和t.Unix()结果恒等 - 打印时：
t.In(loc).Format("2006-01-02 15:04:05")显示的是 loc 对应本地时间，不是“转换出新时刻” - 误用场景：想把“北京时间 10:00”转成“纽约时间”，不能只调
.In(time.LoadLocation("America/New_York"))—— 必须先确保原始t是以Asia/Shanghai解析出来的（否则 Go 默认按 Local 或 UTC 解析，语义错乱）
如何安全地解析带时区字符串并转目标时区？
关键在两步：先用 time.ParseInLocation 显式绑定源时区，再用 .In() 转目标时区。跳过第一步，就等于默认用 time.Local 或 time.UTC 解析，极易出错。
立即学习“go语言免费学习笔记（深入）”；
- 错误示范：
time.Parse("2006-01-02 15:04:05", "2023-01-01 12:00:00")—— 无法识别字符串里的时区信息，也不知它本意是东八区还是西五区 - 正确做法：
loc, _ := time.LoadLocation("Asia/Shanghai"); t, _ := time.ParseInLocation("2006-01-02 15:04:05", "2023-01-01 12:00:00", loc)，再t.In(time.UTC) - 注意：
ParseInLocation的第三个参数是源时区，不是目标时区 —— 很多人在这里搞反
ParseInLocation 或错配 LoadLocation 参数，后面所有 In() 都是在错误基础上叠加。 
