避开Java日期格式化陷阱：`yyyy`与`YYYY`的正确使用

问题背景

处理Java日期时，yyyy和YYYY的混用是一个极易被忽略的严重问题。这两种格式在大部分时间里输出结果一致，导致常规测试很难发现异常。但在每年交替的那一周，使用YYYY会造成年份计算偏移，产生严重的数据错误，尤其在金融、订单和日志系统中，后果可能非常严重。

这篇文章会直接讲清楚两者的区别、问题如何发生，以及如何规避。

核心定义：yyyy (日历年) vs. YYYY (周年)

首先要明确，这是两种完全不同的年份体系。

yyyy (小写) 代表日历年 (Calendar Year)。这就是我们日常使用的公历年，时间范围严格从1月1日到12月31日。在所有常规业务场景下，这都是你应该默认使用的格式。

YYYY (大写) 代表周年 (Week-Based Year)。它基于ISO 8601标准，根据“周”来定义年份。它的核心规则是：如果某一周包含了当年第一个星期四，那这一整周都属于该年。这种格式主要用于某些需要按完整周进行统计的财会或行业系统，通用性极低。

问题复现：年底与年初的年份偏移

这个问题的具体表现，我们直接看年底的例子。比如 2024-12-31 这一天，它本身是星期二，所在的完整一周是从 2024-12-30 (周一) 持续到 2025-01-05 (周日)。按照 YYYY 的规则，它需要判断这一周是否包含了 2025 年的第一个星期四。查一下日历，2025-01-02 就是星期四，正好在这一周内。因此，YYYY 会判定这一整周都属于 2025 年。最终导致的结果就是，当你格式化 2024-12-31 时，得到的年份是错误的 2025。

同样的问题在年初也会发生。比如 2026-01-01 是星期五，它所在的周是从 2025-12-29 到 2026-01-04。而 2026 年的第一个星期四是 1月8日，并不在这一周内。所以，YYYY 会认为这一周仍然属于 2025 年。此时去格式化 2026-01-01，就会得到错误的年份 2025。

结论与开发规范

因为 YYYY 的行为不符合绝大多数业务的直观认知，并且风险隐蔽性高，正确的做法是在团队内建立明确的规范：在所有通用业务场景下，必须只使用小写的 yyyy。

大写的 YYYY 应该被视为一个特殊工具，除非有经过严格评审、明确需要基于“周”进行统计的特殊业务，否则应当禁用。在代码审查时，也应该将日期格式化字符串作为一个常规检查点，从流程上杜绝这种风险。能否注意到这个细节，直接体现了工程师对数据准确性的责任心，在处理核心业务数据时，任何偏差都应被彻底杜绝。