容器时区不一致主因是镜像默认utc而业务需asia/shanghai，解决需在dockerfile固化时区、应用层统一设时区参数并避免挂载宿主机时区等不可靠做法。
容器内部时区不一致，最常见原因是镜像默认使用 utc，而宿主机或业务系统用的是东八区（asia/shanghai），导致日志、定时任务、报表生成时间偏移 8 小时。解决核心是让容器内系统时间和业务逻辑感知的时区统一为 asia/shanghai，且不依赖宿主机环境。
确认容器当前时区和时间
进入容器后执行：
date && cat /etc/timezone && ls -l /etc/localtime
若输出显示 UTC 或时间比北京时间慢 8 小时，说明时区未正确设置。注意：/etc/localtime 是软链接，指向应为 /usr/share/zoneinfo/Asia/Shanghai，而非仅拷贝文件或写死时间字符串。
构建镜像时固化时区（推荐）
在 Dockerfile 中显式设置时区，避免每次运行都依赖启动参数或挂载：
- Debian/Ubuntu 系：添加
RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && echo "Asia/Shanghai" > /etc/timezone - Alpine 系：安装 tzdata 包，再执行
RUN apk add --no-cache tzdata && cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime - Java 应用额外加 JVM 参数：
-Duser.timezone=GMT+8或-Duser.timezone=Asia/Shanghai，防止 SimpleDateFormat 等组件仍按 UTC 解析
应用层统一处理时间逻辑
单纯改系统时区不能完全规避问题，尤其涉及数据库写入、调度器触发、报表时间范围计算等场景：
- 数据库连接配置中显式指定时区，如 MySQL JDBC URL 加
&serverTimezone=Asia/Shanghai - Python 脚本中避免用
datetime.now()，改用datetime.now(timezone('Asia/Shanghai'))；或全局设置os.environ['TZ'] = 'Asia/Shanghai'后调用time.tzset() - 定时任务（如 cron 或 Airflow DAG）需确认其调度器自身时区配置，例如 Airflow 的
default_timezone必须设为Asia/Shanghai
避免常见误区
有些做法看似有效，实则不可靠或埋下隐患：
- 仅通过
-v /etc/localtime:/etc/localtime:ro挂载宿主机时区 —— 容器跨地域部署时失效，且违反镜像不可变原则 - 在 entrypoint 脚本里动态修改时区但未刷新进程环境（如未重设 TZ 环境变量），Java/Node.js 等运行时可能读不到新时区
- 报表服务用“本地时间”渲染但数据库存的是 UTC 时间，又没做转换，导致前端显示与实际生成时间不符
