Go 的时区数据主要来源于系统预装的 IANA 时区数据库（如 /usr/share/zoneinfo），其次 fallback 到 $GOROOT/lib/time/zoneinfo.zip；在 Windows 等无标准时区路径的系统上，若未显式配置 ZONEINFO 环境变量，可能退化为 UTC 或本地均值时间（LMT），导致跨平台时间解析不一致。
go 的时区数据主要来源于系统预装的 iana 时区数据库（如 `/usr/share/zoneinfo`），其次 fallback 到 `$goroot/lib/time/zoneinfo.zip`；在 windows 等无标准时区路径的系统上，若未显式配置 `zoneinfo` 环境变量，可能退化为 utc 或本地均值时间（lmt），导致跨平台时间解析不一致。
Go 语言通过 time.LoadLocation(name string) 加载时区信息，其查找逻辑具有明确的优先级顺序。根据 Go 标准库源码（src/time/zoneinfo.go）中的注释，该函数按以下路径依次尝试加载时区数据：
- 环境变量 ZONEINFO 指定的目录或 ZIP 文件（最高优先级）；
- Unix/Linux 系统的已知安装路径，如 /usr/share/zoneinfo、/usr/lib/zoneinfo 等；
- $GOROOT/lib/time/zoneinfo.zip（编译时嵌入的默认时区包，适用于无系统时区文件的环境，如部分容器或 Windows）。
这意味着：在主流 Linux 发行版中，Go 通常直接使用系统维护的 IANA 时区数据库（由 tzdata 包提供），其内容权威、更新及时；而在 Windows 或精简容器环境中，若未设置 ZONEINFO，Go 将回退至 zoneinfo.zip —— 该 ZIP 文件随 Go 版本发布，版本固定，且不包含历史 LMT（Local Mean Time）规则的完整实现。
你观察到的 1900-01-01 00:53:28 +0053 LMT 与 1900-01-01 01:00:00 +0100 CET 差异，本质源于不同数据源对“1900 年前欧洲中部地区时间规则”的建模分歧：
- LMT（本地平太阳时） 是工业时代前普遍采用的基于经度的地方时间（例如柏林经度 13.4°E → LMT = UTC+00:53:28）。IANA 数据库中，许多时区（如 Europe/Berlin）在 1893 年之前定义了 LMT 规则；
- 不同系统上的 zoneinfo 数据可能来自不同版本的 IANA 数据库（如 tzdata2020a vs tzdata2023c），而各版本对“首个标准化时区生效时间”的处理策略存在差异：有的将首条 STANDARD 规则向前延伸覆盖 LMT 时段，有的则严格保留 LMT 记录。
可通过如下代码验证行为差异：
package main
import (
"fmt"
"time"
)
func main() {
loc, _ := time.LoadLocation("Europe/Berlin")
t1900 := time.Date(1900, 1, 1, 0, 0, 0, 0, loc)
t1905 := time.Date(1905, 1, 1, 0, 0, 0, 0, loc)
fmt.Println("1900-01-01 in Berlin:", t1900) // 可能输出 LMT 或 CET
fmt.Println("1905-01-01 in Berlin:", t1905) // 通常稳定输出 CET（因 1893 年后已启用 CET）
}
⚠️ 注意事项：
- 避免依赖 1900 年前的时间解析：LMT 属于历史兼容性设计，非现代应用所需，应主动规避；
- 强制统一时区源：在 CI/CD 或多平台部署中，推荐构建自定义 zoneinfo.zip（使用 go tool dist bundle 或 tzdata 工具生成），并通过 ZONEINFO=/path/to/zoneinfo.zip 环境变量锁定数据源；
- 生产环境建议：始终使用 UTC 存储和传输时间，仅在展示层按需转换为本地时区，从根本上规避历史时区歧义。
总之，Go 的时区行为是“系统感知型”的——它尊重底层基础设施的时区权威性，而非强行抽象。理解这一设计哲学，是编写可移植、可预测时间逻辑的关键。
