Spring Boot 2.3+ 中 spring.jackson.time-zone 仅影响序列化且需配合 write-dates-as-timestamps=false，对 LocalDateTime 无效；真正起作用的是 JVM 默认时区、数据库连接层设置及字段类型选择。
Spring Boot 2.3+ 中 spring.jackson.time-zone 不再生效？
因为 Jackson 的时区配置在 Spring Boot 2.3 后被默认禁用，spring.jackson.time-zone 仅影响序列化，且需配合 spring.jackson.serialization.write-dates-as-timestamps=false 才能生效。更关键的是，它完全不控制 LocalDateTime 等无时区类型的行为——这些类型压根不携带时区信息，配置再全也没用。
- 真正起作用的是 JVM 默认时区（
TimeZone.getDefault()）和数据库连接层的时区设置 - 如果你用
LocalDateTime存时间，又希望按东八区显示，那它本身就不该用这个类型——该换ZonedDateTime或OffsetDateTime - 若坚持用
LocalDateTime，必须确保所有环节（JVM、MySQL 连接串、MyBatis/JPA 类型处理器）都统一按 +08:00 解释，否则前端看到的时间会漂移
MySQL 连接串里 serverTimezone=GMT%2B8 为什么有时没用？
常见错误是只加了 serverTimezone 却漏了 useTimezone=true。MySQL 驱动默认关闭时区转换，光告诉它“服务器在 GMT+8”没用，它仍按本地 JVM 时区解析 timestamp 字段。
- 完整写法：
jdbc:mysql://localhost:3306/db?serverTimezone=GMT%2B8&useTimezone=true -
GMT%2B8是 URL 编码，别手写成GMT+8（会解析失败） - 如果数据库字段是
DATETIME（无时区），驱动不会做任何转换；只有TIMESTAMP字段才会按serverTimezone转换为 JVM 本地时区 - Spring Boot 3.x 默认使用 MySQL 8.0+ 驱动，
serverTimezone必须显式指定，否则抛java.time.format.DateTimeParseException
spring.default-time-zone 到底管什么？
它只影响 Spring 自身的时间解析逻辑，比如 @DateTimeFormat 注解、ConversionService 里的日期转换器，以及部分 Starter（如 Spring Batch）内部的时间处理。它**不改变** Jackson、JDBC 驱动、Hibernate 或 JVM 的行为。
- 典型场景：前端传
2024-05-20给@RequestBody，Spring 用这个配置决定按哪个时区补全为00:00 - 值必须是 IANA 时区 ID（如
Asia/Shanghai），不能写GMT+8或CST（后者有歧义） - 如果同时设了
spring.jackson.time-zone和spring.default-time-zone，前者只管 JSON 序列化，后者只管字符串转对象——两者互不覆盖
JVM 启动参数 -Duser.timezone=Asia/Shanghai 是终极方案吗？
它是兜底手段，但副作用明显：整个 JVM 里所有依赖默认时区的代码（包括第三方库、日志框架、定时任务）都会被强制改写。一旦某个组件假设时区是 UTC，就可能出错。
- 优先级最高，会覆盖
spring.default-time-zone和所有未显式指定时区的操作 - Logback 的
%d{yyyy-MM-dd HH:mm:ss}格式会受它影响；Quartz 的 cron 触发也会按这个时区计算 - 容器环境（如 Docker）中容易被基础镜像覆盖，建议在 entrypoint 脚本里显式 export
TZ=Asia/Shanghai，比 JVM 参数更稳定 - 微服务里不推荐全局设，应逐模块明确时区策略——比如订单服务用
Asia/Shanghai，国际结算服务用UTC
最麻烦的从来不是配哪个参数，而是不同层级对“同一时间”的理解根本不一致：数据库存的是字面值，JDBC 驱动按自己的规则转，Jackson 又按另一套规则序列化，最后前端 JS 还要用 Date 对象再解析一遍。每个环节都得单独对齐，少一个就差一小时。
