LocalDate.plusDays() 语义上只支持加正数天数，负数虽可运行但属隐式兼容而非官方承诺；应改用 minusDays() 实现减法，以保证语义清晰、可读性强且避免静态分析警告。
LocalDate.plusDays() 为什么不能直接加负数？
LocalDate.plusDays() 设计上只接受 long 类型参数，但它的语义是“加上指定天数”，不是“位移”。虽然传入负数（如 -5）在运行时不会报错，也能得到正确结果（比如 2024-06-10 调用 .plusDays(-5) 得到 2024-06-05），但这是靠底层 plusDays 内部调用了 plus + ChronoUnit.DAYS 实现的隐式兼容，并非 API 承诺行为。官方 Javadoc 明确写的是 “adds the specified number of days”，语义上不鼓励负值。
更稳妥、语义清晰的做法是：加正数用 plusDays()，减天数统一用 minusDays() —— 它专为负向运算设计，可读性高，且未来 JVM 优化或静态分析工具（如 ErrorProne）可能对负数 plusDays 发出警告。
LocalDate.plusDays() 的边界行为和线程安全
LocalDate 是不可变类，所有操作（包括 plusDays()）都返回新实例，原对象不受影响。这意味着它天然线程安全，无需额外同步。
但要注意溢出问题：虽然 LocalDate 支持从 0000-01-01 到 999999999-12-31，但传入极大数值（如 Long.MAX_VALUE）会触发 DateTimeException，错误信息是 "Invalid value for DayOfYear" 或类似时间字段越界提示，而不是算术溢出异常。
立即学习“Java免费学习笔记（深入）”；
- 常见误用：用
int计算天数再强转long，但未校验是否溢出（如days = a - b可能 int 溢出） - 建议：若天数来自用户输入或数据库字段，先做范围检查，例如
if (days 1_000_000) throw new IllegalArgumentException(...) - 性能提示：
plusDays(0)返回的是原引用（JVM 优化），不是新对象，这点可放心用于默认逻辑分支
替代方案：什么时候不该用 plusDays()？
当需求涉及“工作日”“节假日跳过”“月末对齐”或“跨月/年动态偏移”时，plusDays() 就不够用了。它只是简单按日历天数加减，不理解业务规则。
例如：
- “从今天起第 3 个工作日” → 需要结合
TemporalAdjusters或第三方库（如 Time4J） - “加 1 个月，但保持在当月最后一天” → 应该用
localDate.with(TemporalAdjusters.lastDayOfMonth()).plusMonths(1)，而非plusDays(30) - “加 7 天，但跳过周末” → 必须手动循环 +
getDayOfWeek()判断
简单说：plusDays() 只适合“日历天数”的线性增减；一旦出现条件逻辑、周期规律或业务语义，就得换思路。
与 Calendar 和 Date 的兼容转换陷阱
老项目常需把 java.util.Date 或 Calendar 转成 LocalDate 再调用 plusDays()。这里最容易出错的是时区和时间截断。
典型错误写法：new Date().toInstant().atZone(ZoneId.systemDefault()).toLocalDate().plusDays(1) —— 表面看没问题，但若系统默认时区是 Asia/Shanghai，而原始 Date 是基于 UTC 存储的，这个链式调用会引入隐式时区转换偏差。
- 安全做法：明确指定时区，例如
date.toInstant().atZone(ZoneId.of("UTC")).toLocalDate() - 更推荐：如果源头可控，直接用
LocalDate.now(ZoneId.of("UTC"))初始化，避免Date中间态 - 注意：
Calendar.getInstance().getTime().toInstant()同样受Calendar当前时区影响，不要默认信任其“本地时间”含义
真正麻烦的不是加减本身，而是日期来源的上下文是否被准确还原 —— 这点比 plusDays() 的用法本身更值得花时间确认。
