在Java里Calendar类如何操作日期_Java日期计算方式说明-java教程-PHP中文网

set() 是设成某值，add() 是加减若干单位；set() 不触发进位，add() 自动处理溢出；设每月1日需用 set(Calendar.DAY_OF_MONTH, 1)；getActualMaximum() 比硬编码31更可靠；getTimeInMillis() 需先 get() 触发重算；Calendar 非线程安全，须每次新建或用 ThreadLocal；Java 8+ 应优先使用 LocalDateTime/ZonedDateTime。

在java里calendar类如何操作日期_java日期计算方式说明

Calendar 的 set() 和 add() 到底该用哪个

直接说结论：set() 是“设成某值”，add() 是“加减若干单位”。混淆两者是 Java 日期计算中最常见的逻辑错误来源。

比如想把一个 Calendar 对象的月份设为 12 月（即 Calendar.DECEMBER），用 set(Calendar.MONTH, 11) 没问题；但若误用 add(Calendar.MONTH, 11)，就会在当前月份基础上加 11 个月，结果完全不可控。

set() 不会触发自动进位或借位：调用 cal.set(Calendar.DAY_OF_MONTH, 32) 后，cal.get(Calendar.DAY_OF_MONTH) 可能返回 1（下月1号），这取决于底层实现和时区，行为不直观
add() 会自动处理溢出：如 1 月 31 日 + 1 个月 → 自动变成 2 月 28 日（或 29 日）
如果要“清零某字段再设新值”，不能只靠 set()；例如想设成每月 1 日，得先 set(Calendar.DAY_OF_MONTH, 1)，而不是 set(Calendar.DATE, 1)（二者等价，但别混用别名）

为什么 getActualMaximum(Calendar.DAY_OF_MONTH) 比直接写 31 更可靠

因为不是每个月都有 31 天。硬编码 31 在 4 月、6 月、9 月、11 月或 2 月会出错——尤其是跨年、跨闰年时。

getActualMaximum() 返回当前 Calendar 所处月份的实际最大天数，它考虑了年份、月份、甚至时区（极少数情况下影响月末判断）。

Calendar cal = Calendar.getInstance();
cal.set(2024, Calendar.FEBRUARY, 15); // 注意：月份从 0 开始
int lastDay = cal.getActualMaximum(Calendar.DAY_OF_MONTH); // 返回 29
cal.set(Calendar.DAY_OF_MONTH, lastDay); // 安全设为当月最后一天

别用 getMaximum() ——它返回该字段理论最大值（如 DAY_OF_MONTH 总是返回 31）
调用 getActualMaximum() 前，确保 Calendar 的年/月已明确设定，否则可能基于当前时间，导致意外结果
这个方法不修改日历状态，只读取，可放心多次调用

Calendar.getTimeInMillis() 和 new Date().getTime() 的精度陷阱

两者都返回毫秒数，但关键区别在于：前者依赖 Calendar 内部字段是否已“计算完成”。如果刚调用 set() 就立刻取时间戳，可能拿到过期缓存值。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

典型表现：设了年月日，但没设时分秒，getTimeInMillis() 返回的时间却包含旧的时分秒甚至毫秒值，导致时间偏移。

安全做法是调用 cal.getTimeInMillis() 前，先执行 cal.get(Calendar.YEAR) 或任意 get() ——这会强制触发内部重算（computeTime()）
更稳妥的是直接调用 cal.getTime().getTime()，getTime() 方法内部已保证时间同步
注意：Calendar 默认时区是 JVM 启动时确定的，跨时区操作必须显式 cal.setTimeZone(TimeZone.getTimeZone("UTC"))