new Date() 在2026年新项目中应彻底禁用：它是可变、非线程安全、语义模糊的遗留类，月份0起始、年份1900基准等设计反直觉且已弃用；应改用java.time包中的Instant、LocalDateTime等语义清晰、线程安全的类型。
为什么 new Date() 在新项目里等于埋雷
它不是“能用但不好用”，而是从根上就不该出现在 2026 年的新代码里：Date 是一个可变、非线程安全、语义模糊的遗留类型，连它的 toString() 都在偷偷用系统默认时区“伪装”本地时间。你写 new Date()，实际得到的是一个 UTC 瞬时值（Instant 的语义），但所有老 API（比如 getMonth()）又按本地日历解释它——这种撕裂感就是 bug 温床。
月份是 0 起始、年份要减 1900？这不是 API，是考题
这是最常踩的坑，而且编译期完全不报错：
-
date.setMonth(1)→ 实际设成 **2 月**（0 = 一月） -
date.setYear(2026)→ 实际设成 **3926 年**（因为它是 1900 基准） -
date.getMonth()返回8，你以为是 8 月？其实是 **9 月**
这些方法全被标记为 @Deprecated，JDK 从 1.1 就开始劝退，但没人强制你改——直到某次跨年上线，订单时间全错乱。
SimpleDateFormat 和 Date 是“线程安全双废”组合
只要你在工具类里写过 private static SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");，高并发下就大概率出现解析出 "2026-13-99" 这种结果。原因很简单：Date 可变 + SimpleDateFormat 内部有共享状态，两者叠加，等于给多线程开了个竞态漏洞。
立即学习“Java免费学习笔记（深入）”；
替代方案不是加 synchronized，而是直接换掉：
- 格式化/解析用
DateTimeFormatter.ofPattern("yyyy-MM-dd")（不可变、线程安全） - 时间点用
Instant.now()或LocalDateTime.now()（取决于是否需要时区） - 绝对不要把
Date当作“本地时间”来存数据库 DATETIME 字段——它底层仍是毫秒时间戳，只是 toString() 欺骗了你
迁移到 java.time 不是字符串替换，关键看语义对齐
很多老系统把 Date 当“无时区时间”用，其实它本质是 UTC 瞬时值。迁移时必须问清楚：这个字段在业务中代表什么？
- 数据库是
DATETIME（无时区）→ 改用LocalDateTime，Hibernate 5.2+ 原生支持 - 数据库是
TIMESTAMP WITH TIME ZONE→ 必须用ZonedDateTime或OffsetDateTime，硬套LocalDateTime会丢时区信息 - 和前端 JSON 交互时，
Date默认序列化成数字（毫秒），而LocalDateTime默认是字符串（如"2026-01-27T20:26:00"）→ 需统一 Jackson 配置，否则前后端时间对不上
最容易被忽略的一点：别以为把 private Date createTime; 改成 private LocalDateTime createTime; 就万事大吉——如果旧数据是按系统时区反向存的，迁移脚本没做时区校正，历史时间全偏 8 小时。
