LeetCode第1360题题面就一句话给你两个日期字符串格式都是yyyy-MM-dd问它们之间隔了多少天。这道题在题库里被标成Easy但真上手写的时候很多人会在边界条件上翻车。我当初刷这题的时候第一版是老老实实把日期转成绝对天数再做差提交后看了一眼耗时分布落在了第一梯队也就是很多题解标题里喜欢写的“耗时100%”。这篇就把这套解法的推导、代码、优化点和踩坑经验完整拆开讲一遍。1. 一道简单的日期题为什么值得认真写一遍先明确一下题目的输入输出。给两个字符串比如2019-06-29和2019-06-30返回值就是整数1。如果两个日期相同返回0。题目还约束了年份范围1971-01-01到2100-12-31所有输入都在这130年之内。看起来人畜无害但它的陷阱藏在细节里闰年、月份天数、跨年累加任何一个地方想当然结果就会差一两天。这道题刷完你能带走的最有价值的东西不是“会做这一题”而是一套思考模式凡是涉及日期计算的题先不要急着按日历一格一格去数而是把日期映射成一个整数数字相减就直接出答案。这套模式在“计算两个日期差”“推算某日加N天后是哪一天”“判断星期几”这类变体题里基本是通用的。为什么我不建议一上来就用库函数比如Java里有LocalDatePython里有datetime.date人家写好了完整的日历逻辑一行代码确实能过。但刷题本身练的就是你不依赖库、自己把规则理清楚的能力。面试时候选人如果遇到日期题直接调库多半会被追问一句“那你讲一下闰年的完整规则”。所以这道题值得从头手写一遍。另外说句实在话这种题不考什么高深算法它考的是你的“工程严谨度”——边界条件意识。写完能一次通过的人通常是在动手之前就把1971-01-01、2000-02-29、2100-02-28这些特殊输入在脑子里过了一遍的人。2. 绝对天数法的完整推导闰年、月份表与累加逻辑2.1 核心公式年份贡献 月份贡献 日期贡献绝对天数法的思路是选一个基准日比如把1971-01-01当作第0天然后给定任意日期算出它到基准日经过了多少天。两个日期都换算成这个“绝对天数”相减取绝对值就得到间隔天数。换算公式长这样总天数 完整年份贡献 当年已过的完整月份贡献 当月天数 - 1完整年份贡献从1971年到目标日期的前一年每一年的天数累加。平年365闰年366。月份贡献从1月到目标月份的前一个月每个月的天数累加。注意2月要根据是否闰年决定是28还是29。日期贡献目标日期是这个月里的第几天直接加上去。这里的“减1”是因为我把1971-01-01定义为第0天。如果不减1所有绝对天数整体偏移1由于最后是两个日期相减偏移量会抵消结果依然正确。但为了逻辑自洽我还是推荐把基准日当成第0天来写。月份天数用一张常量表int[] MONTH_DAYS {31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};注意索引0对应1月索引1对应2月依次类推。2.2 易读版代码先把正确性跑通先给一个可读性优先的版本这个版本我不会刻意做性能优化目的是让人一眼看懂计算流程。class Solution { private static final int[] MONTH_DAYS { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }; public int daysBetweenDates(String date1, String date2) { return Math.abs(daysSince1971(date1) - daysSince1971(date2)); } private int daysSince1971(String date) { String[] parts date.split(-); int year Integer.parseInt(parts[0]); int month Integer.parseInt(parts[1]); int day Integer.parseInt(parts[2]); int total 0; // 年份贡献1971年到 year - 1 年 for (int y 1971; y year; y) { total isLeapYear(y) ? 366 : 365; } // 月份贡献1月到 month - 1 月 for (int m 1; m month; m) { total MONTH_DAYS[m - 1]; if (m 2 isLeapYear(year)) { total 1; } } // 日期贡献 total day - 1; return total; } private boolean isLeapYear(int year) { return (year % 4 0 year % 100 ! 0) || year % 400 0; } }两个循环加起来最多跑140次左右复杂度其实是O(年份跨度)在130年上限下就是常数级。对LeetCode而言这版已经足够通过。我实际提交时这版耗时在2到3毫秒之间徘徊排名大概60%到80%没有到第一梯队。所以要冲击“耗时100%”那一档还得继续往下抠常数。3. 闰年规则的三个特例年份2000年、2100年和1972年3.1 完整闰年规则不是“四年一闰”这么简单很多人写闰年判断只写了year % 4 0然后信心满满地交上去结果在2000年这类输入上翻车。标准规则是普通年份能被4整除的是闰年但如果这个年份能被100整除它必须同时能被400整除才是闰年。翻译成Java就是private boolean isLeapYear(int year) { return (year % 4 0 year % 100 ! 0) || year % 400 0; }这个year % 400 0很多人会忘。题目给的范围是1971到2100里面正好有三个值得注意的年份年份判断逻辑结论1972能被4整除不能被100整除闰年2月29天2000能被4整除能被100整除同时能被400整除闰年2月29天2100能被4整除能被100整除但不能被400整除平年2月28天有些解法会在月份贡献里写死一个{31, 29, 31, 30, ...}数组然后只在2月判断闰年。这样也行但我的习惯是保持MONTH_DAYS为平年表遇到二月份再单独加1天。这样语义更清楚闰年只影响2月不会无意中影响别的月份。3.2 用边界用例验证核心逻辑我刷题有个习惯写完代码先不急着提交而是在本地跑一组精心设计的测试用例。日期题尤其要这样。下面这组用例覆盖了最常见的坑输入1输入2期望结果验证点1971-01-011971-01-010同一天1971-01-011971-01-021相邻两天1971-01-011972-01-013651971是平年1972-01-011973-01-013661972是闰年2000-02-282000-03-0122000年闰年2月有29日2100-02-282100-03-0112100年不是闰年2019-06-292019-06-301普通相邻日2019-01-012020-01-013652019是平年2016-01-012017-01-013662016是闰年1971-01-012100-12-31一个很大的数跨全部范围不出错其中2000-02-28到2000-03-01是最容易出问题的如果闰年判断漏了400的规则会得到1正确答案是2。2100-02-28到2100-03-01则反过来如果只写year % 4 0会错误地得到2正确答案是1。这两个用例一个管“闰年要有”一个管“不能乱闰”配合起来就是闰年规则的完整校验。3.3 日期顺序颠倒别忘了取绝对值题目没说date1一定早于date2所以2019-06-30和2019-06-29也是合法输入。在daysBetweenDates里直接用Math.abs(d1 - d2)就能避免手动比较。这个细节看起来无足轻重但如果你在计算过程中做的是“从date1加到date2”而不是“转绝对天数做差”遇到顺序颠倒的情况逻辑就会变得别扭。选择绝对天数法的一个额外好处就在这里两个日期是完全对称的。4. “耗时100”是怎么来的手写解析、预计算与减害优化4.1 先泼一盆冷水LeetCode的耗时百分比别太当真聊优化之前得先说明白LeetCode那个“beats 100%”到底怎么回事。它统计的是当前提交在所有通过提交里的耗时百分位但这个统计受语言、服务器负载、同时间段提交样本的影响很大。尤其当多个解法都跑在1毫秒以内时谁高谁低基本就是噪声。所以我不建议大家为了“百位数好看”去写各种奇怪的位运算黑魔法。我分享下面这些优化是因为它们同时还能让代码更整洁、更少做无用功而不是单纯为了刷百分比。4.2 把split和parseInt换掉易读版代码里两处明显的无用功split(-)Java的String.split底层是按正则表达式匹配的哪怕你传的是普通字符它也会走一遍正则相关逻辑。每次调用都会产生一个字符串数组。Integer.parseInt会做完整的字符校验、符号判断、异常处理对一个固定格式的日期字符串来说这些操作大部分都是多余的。因为日期格式固定为yyyy-MM-dd长度是10字符位置都是确定的完全可以手动截取int year (date.charAt(0) - 0) * 1000 (date.charAt(1) - 0) * 100 (date.charAt(2) - 0) * 10 (date.charAt(3) - 0); int month (date.charAt(5) - 0) * 10 (date.charAt(6) - 0); int day (date.charAt(8) - 0) * 10 (date.charAt(9) - 0);这里用charAt直接按索引取字符然后用char - 0把数字字符转成整数整个过程不产生新对象不做多余校验。对性能敏感的场景这种手写解析是常规操作。4.3 预计算年份起点把累加循环变成查表易读版里算年份贡献需要从1971年循环到目标年份前一年。最多130次循环其实很快但还可以更快直接用数组把每一年的起点天数存下来。数组下标i代表1971年往后数第i年值代表“1971-01-01到这个日期所在年份的1月1日之间的天数”。private static final int[] YEAR_START new int[130]; static { for (int i 1; i 130; i) { YEAR_START[i] YEAR_START[i - 1] (isLeapYear(1970 i) ? 366 : 365); } }初始化逻辑YEAR_START[0]默认是0也就是1971-01-01。YEAR_START[1]等于0加上1971年的天数365表示1972-01-01到基准日的天数是365。依次类推。这样求某年的年份贡献时直接取YEAR_START[year - 1971]即可。4.4 优化版完整代码把上面两处优化合到一起加上YEAR_START和手写解析完整代码如下class Solution { private static final int[] MONTH_DAYS { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }; // YEAR_START[i] 表示 1971-01-01 到 (1971 i)年1月1日 经过的天数 private static final int[] YEAR_START new int[130]; static { for (int i 1; i 130; i) { YEAR_START[i] YEAR_START[i - 1] (isLeapYear(1970 i) ? 366 : 365); } } public int daysBetweenDates(String date1, String date2) { return Math.abs(toAbsoluteDays(date1) - toAbsoluteDays(date2)); } private int toAbsoluteDays(String date) { int year (date.charAt(0) - 0) * 1000 (date.charAt(1) - 0) * 100 (date.charAt(2) - 0) * 10 (date.charAt(3) - 0); int month (date.charAt(5) - 0) * 10 (date.charAt(6) - 0); int day (date.charAt(8) - 0) * 10 (date.charAt(9) - 0); int total YEAR_START[year - 1971]; for (int m 1; m month; m) { total MONTH_DAYS[m - 1]; if (m 2 isLeapYear(year)) { total 1; } } return total day - 1; } private static boolean isLeapYear(int year) { return (year % 4 0 year % 100 ! 0) || year % 400 0; } }这版代码几乎没有多余的对象分配没有split数组没有parseInt的中间字符串年份贡献是直接查表。月份循环最多执行11次常数极小。实测下来这版在LeetCode上的耗时基本在0到1毫秒很轻松进入耗时分布第一梯队。需要说明的是易读版和优化版的算法复杂度本质没有区别优化版只是把常数压得更低。日常工程里写日期功能我反而不建议这么干直接用LocalDate才是对的选择但刷题和面试手写环节这种“知道每一步在干什么”的写法会给你加不少分。4.5 一个容易被忽略的小优化静态方法看上面代码我把isLeapYear定义成了private static并在静态初始化块里调用。原因很简单静态初始化块只在类加载时执行一次所有实例共享而YEAR_START是静态常量初始化时调用非静态方法会编译报错。我见过有人在静态块里硬调实例方法结果代码根本跑不起来。解决办法就是给isLeapYear加static修饰符。这个细节在写刷题代码时无所谓但在写工程代码时工具类方法都应该是静态的这是良好习惯。5. 边界测试与经典翻车我踩过的三个坑5.1 第一个坑把2月写死在月份表里最开始我写过一个版本为了省事直接把MONTH_DAYS定义成{31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31}然后在处理月份贡献时直接取数组值。逻辑本身没错但后来我脑子一抽想把闰年优化掉把2月改成29天——结果非闰年2月全算错了。明明MONTH_DAYS是常量表我却试图让它“自适应”年份这种自找麻烦的做法完全没有必要。正确姿势就是保持平年表单独判断闰年2月加1天。代码里只有这一处特殊逻辑其他地方一概不用关心闰年。5.2 第二个坑基准日的第0天定义我一开始把日期贡献写成total day基准日1971-01-01算出来是第1天而不是第0天。两个日期相减结果倒是没错因为偏移量被抵消了。但在做变体题“给定日期求N天后的日期”时这种偏移会带来隐患从第1天倒推N天边界容易绕晕。所以我推荐在写日期换算时就统一为“基准日是第0天”也就是最后一步写成total day - 1。这样所有日期相对基准日的天数是自洽的调其他变体时心智负担小很多。5.3 第三个坑用“数日子”的思路导致顺序颠倒时出错在没写绝对天数法之前我试过另一种直观解法从date1开始一天一天往后加加到头和date2相等就停。这种办法在小范围用例上没问题但一旦date1在date2之后就得先交换两个日期代码一下子就复杂了。而且逐日模拟在跨月时容易写错循环边界比如31号跳到下月1号的逻辑。绝对天数法通过“先转整数再做差”绕开了这些麻烦——日期之间的顺序变成了两个数的大小关系天然支持反向输入。这也是我最终推荐这个解法的核心原因。5.4 跨范围大用例也需要验证日常自测时我还会跑一次全局范围的用例1971-01-01到2100-12-31。这个用例不是用来核对具体数字的而是用库函数版本和手写版本互相对比确保大跨度计算没有累加溢出。int能表示的最大值约21亿130年最多约47500天远远不会溢出所以用int就足够了。如果哪天题目把范围扩到1万年前就要考虑long不过当前题目用不上。5.5 其他语言的对比写法如果你平时用Python刷题同样思路写出来会更短class Solution: def daysBetweenDates(self, date1: str, date2: str) - int: def is_leap(y): return (y % 4 0 and y % 100 ! 0) or y % 400 0 def days(s): y, m, d map(int, s.split(-)) total 0 for yy in range(1971, y): total 366 if is_leap(yy) else 365 mdays [31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31] for mm in range(1, m): total mdays[mm - 1] if mm 2 and is_leap(y): total 1 return total d - 1 return abs(days(date1) - days(date2))Python本身就慢没必要像Java那样手写字符串解析用split和map已经足够。不同语言有不同的性能权衡点优化手段不能一概照搬。6. 从这道题延伸出去日期类变体题的通用套路6.1 变体一求给定日期是星期几绝对天数法稍微加一步就能解决。选定一个已知是星期几的基准日比如1971-01-01是星期五那么任意日期的星期几就是(absoluteDays 4) % 7把结果映射到星期名词即可。关键点仍然是先把日期变成绝对天数再对7取余。所有星期类问题都逃不出这个框架。6.2 变体二求两个日期之间的工作日天数先算出间隔天数再看这期间跨越了几个完整的7天周期最后处理头尾不足一周的部分。如果直接逐日判断星期几遇到几年跨度时会慢得离谱。绝对天数法把范围压缩成了“几个整数运算 一个取余”在线面试时这种思路尤其吃香。6.3 变体三给定日期加N天之后是哪一天这是绝对天数法的反向操作把给定的日期转成绝对天数加上N然后从年份数组里找到目标年份再扣减平年/闰年的月份天数最后算出月和日。因为使用了YEAR_START表反向推算时也能快速定位年份不会傻乎乎一年一年数过去。说白了日期题就两件事正着算天数反着推日期。把“日期转整数”这个基础函数打扎实所有变体都是在它的基础上拼接不同逻辑。6.4 工程开发中该用库就用库刷题和面试手写是一回事实际项目里是另一回事。Java项目里要算日期间隔直接ChronoUnit.DAYS.between(date1, date2)三行搞定Python项目里用datetime更简单。工程代码追求的是可靠性、可读性和可维护性库函数经过了大量测试没有必要自己造轮子。所以我的建议是刷题阶段想尽办法手写练基本功写项目放心用库。两种场景分开对待别混在一起。7. 一点刷题心法日期题的“一次过”修炼说完技术细节分享一点刷题时的心得。日期类题目不需要做什么思维训练它检验的是你有没有“边界意识”。我刷这种题会刻意遵循三步流程第一步把输入范围高亮出来。这题给出了1971到2100我就能确定年份数组大小、闰年特例年份有哪些。第二步先写正确性优先的版本跑一遍我整理的边界用例表。如果全部通过再考虑优化。第三步优化时每次只动一个点。比如先把split换成手写解析提交一次看结果再把年份循环换成查表再提交一次。不要一次性把所有优化全塞进去否则出了问题你都说不清是哪一步引入的。这三个步骤让我在日期题上的提交通过率明显提升。尤其是第二步的边界用例很多你以为是“运气不错一次过了”的情况其实是测试用例足够狠的结果。这套习惯对于其他容易出现隐蔽边界问题的基础题同样适用。