Java应用在Docker里显示UTC时间，不是宿主机时区
根本原因不是Java没读到系统时区，而是基础镜像（比如 openjdk:17-jre-slim）默认用的是Etc/UTC，且不带/usr/share/zoneinfo完整时区数据。JVM启动时查不到Asia/Shanghai这类路径，就fallback到UTC。
实操建议：
- 构建镜像时用
apt-get install -y tzdata（Debian系）或apk add --no-cache tzdata（Alpine），再通过ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime软链生效 - 必须加
ENV TZ=Asia/Shanghai，否则java.time.ZoneId.systemDefault()仍可能返回UTC - Alpine用户注意：
tzdata包在Alpine 3.16+才默认包含完整时区，旧版要显式apk add tzdata并cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
Docker run时传TZ环境变量没用
因为JVM在启动瞬间就读取了系统时区，而TZ环境变量只影响glibc的localtime()等C函数，对Java的ZoneId.systemDefault()无直接作用——除非你同时配了-Duser.timezone=Asia/Shanghai。
常见错误现象：容器里date命令显示正确，但new Date().toString()还是UTC时间。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 启动Java进程时强制指定JVM参数：
-Duser.timezone=Asia/Shanghai - 不要只依赖
docker run -e TZ=Asia/Shanghai，它对Java时区基本无效 - 如果用Spring Boot，可在
application.properties里写spring.jackson.time-zone=GMT+8，但这只管Jackson序列化，不影响LocalDateTime.now()等原生API
Dockerfile里ENV TZ=...和RUN ln -sf ...顺序不能反
时区软链必须在ENV TZ之前建立，否则JVM初始化阶段读不到有效时区文件，后续再改TZ环境变量也来不及——JVM只在启动时加载一次系统时区。
使用场景：多阶段构建中，如果把ln -sf放在FROM openjdk:17-jre-slim之后、COPY应用jar之前，是安全的；但如果放在ENTRYPOINT脚本里，就晚了。
实操建议：
-
RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime放在ENV TZ=Asia/Shanghai前面 - 避免在
ENTRYPOINT或CMD里动态改时区，JVM已启动完毕 - 验证方式：进容器执行
java -XshowSettings:properties -version 2>&1 | grep user.timezone，确认输出是user.timezone = Asia/Shanghai
Alpine镜像里ZoneId.of("Asia/Shanghai")抛ZoneRulesException
Alpine默认精简，/usr/share/zoneinfo/下只有UTC和GMT两个文件，Asia/Shanghai根本不存在，所以ZoneId.of("Asia/Shanghai")会直接失败，不是返回UTC。
性能影响：没有完整zoneinfo，所有带时区的Instant转换都会出错，连ZonedDateTime.now()都跑不起来。
实操建议：
- 必须安装
tzdata：RUN apk add --no-cache tzdata - 别信“Alpine自带时区”这种说法，它只带最简集
- 如果用
FROM openjdk:17-jre-alpine，记得检查基础镜像版本，3.14以下的tzdata包可能不含中国时区（需手动cp）
