go程序默认使用系统时区而非utc，容器或ci中因缺失tzdata或未挂载/etc/localtime导致time.now()返回utc；应安装tzdata、挂载宿主机时区文件或显式用time.loadlocation("asia/shanghai")并全局复用，避免依赖time.local和tz环境变量。
Go 程序默认用的是系统时区，但 time.Now() 在容器或 CI 中可能不准
Go 的 time.Now() 默认读取宿主机的时区配置（通过 /etc/localtime 或 TZ 环境变量），不是硬编码 UTC。这意味着：本地开发机时间正常，一上 Docker 就变成 UTC；CI 流水线里跑测试发现时间戳全偏了 8 小时——不是代码写错了，是环境没对齐。
常见错误现象：time.Now().Format("2006-01-02 15:04:05") 输出 UTC 时间，但你预期是 CST；日志时间戳和数据库记录对不上；定时任务在凌晨 3 点触发，实际想让它在业务时间 9 点执行。
- 确认当前生效时区：运行
go run -e 'package main; import ("fmt"; "time"); func main() { fmt.Println(time.Local) }'，输出类似Local或UTC，但不告诉你具体偏移 - 更可靠的方式是查
time.Now().Location().String()，它会返回Asia/Shanghai或Local这类标识 - 容器中默认没装 tzdata 包，
/usr/share/zoneinfo/Asia/Shanghai文件不存在 →time.LoadLocation("Asia/Shanghai")会 panic
TZ 环境变量只影响 C 时区函数，Go 不认它
很多开发者习惯在 Dockerfile 里加 ENV TZ=Asia/Shanghai，以为能“全局生效”。但 Go 的 time 包完全忽略 TZ，它只依赖两个东西：系统符号链接 /etc/localtime 指向的 zoneinfo 文件，或显式调用 time.LoadLocation()。
所以 TZ 对 Go 程序是无效的装饰，除非你混用了 CGO 调用的 C 库函数（比如某些日志库底层用 strftime）。
PHP商城系统是国内领先商城系统,网店系统,购物系统,网上商城系统,B2C商城系统产品.同时也是一个商业的PHP开发框架。PHP 商城系统由内容、文章、会员、留言、订单、 财务、广告、短消息、数据库管理、营销推广、内置支付管理、商品配送管理、无限级分类、全站搜索等多个功能模块插件组成。在当今瞬机万变的市场环境中，快速高效的IT解决方案是您业务成功的关键。我们PHP商城系统能为您量身打造完全符合需求
立即学习“go语言免费学习笔记（深入）”；
- Docker 构建时，用
apt-get install -y tzdata（Debian/Ubuntu）或apk add --no-cache tzdata（Alpine）安装时区数据 - 启动容器时，挂载宿主机时区文件：
-v /etc/localtime:/etc/localtime:ro，比设TZ更直接有效 - 如果必须用
time.LoadLocation("Asia/Shanghai")，请确保该路径下有对应文件：/usr/share/zoneinfo/Asia/Shanghai，否则 panic 信息是unknown time zone Asia/Shanghai
显式指定时区比依赖 time.Local 更可控
time.Local 看似方便，但它把“当前环境时区”这个不确定因素带进了业务逻辑。比如一个服务既要处理用户本地时间（按城市），又要生成报表用北京时间，混用 time.Local 会让逻辑耦合、难以测试。
推荐做法：所有需要明确时区的场景，都用 time.LoadLocation() 加载并复用 *time.Location 实例，而不是每次调用 time.Now().In(loc) 都重新解析。
- 初始化一次，全局复用：
shanghai, _ := time.LoadLocation("Asia/Shanghai")，放在init()或包级变量里 - 避免在循环或高频路径里反复调用
time.LoadLocation()—— 它会读文件、解析，有开销 - 测试时可注入
*time.Location，比如用time.UTC替换，让单元测试不依赖环境 - 注意：
time.LoadLocation("CST")是错的，CST 是模糊缩写（可能是 China Standard Time，也可能是 Central Standard Time），必须用完整 IANA 名称，如Asia/Shanghai
JSON 序列化时 time.Time 默认转成 RFC3339，但时区信息可能丢失
用 json.Marshal() 序列化 time.Time 时，Go 默认输出类似 "2024-05-20T14:23:11+08:00" 的字符串，看起来带时区。但问题在于：如果原始 time.Time 是用 time.Now().In(shanghai) 构造的，序列化后是带 +08:00 的；但如果它是 time.Now()（即 Local），而宿主机时区是 UTC，那输出就是 +00:00 —— 同一份代码，在不同机器上 JSON 输出格式不一致。
- 若需强制统一输出为北京时间，不要依赖
time.Local，而是显式转换：t.In(shanghai).Format(time.RFC3339) - 自定义 JSON marshal：给结构体字段加上
json:"xxx,omitempty,time_rfc3339"标签不起作用，Go 不支持时区定制；得实现MarshalJSON()方法 - API 返回时间字段前，建议统一转成 ISO8601 字符串并带上
Z或偏移，别让前端猜时区
zoneinfo，而 time.LoadLocation 的错误提示又很安静——它只返回 nil 和 error，不 panic，容易被忽略。 
