闰年判断的核心逻辑是：能被4整除且不能被100整除，或能被400整除；即(year % 4 == 0 && year % 100 != 0) || (year % 400 == 0)。
判断闰年的核心逻辑条件是什么
闰年判断不是简单看能否被4整除，C++里必须严格按公历规则：能被4整除但不能被100整除，或者能被400整除。这个“或者”是关键，对应 ||；“但不能”对应 && 和取反 !。漏掉任一条件都会误判，比如1900年不是闰年，2000年才是。
标准写法与常见错误对比
正确写法要同时覆盖两个分支，且括号优先级必须清晰。下面这行是推荐的、无歧义的表达：
bool isLeapYear(int year) {
return (year % 4 == 0 && year % 100 != 0) || (year % 400 == 0);
}
容易出错的写法包括：
- 写成
year % 4 == 0 || year % 400 == 0—— 忽略了100的排除规则，1900会被判为闰年 - 写成
year % 4 == 0 && year % 100 != 0 || year % 400 == 0—— 缺少外层括号，&&优先级高于||，实际等价于(year % 4 == 0 && year % 100 != 0) || year % 400 == 0，看似对，但可读性差，易引发维护误解 - 用
!替代!=，比如!(year % 100)—— 虽语法合法，但增加理解成本，不推荐在业务逻辑中混用
边界年份测试必须覆盖哪些值
仅用2000、2004、2100这类典型值测试不够。以下年份建议纳入单元验证：
立即学习“C++免费学习笔记（深入）”；
-
1900→ 应返回false（被100整除但不被400整除） -
2000→ 应返回true（被400整除） -
2024→ 应返回true（被4整除且不被100整除） -
2100→ 应返回false（同1900） -
0或负数 → 视业务而定，但函数本身不校验输入范围，需额外处理或文档说明
性能与可读性的平衡点在哪
这个判断本身没有性能瓶颈，但逻辑表达是否清晰直接影响协作效率。有人会把条件拆成变量提升可读性：
bool divisibleBy4 = (year % 4 == 0); bool divisibleBy100 = (year % 100 == 0); bool divisibleBy400 = (year % 400 == 0); return (divisibleBy4 && !divisibleBy100) || divisibleBy400;
这种写法适合教学或复杂业务嵌套场景，但日常代码中直接写单行更常见。真正要注意的是：别为了“看起来高级”而用位运算替代取模（如 year & 3 判是否被4整除），它只对正数幂次有效，且牺牲可移植性和语义明确性。
闰年逻辑看着简单，但% 100和% 400这两个分支一旦漏掉括号或理解偏差，就会在跨世纪年份上静默出错——而这类问题往往上线后很久才暴露。
