电子万年历开发避坑指南：从闰年算法到RTC同步的那些坑

做电子万年历，听起来是个挺“古典”的单片机项目，很多朋友觉得不就是读个RTC、算个日期、再显示出来嘛。但真上手了，才会发现处处是“坑”。我见过不少项目，显示正常跑了大半年，一到2月29号就卡壳；或者按键调时间时，日期莫名其妙跳变；更别提RTC电池耗尽后，系统时间直接“穿越”回出厂日期。这些细节问题，往往在项目初期测试时难以发现，却足以让一个看似完美的作品在用户手中变成“半成品”。今天，我们就抛开那些系统性的教程，聚焦于开发过程中最容易出错的“魔鬼细节”，通过几个真实的故障案例，聊聊如何调试、如何避坑，以及构建一套可复用的调试心法。

1. 闰年算法的“隐形陷阱”与日期边界处理

日期计算是万年历的核心，而闰年判定则是核心中的核心。教科书上的规则“能被4整除但不能被100整除，或者能被400整除”人人都会背，但将其转化为无懈可击的代码，并处理好所有边界情况，则是另一回事。

1.1 算法实现中的常见漏洞

最直接的实现方式是用if-else语句。但这里第一个坑就是运算顺序和括号的使用。考虑以下代码：

// 有风险的写法
if (year % 4 == 0 && year % 100 != 0 || year % 400 == 0) {
    is_leap = 1;
}

这段代码在大多数情况下工作正常，但它的逻辑依赖于运算符优先级（% > ==/!= > && > ||）。虽然C语言中&&优先级高于||，但为了绝对清晰和避免后续维护者误解，务必加上括号。

// 推荐的清晰写法
if ((year % 4 == 0) && (year % 100 != 0)) || (year % 400 == 0) {
    is_leap = 1;
}

更大的坑在于数据类型。如果你使用的年份变量是unsigned char（范围0-255），那么计算公元2000年（能被400整除）之后的年份时，year % 400这个操作对于大于255的年份是未定义的（因为400>255）。因此，年份变量至少应使用unsigned int。

注意：在处理历史日期（如1900年）或未来日期（如2100年）时，务必测试2100年。2100年能被4和100整除，但不能被400整除，所以它不是闰年。这是检验你算法是否正确的最经典用例。

1.2 二月日期增减的逻辑闭环

闰年算法正确，只是第一步。更棘手的是在日期递增或递减逻辑中，动态判断二月的天数。一个常见的错误是在日期更新函数中，直接使用一个固定的月份天数数组，而忽略了当年是否是闰年。

假设我们有一个函数increment_date()，每天调用一次。错误的逻辑可能是：

day++;
if (day > days_in_month[month]) { // days_in_month是固定数组
    day = 1;
    month++;
    if (month > 12) {
        month = 1;
        year++;
    }
}

这里days_in_month[1]（代表二月）固定是28。那么在闰年，2月28号之后会直接跳到3月1号，丢失了2月29日。

正确的做法是，在比较day和当月天数前，实时计算当月最大天数：

uint8_t get_days_in_month(uint16_t year, uint8_t month) {