最稳妥方案是同时挂载宿主机的 /etc/localtime 和 /etc/timezone。Java 应用时间不准常因读取错误时区配置所致，仅挂载前者不够；OpenJDK 优先读取 /etc/timezone，若其为 Etc/UTC 或缺失，即使 localtime 正确仍按 UTC 解析。需确保宿主机已设正确时区（timedatectl status 验证），容器启动时双挂载并验证 date 与 cat /etc/timezone 结果一致；Java 层建议补充 -Duser.timezone=Asia/Shanghai；Alpine 镜像需额外安装 tzdata，busybox 类镜像则仅挂 localtime 并保证宿主机 /etc/timezone 有效。
直接挂载宿主机的 /etc/localtime 和 /etc/timezone 是最稳妥、无需修改镜像、也不依赖容器内权限的方案。Java 应用时间不准，往往不是“容器没校时”，而是它读取了错误的时区配置——尤其当容器默认用 UTC，而 Java 从 /etc/timezone 解析时区时，差 8 小时就很容易出现。
必须同时挂载两个文件
只挂 /etc/localtime 不够。很多 Java 运行时（尤其是 OpenJDK）会优先读取 /etc/timezone 来确定默认时区；若该文件不存在或内容为 Etc/UTC，即使 /etc/localtime 指向上海时区，Java 仍可能按 UTC 解析时间。
-
宿主机需已正确设置本地时区：执行
timedatectl status确认 `Time zone` 显示如Asia/Shanghai (CST, +0800) -
启动容器时加两条挂载：
docker run -v /etc/localtime:/etc/localtime:ro -v /etc/timezone:/etc/timezone:ro your-java-app -
Docker Compose 写法：
services: app: image: your-java-app volumes: - "/etc/localtime:/etc/localtime:ro" - "/etc/timezone:/etc/timezone:ro"
验证是否生效
进入容器后运行两行命令，结果必须与宿主机完全一致：
-
date—— 输出当前时间（含时区缩写，如 CST） -
cat /etc/timezone—— 输出应为Asia/Shanghai（不是Etc/UTC或空）
若任一不匹配，说明挂载未成功或宿主机自身时区未设好。
立即学习“Java免费学习笔记（深入）”；
Java 层面额外加固（可选但推荐）
挂载解决系统级时区，但某些 Java 场景（如 Spring Boot 启动、Logback 时间戳、JDBC 时间处理）仍可能因 JVM 缓存或初始化顺序导致短暂偏差。建议补充 JVM 参数：
- 启动时添加：
-e JAVA_OPTS="-Duser.timezone=Asia/Shanghai" - 或在
docker run中直接传：-e "JAVA_TOOL_OPTIONS=-Duser.timezone=Asia/Shanghai" - 注意：避免同时用
-Duser.timezone=GMT+08，它不支持夏令时，且与Asia/Shanghai行为不完全等价
特殊镜像注意事项
Alpine 或极简镜像（如 openjdk:alpine）默认不含 tzdata，仅挂载 /etc/localtime 可能失效：
- 构建镜像时补装：
RUN apk add --no-cache tzdata - 或改用完整基础镜像（如
openjdk:17-jdk-slim），它自带时区数据 - busybox 类镜像无法挂
/etc/timezone（路径不存在），此时只挂/etc/localtime:ro并确保宿主机该文件有效即可
