ChronoUnit.between() 返回负数是因为参数顺序决定减法方向：起点在前、终点在后，若颠倒则结果为负；它不自动比较大小，也不处理时区，且YEARS/MONTHS按日历字段计算而非实际天数，返回类型恒为long。
ChronoUnit.between() 为什么算出来是负数？
因为 ChronoUnit.between() 的参数顺序很关键：第一个是起点，第二个是终点。如果把时间更晚的传在前面，结果就是负的——它不自动判断大小，只做减法。
- 常见错误现象：
ChronoUnit.DAYS.between(LocalDateTime.now(), LocalDateTime.of(2020, 1, 1, 0, 0))返回一个很大的负数 - 正确用法：始终确保第一个参数是较早时间，第二个是较晚时间；不确定时先用
isBefore()或isAfter()判断 - 注意：它不处理时区，
ZonedDateTime传进去会抛DateTimeException，必须用Instant或同类型时间对象
用 ChronoUnit 计算“年”或“月”要特别小心
ChronoUnit.YEARS 和 ChronoUnit.MONTHS 看似直观，但它们只看日历字段差值，不考虑实际天数跨度。比如从 2023-01-31 到 2024-01-31 是 1 年，但从 2023-01-31 到 2024-02-01 就算成 1 年又 1 天（即 13 个月），而不是简单加 1。
- 使用场景：适合粗略估算、日历对齐类逻辑（如“满一年发奖金”），不适合精确天数推演
- 性能影响：比
DAYS或HOURS稍慢，因为要解析年月日结构 - 容易踩的坑：跨闰年、2 月 29 日、月末日期（如 1 月 31 日 → 2 月 28 日）会导致结果不符合直觉
ChronoUnit 不支持自定义单位，别想绕过 Period/Duration
有人试图用 ChronoUnit 表示“工作日”或“季度”，这是行不通的。它只是 JDK 内置的固定枚举，没有扩展机制。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 常见错误现象：写
ChronoUnit.WORK_DAYS编译失败；或误以为ChronoUnit.WEEKS能按周一到周五算 - 替代方案：真要算工作日，得自己写循环 +
DayOfWeek判断；算季度用TemporalAdjusters配合LocalDate.with() - 兼容性提醒：Java 8 引入，所有后续版本都可用，但 Android API 26+ 才完整支持
ChronoUnit的全部方法
between() 返回 long，但别直接当 int 用
返回类型是 long，不是 int。哪怕你算的是两个相邻小时，也得接 long，否则可能溢出或编译报错。
立即学习“Java免费学习笔记（深入）”；
- 典型错误：
int days = ChronoUnit.DAYS.between(d1, d2);—— Java 会提示“possible loss of precision” - 正确写法：
long days = ChronoUnit.DAYS.between(d1, d2);，需要int时显式(int) days，并确保业务上不会超Integer.MAX_VALUE - 性能提示：这个转换开销几乎为零，但隐式强转容易掩盖逻辑风险，比如两个相距几十年的日期差可能超过 21 亿天
ChronoUnit，后者该用 Duration 或 Period 就得用，混着来早晚出问题。 
