time.LoadLocation 返回 nil 主因是时区名拼写错误或系统缺失 zoneinfo 数据；Go 依赖操作系统时区数据库，如 Linux 的 /usr/share/zoneinfo；应检查 error、验证路径、容器中安装 tzdata，并优先用 LoadLocation 而非 FixedZone 处理真实地理时区。
time.LoadLocation 返回 nil 的常见原因
调用 time.LoadLocation 后得到 nil，几乎一定是时区名拼写错误或系统未安装对应时区数据。Go 本身不自带时区数据库，而是依赖操作系统提供的 /usr/share/zoneinfo（Linux/macOS）或注册表（Windows）。比如写成 "Asia/Shanghai" 是对的，但 "Asia/ShangHai"、"China/Beijing" 或 "GMT+8" 都会返回 nil。
实操建议：
- 始终检查返回 error：
loc, err := time.LoadLocation("Asia/Shanghai"); if err != nil { log.Fatal(err) } - 用
time.ZoneNames()查看当前环境支持的时区名（注意：它只返回已加载过的 zone 名，不能用来“探测”可用名） - Linux/macOS 下可手动验证：运行
ls /usr/share/zoneinfo/Asia/ | grep -i shang，确认Shanghai存在 - 容器环境（如 Alpine）默认不含 zoneinfo，需显式安装：Dockerfile 中加
RUN apk add --no-cache tzdata
time.LoadLocation 和 time.FixedZone 的关键区别
time.LoadLocation 加载的是带完整夏令时规则的地理时区，而 time.FixedZone 只是固定偏移（如 UTC+8），不处理 DST 切换。例如美国东部时间（"America/New_York"）在 3 月第二个周日会从 EST（UTC-5）切到 EDT（UTC-4），FixedZone 完全无法模拟这个行为。
实操建议：
- 只要涉及真实地理区域（如用户所在地、业务部署地），必须用
LoadLocation，别图省事用FixedZone -
FixedZone仅适用于明确不需要 DST 的场景，比如解析日志中带固定偏移的时间字符串："2024-04-01T12:00:00+08:00" - 注意：即使传入
"UTC"，也应走LoadLocation("UTC")而非FixedZone("UTC", 0)，前者更标准且与time.UTC兼容
跨时区时间转换的正确姿势
很多人误以为要先将时间转成 UTC 再转目标时区，其实完全没必要——time.Time 内部始终以 UTC 纳秒存储，所有时区转换都是 View 层操作。直接用 .In(loc) 即可，性能无损耗。
实操建议：
- 避免冗余转换：不要写
t.UTC().In(loc)，直接t.In(loc) - 注意原始时间的时区含义：如果 t 来自
time.Now()，它已是本地时区；如果来自Parse且未指定时区，默认是time.Local，不是 UTC - 解析带时区的时间字符串时，优先用
time.RFC3339等内置 layout，它们能自动识别并保留偏移；若用自定义 layout，末尾务必加上Z或MST占位符，并确保传入正确的*time.Location - 示例：解析
"2024-04-01 10:30:00 CST"前，先确认CST是指中国标准时间（LoadLocation("Asia/Shanghai")）还是美国中部时间（"America/Chicago"）——缩写歧义大，生产环境应避免依赖
测试多时区逻辑时的陷阱
本地开发机时区（time.Local）会影响测试结果，尤其是当代码隐式依赖 time.Now() 或未显式指定 location 的 Parse 时。CI 环境（如 GitHub Actions）默认是 UTC，和你本地可能不一致。
实操建议：
- 测试中永远显式传入 location：不要依赖
time.Local，哪怕只是临时loc, _ := time.LoadLocation("Asia/Shanghai") - 用
time.Now().In(loc)替代time.Now()做断言，确保时间基准可控 - 避免在测试里修改系统时区（如
TZ=Asia/Shanghai go test），这不可靠且难以调试 - 对夏令时切换点附近的逻辑（如 3 月 10 日、11 月 3 日），单独写边界测试，用已知的 past/future 时间点验证是否正确应用了 DST 规则
真正麻烦的从来不是加载时区，而是假设“某个缩写=某个偏移”或忽略夏令时规则变化——这些细节在生产环境出问题时，往往表现为凌晨两点的日志时间错乱或定时任务提前/延后一小时。
