LocalDate.toEpochDay() 固定以1970-01-01为基准计算天数差，不支持自定义纪元；若需“协定纪元”，应使用ChronoUnit.DAYS.between()或手动相减toEpochDay()值。
LocalDate.toEpochDay() 返回的是从 1970-01-01（ISO 纪元起始日）到该日期之间的完整天数，不是自“协定纪元”——它压根不支持自定义纪元。如果你看到“协定纪元”这个词，大概率是混淆了 Java 的 EpochDay 概念和某些领域（如金融协议、区块链时间戳）里自行约定的起始日。
为什么 toEpochDay() 固定以 1970-01-01 为基准
这是 ISO 8601 和 Java Time API 的硬性约定：LocalDate 的纪元（epoch）就是 1970-01-01，且不可更改。调用 toEpochDay() 本质是计算该日期与这个固定起点的天数差。
- 例如：
LocalDate.of(1970, 1, 1).toEpochDay()→0 -
LocalDate.of(1970, 1, 2).toEpochDay()→1 -
LocalDate.of(1969, 12, 31).toEpochDay()→-1
如果真要换算成“自某协定日”的天数，得手动偏移
Java 没有内置“自定义纪元的 toEpochDay”，但你可以用 ChronoUnit.DAYS.between() 或直接减法完成等效计算。
- 设协定起始日为
agreementStart = LocalDate.of(2020, 1, 1) - 目标日期为
target = LocalDate.of(2023, 6, 15) - 正确做法是：
ChronoUnit.DAYS.between(agreementStart, target)→1251 - 或等价写法：
target.toEpochDay() - agreementStart.toEpochDay()（因为两者都基于同一纪元，相减即抵消基准）
⚠️ 注意：不能直接改 toEpochDay() 的行为，也不能靠时区或格式化器影响结果——它只跟日期本身有关，与时区、本地化完全无关。
常见误用与性能陷阱
有人试图用 Instant 或 ZonedDateTime 中转来“调整纪元”，这不仅多余，还可能引入时区偏差：
- ❌ 错误：
localDate.atStartOfDay().atZone(ZoneId.systemDefault()).toInstant().getEpochSecond() / 86400—— 这算的是秒级 Unix 时间戳再转天数，会因夏令时/时区导致边界日出错 - ✅ 正确：坚持用
LocalDate+ChronoUnit.DAYS.between()或纯toEpochDay()相减 - 性能上：所有操作都是 O(1)，无需担心；但频繁构造
LocalDate对象（如在循环中解析字符串）才是真正的瓶颈点
真正需要“协定纪元”时，别指望 API 自动适配——把协定日存成常量，所有计算都显式减去它。省事又不易错。
