Java Date类因可变性、线程不安全、月份年份偏移、职责混乱及时区语义模糊等问题被JDK 8弃用，应改用java.time包中的Instant、LocalDateTime等不可变、线程安全的类。
Java中的Date类（java.util.Date）自JDK 1.0起就存在，但其设计已被广泛认为过时且问题重重。它不是线程安全的、API混乱、语义模糊，且与现代时间模型严重脱节。JDK 8引入java.time包后，官方明确建议弃用Date类（除部分构造方法和toString()等少数方法外），但因历史代码大量存在，理解其缺陷对维护和迁移至关重要。
可变性与线程不安全
Date对象是可变的（mutable）——几乎所有修改方法（如setYear()、setMonth()、setTime()）都会直接改变原对象状态。这导致在多线程环境下极易引发竞态条件，且无法作为不可变值安全共享。
- 没有提供不可变副本机制，开发者需手动克隆（如
new Date(date.getTime())），易遗漏 - 集合类（如
HashSet）中若将Date用作键，后续修改会导致哈希码变化，破坏集合一致性 - Spring、Hibernate等框架内部常需额外同步或防御性拷贝，增加开销和出错风险
月份与年份的反直觉偏移
Date的月份从0开始（0=January，11=December），年份则以1900为基准（如setYear(123)表示2023年）。这种设计源于早期C语言struct tm，但完全违背自然语言习惯，极易引发逻辑错误。
- 常见误写：
date.setMonth(1)本意设为1月，实际设为2月 - 跨年计算易错：如
date.setYear(2023)会将年份设为3923年（2023+1900） - 无编译期检查，运行时才暴露，调试成本高
职责混乱与功能割裂
Date既表示时间点（instant），又承担格式化、解析、日历运算等职责，违反单一职责原则。真正的时间计算依赖Calendar，格式化依赖SimpleDateFormat，三者协作复杂且各自有坑。
立即学习“Java免费学习笔记（深入）”；
-
SimpleDateFormat非线程安全，常被误用为静态变量，导致解析结果错乱 -
Calendar实例创建开销大，且其get()/set()方法仍延续0基月份等反直觉设计 - 日期加减需先转
Calendar，再回转Date，冗余且易出错（如忽略时区、夏令时）
时区与UTC语义模糊
Date内部仅存储自1970-01-01 00:00:00 UTC以来的毫秒数（即一个瞬时值），但其toString()方法默认按JVM本地时区格式化输出，造成“Date含时区”的误解。实际它不含时区信息，也不支持时区转换。
- 开发者常误以为
new Date()是“本地时间”，实则是UTC时刻，只是打印时做了本地化 - 跨时区系统中，直接比较两个
Date看似安全，但若混入Calendar或SimpleDateFormat的时区操作，极易引入偏差 - 无内置方法区分“带时区的日期时间”（如
ZonedDateTime）和“仅时间点”（如Instant）
这些问题共同导致Date成为Java中最容易写出隐蔽bug的类之一。替代方案明确：用Instant表示时间点，LocalDateTime/ZonedDateTime处理日历业务，DateTimeFormatter负责格式化——清晰、不可变、线程安全、语义准确。
