闰年判断必须用“(year % 4 == 0 && year % 100 != 0) || year % 400 == 0”，单用%4会误判1900、2100等整百年；高频场景用数学表达式，低频可用LocalDate.isLeapYear()；测试须覆盖1900、2000、2100。
闰年判断的数学规则必须先写对
直接说结论：Java里判断闰年不能只看 % 4 == 0，否则2100、1900这类整百年都会错判为闰年。核心规则是「能被4整除但不能被100整除，或者能被400整除」——这不是口诀，是必须严格落地的布尔逻辑。
常见错误现象：year % 4 == 0 单独使用，导致1900年返回 true（实际不是闰年）；或用 &&/|| 搞反优先级，加不加括号结果天差地别。
- 务必用括号明确逻辑分组：
(year % 4 == 0 && year % 100 != 0) || (year % 400 == 0) - 避免写成
year % 4 == 0 || year % 400 == 0 && year % 100 != 0—— 运算符优先级会让它等价于year % 4 == 0 || (year % 400 == 0 && year % 100 != 0)，漏掉「被100整除但不被400整除」的排除逻辑 - 注意
year是int类型即可，不需要long或包装类，避免空指针或自动拆箱异常
用 LocalDate 判断更安全但有隐藏成本
Java 8+ 推荐用 LocalDate 的 isLeapYear() 方法，它内部已封装正确逻辑，且自动处理负数年份（公元前）、超大年份等边界情况。
但要注意：这个方法创建了临时对象，如果在高频循环中反复调用（比如批量校验10万条日期），会带来可测量的GC压力和性能损耗。
立即学习“Java免费学习笔记（深入）”；
- 高频场景（如金融系统日历计算）优先用纯数学表达式：
(year % 4 == 0 && year % 100 != 0) || year % 400 == 0 - 业务逻辑简单、调用频次低（比如用户输入单个年份校验），直接用
LocalDate.of(year, 1, 1).isLeapYear() - 别用
Calendar—— 它的getActualMaximum(Calendar.DAY_OF_YEAR)返回366才认为是闰年，既慢又绕，还可能因时区/本地化出偏差
测试时容易漏掉的三个关键年份
光测2000、2004、2024这种「看起来像闰年」的年份不够，必须覆盖规则里的所有分支断点。否则上线后遇到1900年，财务报表日期就全偏一天。
-
1900：能被4和100整除，但不能被400整除 → 必须返回false -
2000：能被4、100、400整除 → 必须返回true -
2100：同1900，是下一个典型失败案例 → 必须返回false
建议在单元测试里显式写出这三个用例，而不是靠随机数据覆盖。
别在字符串年份上直接取模
如果输入是 String yearStr = "2024"，别手快写 yearStr % 4 —— Java不支持字符串取模，编译直接报错 bad operand types for binary operator '%'。
常见错误路径：先用 Integer.parseInt() 转换，但没包 try-catch，遇到空串或非数字就崩；或用 Integer.valueOf() 忘了它可能抛 NumberFormatException。
- 稳妥做法：
int year = Integer.parseInt(yearStr.trim())，并确保上游已校验非空和数字格式 - 如果输入不可信，用
Optional.ofNullable(yearStr).map(s -> s.trim()).filter(s -> s.matches("\d+")).map(Integer::parseInt)更健壮 - 千万别用
yearStr.charAt(3) == '4'这类魔数判断——2024是闰年，2124也是，但2224不是
闰年逻辑本身很简单，但年份来源、类型转换、边界年份覆盖这三块，才是线上出问题最多的地方。
