Date类不能直接用于日期计算，因其设计缺陷：月份从0开始、年份以1900为基点、方法非线程安全且已废弃；Calendar需clear再set字段以防状态残留；新项目应使用Java 8+的不可变、线程安全的java.time API。
Java中Date类为什么不能直接用作日期计算
Date 类在 JDK 1.0 就已存在，但它的大部分方法（如 setYear()、getMonth()、getDate()）从 JDK 1.1 起就被标记为 @Deprecated。这不是因为功能失效，而是设计缺陷：月份从 0 开始（0 表示一月），年份以 1900 为基点（123 表示 2023 年），且所有方法都不是线程安全的。
常见错误现象：
- 调用
date.getMonth()返回0却误以为是一月以外的月份 - 用
new Date(2023, 1, 1)构造对象，结果得到的是 2024 年 2 月 1 日（因年份+1900、月份+1） - 多线程环境下共享
Date实例并调用setTime()，导致时间值错乱
实际使用中，Date 仅建议作为「时间戳载体」——即只通过 getTime() 获取 long 值，或用构造函数 new Date(long) 初始化。所有业务逻辑中的日期操作，应避免直接调用其已废弃方法。
Calendar类做日期加减时必须先clear再set
Calendar 是 Date 的“补丁式替代”，但它内部状态复杂：字段未显式设置时可能沿用上一次实例的缓存值，尤其在复用同一 Calendar 实例时极易出错。
立即学习“Java免费学习笔记（深入）”；
典型错误写法：
Calendar cal = Calendar.getInstance(); cal.set(Calendar.YEAR, 2023); cal.add(Calendar.DAY_OF_MONTH, 5); // 你以为是2023-xx-xx加5天？其实可能还是2024年的某天
原因：getInstance() 返回的 Calendar 包含完整当前时间（年月日时分秒毫秒），只调用 set(Calendar.YEAR, 2023) 并不会清空月、日等字段，后续 add() 会在原有基础上叠加。
正确做法：
- 每次重用前必须调用
cal.clear() - 再按需
set()年、月、日等字段（注意月份仍从0开始） - 执行
add()或roll()前确保字段已明确初始化
示例：
Calendar cal = Calendar.getInstance(); cal.clear(); // 关键！ cal.set(Calendar.YEAR, 2023); cal.set(Calendar.MONTH, Calendar.JANUARY); // = 0 cal.set(Calendar.DAY_OF_MONTH, 1); cal.add(Calendar.DAY_OF_MONTH, 5); // 确保是2023-01-06
Calendar.getTime()返回的Date对象仍是可变的
很多人以为调用 calendar.getTime() 得到一个“快照”后，就可以放心修改原 Calendar。但这个 Date 对象内部只是包装了同一个 long time 值，它本身不隔离状态。
问题在于：Date 的 setTime()、setHours() 等方法依然可用，一旦被意外调用，会污染原始时间语义。
更隐蔽的风险：
- 将
calendar.getTime()传给外部方法，而该方法内部调用了date.setTime(...) - 把返回的
Date存入可变容器（如ArrayList），之后又对容器中元素调用setTime()
因此，如果必须返回时间表示，优先考虑：
- 返回
calendar.getTimeInMillis()的long值（不可变） - 或封装成
Instant（Java 8+）：Instant.ofEpochMilli(calendar.getTimeInMillis()) - 若必须返回
Date，至少做防御性拷贝：new Date(calendar.getTimeInMillis())
别再用Date和Calendar处理新项目的时间逻辑
Java 8 引入的 java.time 包（如 LocalDateTime、ZonedDateTime、Duration、Period）已彻底解决上述所有问题：不可变、线程安全、语义清晰、无魔法数字。
迁移成本其实很低：
-
new Date()→Instant.now() -
calendar.get(Calendar.YEAR)→LocalDateTime.now().getYear() -
calendar.add(Calendar.MONTH, 1)→localDate.plusMonths(1)
唯一需要警惕的是遗留接口：比如 JDBC 的 PreparedStatement.setDate() 还要求 java.sql.Date。这时应严格遵循转换规范：java.sql.Date.valueOf(localDate) 或 Timestamp.from(instant)，而不是用 new java.sql.Date(date.getTime()) 这种绕过类型语义的写法。
老代码里还藏着 Date 和 Calendar 不代表必须容忍它们——只要涉及日期计算、格式化、时区转换，就该视为技术债立即重构。
