TimeZone.getDefault() 返回的是 JVM 启动时缓存的默认时区，并非实时系统时区；系统修改后需调用 TimeZone.setDefault(null) 刷新，否则仍返回旧值。
TimeZone.getDefault() 返回的真的是系统时区吗？
不一定。它返回的是 JVM 启动时缓存的默认时区，不是实时读取操作系统设置。如果系统时区在 JVM 运行中被修改（比如 Linux 上改了 /etc/localtime），TimeZone.getDefault() 仍会返回旧值，除非显式调用 TimeZone.setDefault(null) 强制刷新。
- 首次调用
TimeZone.getDefault()会从系统属性user.timezone读取；未设置则尝试解析java.home下的时区配置或调用底层getSystemTimeZoneId() - 后续调用直接返回缓存对象，不重新探测——这是多数“改了系统时区但 Java 没反应”的根源
- 若需动态响应系统变更，应避免依赖
getDefault()，改用TimeZone.getTimeZone("Asia/Shanghai")显式指定 ID
使用 TimeZone.getTimeZone(String) 时 ID 写错会怎样？
不会抛异常，而是静默返回 GMT（即 UTC+0）时区对象，且 getID() 仍返回你传入的错误字符串。这是最隐蔽的坑之一。
- 常见错误 ID：
"CST"（歧义：美国中部？中国标准？）、"GMT+8"（非标准 ID，应写"Asia/Shanghai"）、"Beijing"（无效，正确是"Asia/Shanghai"） - 验证方式：调用
TimeZone.getTimeZone(id).getID()，若返回与输入不一致（如输入"CST"却返回"GMT"），说明 ID 无效 - 安全做法：用
TimeZone.getAvailableIDs()查可用列表，或优先使用 IANA 标准 ID（如"Europe/London"、"America/New_York"）
SimpleDateFormat 里 setTimeZone() 和 new SimpleDateFormat(pattern, locale) 的时区行为差异
前者影响格式化/解析结果，后者只影响语言环境（如月份名、星期名），完全不改变时区逻辑。
-
SimpleDateFormat默认使用TimeZone.getDefault()，不是系统本地时区，也不是构造时的 locale 所在时区 - 必须显式调用
setTimeZone(TimeZone.getTimeZone("UTC"))才能控制时间偏移输出 - 解析字符串时，若字符串含时区信息（如
"2023-01-01T12:00:00+0800"），setTimeZone()会被忽略；若无时区（如"2023-01-01 12:00:00"），才按设定时区解释为本地时间 - Java 8+ 强烈建议换用
DateTimeFormatter+ZonedDateTime，避免此类隐式依赖
TimeZone 在跨年、夏令时切换日是否可靠？
对历史数据基本可靠，但对“未来多年后”的夏令时规则可能失效——因为 TimeZone 依赖 JVM 自带的 tzdata 数据库，版本老旧时无法反映各国新发布的调整公告。
立即学习“Java免费学习笔记（深入）”；
- 例如：2023 年巴西取消夏令时，但 JDK 8u202（2019 年发布）仍认为其每年 10 月启动 DST
- 检查当前 tzdata 版本：运行
java -XshowSettings:all -version 2>&1 | grep "tzdata" - 升级方式：更新 JDK，或手动替换
$JAVA_HOME/jre/lib/tzdb.dat（高风险，不推荐生产环境使用） - 真正需要长期准确性的场景（如航班排期、金融结算），应对接外部时区服务（如 IANA 官网或 NTP 时区 API），而非仅靠
TimeZone
