Go 的时区数据主要来源于系统本地时区数据库（如 Linux 的 /usr/share/zoneinfo）、环境变量 ZONEINFO 指定路径，或内置的 $GOROOT/lib/time/zoneinfo.zip；不同操作系统和时区数据库版本可能导致历史时间解析差异（如 LMT 与 CET 并存），影响可移植性。
go 的时区数据主要来源于系统本地时区数据库（如 linux 的 `/usr/share/zoneinfo`）、环境变量 `zoneinfo` 指定路径，或内置的 `$goroot/lib/time/zoneinfo.zip`；不同操作系统和时区数据库版本可能导致历史时间解析差异（如 lmt 与 cet 并存），影响可移植性。
Go 语言在解析时区（如通过 time.LoadLocation("Europe/Berlin")）时，并不自带完整、静态的时区规则集，而是动态加载外部时区数据。其查找逻辑严格遵循 time.LoadLocation 函数的源码注释，按优先级顺序尝试以下位置：
- ZONEINFO 环境变量指定的目录或 ZIP 文件（最高优先级）；
-
Unix/Linux 系统的“已知安装路径”，例如：
- /usr/share/zoneinfo（主流发行版标准路径）
- /usr/lib/zoneinfo、/etc/zoneinfo（部分系统变体）
- Go 安装目录下的内置 ZIP 包：$GOROOT/lib/time/zoneinfo.zip（编译时嵌入，作为兜底 fallback）。
这意味着：
✅ 在标准 Linux 发行版上，Go 通常直接使用系统更新的 IANA 时区数据库（如 tzdata 包），支持精细的历史偏移（含夏令时、LMT 等）；
⚠️ 在 Windows 或容器等无标准 zoneinfo 路径的环境中，若未设置 ZONEINFO 且 GOROOT 中的 zoneinfo.zip 版本较旧或缺失，则 LoadLocation 可能退化为返回 UTC，或对 1900 年前后的日期解析为 LMT（Local Mean Time）——一种基于经度计算的本地平太阳时，而非现代法定时区。
例如，以下代码在不同环境可能输出不一致结果：
loc, _ := time.LoadLocation("Europe/Berlin")
t := time.Date(1900, 1, 1, 0, 0, 0, 0, loc)
fmt.Println(t) // 可能输出 "1900-01-01 00:53:28 +0053 LMT" 或 "1900-01-01 01:00:00 +0100 CET"
原因在于：IANA 时区数据库中，Europe/Berlin 的第一条正式时区规则始于 1893 年（德国统一采用中欧时间），但更早年份是否回溯应用 CET、还是保留 LMT，取决于具体数据库版本的实现策略——某些版本将首条规则“向前延伸”，另一些则严格保留 LMT 偏移。因此，1900 年这一边界值极易暴露差异。
确保跨平台行为一致的最佳实践：
- ✅ 显式分发统一 zoneinfo 数据：使用 go tool dist bundle 或手动构建定制 zoneinfo.zip，并设置 ZONEINFO=/path/to/zoneinfo.zip；
- ✅ 避免依赖系统路径：尤其在 Docker 镜像中，精简基础镜像（如 scratch 或 alpine）时，务必挂载或嵌入 zoneinfo；
- ✅ 谨慎处理历史时间：对 1970 年前（尤其是 1900–1920 年间）的时间运算，应明确预期偏移，必要时用 time.FixedZone 手动指定；
- ❌ 不依赖 time.Local 解析历史时区——它会绑定宿主机配置，完全不可控。
归根结底，Go 的时区机制是“务实派”：它不重复造轮子，而是桥接操作系统生态。理解其加载链路，是编写可重现、可部署时间敏感型服务（如金融结算、日志归档、合规审计）的前提。
