最可靠方式是挂载宿主机的 /etc/localtime 和 /etc/timezone 文件（只读），因仅设 TZ 环境变量常失效：Alpine/Debian minimal 镜像默认缺失 tzdata，TZ 仅影响部分函数，而 date、ls -l 等依赖 /etc/localtime；若该文件指向 UTC，时间仍显示为 UTC；且 TZ 非系统级权威源，与 /etc/localtime 冲突会导致多运行时行为不一致。
直接挂载宿主机的 /etc/localtime 和 /etc/timezone 文件，是最可靠、零配置开销的方式。 其他方法（如仅设 TZ 环境变量）在部分镜像或运行时中可能被忽略，无法保证系统级时间显示一致。
为什么只设 TZ 环境变量经常失效
很多基础镜像（尤其是 Alpine、Debian minimal）默认不安装 tzdata 包，TZ=Asia/Shanghai 仅影响部分 C 库函数（如 strftime()），但 date、ls -l、journalctl 等命令仍依赖 /etc/localtime 文件。若该文件指向 /usr/share/zoneinfo/Etc/UTC，时间输出仍是 UTC。
-
TZ是用户态提示，不是内核或 glibc 的权威时区源 - Java、.NET、Node.js 等运行时可能同时读取
TZ和/etc/localtime，二者冲突会导致行为不一致 - Alpine 镜像中未安装
tzdata时，TZ值甚至无法被解析，date直接 fallback 到 UTC
必须挂载 /etc/localtime 和 /etc/timezone
这两个文件共同构成 Linux 系统级时区事实来源：/etc/localtime 是二进制时区数据（软链或拷贝），/etc/timezone 是纯文本标识（如 Asia/Shanghai），某些工具（如 dpkg-reconfigure tzdata）会读它。
- 挂载必须加
:ro（只读），避免容器意外覆盖宿主机配置 - 宿主机本身必须已正确配置时区（
timedatectl set-timezone Asia/Shanghai），否则挂载的是错误值 - 若宿主机用的是
systemd-timesyncd或chrony，时间同步也一并继承，无需容器内重复部署 NTP
示例命令：
docker run -d \ -v /etc/localtime:/etc/localtime:ro \ -v /etc/timezone:/etc/timezone:ro \ --name myapp \ myapp-image
Alpine 镜像要额外装 tzdata 才能支持挂载
Alpine 默认不带完整 /usr/share/zoneinfo/，即使挂载了宿主机 /etc/localtime，glibc/musl 也可能因缺少时区数据库而 fallback 到 UTC。必须在构建阶段显式安装：
FROM alpine:latest RUN apk add --no-cache tzdata \ && cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \ && echo "Asia/Shanghai" > /etc/timezone
- 仅靠
apk add tzdata不够——它只安装数据，不自动设置链接 - 若你坚持运行时挂载（而非构建时固化），则必须确保宿主机的
/etc/localtime是真实文件（非空链接），否则 Alpine 容器读不到有效时区数据 - 验证方式：进容器执行
ls -l /etc/localtime，应看到指向/usr/share/zoneinfo/...的有效软链
别信“自动继承”——容器从不自动同步宿主机时区
容器启动时不会扫描宿主机时区并自动配置；命名空间隔离决定了它看到的 /etc/localtime 就是镜像自带的那份（通常是 UTC）。所谓“继承”，必须靠显式挂载或构建时复制来实现。
- 哪怕宿主机
timedatectl status显示Time zone: Asia/Shanghai (CST, +0800)，容器内date依然可能是 UTC - Kubernetes 中用
hostPath挂载时，路径必须写成/etc/localtime（不能用..data符号链接，否则挂载失败） - Docker Desktop for Mac/Windows 用户注意：其 Linux VM 的时区可能和 macOS/Windows 主机不一致，需先确认 VM 的
/etc/localtime
