docker容器默认utc时区，需按场景选择配置方式：构建镜像时固化（debian/alpine适配）、运行时动态注入tz环境变量（限支持镜像）、挂载宿主机时区文件（强一致性要求），并规避常见陷阱。
Docker 容器默认使用 UTC 时区，而业务系统往往依赖本地时间（如 Asia/Shanghai）进行日志记录、定时任务、用户展示等。配置不当会导致时间偏差、任务错乱、排查困难等问题。关键不是“选一种方法”，而是根据部署阶段、镜像可控性、环境一致性来匹配合适的方式。
构建镜像时固化时区（适合标准化交付）
如果能修改 Dockerfile，这是最稳定的做法。它让时区成为镜像的一部分，不依赖宿主机或运行时参数。
- 对 Debian/Ubuntu 系统：
ENV TZ=Asia/Shanghai RUN ln -sf /usr/share/zoneinfo/${TZ} /etc/localtime && \ echo ${TZ} > /etc/timezone && \ dpkg-reconfigure -f noninteractive tzdata - 对 Alpine 系统（精简版）：
ENV TZ=Asia/Shanghai RUN apk add --no-cache tzdata && \ cp /usr/share/zoneinfo/${TZ} /etc/localtime && \ echo ${TZ} > /etc/timezone && \ apk del tzdata这样构建出的镜像，无论在哪台机器上运行，
date、cron、Java/Python 的time.now()都会按上海时区输出。
启动容器时动态注入（适合快速验证或不可改镜像场景）
当使用第三方镜像（如 jupyter/base-notebook）且无法修改源 Dockerfile 时，用 -e TZ=Asia/Shanghai 最直接：
docker run -d -e TZ=Asia/Shanghai --name app nginx:alpine
⚠️ 注意：该方式仅对支持 TZ 解析的基础镜像有效（glibc 系统如 Debian/Ubuntu 通常支持；musl 系统如 Alpine 需已安装 tzdata）。若发现 date 仍显示 UTC，说明镜像未加载时区数据，此时需配合挂载或换用其他方法。
挂载宿主机时区文件（适合生产环境强一致性要求）
对日志采集、监控告警、金融类定时作业等场景，建议同时挂载两个文件，确保系统级时间完全同步：
docker run -d \ -v /etc/localtime:/etc/localtime:ro \ -v /etc/timezone:/etc/timezone:ro \ -e TZ=Asia/Shanghai \ --name app nginx:alpine
其中：
-
/etc/localtime是符号链接或二进制时区数据，决定localtime()等 C 函数行为； -
/etc/timezone是纯文本文件（Debian/Ubuntu 特有），供tzdata工具识别； -
:ro表示只读，防止容器内进程意外覆盖宿主机配置。
补充：避免常见陷阱
- 不要只设
TZ环境变量却不挂载或不生成时区文件——部分应用（如旧版 Java 应用、某些 Go 二进制）可能忽略TZ，只认/etc/localtime； - 不要在容器内用
docker exec临时改时区——重启后失效，且无法保证所有进程（尤其是 PID 1）生效； - 若用
docker-compose.yml，统一在environment和volumes中声明，便于团队复用：services: app: image: myapp:latest environment: - TZ=Asia/Shanghai volumes: - /etc/localtime:/etc/localtime:ro - /etc/timezone:/etc/timezone:ro
本质上，时区不是“设置一次就完事”的配置，而是需要和你的构建流程、部署规范、基础镜像选型协同考虑的一致性保障机制。
