如果你写过日期相关的业务代码大概率曾被判断闰年这个看似人畜无害的需求坑过。别笑我在某次处理跨年结算数据时就因为闰年条件写反导致2月的最后一天被吞掉上游对账差了一整天。事后复盘发现团队里每个人心里闰年规则的版本都不太一样。今天这篇就把C里判断闰年这件事彻底讲清楚从历法规则到代码写法从边界测试到工程封装再到批量统计和常见错误复盘让你在任意场景下都能写出不出错的版本。无论你是刚学C的初学者还是需要在生产环境里处理日期的老手都可以从中找到直接能用的方法。1. 闰年规则里容易踩的认知误区百年不闰与四百年再闰1.1 完整判定条件是怎么推导出来的很多人只记得四年一闰却不知道这只是被简化的口诀。公历格里高利历的一个回归年大约是365天5小时48分46秒换算成小数约365.2422天。如果每年都按365天算每过4年就会多出将近一天所以四年一闰是第一次修正让平均年长变成365.25天。问题是365.25仍然比真实值偏大大约每128年会多出一天于是还需要逢百不闰的第二次修正把能被100整除的年份从闰年里剔除。可这样又修正过头了一点平均年长变成365.24天于是再补一个逢四百再闰把能被400整除的年份重新算作闰年。三层修正下来平均年长约365.2425天已经非常接近真实回归年。这个推导过程解释了为什么规则不是一句四年一闰就能写完的每引入一层修正都是为了对齐真实的天文周期。你不需要背下365.2422这个数字但至少要理解能被4整除和能被100整除不是简单的叠加关系而是先加一层、再扣一层、最后又补一层的三步操作。理解到这一层写代码时就不容易把条件记成year % 4 0或year % 100 ! 0这种残缺版本。1.2 正确规则与典型年份对照最终规则可以精简为三句话能被4整除且不能被100整除的年份是闰年能被400整除的年份也是闰年其余年份都不是。写成逻辑表达式就是year % 4 0 (year % 100 ! 0 || year % 400 0)。注意我特意加了括号虽然的优先级本来就高于||但括号能让读代码的人第一眼就看到四年一闰和百年不闰是捆绑在一起的条件避免误读。年份能被4整除能被100整除能被400整除结论1900是是否平年2000是是是闰年2024是否否闰年2100是是否平年2400是是是闰年这张表把最容易出错的组合都列出来了1900和2100能被4整除也能被100整除但就是不能被400整除所以都是平年2000和2400则因为能被400整除反而重新成为闰年。很多人在日常年份里写不出问题一碰到整百年份就翻车原因就是只在四年一闰层面理解没把百年不闰和四百年再闰落进条件里。1.3 一个容易混淆的概念公历闰年 vs 农历闰月还有一个概念上的坑值得单独说判断闰年的默认语境是公历格里高利历。农历里也有闰月年但那种闰年和公历的闰年没有数学上的对应关系不能拿year % 4去套。初学者在搜索资料时偶尔会看到闰年有闰月这类说法进而产生混淆其实不用纠结业务代码里提到判断闰年几乎都是指公历的2月多一天这件事。2. 多种C实现写法的取舍从一行表达式到标准库2.1 最经典的一行表达式bool isLeapYear(int year) { return (year % 4 0 year % 100 ! 0) || year % 400 0; }这是最标准的教科书写法。%是取余运算符year % 4 0表示 year 能被4整除。代码把规则直接翻译成了逻辑运算前半个括号覆盖四年一闰且百年不闰后半个year % 400 0覆盖四百年再闰。这行代码简洁、可读性好也是绝大多数项目里的默认实现。它隐含了一个前提year 是正整数如果外部输入是负数或者超出合理范围这个版本不会做任何保护。2.2 防御式写法先校验再判断bool isLeapYear(int year) { if (year 1 || year 9999) { return false; } if (year % 400 0) return true; if (year % 100 0) return false; if (year % 4 0) return true; return false; }这段代码和一行表达式在核心判定上完全等价但多做了两件事第一对年份范围做了前置校验不在合法区间时直接返回 false避免把异常数据继续往下传第二把判断拆成三个独立条件逻辑链是先看400、再看100、最后看4每一步都很直白。它的可读性更好也更方便后续扩展比如想对非法年份抛异常或记录日志不用动主体判断。代价是多写了几行但对于工程代码来说非常划算。2.3 C20标准库一行调用 is_leap()如果你的项目可以用C20chrono标准库已经为年份封装了闰年判断直接调is_leap()就行。#include chrono bool isLeapYear(int y) { using namespace std::chrono; return year{y}.is_leap(); }这个版本最大的优点是省心标准库内部实现经过了充分验证基本不存在自己写错的可能性。缺点是它要求编译器支持C20很多老项目、嵌入式环境或兼容性要求高的地方不一定能用。我的建议是能上C20的项目直接用它不能上的就用手写版本没必要为了这一个函数强行切换编译标准。2.4 算法题场景的短写法与查表思想在面试或在线评测场景里最常见的是一行表达式版本因为短、快、不易出错。有些人也会写得更紧凑比如用三目运算符嵌套但我个人不推荐可读性会明显下降。查表法用得很少针对单个年份判断一次取余运算的成本低到可以忽略提前把一百年的结果算好存进数组反而浪费初始化时间和内存。只有在某种极端批量场景下比如对固定区间年份做千万次重复查询才值得把结果预生成成一个bitset或bool数组。2.5 写法对比与选型建议把常见写法放在一张表里看写法代码量可读性健壮性依赖一行表达式1行中中无防御式6行左右高高无C20 chrono1行高高C20查表较多低高自定义逻辑选型时我的排序是算法题用一行表达式业务工具函数用防御式新项目且编译环境允许时优先C20标准库。查表法一般不考虑除非能先证明自己确实遇到了热点。另一个容易被忽略的点是命名建议用isLeapYear或isLeap这类以is开头的动词不要叫judgeYear或checkYear这种语义模糊的名字团队协作时一眼能看出意图很重要。2.6 constexpr把判断挪到编译期如果希望某些年份的闰年判断在编译期就完成可以把函数标记为constexprconstexpr bool isLeapYear(int year) { return (year % 4 0 year % 100 ! 0) || year % 400 0; }C11标准下constexpr函数体里允许写一条return配合这个版本已经够用C14之后更宽松支持更多语句。加上constexpr后你就可以在代码里写constexpr bool leap isLeapYear(2024);也能配合static_assert做编译期测试。这个特性最实用的地方是下一节会看到的测试代码以及需要预生成常量表的场景。3. 用测试矩阵逼出边界问题手工用例与系统级交叉验证3.1 关键边界年份与静态断言判断闰年的代码很短但恰恰因为短很多人写完就不测了。我建议至少对下面这几个年份做断言2024普通闰年、2025普通平年、1900整除100但不整除400、2000整除400、2100整除100但不整除400、2400整除400。#include cassert #include iostream constexpr bool isLeapYear(int year) { return (year % 4 0 year % 100 ! 0) || year % 400 0; } int main() { static_assert(isLeapYear(2024), 2024 should be leap); static_assert(!isLeapYear(2025), 2025 should not be leap); static_assert(!isLeapYear(1900), 1900 should not be leap); static_assert(isLeapYear(2000), 2000 should be leap); static_assert(!isLeapYear(2100), 2100 should not be leap); static_assert(isLeapYear(2400), 2400 should be leap); std::cout all boundary assertions passed. std::endl; return 0; }这里用static_assert而不是运行时assert好处是断言在编译期完成条件不满足时编译直接失败问题暴露得越早越好。如果编译器对constexpr支持不好或者你还没掌握constexpr也可以用assert(isLeapYear(2024));放在 main 函数开头效果类似只是发生在运行阶段。特别提醒一个测试误区别只挑能被4整除的年份。正确代码和残缺代码只判断year % 4 0在2024、2028这些年份上结果完全一样只有1900、2100这样的整百平年才能把错误实现暴露出来。我见过不少人的测试用例全是普通年份跑得全绿结果一到生产环境遇到整百年就翻车。3.2 用 mktime 反推二月天数做交叉验证为了验证自己写的规则和系统认知一致我偶尔会用mktime做独立对拍。mktime会根据tm结构体中的字段自动归一化日期利用这个特性可以反推某年二月的最后一天是28还是29#include ctime #include iostream bool isLeapYearByMktime(int year) { std::tm t{}; t.tm_year year - 1900; t.tm_mon 2; // 三月 t.tm_mday 0; // 第0天等价于二月最后一天 std::mktime(t); return t.tm_mday 29; } int main() { for (int y 2000; y 2030; y) { bool a isLeapYear(y); bool b isLeapYearByMktime(y); if (a ! b) { std::cout mismatch at y std::endl; } } std::cout cross-check finished. std::endl; return 0; }这里的技巧是tm_mday设为0它表示上个月的最后一天把tm_mon设成2三月0号自然就对应二月的最后一天。mktime会把日期规范化所以无论你传什么都行它都会算出正确的tm_mday。如果手写规则和系统函数结果不一致大概率是规则写错了。这个方法也有局限它依赖运行环境的日历实现和时区对很老的年份或极端年份不一定可靠所以更适合当作交叉验证工具而不是业务代码里的常规判断方式。3.3 全区间统计400年97个闰年的数学锚点比手工选点更狠的测试方式是直接扫一个长区间然后用数学规律验证总数。公历历法有一个固定周期每400年恰好有97个闰年。这是由规则本身的组合结构决定的也是验证规则是否写对的天然锚点。int countLeapYearsInRange(int start, int end) { int cnt 0; for (int y start; y end; y) { if (isLeapYear(y)) cnt; } return cnt; } int main() { int cnt countLeapYearsInRange(1, 400); std::cout leap years in [1,400] cnt std::endl; if (cnt ! 97) { std::cout rule is wrong! std::endl; } return 0; }如果输出不是97说明规则里有条件写反了。比如把year % 100 ! 0误写成year % 100 0这种错误在单点用例里往往发现不了但在400年统计下一目了然。顺便说一句[1,800] 区间应该是194个[1,1200] 是291个400的倍数年份区间都按这个规律递增。3.4 什么样的测试才算真正覆盖到位判断闰年是一个典型的逻辑简单但边界敏感的函数。我的固定做法是四层测试第一层六个关键边界点用static_assert编译期锁定第二层用mktime对 2000 到 2030 年做交叉对拍第三层用400年97个闰年的规律做区间统计第四层用上一节的二进制条件把已知年份全部跑一遍。这四层做完函数出错的概率已经很低了。另外测试不能只在本地过一遍。碰到跨平台项目我还会在 Windows、Linux 和 macOS 各跑一次因为mktime的底层日历行为在不同平台上可能有细微差别。如果你的最终判断完全不用mktime平台差异的影响其实不大但跑一遍测试总归更安心尤其当项目要交付给不同环境的用户时。测试成本很低收获的确定性却很高。判断闰年虽小但它往往嵌在日期计算链的最底层一旦出错上层所有依赖它的数据都会跟着错所以多花十分钟做交叉验证不算浪费。4. 工程化落地从单个判断到日期工具链4.1 搭配二月天数封装 daysInMonth判断闰年本身只是返回一个布尔值但在业务代码里它最常被用来计算某个月有多少天。所以我会把它和daysInMonth放在一起封装int daysInMonth(int year, int month) { static const int days[] {31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31}; if (month 1 || month 12) { return -1; } if (month 2 isLeapYear(year)) { return 29; } return days[month - 1]; }这里用static const数组保存每个月的基础天数可读性比一连串 if 好得多。只有2月需要根据闰年结果单独处理普通年份返回28闰年返回29。注意月份合法性检查要放在数组下标访问之前否则month为13或0时会发生越界访问这是初学C最容易踩的未定义行为。这个函数的返回值设计采用了 -1 表示非法月份。你也可以改成返回 0 或者抛异常但团队里最好统一约定。我个人倾向于返回 -1因为调用方很容易用if (daysInMonth(...) 0)做判断语义也清楚。如果你喜欢C的异常机制也可以对非法参数抛出std::invalid_argument但那样会让使用者被迫写 try-catch在普通工具函数里显得有些重。做一个简单约定并写进注释往往比引入异常更实用。4.2 日期合法性校验一层层往上垒有了闰年判断和每月天数就能往上垒一个完整的日期校验器bool isValidDate(int year, int month, int day) { if (year 1 || year 9999) { return false; } int maxDay daysInMonth(year, month); if (maxDay -1) { return false; } return day 1 day maxDay; }这个函数的逻辑依赖底层两个函数都正确先判断年份范围再通过daysInMonth拿到当月天数最后检查天是否落在合法区间。看似简单但它能处理所有月份和闰年组合包括2月29日在闰年合法、在平年非法这类场景。把底层函数测试扎实了上层就不需要重复写大量的 if 分支这是工程上自底向上的典型思路。4.3 避免重复实现集中管理日期工具团队项目里有个我见过无数次的坏味道每个模块都自己写一份闰年判断。A同学记得一句口诀写了year % 4 0B同学从网上抄了个带100和400修正的版本C同学从老项目里复制了一段带额外判断的代码。结果同一个系统里不同模块对1900年的结论不一样最后表现在用户端就是日期错乱、对账失败。解决办法很简单把isLeapYear、daysInMonth、isValidDate集中放在一个工具文件里用同一套测试保护所有业务代码统一 include。就算只是个人项目也建议把日期相关函数独立成模块而不是散落在每个调用处。如果项目里有代码审查流程我会把全项目不得出现第二份闰年判断实现写进约定里。这样的约束听起来有点小题大做但日期bug往往就是在这种重复实现里悄悄繁殖的。控制住入口比事后追查省心得多。另外把日期工具放进独立模块后后续想升级底层实现也容易比如从手写规则换成C20标准库只需要改一个文件跑同一套测试其他模块完全无感。这带来的长期收益远超过多建一个文件的那点成本。4.4 编译期数组与常量场景上一节提到的constexpr在这里还有一层用处预生成只读的闰年标志数组。比如你知道业务只关心2024到2030这7年就可以在编译期把标志填好constexpr bool leapFlags[] { isLeapYear(2024), isLeapYear(2025), isLeapYear(2026), isLeapYear(2027), isLeapYear(2028), isLeapYear(2029), isLeapYear(2030) };这段代码在编译期就完成所有计算数组进入只读存储区运行时不再需要任何取余运算。对普通业务程序意义不大但在嵌入式或对性能苛刻的场景里这种编译期常量化是很实用的思路。如果年份区间在编译期就能确定直接用constexpr数组甚至现代C的std::array都能让代码更安全。5. 批量场景的O(1)统计与常见错误复盘5.1 统计区间闰年数数论公式代替循环如果只是判断单个年份isLeapYear就够了。但业务里偶尔会需要统计某个区间内一共有多少个闰年比如计费系统按天算钱时想预估跨年区间的天数或者做数据报表时想按闰年平均分摊。逐个循环当然可以但有一个更优美的数学写法小于等于 n 的闰年数量等于n/4 - n/100 n/400这里的除法全部是整数除法。int countLeapYearsUpTo(int n) { return n / 4 - n / 100 n / 400; } int countLeapYearsInRange(int start, int end) { if (start end) return 0; return countLeapYearsUpTo(end) - countLeapYearsUpTo(start - 1); }为什么这个公式成立因为能被4整除的年份先全部算进来再把其中能被100整除的扣掉最后把扣多了的、能被400整除的年份加回来。整个公式恰好复刻了闰年规则的三层修正。举例来说countLeapYearsUpTo(400)等于 97countLeapYearsUpTo(800)等于 194和前面测试一节提到的数学锚点完全吻合。这个O(1)函数在极端情况下还能计算区间内闰日的数量比如某段时间跨过了2月29日按日计费的总天数就要多算一天。用这个函数预先算出闰日个数可以让金额估算更精确不需要真的逐年遍历。当然实际计费系统要考虑时区、起止时刻、自然日还是工作日等多种因素闰日只是其中一块拼图。但至少你会发现一个看似不起眼的闰年判断往上可以支撑出很多业务逻辑。5.2 常见错误一只记得四年一闰新手的头号错误是只写year % 4 0。在2024、2028这类年份上这个条件完全正确所以局部测试很难发现问题。一旦遇到1900错误就暴露了1900能被4整除但不是闰年。如果项目里还有一份正确的实现两个模块算出来的2月天数就会不一样。这种不一致最坑人因为它不报错只是结果悄悄出现分歧。修正方式只有一句话把百年不闰、四百年再闰一起写进条件。哪怕你暂时不理解历法推导先把完整表达式背下来用也比残缺版强得多。我建议不要直接抄网上代码而是自己在编辑器里默写几遍把它变成条件反射这样面试和写项目时都不容易出错。5.3 常见错误二用浮点数处理整除第二种常见错误是试图用浮点运算判断整除比如写if (year / 4.0 0)。这行代码有两个问题第一year / 4.0在 year 为正整数时几乎不可能等于0逻辑本身就错第二浮点数在计算机里是近似表示做除法后比较相等容易遇到精度陷阱。还有人写if (year % 4.0 0)这在C里直接编译不过因为%要求两个操作数都是整型。正确的做法永远是整数取余year % 4 0。取余的结果对正整数是精确的没有任何精度损失。5.4 常见错误三条件杂糅与维护性陷阱第三种错误是把逻辑条件写成year % 400 0 || year % 100 ! 0 year % 4 0。这个表达式在数学上可能等价于完整规则但对阅读者来说非常不友好尤其当后续有人想改逻辑时很容易误解成能被400整除或不能被100整除。我见过有人费了半天劲去推演运算符优先级就为了验证这行代码对不对。正确做法是坚持(year % 4 0 year % 100 ! 0) || year % 400 0这种教科书形态用括号把一组条件显式圈起来维护成本会低很多。5.5 负年份与公元前纪年的边界还有一个经常在历史数据处理里冒出来的问题年份为负数怎么办从数学上说闰年规则对负数没有直接定义因为整除语义与公历纪年的历史断代并不吻合。比如公元前1年在天文纪年法里对应年份0而有些库又把公元前100年表示成 -99混乱就在所难免。我在实际处理这类数据时更倾向于在业务入口处做限制只接受1年及以后的公历年份遇到负数一律返回 false 或直接报错。底层的isLeapYear不应该替调用方背历史纪年映射这个锅。5.6 性能优化先看调用模式再看单次运算最后聊聊性能。单次闰年判断只是两三次整数取余在普通CPU上是纳秒级操作完全不需要优化。如果有人劝你用位运算或者查表来加速先问自己这个函数真的被调用了上亿次吗如果是还要看年份是否变化。我在一个统计服务里见过这样的代码遍历上千万条记录时每条都调用isLeapYear(year)但年份根本就是同一个值。把这次调用提到循环外只计算一次整体耗时立刻降了接近一半。这才是真正的性能问题不是取余太慢而是重复计算太多。所以性能优化有个朴素原则先消除重复计算再考虑指令级优化。判断闰年这么简单的函数尤其适合这个原则。如果确实需要在高频循环里对不同年份做判断那一行表达式版本已经足够快不用再折腾别的花活。毕竟让代码停留在好读、正确、稳定的状态往往比把它压榨到极致更符合绝大多数业务场景的收益。写到这里想起我第一次写闰年判断的场景当时只记得四年一闰自信满满地写了year % 4 0直到某次跑批数据在1900年附近对不上账才老老实实把历法规则补全。从那以后我的习惯是先列边界用例再写实现先想清楚调用场景再定封装层级。判断闰年这件事本身不难难的是在真实项目里用对、测稳。如果你也正被日期相关的小问题困扰希望这篇能帮你少走几步弯路。 
长河君 · 2026/10/19 5:09:31 · 阅读 1.2k C++闰年判断全指南：规则、实现与边界测试
如果你写过日期相关的业务代码大概率曾被判断闰年这个看似人畜无害的需求坑过。别笑我在某次处理跨年结算数据时就因为闰年条件写反导致2月的最后一天被吞掉上游对账差了一整天。事后复盘发现团队里每个人心里闰年规则的版本都不太一样。今天这篇就把C里判断闰年这件事彻底讲清楚从历法规则到代码写法从边界测试到工程封装再到批量统计和常见错误复盘让你在任意场景下都能写出不出错的版本。无论你是刚学C的初学者还是需要在生产环境里处理日期的老手都可以从中找到直接能用的方法。1. 闰年规则里容易踩的认知误区百年不闰与四百年再闰1.1 完整判定条件是怎么推导出来的很多人只记得四年一闰却不知道这只是被简化的口诀。公历格里高利历的一个回归年大约是365天5小时48分46秒换算成小数约365.2422天。如果每年都按365天算每过4年就会多出将近一天所以四年一闰是第一次修正让平均年长变成365.25天。问题是365.25仍然比真实值偏大大约每128年会多出一天于是还需要逢百不闰的第二次修正把能被100整除的年份从闰年里剔除。可这样又修正过头了一点平均年长变成365.24天于是再补一个逢四百再闰把能被400整除的年份重新算作闰年。三层修正下来平均年长约365.2425天已经非常接近真实回归年。这个推导过程解释了为什么规则不是一句四年一闰就能写完的每引入一层修正都是为了对齐真实的天文周期。你不需要背下365.2422这个数字但至少要理解能被4整除和能被100整除不是简单的叠加关系而是先加一层、再扣一层、最后又补一层的三步操作。理解到这一层写代码时就不容易把条件记成year % 4 0或year % 100 ! 0这种残缺版本。1.2 正确规则与典型年份对照最终规则可以精简为三句话能被4整除且不能被100整除的年份是闰年能被400整除的年份也是闰年其余年份都不是。写成逻辑表达式就是year % 4 0 (year % 100 ! 0 || year % 400 0)。注意我特意加了括号虽然的优先级本来就高于||但括号能让读代码的人第一眼就看到四年一闰和百年不闰是捆绑在一起的条件避免误读。年份能被4整除能被100整除能被400整除结论1900是是否平年2000是是是闰年2024是否否闰年2100是是否平年2400是是是闰年这张表把最容易出错的组合都列出来了1900和2100能被4整除也能被100整除但就是不能被400整除所以都是平年2000和2400则因为能被400整除反而重新成为闰年。很多人在日常年份里写不出问题一碰到整百年份就翻车原因就是只在四年一闰层面理解没把百年不闰和四百年再闰落进条件里。1.3 一个容易混淆的概念公历闰年 vs 农历闰月还有一个概念上的坑值得单独说判断闰年的默认语境是公历格里高利历。农历里也有闰月年但那种闰年和公历的闰年没有数学上的对应关系不能拿year % 4去套。初学者在搜索资料时偶尔会看到闰年有闰月这类说法进而产生混淆其实不用纠结业务代码里提到判断闰年几乎都是指公历的2月多一天这件事。2. 多种C实现写法的取舍从一行表达式到标准库2.1 最经典的一行表达式bool isLeapYear(int year) { return (year % 4 0 year % 100 ! 0) || year % 400 0; }这是最标准的教科书写法。%是取余运算符year % 4 0表示 year 能被4整除。代码把规则直接翻译成了逻辑运算前半个括号覆盖四年一闰且百年不闰后半个year % 400 0覆盖四百年再闰。这行代码简洁、可读性好也是绝大多数项目里的默认实现。它隐含了一个前提year 是正整数如果外部输入是负数或者超出合理范围这个版本不会做任何保护。2.2 防御式写法先校验再判断bool isLeapYear(int year) { if (year 1 || year 9999) { return false; } if (year % 400 0) return true; if (year % 100 0) return false; if (year % 4 0) return true; return false; }这段代码和一行表达式在核心判定上完全等价但多做了两件事第一对年份范围做了前置校验不在合法区间时直接返回 false避免把异常数据继续往下传第二把判断拆成三个独立条件逻辑链是先看400、再看100、最后看4每一步都很直白。它的可读性更好也更方便后续扩展比如想对非法年份抛异常或记录日志不用动主体判断。代价是多写了几行但对于工程代码来说非常划算。2.3 C20标准库一行调用 is_leap()如果你的项目可以用C20chrono标准库已经为年份封装了闰年判断直接调is_leap()就行。#include chrono bool isLeapYear(int y) { using namespace std::chrono; return year{y}.is_leap(); }这个版本最大的优点是省心标准库内部实现经过了充分验证基本不存在自己写错的可能性。缺点是它要求编译器支持C20很多老项目、嵌入式环境或兼容性要求高的地方不一定能用。我的建议是能上C20的项目直接用它不能上的就用手写版本没必要为了这一个函数强行切换编译标准。2.4 算法题场景的短写法与查表思想在面试或在线评测场景里最常见的是一行表达式版本因为短、快、不易出错。有些人也会写得更紧凑比如用三目运算符嵌套但我个人不推荐可读性会明显下降。查表法用得很少针对单个年份判断一次取余运算的成本低到可以忽略提前把一百年的结果算好存进数组反而浪费初始化时间和内存。只有在某种极端批量场景下比如对固定区间年份做千万次重复查询才值得把结果预生成成一个bitset或bool数组。2.5 写法对比与选型建议把常见写法放在一张表里看写法代码量可读性健壮性依赖一行表达式1行中中无防御式6行左右高高无C20 chrono1行高高C20查表较多低高自定义逻辑选型时我的排序是算法题用一行表达式业务工具函数用防御式新项目且编译环境允许时优先C20标准库。查表法一般不考虑除非能先证明自己确实遇到了热点。另一个容易被忽略的点是命名建议用isLeapYear或isLeap这类以is开头的动词不要叫judgeYear或checkYear这种语义模糊的名字团队协作时一眼能看出意图很重要。2.6 constexpr把判断挪到编译期如果希望某些年份的闰年判断在编译期就完成可以把函数标记为constexprconstexpr bool isLeapYear(int year) { return (year % 4 0 year % 100 ! 0) || year % 400 0; }C11标准下constexpr函数体里允许写一条return配合这个版本已经够用C14之后更宽松支持更多语句。加上constexpr后你就可以在代码里写constexpr bool leap isLeapYear(2024);也能配合static_assert做编译期测试。这个特性最实用的地方是下一节会看到的测试代码以及需要预生成常量表的场景。3. 用测试矩阵逼出边界问题手工用例与系统级交叉验证3.1 关键边界年份与静态断言判断闰年的代码很短但恰恰因为短很多人写完就不测了。我建议至少对下面这几个年份做断言2024普通闰年、2025普通平年、1900整除100但不整除400、2000整除400、2100整除100但不整除400、2400整除400。#include cassert #include iostream constexpr bool isLeapYear(int year) { return (year % 4 0 year % 100 ! 0) || year % 400 0; } int main() { static_assert(isLeapYear(2024), 2024 should be leap); static_assert(!isLeapYear(2025), 2025 should not be leap); static_assert(!isLeapYear(1900), 1900 should not be leap); static_assert(isLeapYear(2000), 2000 should be leap); static_assert(!isLeapYear(2100), 2100 should not be leap); static_assert(isLeapYear(2400), 2400 should be leap); std::cout all boundary assertions passed. std::endl; return 0; }这里用static_assert而不是运行时assert好处是断言在编译期完成条件不满足时编译直接失败问题暴露得越早越好。如果编译器对constexpr支持不好或者你还没掌握constexpr也可以用assert(isLeapYear(2024));放在 main 函数开头效果类似只是发生在运行阶段。特别提醒一个测试误区别只挑能被4整除的年份。正确代码和残缺代码只判断year % 4 0在2024、2028这些年份上结果完全一样只有1900、2100这样的整百平年才能把错误实现暴露出来。我见过不少人的测试用例全是普通年份跑得全绿结果一到生产环境遇到整百年就翻车。3.2 用 mktime 反推二月天数做交叉验证为了验证自己写的规则和系统认知一致我偶尔会用mktime做独立对拍。mktime会根据tm结构体中的字段自动归一化日期利用这个特性可以反推某年二月的最后一天是28还是29#include ctime #include iostream bool isLeapYearByMktime(int year) { std::tm t{}; t.tm_year year - 1900; t.tm_mon 2; // 三月 t.tm_mday 0; // 第0天等价于二月最后一天 std::mktime(t); return t.tm_mday 29; } int main() { for (int y 2000; y 2030; y) { bool a isLeapYear(y); bool b isLeapYearByMktime(y); if (a ! b) { std::cout mismatch at y std::endl; } } std::cout cross-check finished. std::endl; return 0; }这里的技巧是tm_mday设为0它表示上个月的最后一天把tm_mon设成2三月0号自然就对应二月的最后一天。mktime会把日期规范化所以无论你传什么都行它都会算出正确的tm_mday。如果手写规则和系统函数结果不一致大概率是规则写错了。这个方法也有局限它依赖运行环境的日历实现和时区对很老的年份或极端年份不一定可靠所以更适合当作交叉验证工具而不是业务代码里的常规判断方式。3.3 全区间统计400年97个闰年的数学锚点比手工选点更狠的测试方式是直接扫一个长区间然后用数学规律验证总数。公历历法有一个固定周期每400年恰好有97个闰年。这是由规则本身的组合结构决定的也是验证规则是否写对的天然锚点。int countLeapYearsInRange(int start, int end) { int cnt 0; for (int y start; y end; y) { if (isLeapYear(y)) cnt; } return cnt; } int main() { int cnt countLeapYearsInRange(1, 400); std::cout leap years in [1,400] cnt std::endl; if (cnt ! 97) { std::cout rule is wrong! std::endl; } return 0; }如果输出不是97说明规则里有条件写反了。比如把year % 100 ! 0误写成year % 100 0这种错误在单点用例里往往发现不了但在400年统计下一目了然。顺便说一句[1,800] 区间应该是194个[1,1200] 是291个400的倍数年份区间都按这个规律递增。3.4 什么样的测试才算真正覆盖到位判断闰年是一个典型的逻辑简单但边界敏感的函数。我的固定做法是四层测试第一层六个关键边界点用static_assert编译期锁定第二层用mktime对 2000 到 2030 年做交叉对拍第三层用400年97个闰年的规律做区间统计第四层用上一节的二进制条件把已知年份全部跑一遍。这四层做完函数出错的概率已经很低了。另外测试不能只在本地过一遍。碰到跨平台项目我还会在 Windows、Linux 和 macOS 各跑一次因为mktime的底层日历行为在不同平台上可能有细微差别。如果你的最终判断完全不用mktime平台差异的影响其实不大但跑一遍测试总归更安心尤其当项目要交付给不同环境的用户时。测试成本很低收获的确定性却很高。判断闰年虽小但它往往嵌在日期计算链的最底层一旦出错上层所有依赖它的数据都会跟着错所以多花十分钟做交叉验证不算浪费。4. 工程化落地从单个判断到日期工具链4.1 搭配二月天数封装 daysInMonth判断闰年本身只是返回一个布尔值但在业务代码里它最常被用来计算某个月有多少天。所以我会把它和daysInMonth放在一起封装int daysInMonth(int year, int month) { static const int days[] {31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31}; if (month 1 || month 12) { return -1; } if (month 2 isLeapYear(year)) { return 29; } return days[month - 1]; }这里用static const数组保存每个月的基础天数可读性比一连串 if 好得多。只有2月需要根据闰年结果单独处理普通年份返回28闰年返回29。注意月份合法性检查要放在数组下标访问之前否则month为13或0时会发生越界访问这是初学C最容易踩的未定义行为。这个函数的返回值设计采用了 -1 表示非法月份。你也可以改成返回 0 或者抛异常但团队里最好统一约定。我个人倾向于返回 -1因为调用方很容易用if (daysInMonth(...) 0)做判断语义也清楚。如果你喜欢C的异常机制也可以对非法参数抛出std::invalid_argument但那样会让使用者被迫写 try-catch在普通工具函数里显得有些重。做一个简单约定并写进注释往往比引入异常更实用。4.2 日期合法性校验一层层往上垒有了闰年判断和每月天数就能往上垒一个完整的日期校验器bool isValidDate(int year, int month, int day) { if (year 1 || year 9999) { return false; } int maxDay daysInMonth(year, month); if (maxDay -1) { return false; } return day 1 day maxDay; }这个函数的逻辑依赖底层两个函数都正确先判断年份范围再通过daysInMonth拿到当月天数最后检查天是否落在合法区间。看似简单但它能处理所有月份和闰年组合包括2月29日在闰年合法、在平年非法这类场景。把底层函数测试扎实了上层就不需要重复写大量的 if 分支这是工程上自底向上的典型思路。4.3 避免重复实现集中管理日期工具团队项目里有个我见过无数次的坏味道每个模块都自己写一份闰年判断。A同学记得一句口诀写了year % 4 0B同学从网上抄了个带100和400修正的版本C同学从老项目里复制了一段带额外判断的代码。结果同一个系统里不同模块对1900年的结论不一样最后表现在用户端就是日期错乱、对账失败。解决办法很简单把isLeapYear、daysInMonth、isValidDate集中放在一个工具文件里用同一套测试保护所有业务代码统一 include。就算只是个人项目也建议把日期相关函数独立成模块而不是散落在每个调用处。如果项目里有代码审查流程我会把全项目不得出现第二份闰年判断实现写进约定里。这样的约束听起来有点小题大做但日期bug往往就是在这种重复实现里悄悄繁殖的。控制住入口比事后追查省心得多。另外把日期工具放进独立模块后后续想升级底层实现也容易比如从手写规则换成C20标准库只需要改一个文件跑同一套测试其他模块完全无感。这带来的长期收益远超过多建一个文件的那点成本。4.4 编译期数组与常量场景上一节提到的constexpr在这里还有一层用处预生成只读的闰年标志数组。比如你知道业务只关心2024到2030这7年就可以在编译期把标志填好constexpr bool leapFlags[] { isLeapYear(2024), isLeapYear(2025), isLeapYear(2026), isLeapYear(2027), isLeapYear(2028), isLeapYear(2029), isLeapYear(2030) };这段代码在编译期就完成所有计算数组进入只读存储区运行时不再需要任何取余运算。对普通业务程序意义不大但在嵌入式或对性能苛刻的场景里这种编译期常量化是很实用的思路。如果年份区间在编译期就能确定直接用constexpr数组甚至现代C的std::array都能让代码更安全。5. 批量场景的O(1)统计与常见错误复盘5.1 统计区间闰年数数论公式代替循环如果只是判断单个年份isLeapYear就够了。但业务里偶尔会需要统计某个区间内一共有多少个闰年比如计费系统按天算钱时想预估跨年区间的天数或者做数据报表时想按闰年平均分摊。逐个循环当然可以但有一个更优美的数学写法小于等于 n 的闰年数量等于n/4 - n/100 n/400这里的除法全部是整数除法。int countLeapYearsUpTo(int n) { return n / 4 - n / 100 n / 400; } int countLeapYearsInRange(int start, int end) { if (start end) return 0; return countLeapYearsUpTo(end) - countLeapYearsUpTo(start - 1); }为什么这个公式成立因为能被4整除的年份先全部算进来再把其中能被100整除的扣掉最后把扣多了的、能被400整除的年份加回来。整个公式恰好复刻了闰年规则的三层修正。举例来说countLeapYearsUpTo(400)等于 97countLeapYearsUpTo(800)等于 194和前面测试一节提到的数学锚点完全吻合。这个O(1)函数在极端情况下还能计算区间内闰日的数量比如某段时间跨过了2月29日按日计费的总天数就要多算一天。用这个函数预先算出闰日个数可以让金额估算更精确不需要真的逐年遍历。当然实际计费系统要考虑时区、起止时刻、自然日还是工作日等多种因素闰日只是其中一块拼图。但至少你会发现一个看似不起眼的闰年判断往上可以支撑出很多业务逻辑。5.2 常见错误一只记得四年一闰新手的头号错误是只写year % 4 0。在2024、2028这类年份上这个条件完全正确所以局部测试很难发现问题。一旦遇到1900错误就暴露了1900能被4整除但不是闰年。如果项目里还有一份正确的实现两个模块算出来的2月天数就会不一样。这种不一致最坑人因为它不报错只是结果悄悄出现分歧。修正方式只有一句话把百年不闰、四百年再闰一起写进条件。哪怕你暂时不理解历法推导先把完整表达式背下来用也比残缺版强得多。我建议不要直接抄网上代码而是自己在编辑器里默写几遍把它变成条件反射这样面试和写项目时都不容易出错。5.3 常见错误二用浮点数处理整除第二种常见错误是试图用浮点运算判断整除比如写if (year / 4.0 0)。这行代码有两个问题第一year / 4.0在 year 为正整数时几乎不可能等于0逻辑本身就错第二浮点数在计算机里是近似表示做除法后比较相等容易遇到精度陷阱。还有人写if (year % 4.0 0)这在C里直接编译不过因为%要求两个操作数都是整型。正确的做法永远是整数取余year % 4 0。取余的结果对正整数是精确的没有任何精度损失。5.4 常见错误三条件杂糅与维护性陷阱第三种错误是把逻辑条件写成year % 400 0 || year % 100 ! 0 year % 4 0。这个表达式在数学上可能等价于完整规则但对阅读者来说非常不友好尤其当后续有人想改逻辑时很容易误解成能被400整除或不能被100整除。我见过有人费了半天劲去推演运算符优先级就为了验证这行代码对不对。正确做法是坚持(year % 4 0 year % 100 ! 0) || year % 400 0这种教科书形态用括号把一组条件显式圈起来维护成本会低很多。5.5 负年份与公元前纪年的边界还有一个经常在历史数据处理里冒出来的问题年份为负数怎么办从数学上说闰年规则对负数没有直接定义因为整除语义与公历纪年的历史断代并不吻合。比如公元前1年在天文纪年法里对应年份0而有些库又把公元前100年表示成 -99混乱就在所难免。我在实际处理这类数据时更倾向于在业务入口处做限制只接受1年及以后的公历年份遇到负数一律返回 false 或直接报错。底层的isLeapYear不应该替调用方背历史纪年映射这个锅。5.6 性能优化先看调用模式再看单次运算最后聊聊性能。单次闰年判断只是两三次整数取余在普通CPU上是纳秒级操作完全不需要优化。如果有人劝你用位运算或者查表来加速先问自己这个函数真的被调用了上亿次吗如果是还要看年份是否变化。我在一个统计服务里见过这样的代码遍历上千万条记录时每条都调用isLeapYear(year)但年份根本就是同一个值。把这次调用提到循环外只计算一次整体耗时立刻降了接近一半。这才是真正的性能问题不是取余太慢而是重复计算太多。所以性能优化有个朴素原则先消除重复计算再考虑指令级优化。判断闰年这么简单的函数尤其适合这个原则。如果确实需要在高频循环里对不同年份做判断那一行表达式版本已经足够快不用再折腾别的花活。毕竟让代码停留在好读、正确、稳定的状态往往比把它压榨到极致更符合绝大多数业务场景的收益。写到这里想起我第一次写闰年判断的场景当时只记得四年一闰自信满满地写了year % 4 0直到某次跑批数据在1900年附近对不上账才老老实实把历法规则补全。从那以后我的习惯是先列边界用例再写实现先想清楚调用场景再定封装层级。判断闰年这件事本身不难难的是在真实项目里用对、测稳。如果你也正被日期相关的小问题困扰希望这篇能帮你少走几步弯路。