Java Date类已过时，因设计缺陷多、线程不安全、语义模糊且无法正确处理时区；其getYear()返回距1900年差值、getMonth()返回0–11，均被@Deprecated标记；应通过toInstant()转java.time类型处理。
Java 的 Date 类早已过时，不建议在新代码中直接使用 —— 它的设计缺陷多、线程不安全、语义模糊，且无法正确处理时区和日历系统细节。
为什么 Date 的 getYear()、getMonth() 会返回错误值
这些方法是早期 JDK 1.0 的遗留设计，返回值做了非直观偏移：getYear() 返回距 1900 年的年份差（如 2024 年返回 124），getMonth() 返回 0～11（1 月为 0），getDate() 才是 1～31。更糟的是，它们已被标记为 @Deprecated，编译期就会警告。
- 不要依赖这些 getter，它们无法表达“2024 年 3 月 15 日”这种直觉语义
- 若必须读取旧
Date对象，应转成Instant或LocalDateTime再解析 - 用
SimpleDateFormat解析或格式化时，也需注意其内部仍调用这些过时方法，容易引发隐式错误
Date 和 SimpleDateFormat 组合为何线程不安全
SimpleDateFormat 内部维护可变状态（如解析位置、缓存的 Calendar 实例），而 Date 本身虽不可变，但所有基于它的格式化/解析操作都依赖这个共享的、可变的 SimpleDateFormat 实例。
- 多个线程共用一个
SimpleDateFormat实例时，会出现解析错乱（如把 “2024-01-01” 解成 2023 年）或抛出java.lang.NumberFormatException - 常见错误写法：
private static final SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd") - 替代方案：用
DateTimeFormatter（线程安全、不可变），或每次新建SimpleDateFormat实例（性能差，仅作临时兼容）
从 Date 迁移到 java.time 的关键转换点
核心原则是：把 Date 当作“时间戳的容器”，只通过 toInstant() 拆解，再按语义选择 java.time 类型处理。
立即学习“Java免费学习笔记（深入）”；
-
new Date().toInstant()→ 得到 UTC 时间点（Instant） -
date.toInstant().atZone(ZoneId.systemDefault())→ 转成本地时区的ZonedDateTime -
date.toInstant().atOffset(ZoneOffset.UTC)→ 转成带固定偏移的OffsetDateTime - 反向转换：只有
Instant可无损转回Date（Date.from(instant)）；LocalDateTime没有时区信息，不能直接转，必须指定时区补全
真正麻烦的不是转换语法，而是业务逻辑里那些隐含时区假设的 Date 使用场景——比如把 Date 存进数据库却没记录时区，或者用 before()/after() 做跨时区比较。这些地方不重构语义，光换 API 没用。
