Calendar.get(WEEK_OF_YEAR)不可靠，因依赖Locale的首日和最小天数；正确做法是锚定日期推算周一/周六；SimpleDateFormat解析会清空时分秒；set后须调getTime()刷新；Java 8+推荐用LocalDate+TemporalAdjusters。
Calendar.get() 返回的 WEEK_OF_YEAR 不可靠
用 Calendar 算周一/周日，很多人第一反应是调 get(WEEK_OF_YEAR) 再配合 set(WEEK_OF_YEAR, ...)，结果发现跨年时日期乱跳、12月最后一周算成下一年第1周。这是因为 WEEK_OF_YEAR 依赖 getFirstDayOfWeek() 和 getMinimalDaysInFirstWeek()，不同 Locale 默认值不同（比如 US 是 Sunday 开头、Minimal=1，CHINA 是 Monday 开头、Minimal=4），直接操作它本质是在“按周编号”维度推算，不是“找本周起止日期”。
正确做法是：先锚定当前日期，再往回/往前推到最近的周一和周日。
- 用
cal.get(Calendar.DAY_OF_WEEK)获取今天是星期几（注意：SUNDAY=1,MONDAY=2, ...,SATURDAY=7） - 往回减
(dayOfWeek - Calendar.MONDAY)天得周一 - 往后加
(Calendar.SATURDAY - dayOfWeek)天得周六（注意：不是周日！Calendar的“周末”在业务中常指周六+周日，但“本周六”才是严格对应周一的结束日） - 如果真要周日，就再加 1 天；但需意识到：周日属于下一周的
WEEK_OF_YEAR
SimpleDateFormat 解析后 set() 会丢掉时分秒
有人先用 SimpleDateFormat 格式化当前时间字符串，再 parse 回 Date，接着塞进 Calendar 里 set 时间字段——这会导致时分秒被清零。因为 SimpleDateFormat 默认只解析到你指定的格式部分，没写的就补 0。
例如：new SimpleDateFormat("yyyy-MM-dd").parse("2024-06-10") 得到的是当天 00:00:00 的 Date，再 set 到 Calendar 就永远从零点开始算偏移。
立即学习“Java免费学习笔记（深入）”；
- 想保留原始时间的时分秒？别 parse 字符串，直接 clone 当前
Calendar实例 - 用
Calendar cal = Calendar.getInstance(); Calendar base = (Calendar) cal.clone(); - 所有推算都在
base上做，原始cal的时分秒不受影响
Calendar.set() 后必须调用 Calendar.getTime() 才生效
Calendar 是可变对象，但它的内部时间戳（timeInMillis）不会在每次 set() 后自动更新。如果你只 set 年月日，没调 getTime() 或 get() 触发计算，后续再 get 其他字段（比如 HOUR_OF_DAY）可能返回旧值或错误值。
典型现象：设完周一日期后直接打印 format.format(cal.getTime())，结果还是原来的小时分钟——因为 getTime() 强制触发了内部重算。
- 每次完成日期字段修改后，立刻调一次
cal.getTime()（哪怕不存结果） - 或者统一在最后一步调，但确保中间没混用未刷新的字段 get 操作
- 避免链式写法如
cal.set(...).set(...).getTime()——set()返回 void
LocalDate + TemporalAdjusters 更安全（Java 8+）
如果项目已用 Java 8+，硬啃 Calendar 不仅容易错，还难测。用 LocalDate 配合 TemporalAdjusters 是更直白的选择：语义清晰、不可变、无时区干扰。
例如获取本周一：LocalDate.now().with(TemporalAdjusters.previousOrSame(DayOfWeek.MONDAY))；本周日：.with(TemporalAdjusters.nextOrSame(DayOfWeek.SUNDAY))。
-
previousOrSame和nextOrSame能处理“今天就是周一/周日”的边界情况 - 不依赖默认时区，
LocalDate.now()默认用系统时区，但你可以显式传ZoneId.systemDefault()或ZoneOffset.UTC - 如果必须返回
Date，用localDate.atStartOfDay(ZoneId.systemDefault()).toInstant().toEpochMilli()转，别用过时的GregorianCalendar.from()
真正麻烦的从来不是“怎么算出周一”，而是“算出来之后，这个周一到底属于哪一周的统计周期”。Calendar 的模糊性在这里暴露得最彻底——它既像一个时间容器，又像一个日历规则引擎，而这两者在跨年、跨月、时区切换时根本无法解耦。
