17370845950

闰年判断的核心逻辑是：能被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这类典型值测试不够。以下年份建议纳入单元验证：

• 1900 → 应返回 false（被100整除但不被400整除）
• 2000 → 应返回 true（被400整除）
• 2025 → 应返回 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这两个分支一旦漏掉括号或理解偏差，就会在跨世纪年份上静默出错——而这类问题往往上线后很久才暴露。