闰年会导致日期转序号错误，进而使取余排班错位。关键在“日期→序号”环节是否正确处理闰年规则，而非取余操作本身；应使用标准库序号函数、避免手算、加强跨年及边界日测试。
会错位，而且错得隐蔽、查得费劲。
用日期取余排班，本质是把日期映射成一个整数（比如“2024-02-29” → 第 N 天），再对班次数量取模（如 % 3），得到轮值编号。这个方法看似简洁，但一旦跨闰年边界，就容易因“天数偏移”导致周期错乱——不是逻辑写错了，而是输入的“第 N 天”本身算错了。
关键问题不在取余操作，而在“日期转序号”的环节是否处理了闰年
- 如果你用的是简单累加：每年固定按 365 天算，那 2024 年会少算 1 天 → 后续所有日期的序号都小 1 → 取余结果整体偏移；
- 如果你硬编码了每月天数表，但没在 2 月设为 29 天（2024、2028 等年份），2 月 29 日当天就会溢出或跳过 → 序号断层；
- 如果你依赖某库的
date.toordinal()或类似函数，要确认它底层是否严格遵循公历规则（比如 1900 是平年、2000 是闰年）——不少轻量级工具或自定义实现会漏掉世纪年规则。
真实影响场景举例
某三班倒系统用 date.toordinal() % 3 分配早/中/夜班：
- 2023-02-28 → 序号 X，X % 3 = 0 → 早班
- 按 365 天推算，2024-02-28 应为 X+365 → (X+365) % 3 = (X+2) % 3 = 2 → 夜班
- 但实际 2024 是闰年，2023-02-28 到 2024-02-28 是 366 天 → 正确序号是 X+366 → (X+366) % 3 = X % 3 = 0 → 还是早班
→ 若代码里用了 365，就多转了一轮，班次提前一天切换。
怎么防？
- ✅ 用标准库中经过验证的序号转换（如 Python
date.toordinal()、JavaLocalDate.toEpochDay()），它们已内置完整闰年逻辑； - ✅ 避免手写“年×365 + 闰年个数 + 当年日序”这类公式，除非你明确实现了
isleap()且覆盖了 100/400 规则； - ✅ 对排班结果做跨年快照比对：拉出 2023-12 和 2024-01 的排班表，重点看 2 月前后几天是否连续、无跳变；
- ✅ 在测试用例里强制包含 2024-02-29、2025-02-28、2100-02-28（平年）等典型边界日，验证序号衔接。
闰年不会让取余运算本身出错，但它会让“被取余的那个数”失真——就像用一把刻度不准的尺子量长度，再怎么精确除以 3，结果还是错的。
