Java中处理业务周期需区分Duration（纳秒级精确时长）和Period（日历语义化偏移）：Duration适用于定时任务、超时控制等钟表时间场景；Period适用于“下月同日”“每季度首日”等日历调整；混用时先Period定位日期，再Duration计算时长。
Java 中处理业务周期，不能只靠加减毫秒数。Duration 和 Period 是专为时间计算设计的工具类，但用错场景会导致逻辑错误——比如用 Duration 计算“3个月后”会出问题，因为月份天数不固定；而用 Period 处理“2小时30分钟”又会丢失精度。关键在分清：Duration 用于**基于时间长度的精确量度（纳秒级）**，Period 用于**基于日历单位的语义化偏移（年月日）**。
Duration：适合“持续时长”类计算
Duration 表示两个 Instant 之间的时间差，单位是纳秒，适用于定时任务、超时控制、耗时统计等与“钟表时间”强相关的场景。
- 构造方式：用 ofHours(2)、ofMinutes(30)、ofSeconds(45, 123_000_000) 等静态方法，避免直接传入毫秒数（易出错）
- 加减操作：可对 Instant 或 LocalDateTime（需注意：LocalDateTime 不含时区，加 Duration 可能跨日但不考虑夏令时）做运算，例如：instant.plus(Duration.ofDays(1)) 是精确的 24 小时后
- 慎用场景：不要用 Duration 计算“下个月第一天”或“去年同月”，这类需求本质是日历调整，应交给 Period + LocalDate
Period：适合“日历偏移”类业务周期
Period 表示年、月、日三个日历单位的组合，用于表达“3个月零5天后”、“去年同日”、“每季度首日”等含语义的周期逻辑，底层依赖 ChronoUnit 和日期系统规则（如闰年、大小月）。
- 构造方式：用 of(1, 3, 5)（1年3月5日），或 between(startDate, endDate) 自动推导（结果是“最小粒度”表示，如 between(2023-01-15, 2024-04-20) 得到 P1Y3M5D）
- 加减操作：只能作用于 LocalDate、LocalDateTime、YearMonth 等支持日历计算的类型，例如：localDate.plus(Period.ofMonths(3)) 会跳到下下个月的同日（若不存在则取月末）
- 注意边界：2023-01-31.plusMonths(1) → 2023-02-28（不是 2023-03-03），这是 Period 的“日历友好”行为，也是业务中常被忽略的关键点
混合使用：解决真实业务周期问题
复杂周期往往既含日历偏移，又含固定时长。例如：“每月5号上午9点触发，持续2小时30分钟”。这时需拆解步骤：
立即学习“Java免费学习笔记（深入）”；
- 先用 Period 定位日历节点：nextTrigger = currentDate.withDayOfMonth(5).withHour(9).withMinute(0)，再用 plus(Period.ofMonths(1)) 推进到下月
- 再用 Duration 表达持续窗口：endTime = startTime.plus(Duration.ofHours(2).plusMinutes(30))
- 若涉及时区（如用户分布在不同时区），必须用 ZonedDateTime：先用 Period 调整日期部分，再用 Duration 调整时间部分，避免本地时间误算
避坑提醒：常见错误模式
很多周期逻辑 bug 来自类型误用或忽略上下文：
- 用 Duration.ofDays(30) 替代 Period.ofMonths(1)：30天 ≠ 1个月（1月31日 + 30天 = 3月2日，但1月31日 + 1个月 = 2月28日）
- 对 Instant 使用 Period：Instant 没有“年月日”概念，Period.ofYears(1).addTo(instant) 会抛 DateTimeException
- 忽略夏令时影响：LocalDateTime.plus(Duration.ofHours(24)) 总是加24小时；但 ZonedDateTime.plus(Period.ofDays(1)) 在夏令时切换日可能变成23或25小时——按业务需求选择
