面试必问：搞懂什么叫闰年，3行代码搞定原理
上周陪朋友复盘技术面，他卡在一个基础题上：“请手写一个判断闰年的函数。” 他愣了五秒，脑子一片空白。面试官没追问，但他挂了。
别觉得这是小题大做。在 Java、Python、Go 等后端开发中，日期处理是高频场景。很多候选人背住了 if (year % 4 == 0) 就完事了，但一旦面试官追问：“什么叫闰年的底层逻辑是什么？为什么还要除以 100 和 400？” 答不上来，直接暴露基础不牢。
这就是典型的面试必问陷阱：看似简单，实则考察你对边界条件、位运算优化以及业务逻辑严密性的理解。今天不整虚的，咱们从源码级拆解这个问题，把“什么叫闰年”这个知识点吃透。
一、 入口定位：为什么日期判断这么容易翻车
在聊代码之前，先搞清楚业务背景。为什么我们要纠结闰年？
在金融结算、物流排期、甚至游戏服务器时间同步中，日期错误可能导致资金损失或数据错乱。比如，某电商平台的“每月底最后一天”发券逻辑，如果在闰年 2 月写死为 28 号，那 29 号的用户就领不到券，直接引发客诉。
在主流语言的标准库中，日期判断通常封装在 Calendar (Java)、datetime (Python) 或 time (Go) 模块里。但面试很少让你直接调用库函数，而是要求你手写实现。
为什么？因为库函数屏蔽了细节，而手写过程能暴露你的思维盲区。很多初学者以为“能被 4 整除就是闰年”，这是错的。正确的规则是：普通年份能被 4 整除但不能被 100 整除；
世纪年份（能被 100 整除的）必须能被 400 整除。这个规则的由来，与地球公转周期（约 365.2422 天）和历法修正有关。儒略历每年 365.25 天，为了补偿多出的 0.0078 天，每 4 年加一天；但这样每 100 年又会多出约 3 天，所以每 100 年去掉一天；再为了补偿，每 400 年又加回来一天。这就是“四年一闰，百年不闰，四百年再闰”的由来。
二、 核心片段：主流语言的标准实现
我们先看几种主流语言中，判断闰年的核心逻辑。注意，这里展示的是底层判断逻辑，而非直接调用 API。
Java 实现
Java 中 Calendar 类有一个 LEAP_YEAR 常量，但判断逻辑通常在工具类中。以下是基于 JDK 源码思想简化的实现：
public class YearUtils {/*** 判断是否为闰年* 逻辑来源：Java.util.GregorianCalendar 底层实现思想* @param year 年份* @return true-是闰年，false-平年*/public static boolean isLeapYear(int year) {// 1. 能被 4 整除是必要条件，快速排除大部分平年if (year % 4 != 0) {return false;}// 2. 能被 100 整除的，必须进一步检查能否被 400 整除if (year % 100 == 0) {// 世纪年，只有能被 400 整除才是闰年return year % 400 == 0;}// 3. 非世纪年且能被 4 整除，直接是闰年return true;}
}逐行注释解析：year % 4 != 0: 这是第一道过滤网。绝大多数年份（75%）在这里被直接判定为平年，效率最高。
year % 100 == 0: 只有世纪年（如 1900, 2000）才进入这个分支。这里体现了“百年不闰”的规则。
year % 400 == 0: 世纪年的特殊处理。2000 年是闰年，1900 年不是。
return true: 如果没被 100 整除，且被 4 整除，那就是标准的“四年一闰”。Python 实现
Python 的写法更简洁，但逻辑一致。在 datetime 模块的 C 扩展源码中，类似逻辑如下：
def is_leap(year: int) - bool:判断闰年参考：CPython 源码 Modules/_datetimemodule.c 中的 _is_leap 函数逻辑# 位运算优化：year 3 == 0 等价于 year % 4 == 0# 在 C 层面，位运算比取模快，但 Python 层面可读性优先if year % 4 != 0:return Falseif year % 100 == 0:return year % 400 == 0return True关键点：
Python 中 % 运算符性能足够好，通常不需要用位运算 3 替代 % 4，除非在极高性能敏感的底层 C 扩展开发中。但在面试手写时，保持 % 的可读性更佳。
三、 设计思想：为什么是这个逻辑？
很多候选人写代码时，喜欢用嵌套 if-else 或者复杂的布尔表达式，比如：
// 糟糕的写法：可读性差，容易出错
return (year % 4 == 0 year % 100 != 0) || (year % 400 == 0);虽然这个写法逻辑正确，但在面试中，面试官更看重的是分支的清晰度和边界处理。
设计思想核心：短路求值（Short-circuit Evaluation）：Java 中 和 || 具有短路特性。如果第一个条件为假，第二个不执行。上面的“糟糕写法”其实利用了这一点，但逻辑纠缠在一起，难以维护。
分层过滤：将判断过程分为“普通年”和“世纪年”两个层级，符合人类认知习惯，也便于单元测试覆盖。
边界意识：必须考虑到 1900（非闰年）和 2000（闰年）这两个经典反例。如果你的代码把 1900 判成闰年，直接挂掉。在 掘金技术社区 上，很多资深工程师分享过类似案例：某金融系统因未正确处理 1900 年边界，导致历史数据回溯时利息计算错误。虽然现代系统很少处理 1900 年前的数据，但面试中展示你对边界的敏感度，是加分项。
四、 手写简化版：位运算与极致优化
如果在面试中，你想秀一下肌肉，可以引入位运算。对于非负整数，n % 4 == 0 等价于 n 3 == 0。
Java 位运算版本：
public static boolean isLeapBitwise(int year) {// 步骤1: 检查是否能被4整除// year 3 提取最低两位，若为0则能被4整除if ((year 3) != 0) {return false;}// 步骤2: 检查是否是世纪年（能被100整除）// 这里不能用位运算判断100，因为100不是2的幂// 所以必须保留 % 100if (year % 100 == 0) {// 步骤3: 检查是否能被400整除// 400 = 16 * 25，也不是2的幂，无法用纯位运算return year % 400 == 0;}return true;
}注意： 很多人以为所有除法都能用位运算替代，这是误区。只有当除数是 2 的幂（2, 4, 8, 16...）时，才能用移位或按位与替代。100 和 400 都不是，所以只能保留取模运算。
性能对比：
在绝大多数应用场景下，% 运算符的硬件支持非常好，与位运算的性能差距微乎其微。除非你在处理每秒百万次以上的日期判断，否则可读性 微优化。面试时，除非面试官明确要求“请优化性能”，否则优先使用清晰可读的 % 写法。
五、 应用场景与避坑指南
“什么叫闰年”不仅仅是考你逻辑，更考你在真实场景中如何应用。
1. 数据库日期处理
在 MySQL 中，DATE_ADD 函数会自动处理闰年。但如果你在应用层手动计算“下个月第一天”，就需要注意：
import datetimedef next_month_first(year, month):if month == 12:return datetime.date(year + 1, 1, 1)else:return datetime.date(year, month + 1, 1)避坑点： 不要手动计算 day = 28 or 29，让库函数去处理。手动计算极易在闰年 2 月出错。
2. 前端时间库
在 JavaScript 中，new Date(2024, 1, 29) 是合法的（2024 是闰年），但 new Date(2023, 1, 29) 会溢出到 3 月 1 日。
面试高频追问：“如何判断前端传入的日期字符串是否合法？”
答案：不要只检查格式，要检查实际日期是否存在。例如，2023-02-29 格式正确，但日期不存在。3. 时区与闰秒
虽然闰年和闰秒不同，但面试中常混淆。闰年是日历概念，闰秒是原子钟与地球自转的校准。在分布式系统中，NTP 同步时间时，需处理闰秒跳变，但这与闰年判断无关，不要答偏了。
总结与互动
搞懂什么叫闰年，本质上是搞懂边界条件处理和业务规则映射。基础层：掌握 4, 100, 400 的规则。
进阶层：理解为什么需要这三层过滤（历法修正背景）。
实战层：在代码中优先使用标准库，手写时注意边界测试（1900, 2000, 2024）。面试中被问到这个问题，不要只给代码，要说出：“我考虑了世纪年的特殊情况，比如 1900 年不是闰年，2000 年是闰年，我的代码通过了这两个边界测试。” 这句话的含金量，比代码本身更高。
最后抛个问题给大家：在你们的项目中，有没有遇到过因为日期处理导致的 Bug？你更常用哪种写法？是依赖标准库，还是自己封装工具类？评论区交流，看看谁踩过的坑最多。
