-duser.timezone=asia/shanghai必须紧接java命令后、-jar前生效；docker需安装tzdata并设tz；spring boot中localdatetime序列化时区错乱需配置jackson或改用zoneddatetime。
Java启动时加-Duser.timezone没生效？检查JVM参数加载顺序
很多同学加了-Duser.timezone=Asia/Shanghai却还是拿到UTC时间，根本原因是JVM参数被覆盖或加载太晚。Spring Boot的application.properties里配spring.jackson.time-zone只影响Jackson序列化，不改JVM全局时区。
-
-Duser.timezone必须放在java命令最前面，紧挨java之后，不能塞在-jar后面或-Xmx中间 - Docker里用
ENTRYPOINT ["java", "-Duser.timezone=Asia/Shanghai", "-jar", "app.jar"]，别写成ENV JAVA_OPTS="-Duser.timezone=..."——JAVA_OPTS不被默认读取 - Tomcat等容器若通过
setenv.sh设置，要确认该文件确实被catalina.shsourced，且参数格式为JAVA_OPTS="-Duser.timezone=Asia/Shanghai"
代码里调TimeZone.setDefault()为什么有时无效？
这个方法能改JVM全局时区，但仅对后续新建的SimpleDateFormat、Calendar等生效；已创建的实例（比如Spring单例Bean里缓存的DateFormat）不受影响，还会用旧时区解析。
- 避免在运行时调
TimeZone.setDefault()，尤其在多线程环境——它不是线程安全的，可能引发不可预测的时区漂移 - 如果必须动态切换，优先用
LocalDateTime/ZonedDateTime+ 显式传ZoneId，例如ZonedDateTime.now(ZoneId.of("Asia/Shanghai")) - 排查时打印
TimeZone.getDefault().getID()和new Date().toString()，看是否真变了——别只信配置文件
Spring Boot应用中LocalDateTime转JSON时区错乱？
LocalDateTime本身不含时区，但Jackson默认会按系统默认时区转成毫秒时间戳，前端再解析就容易偏8小时。这不是user.timezone能解决的，是序列化逻辑问题。
- 在
@Configuration类里注册Jackson2ObjectMapperBuilder，显式设.timeZone(TimeZone.getTimeZone("Asia/Shanghai")) - 更推荐方式：用
OffsetDateTime或ZonedDateTime替代LocalDateTime，让时区信息随数据一起流转 - 若用
@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")，记得加timezone = "GMT+8"，否则pattern只控制格式，不控制时区解释
Docker容器里Java进程始终是UTC？查/etc/timezone和tzdata包
即使JVM参数正确，容器底层没装对时区数据，Asia/Shanghai可能 fallback 成UTC。Alpine镜像尤其常见，因为默认精简掉了tzdata。
立即学习“Java免费学习笔记（深入）”；
- Alpine基础镜像需加
RUN apk add --no-cache tzdata，再ENV TZ=Asia/Shanghai - Debian/Ubuntu系镜像检查
/etc/timezone内容是否为Asia/Shanghai，并确认/usr/share/zoneinfo/Asia/Shanghai存在 - 启动容器时用
-v /etc/localtime:/etc/localtime:ro挂载宿主机时区文件，简单粗暴但有效
真正麻烦的是混合部署场景：K8s里不同节点宿主机时区不一致，又没统一配tzdata和JVM参数，这时候光改代码根本压不住时区抖动。得从CI/CD层把JVM参数和基础镜像版本钉死。
