localdate.minusweeks() 返回新实例且不修改原对象，等价于 minus(7 * weeks, chronounit.days)，自动处理跨月跨年闰年，语义清晰优于 minusdays(7)，但需注意“今天”的时区来源。
minusWeeks() 的行为和返回值类型
LocalDate.minusWeeks() 不会改变原对象，而是返回一个新 LocalDate 实例，这点和所有 LocalDate 的时间运算方法一致。它内部等价于 minus(7 * weeks, ChronoUnit.DAYS)，也就是按天数减去整周——所以“上周同一天”这个语义天然成立，不需要额外对齐或调整。
常见错误是误以为它会修改原变量：
LocalDate today = LocalDate.now(); today.minusWeeks(1); // ❌ 无效果：返回值被丢弃 System.out.println(today); // 还是今天
正确写法必须接收返回值：
LocalDate today = LocalDate.now(); LocalDate lastWeek = today.minusWeeks(1); // ✅ System.out.println(lastWeek); // 如 2024-06-12（若 today 是 2024-06-19）
处理边界场景：跨月、跨年、闰年
LocalDate 自动处理所有日历边界，minusWeeks() 不需要你手动判断是否跨月或跨年。例如 2024-01-03 调用 .minusWeeks(1) 得到 2023-12-27，完全可靠。
但要注意：它只做纯日期计算，不考虑时区、夏令时或业务规则（比如“上周一”是否指工作日）。如果你的业务定义“上周”为“上一个周一至周日区间”，那 minusWeeks(1) 并不满足——它只是“7天前”，不是“上个自然周”。
- 跨月/跨年：无需干预，
LocalDate内置支持 - 闰年2月29日：2024-02-29.minusWeeks(1) → 2024-02-22，安全
- 想获取“上周一”？得先用
with(DayOfWeek.MONDAY)对齐再减
与 minusDays(7) 的区别和选型建议
从结果看，minusWeeks(1) 和 minusDays(7) 完全等价；但从语义和可维护性角度，推荐用 minusWeeks()。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
原因如下：
- 意图更清晰：看到
minusWeeks(1)就知道是“上周”，而minusDays(7)需要心算是否恰好是一周 - 便于扩展：如果后续逻辑变成“上 N 周”，
minusWeeks(n)直接替换变量，minusDays(7 * n)容易漏乘或写错 - 性能无差异：两者底层都转为
minus()+ChronoUnit.DAYS，没有运行时开销差别
容易忽略的时区和初始化陷阱
LocalDate 本身不含时区信息，所以 minusWeeks() 的结果完全取决于你构造它的那一刻。最常踩的坑是用 LocalDateTime.now() 或 ZonedDateTime.now() 转换时没指定时区：
LocalDateTime now = LocalDateTime.now(); // ❌ 依赖系统默认时区，且不含时区上下文 LocalDate date = now.toLocalDate(); // 可能因本地时区偏移导致“昨天”
更稳妥的方式是显式基于当前时区获取日期：
LocalDate today = LocalDate.now(ZoneId.systemDefault()); // ✅ 明确时区来源 LocalDate lastWeek = today.minusWeeks(1);
或者，如果你在处理用户输入或 API 时间戳，务必确认原始字符串是否已带时区（如 "2024-06-19T10:00:00+08:00"），避免直接 parse() 成 LocalDate 丢失上下文。
真正复杂的点不在减法本身，而在“今天”是怎么来的——源头模糊，结果再准也没意义。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
