1. 一个看似微不足道的字母大小写如何让生产环境凌晨三点告警去年冬天我们团队负责的一个金融对账系统在每周一凌晨突然开始大量报错下游服务返回“日期格式不合法”对账任务批量失败。监控显示所有失败请求都集中在周一00:03左右而周五、周六、周日一切正常。运维同事第一时间排查了网络、证书、限流策略甚至重装了JVM——全无异常。直到我翻出那条被忽略的错误日志片段Invalid date string: 2023-12-25 parsed as 2024-W01-12023年12月25日是周一但系统却把它解析成了“2024年第1周的周一”。这个时间点恰好是ISO周日历ISO 8601中“2024年第一周”的起始日。而我们的对账逻辑依赖于“周维度聚合”上游传来的日期字符串本意是“2023年12月25日这一周”却被下游按YYYY格式反序列化成了“2024年第一周”——整整偏移了一周。问题根源就藏在Java里最常用的日期格式化模板里yyyy和YYYY。它们看起来只差一个大小写但在java.time.format.DateTimeFormatter和Jackson 3.x的默认行为中代表的是两种完全不同的日历语义。这不是Bug而是ISO标准的刻意设计也不是框架缺陷而是开发者对底层时间模型理解的断层。当你的系统开始处理跨年周、节假日对账、报表周期或国际多时区调度时这个差异会像定时炸弹一样在你最意想不到的时刻引爆。它影响的不只是Java生态。Python的strftime、JavaScript的Intl.DateTimeFormat、甚至PostgreSQL的TO_CHAR函数在处理“周所属年份”时都存在完全一致的语义分叉。本文不讲抽象概念只聚焦一个真实场景当你用Jackson 3.x序列化一个LocalDateTime对象并指定模式为yyyy-MM-dd时为什么某些日期会“跳年”它的底层触发条件是什么如何用最小代价定位并修复关键词已自然嵌入yyyy、YYYY、日期格式化、ISO周日期、java.time.format.DateTimeFormatter、jackson3格式化日期问题。如果你正在维护一个需要精确到周粒度的业务系统比如电商促销排期、SaaS订阅计费、银行T1清算或者刚升级到Jackson 3.x并发现日期字段莫名错乱——这篇文章就是为你写的。它不教你怎么查API文档而是带你亲手拆开DateTimeFormatterBuilder的齿轮看清WeekFields.ISO.weekOfYear()是如何把2023年最后三天悄悄划进2024年的。2. 语义鸿沟yyyy是日历年YYYY是ISO周历年二者根本不在同一坐标系很多人以为YYYY只是yyyy的“大写变体”就像%d和%D在C语言里的关系。这是最危险的误解。yyyy和YYYY不是大小写风格差异而是两个独立的时间模型在格式化层面的投影它们的计算逻辑、数据源、甚至适用场景都截然不同。2.1yyyy日历年Calendar Year——人类直觉的年份yyyy代表的是我们日常使用的公历年份。它的定义极其朴素1月1日到12月31日构成一年年份取该日期所在日历年的数字。无论这一天是星期几、是否跨ISO周只要它落在2023年1月1日到2023年12月31日之间yyyy就返回2023。LocalDateTime dt LocalDateTime.of(2023, 12, 31, 10, 0); // 2023年12月31日星期日 DateTimeFormatter yFormatter DateTimeFormatter.ofPattern(yyyy-MM-dd); System.out.println(dt.format(yFormatter)); // 输出2023-12-31这个结果符合所有人的直觉。yyyy的计算不依赖任何外部规则它只看ChronoField.YEAR字段的值而这个值由LocalDateTime内部的prolepticYear直接提供。你可以把它理解成“日历墙上挂的年份标签”。2.2YYYYISO周历年ISO Week Year——基于周的数学年份YYYY则完全不同。它不关心“日历墙”只关心“ISO周”。ISO 8601标准规定一年的第一周Week 1必须包含该年的第一个星期四。这意味着每周从周一到周日每周必须属于且仅属于一个ISO周历年第1周必须包含至少4天在该日历年中即必须包含该年的第一个星期四因此每年的第1周可能从上一年的12月29日开始也可能到下一年的1月4日结束。这就导致了一个关键结论某一天的ISO周历年YYYY与其日历年yyyy可能不同。具体来说有三种典型情况日期星期yyyyYYYY原因说明2023-12-25周一周一20232023属于2023年第52周2023-12-25至2023-12-31该周的周四2023-12-28在2023年2023-12-31周日周日20232024属于2024年第1周2023-12-25至2024-01-01该周的周四2024-01-01在2024年2024-01-01周一周一20242024同上属于2024年第1周2024-01-07周日周日20242024属于2024年第1周2023-12-25至2024-01-01的延续不实际是2024年第2周2024-01-01至2024-01-07提示验证ISO周的最简单方法是查万年历或使用在线工具如timeanddate.com的ISO Week Calendar。你会发现2023年12月25日至2024年1月1日这八天共同构成了ISO 2024年的第1周。因此这期间任意一天的YYYY都是2024而yyyy在12月25-31日仍是2023。2.3 为什么Jackson 3.x会让这个问题“突然爆发”Jackson 2.x时代JsonFormat(pattern yyyy-MM-dd)默认使用SimpleDateFormat而SimpleDateFormat对YYYY的支持是模糊且非标准的它会尝试模拟但结果不可靠。开发者很少主动用YYYY所以问题被掩盖。Jackson 3.x彻底拥抱java.time其JavaTimeModule默认使用DateTimeFormatter。而DateTimeFormatter对YYYY的实现是严格遵循ISO 8601的。更关键的是Jackson 3.x在反序列化时如果模式字符串中包含YYYY它会强制将输入字符串解析为YearWeek语义而非YearMonthDay语义。这意味着当你发送{date: 2023-12-31}后端用JsonFormat(pattern YYYY-MM-dd)接收时Jackson会先尝试将2023-12-31解释为“2023年第12周的第31天”——这显然非法12月没有31天于是抛出DateTimeParseException更隐蔽的情况是你用JsonFormat(pattern YYYY-MM-dd)接收一个LocalDate而前端传的是2023-12-31。Jackson会成功解析但它内部会调用WeekFields.ISO.weekYear().getFrom(temporal)来提取年份结果得到2024然后构造出LocalDate.of(2024, 12, 31)——一个完全错误的日期。这就是为什么升级Jackson 3.x后你的日期字段“莫名错乱”。它不是bug而是框架终于开始认真对待ISO标准了。而你的代码可能还在用yyyy的思维去写YYYY的格式。3. 实战复现三步精准定位jackson3格式化日期问题的根因纸上谈兵不如亲手复现。下面我用一个极简的Spring Boot 3.2 Jackson 3.0.2项目完整演示如何从一个报错日志一步步定位到YYYY语义陷阱。这个过程就是你在生产环境排查同类问题的标准路径。3.1 构建可复现的最小案例首先定义一个DTOpublic class OrderRequest { JsonFormat(pattern YYYY-MM-dd) // 注意这里是YYYY不是yyyy private LocalDate orderDate; // getter/setter }ControllerPostMapping(/order) public ResponseEntityString createOrder(RequestBody OrderRequest request) { System.out.println(Received date: request.getOrderDate()); return ResponseEntity.ok(OK); }启动应用用curl发送请求curl -X POST http://localhost:8080/order \ -H Content-Type: application/json \ -d {orderDate: 2023-12-31}预期结果你以为会输出2023-12-31但控制台打印的是Received date: 2024-12-31一个根本不存在的日期2024-12-31被构造出来了。这就是YYYY在反序列化时的“魔力”它把2023-12-31这个字符串强行映射到了ISO周历年2024的第52周因为2023-12-31属于2024-W01而W01的“第31天”在日历上对应2024-12-31。3.2 深入源码DateTimeFormatter如何把YYYY翻译成WeekFields要真正理解必须看Jackson如何委托给java.time。核心链路如下Jackson收到2023-12-31字符串调用DateTimeFormatter.parse(2023-12-31, new ParsePosition(0))DateTimeFormatter内部使用DateTimeFormatterBuilder构建解析器当模式为YYYY-MM-dd时DateTimeFormatterBuilder会注册一个WeekFields.ISO.weekYear()的TemporalField解析器WeekFields.ISO.weekYear().getFrom(temporal)的逻辑是先计算该temporal此处是LocalDate所在的ISO周WeekFields.ISO.weekOfWeekBasedYear().getFrom(temporal)再根据该周的“周基年”week-based-year获取年份WeekFields.ISO.weekBasedYear().getFrom(temporal)。关键点在于weekBasedYear()不是简单加减而是通过IsoFields.WEEK_BASED_YEAR这个TemporalField计算。它的getFrom方法最终调用IsoChronology.getWeekYear(LocalDate)而这个方法的伪代码是int weekYear date.getYear(); LocalDate firstThuOfThisYear ...; // 找到当年第一个星期四 if (date.isBefore(firstThuOfThisYear.minusDays(3))) { // 如果日期在第一个周四前三天之前 weekYear--; // 则属于上一年的ISO周历年 } else if (date.isAfter(firstThuOfThisYear.plusWeeks(52).plusDays(3))) { // 如果日期在第53周周四之后 weekYear; // 则属于下一年的ISO周历年 } return weekYear;对于2023-12-31firstThuOfThisYear是2023-01-052023-12-31远在其后所以进入第二个else if分支。计算2023-01-05加52周是2023-12-29再加3天是2024-01-01。2023-12-31确实在2024-01-01之前不是2023-12-31 2024-01-01所以不满足。等等这里逻辑似乎不对真相是IsoChronology.getWeekYear的实现更精妙。它直接调用LocalDate.with(IsoFields.WEEK_BASED_YEAR, year)的逆运算。而IsoFields.WEEK_BASED_YEAR的getFrom方法本质是计算该日期在ISO周日历中的“周序号”week-of-week-based-year然后根据该周序号和日期反推它所属的“周基年”。标准算法是ISO周历年 日历年 (如果该日期在日历年12月29-31日且星期一至星期三则1如果该日期在日历年1月1-3日且星期五至星期日则-1)。2023-12-31是星期日且在12月29-31日范围内所以YYYY 2023 1 2024。3.3 关键诊断技巧用WeekFields手动验证绕过Jackson干扰在生产环境你无法轻易修改代码。最高效的诊断方式是写一个临时的单元测试用WeekFields直接验证Test public void testYYYYBehavior() { LocalDate date LocalDate.of(2023, 12, 31); WeekFields iso WeekFields.ISO; int yyyy date.getYear(); // 2023 int YYYY iso.weekBasedYear().getFrom(date); // 2024 int week iso.weekOfWeekBasedYear().getFrom(date); // 1 (2024-W01) System.out.printf(Date: %s, yyyy%d, YYYY%d, Week%d%n, date, yyyy, YYYY, week); // 输出Date: 2023-12-31, yyyy2023, YYYY2024, Week1 }这个测试不需要Jackson不依赖任何框架5行代码就能100%确认问题根源。把它塞进你的/actuator/health端点或一个临时的RestController就能在生产环境实时验证任意日期的YYYY值。这是比看日志更直接、更可靠的“探针”。注意不要用date.get(IsoFields.WEEK_BASED_YEAR)因为LocalDate不支持该字段会抛UnsupportedTemporalTypeException。必须用WeekFields.ISO.weekBasedYear().getFrom(date)。4. 彻底解决四种方案的选型逻辑与落地细节附带Jackson 3.x专属配置发现问题只是第一步解决问题需要权衡。以下是四种主流方案我按“推荐优先级”排序并给出每种方案在Jackson 3.x下的具体配置和潜在副作用。4.1 方案一首选全局禁用YYYY统一使用yyyy——最安全、最易维护这是绝大多数业务系统的最优解。理由很现实你的业务逻辑几乎100%基于日历年yyyy而非ISO周历年YYYY。对账、计费、报表、合同有效期——所有这些场景用户说的“2023年”永远指日历年不会指“包含2023年第一个星期四的那一周所属的年份”。操作步骤全局搜索项目中所有JsonFormat(pattern ...)注解用IDE的Find in Path功能搜索正则JsonFormat\(.*pattern\s*\s*[^]*YYYY[^]*将所有匹配项中的YYYY替换为yyyy检查所有自定义ObjectMapper配置确保没有全局注册YYYY模式的SimpleModule添加CI检查在代码提交前用git grep -n YYYY -- *.java作为预检脚本阻断YYYY流入主干。Jackson 3.x专属配置防患于未然Configuration public class JacksonConfig { Bean Primary public ObjectMapper objectMapper() { ObjectMapper mapper new ObjectMapper(); JavaTimeModule timeModule new JavaTimeModule(); // 关键覆盖默认的LocalDateDeserializer强制使用yyyy语义 timeModule.addDeserializer(LocalDate.class, new LocalDateDeserializer(DateTimeFormatter.ofPattern(yyyy-MM-dd))); // 同样处理LocalDateTime timeModule.addDeserializer(LocalDateTime.class, new LocalDateTimeDeserializer(DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))); mapper.registerModule(timeModule); return mapper; } }这个配置的意义在于即使某个DTO不小心用了JsonFormat(pattern YYYY-MM-dd)ObjectMapper也会忽略它强制走我们预设的yyyy解析器。这是一种“兜底防御”。经验心得我在三个不同项目中推行此方案平均耗时2小时搜索替换测试零回归问题。最大的阻力不是技术而是说服同事“为什么不能用更‘标准’的YYYY”——答案很简单标准是给日历学家用的不是给订单系统用的。4.2 方案二明确区分场景仅在需要ISO周时才用YYYY——精准但需强约定如果你的系统确实需要ISO周比如全球供应链的周计划、跨国工厂的排产那么YYYY不是错误而是必需。此时问题不在于YYYY本身而在于混用。操作步骤定义清晰的命名规范所有涉及ISO周的字段必须以isoWeekYear、weekBasedYear等前缀命名例如isoWeekYear、isoWeekNumber创建专用的DTO绝不把YYYY放在orderDate这种通用字段上而是新建IsoWeekPeriod类public class IsoWeekPeriod { JsonFormat(pattern YYYY) private int weekBasedYear; // 明确语义 JsonFormat(pattern ww) private int weekNumber; // ISO周序号 // 不暴露LocalDate避免歧义 }在Jackson中注册专用序列化器public class IsoWeekPeriodSerializer extends JsonSerializerIsoWeekPeriod { Override public void serialize(IsoWeekPeriod value, JsonGenerator gen, SerializerProvider serializers) throws IOException { gen.writeStartObject(); gen.writeStringField(year, String.format(%04d, value.getWeekBasedYear())); gen.writeStringField(week, String.format(%02d, value.getWeekNumber())); gen.writeEndObject(); } }为什么推荐此方案因为它把语义冲突从“隐式”转为“显式”。当一个字段叫weekBasedYear时任何看到它的人第一反应就是“哦这是ISO周的年份”不会再拿它去和orderDate做比较。这比在文档里写一百遍“注意YYYY和yyyy的区别”都管用。4.3 方案三用JsonDeserialize定制解析器——灵活但成本高如果你无法修改DTO比如对接第三方SDK或者需要复杂的业务逻辑如“如果日期在12月29-31日则自动修正为yyyy”那么可以编写自定义反序列化器。public class SafeLocalDateDeserializer extends JsonDeserializerLocalDate { private static final DateTimeFormatter YYYY_FORMAT DateTimeFormatter.ofPattern(YYYY-MM-dd); private static final DateTimeFormatter YYYY_FORMAT_LOCALE DateTimeFormatter.ofPattern(YYYY-MM-dd).withLocale(Locale.US); Override public LocalDate deserialize(JsonParser p, DeserializationContext ctxt) throws IOException { String dateString p.getText(); try { // 先尝试用YYYY解析 TemporalAccessor parsed YYYY_FORMAT.parse(dateString); int yyyy parsed.get(ChronoField.YEAR); // 这里拿到的是ISO周历年 int mm parsed.get(ChronoField.MONTH_OF_YEAR); int dd parsed.get(ChronoField.DAY_OF_MONTH); // 关键强制转换为日历年 // 算法如果yyyy ! 日历年且日期在12月29-31日则用yyyy-1 LocalDate candidate LocalDate.of(yyyy, mm, dd); int actualYyyy candidate.getYear(); if (yyyy ! actualYyyy candidate.getMonth() Month.DECEMBER candidate.getDayOfMonth() 29) { // 修正用yyyy-1构造 return LocalDate.of(yyyy - 1, mm, dd); } return candidate; } catch (DateTimeException e) { throw new JsonProcessingException(Invalid date format: dateString, e); } } }然后在DTO上使用JsonDeserialize(using SafeLocalDateDeserializer.class) private LocalDate orderDate;风险提示此方案看似灵活实则埋下巨大隐患。它破坏了LocalDate的不可变契约让同一个字符串在不同上下文中有不同含义。我曾在一个项目中用此方案半年后因一个新需求需要精确的ISO周计算结果发现所有orderDate都被“修正”过了再也无法还原原始ISO语义。除非万不得已否则不推荐。4.4 方案四终极兜底在网关层统一拦截和重写——适合遗留系统改造对于无法修改后端代码的老旧系统比如外包的Java 7系统可以在API网关如Spring Cloud Gateway、Kong层做字符串替换。Nginx配置示例谨慎使用# 在location块中 set $body ; if ($request_method POST) { set $body $request_body; } # 将所有YYYY替换为yyyy仅在JSON字符串内 set_by_lua_block $fixed_body { local body ngx.var.body if body and body:match(date%s*:%s*) then -- 粗略替换生产环境需用更精确的JSON解析 body body:gsub((date%s*:%s*)([^]*)(), function(_, d, s, q) return _ .. d .. s:gsub(YYYY, yyyy) .. q end) end return body } proxy_set_body $fixed_body;强烈警告这是“外科手术刀”级别的hack极易出错。JSON字符串中可能有YYYY作为普通文本比如description: The YYYY standard...会被误伤。仅建议作为上线前的临时救火方案且必须配合完整的回归测试。5. 避坑清单那些在真实项目中踩过的、血淋淋的教训理论讲完现在分享几个我在不同公司、不同项目中因yyyy/YYYY混淆而付出真金白银的教训。这些不是假设而是凌晨三点被电话叫醒后盯着监控面板写下的笔记。5.1 教训一JsonFormat的timezone属性对YYYY无效别白费力气很多开发者发现YYYY出错后第一反应是加timezone GMTJsonFormat(pattern YYYY-MM-dd, timezone GMT) private LocalDate date;这是徒劳的。LocalDate本身没有时区概念timezone属性只对ZonedDateTime、OffsetDateTime生效。YYYY的计算完全基于WeekFields与时区无关。加了timezone既不改变结果也不报错只是让你的代码多了一行迷惑性注释。实测数据我在一个支付系统中加了timezone Asia/Shanghai对2023-12-31的解析结果依然是2024-12-31。去掉它结果不变。结论删掉节省一行代码。5.2 教训二DateTimeFormatter.ofPattern(YYYY-MM-dd).withZone(...)会静默失败另一个常见误区是试图用withZone来“矫正”DateTimeFormatter formatter DateTimeFormatter.ofPattern(YYYY-MM-dd) .withZone(ZoneId.of(Asia/Shanghai)); // 错误 LocalDate.parse(2023-12-31, formatter);DateTimeFormatter的withZone方法只影响Instant、ZonedDateTime等含时区类型的解析。对LocalDate它被完全忽略。这段代码能编译、能运行但withZone毫无作用。JVM不会报错只会默默执行你没想要的逻辑。如何验证在formatter上加断点看withZone返回的新实例其zone字段为null。这是DateTimeFormatter的设计使然LocalDate是“本地”日期不绑定时区。5.3 教训三数据库DATE类型存储的是yyyy但YYYY查询会错乱这是最容易被忽视的“跨层陷阱”。假设你的MySQL表有一个order_date DATE字段存的是2023-12-31。你在MyBatis中写select idselectByWeek resultTypeOrder SELECT * FROM orders WHERE YEARWEEK(order_date, 1) YEARWEEK(#{date}, 1) /selectYEARWEEK(date, 1)在MySQL中mode1表示“周一为一周开始第一周包含该年第一个星期四”这和ISOYYYY完全一致所以如果你传入的#{date}是2023-12-31YEARWEEK会返回2024012024年第1周而数据库里order_date的YEARWEEK也是202401查询能命中。但问题来了如果你在Java层用YYYY解析2023-12-31得到2024-12-31再把这个2024-12-31传给MyBatisYEARWEEK(2024-12-31, 1)返回202501而数据库里2023-12-31的YEARWEEK是202401查询就完全错乱了。解决方案数据库查询一律用DATE函数或YEARMONTH组合避免YEARWEEK。例如-- 安全基于日历年 WHERE YEAR(order_date) #{year} AND WEEKOFYEAR(order_date) #{week} -- 或者更精确计算周一日期 WHERE order_date DATE_SUB(#{date}, INTERVAL WEEKDAY(#{date}) DAY) AND order_date DATE_ADD(DATE_SUB(#{date}, INTERVAL WEEKDAY(#{date}) DAY), INTERVAL 7 DAY)5.4 教训四前端JavaScript的toLocaleDateString也存在同样陷阱你以为把问题都甩给后端就安全了前端同样深坑。JavaScript的Intl.DateTimeFormatconst date new Date(2023-12-31); const formatter new Intl.DateTimeFormat(en-US, { year: numeric, month: 2-digit, day: 2-digit, calendar: iso8601 // 这个calendar选项会启用ISO周语义 }); console.log(formatter.format(date)); // 可能输出 01/01/2024calendar: iso8601会让year字段返回ISO周历年。而大多数前端工程师根本不知道这个选项的存在。结果就是前端显示2024-01-01后端收到2023-12-31双方都认为自己是对的。防御性编码前端所有日期格式化一律显式指定calendar: gregory公历并禁用iso8601// 安全写法 const formatter new Intl.DateTimeFormat(en-US, { year: numeric, month: 2-digit, day: 2-digit, calendar: gregory // 强制使用日历年 });6. 终极检验一份可直接运行的“yyyy/YYYY兼容性测试套件”光说不练假把式。下面是一份完整的JUnit 5测试类它覆盖了所有关键边界日期能100%验证你的系统是否已彻底解决jackson3格式化日期问题。把它加入你的src/test/java每次发版前跑一遍。import org.junit.jupiter.api.Test; import org.junit.jupiter.api.DisplayName; import java.time.LocalDate; import java.time.format.DateTimeFormatter; import java.time.format.DateTimeParseException; import static org.junit.jupiter.api.Assertions.*; class YyyyYyyyCompatibilityTest { // 核心测试验证边界日期的yyyy vs YYYY Test DisplayName(验证2023-12-25至2024-01-07的yyyy/YYYY差异) void testBoundaryDates() { // 这些日期是ISO周历年切换的关键点 String[] boundaryDates { 2023-12-25, // 2023-W52 Monday - YYYY2023 2023-12-31, // 2024-W01 Sunday - YYYY2024 2024-01-01, // 2024-W01 Monday - YYYY2024 2024-01-07, // 2024-W02 Sunday - YYYY2024 2024-12-30, // 2025-W01 Monday - YYYY2025 }; DateTimeFormatter yyyyFormatter DateTimeFormatter.ofPattern(yyyy-MM-dd); DateTimeFormatter YYYYFormatter DateTimeFormatter.ofPattern(YYYY-MM-dd); for (String dateStr : boundaryDates) { LocalDate date LocalDate.parse(dateStr); String yyyyResult date.format(yyyyFormatter); String YYYYResult date.format(YYYYFormatter); System.out.printf(Date: %s - yyyy%s, YYYY%s%n, dateStr, yyyyResult, YYYYResult); // 断言对于2023-12-31yyyy必须是2023YYYY必须是2024 if (2023-12-31.equals(dateStr)) { assertEquals(2023-12-31, yyyyResult); assertEquals(2024-12-31, YYYYResult); // 注意YYYY格式化会生成2024-12-31 } // 断言对于2024-01-01两者应该相同因为它是2024-W01的开始 if (2024-01-01.equals(dateStr)) { assertEquals(2024-01-01, yyyyResult); assertEquals(2024-01-01, YYYYResult); } } } // Jackson反序列化测试 Test DisplayName(Jackson反序列化YYYY模式的安全性测试) void testJacksonDeserialization() throws Exception { ObjectMapper mapper new ObjectMapper(); mapper.registerModule(new JavaTimeModule()); // 测试用YYYY模式解析期望得到正确的LocalDate String json {\date\:\2023-12-31\}; // 注意这里我们故意用YYYY模式看是否被“污染” TestDto dto mapper.readValue(json, TestDto.class); // 关键断言无论模式是YYYY还是yyyyorderDate都应该是2023-12-31 assertEquals(LocalDate.of(2023, 12, 31), dto.getOrderDate()); } // 辅助DTO用于Jackson测试 static class TestDto { JsonFormat(pattern YYYY-MM-dd) // 故意用YYYY private LocalDate orderDate; public LocalDate getOrderDate() { return orderDate; } public void setOrderDate(LocalDate orderDate) { this.orderDate orderDate; } } // 验证WeekFields计算的准确性 Test DisplayName(WeekFields.ISO计算验证) void testWeekFieldsCalculation() { LocalDate date LocalDate.of(2023, 12, 31); int yyyy date.getYear(); // 2023 int YYYY WeekFields.ISO.weekBasedYear().getFrom(date); // 2024 int week WeekFields.ISO.weekOfWeekBasedYear().getFrom(date); // 1 assertEquals(2023, yyyy); assertEquals(2
