Calendar.add()需配合setLenient(false)防意外进位，操作月份用Calendar.MONTH而非数字1，获取当月天数优先用getActualMaximum()，多线程下须每次newInstance或clone，Calendar虽过时但在跨时区、历法细节等场景仍不可替代。
Calendar.add() 是日期计算的核心方法，但必须配合 setLenient(false) 防止意外进位
直接调用 add() 看似简单，但默认的宽松模式（lenient）会让 2023-02-30 变成 2023-03-02，而不是抛异常。这在金融、考勤等强校验场景极易埋雷。
- 务必在创建实例后立即调用
calendar.setLenient(false) -
add()修改的是内部字段值，不触发即时重算；如需立刻生效并校验，后续要调用calendar.getTime()或calendar.get(Calendar.DAY_OF_MONTH) - 对月份操作要特别注意：1 月对应
Calendar.JANUARY = 0，所以加 1 个月应传Calendar.MONTH，而非硬写1
getActualMaximum() 比直接写死 31 更安全地获取当月天数
用 calendar.getActualMaximum(Calendar.DAY_OF_MONTH) 获取当前 Calendar 实例所在月份的实际最大天数，比判断是否闰年再分支处理更简洁可靠。
- 它自动考虑平年/闰年、大小月、甚至农历相关 Calendar 子类（如 JapaneseCalendar）
- 不能用于任意日期构造——必须先用
set()或setTime()定位到目标年月，再调用 - 例如：想算 2024 年 2 月有多少天，得先
calendar.set(2024, Calendar.FEBRUARY, 1)，再调getActualMaximum()
Calendar.getInstance() 返回的是可变对象，多线程下必须每次 new 或 clone
静态方法 Calendar.getInstance() 返回的实例不是线程安全的。多个线程共用同一个实例调用 set() 或 add()，结果不可预测。
- 推荐做法：每次需要时都调用
Calendar.getInstance()，不要缓存复用 - 若性能敏感且必须复用，用
calendar.clone()获得副本（返回类型是 Object，需强制转型） - 避免用 static final Calendar —— 这是典型的线程安全陷阱
Calendar 已过时，但 LocalDate.plusDays() 等 API 无法替代所有场景
Java 8 的 LocalDate 确实更直观，但它没有内置时区偏移计算、也没有类似 getLeastMaximum() 这种细粒度日历逻辑支持。
立即学习“Java免费学习笔记（深入）”；
- 涉及跨时区时间推算（比如“北京时间上午9点 + 24小时”是否仍为上午9点）、或需兼容旧系统返回的
java.util.Date时，Calendar 仍是绕不开的中间层 -
Calendar.toInstant()和Instant.atZone()是桥接新旧 API 的关键组合 - 别试图把所有 Calendar 逻辑强行改造成 LocalDate —— 有些业务规则本身就依赖 GregorianCalendar 的闰秒/历法细节
add()，结果可能连自己都解释不了。 
