yearmonth用于年月粒度事件管理，如账单日；monthday用于无年份的月日事件，如生日提醒；二者均需显式转为localdate参与日期运算，不可直接用于定时调度。
YearMonth 适合管理「年+月」粒度的周期事件
比如账单日、订阅续费、季度报表生成——这些事情不关心具体哪一天，只和年份月份绑定。YearMonth 就是干这个的，它天然排除了日级歧义（比如 2 月 30 日直接构造失败），也比用 LocalDate 截断日部分更安全。
常见错误是拿 YearMonth 去做日期计算：比如“下个月”写成 yearMonth.plusMonths(1) 没问题，但想算“下个月第 5 天”就该转成 LocalDate 再操作，别硬塞在 YearMonth 上。
- 构造时传入非法月份（如 13）会抛
DateTimeException，不是静默修正 - 和
LocalDate互转要显式调用atDay(int)或withDayOfMonth(int)，没有隐式转换 - 数据库映射需注意：JDBC 4.2+ 支持
YearMonth，但旧版 Hibernate 可能得用@Convert手动处理
YearMonth billingCycle = YearMonth.of(2024, 3); // 2024 年 3 月 LocalDate dueDate = billingCycle.atDay(15); // 转成 2024-03-15
MonthDay 解决「每年固定月日」类事件，但必须补年份才能参与运算
MonthDay 存的是“7 月 15 日”这种无年份信息的组合，典型场景是生日提醒、节假日规则（如“每年 10 月第一个星期一”）、会员周年权益重置。它本身不能比较大小、不能加减，所有时间运算前都得绑定具体年份。
最容易踩的坑是直接拿两个 MonthDay 比较：比如 monthDay1.isBefore(monthDay2) 看似合理，其实只是按月、日字典序比，完全不考虑跨年逻辑（12 月 31 日“小于”1 月 1 日）。真要判断“今年哪个先到”，得先转成 LocalDate。
立即学习“Java免费学习笔记（深入）”；
JTopCMS基于JavaEE自主研发，是用于管理站群内容的国产开源软件(CMS)，能高效便捷地进行内容采编，审核，模板制作，用户交互以及文件等资源的维护。安全，稳定，易扩展，支持国产中间件及数据库，适合建设政府，教育以及企事业单位的站群系统。 系统特色 1. 基于 JAVA 标准自主研发，支持主流国产信创环境，国产数据库以及国产中间件。安全，稳定，经过多次政务与企事业单位项目长期检验，顺利通过
- 构造
MonthDay.of(2, 29)合法，但调用atYear(2023)会抛异常（2023 不是闰年） - 序列化时默认不含年份，JSON 或数据库存它容易丢失上下文，建议搭配年份字段一起存
- 时区无关——它不表示具体时刻，别试图用它算 UTC 时间偏移
MonthDay independenceDay = MonthDay.of(7, 4); LocalDate thisYear = independenceDay.atYear(2024); // 2024-07-04
YearMonth 和 MonthDay 都不能直接用于定时任务调度
像 Quartz、Spring Scheduler 这类框架只认 Instant、ZonedDateTime 或 cron 表达式，YearMonth 和 MonthDay 得先落地为具体日期时间点。比如“每月 1 号凌晨执行”，不能只存 MonthDay.of(1, 1)，而要每次动态生成当月的 LocalDateTime.of(year, month, 1, 0, 0)。
性能上没明显差异，但逻辑错位风险高：如果把 MonthDay 当作“每年重复”的标志存在缓存里，又忘了在每次触发前校验当年是否有效（比如 2 月 29 日在平年不存在），任务就会静默失败。
- 别在定时器配置里硬编码
YearMonth.now()—— 它只取初始化那一刻的值，不会自动更新 - 用
CronTrigger更稳妥：表达“每月 1 号”用0 0 0 1 * ?，比手动算YearMonth更直观可靠 - 若业务强依赖周期语义（如“季度末最后一天”），优先用
YearQuarter+TemporalAdjusters.lastDayOfQuarter()，别自己推算
时区与序列化是实际落地时最常被忽略的细节
YearMonth 和 MonthDay 本身不带时区，但落到具体日期时，时区就关键了。比如“每月 1 号 0 点触发”，在东八区是 2024-03-01T00:00+08:00，在美西是 2024-02-29T16:00-08:00——差整整一天。系统若跨时区部署，必须明确以哪个时区为准来解析 MonthDay。
JSON 序列化默认用 ISO 格式：YearMonth 输出为 "2024-03"，MonthDay 是 "--07-04"。前端或下游服务若没按 JSR-310 规范解析，可能当成字符串直接截取，导致逻辑错乱。
- Jackson 需注册
JavaTimeModule，否则反序列化MonthDay会报InvalidDefinitionException - MySQL 存
YearMonth推荐用CHAR(7)或YEAR + TINYINT组合，别用DATE类型硬塞（会补 01 日，语义污染） - 测试时别只测当前年份——尤其涉及
MonthDay.atYear()的逻辑，务必覆盖闰年和平年边界
真正麻烦的不是 API 怎么写，而是“哪天算这个周期的开始”“跨年时要不要顺延”“用户时区和服务器时区谁说了算”——这些业务规则一旦模糊，再准的类型也救不了。
