短视频平台上那种"输入生日，算一算适合你的恋爱对象几岁"的小工具，隔一阵就会火一轮。表面看是个年龄计算器在线计算的娱乐小玩意，实际上它背后压着三件事：一是日期与年龄的精确计算，二是"匹配区间"这套设定从哪来、可信到什么程度，三是一个纯前端小工具怎么在手机上跑得稳、传得开。我这几年给身边不少朋友做过类似的小页面，也帮人改过几个"算出来总是差一岁"的版本，踩过的坑基本都在日期解析、闰年边界和时区归一化这几处。
下面我按自己实际动手的顺序拆：先把需求掰开揉碎，再讲算法怎么落地，然后给一份能直接抄的代码和排查表，最后聊聊这类东西为什么容易被转发、还能往哪扩。适合三类人看：想自己做一个玩的前端新手、被产品丢过来一个"三天上线趣味小活动"的开发者、以及纯粹好奇"它到底怎么算出来的"普通用户。
1. 先把需求拆开：这个计算器到底在卖什么
1.1 从一句"适合你的对象几岁"拆出四层需求
大多数人第一次看到"年龄计算器适合你的恋爱对象"这种标题，第一反应是"这玩意儿能算什么"，第二反应是"输入我生日试试"。但如果你真要做这个东西，得先把它拆成四层，因为这四层对应的技术难度和实现成本完全不一样。
第一层是年龄计算，输入出生日期，输出周岁、虚岁、已经活了多少天、距离下次生日还有几天。这层是纯数学，是整件东西的地基，也是唯一必须有正确答案的部分。第二层是年龄差计算，输入两个生日，输出谁大谁小、差几岁几个月几天。这层常用于情侣之间互相测，"我们差三岁零两个月"这种结果。第三层是匹配区间推导，输入你的年龄，输出一个"适合你的对象年龄范围"，比如 24 岁的人得到 19 到 34 岁。这层是设定，不是定律，必须写清楚它的来源。第四层是结果包装，把上面算出来的数字套进一段有情绪价值的文案里，做成能截图发出去的东西。
为什么要这么拆？因为很多人做这类工具时会一头扎进第四层，先想文案、先想配色，结果上线第一天就被评论区骂"算错了，我明明是 26 岁它说 25"。真正的顺序应该是反过来的：先把第一层做到零错误，再往上叠。第一层错了，上面三层全是废的。
注意：这个顺序不是流程洁癖，是成本问题。文案改十版只花半天，年龄算错一岁的修复成本可能是重发一版客户端。
1.2 计算结果的可信度边界：哪些能算，哪些只是设定
这一点必须说清楚，否则容易误导人。年龄计算器里，"你今年多少岁""你活了多少天""你下次生日是周几"这些是确定的、可验证的，只要算法对，结果唯一。而"适合你的对象年龄"是一个文化约定出来的区间，它的作用是帮你开个话题，不是替你做决策。
我一般会在页面底部加一行小字，说明这个区间是怎么来的、它只是一种参考视角。这不是免责声明式的敷衍，而是对用户诚实。你越老实说"这是我们用一种流行算法估算的"，用户反而越愿意玩，因为它变成了"看看这个算法怎么评价我"，而不是"这台机器替我做判断"。
还有个容易忽略的点：未满 18 岁的输入怎么处理。如果你不做处理，一个 15 岁的用户可能算出"适合 14 到 16 岁"，看起来没问题，但有些公式（下面会讲）在低龄段会产生很荒谬的结果，比如算出下限比本人还大。稳妥的做法是低龄段直接不给匹配区间，改成输出"先把书读完"这类调侃文案，把功能引导成娱乐而不是建议。
1.3 谁在用它，用来干嘛：三种真实使用场景
我在后台数据里见过三种典型用法，它们的诉求差别很大。
第一种是自我好奇型，占比最高。用户输入自己的生日，看看自己几岁几个月零几天，看看下次生日还有多少天，看看属相和星座。这类用户只输入一次，但停留时间不短，会反复切换虚岁周岁看差异。第二种是双人对比型，情侣或者暧昧对象互相输入，重点看年龄差和"谁先过生日"。这类用户的分享意愿最强，因为他有对象可以 @。第三种是纯娱乐截屏型，只看匹配区间，看完截图就走，根本不关心计算精度。
这三种用法对产品的要求完全不一样：第一种要求准确和细节丰富，第二种要求双人输入体验顺滑、结果好看，第三种要求首屏够快、结果够有梗。如果你的资源只够做一个，我会优先做第一种，因为它最容易建立"这工具靠谱"的印象，而靠谱的口碑会带动后两种传播。
2. 核心算法拆解：年龄、生日、匹配区间怎么算
2.1 周岁判定：一年真的不是 365 天
很多人第一版年龄算法是这么写的：用当前时间戳减去出生时间戳，除以 86400000，再除以 365。这个算法看起来合理，实际误差能到好几天，原因是闰年和夏令时。四年一个闰日，累计下来 365 的平均值就偏了；而有夏令时的地区，一年里有两天只有 23 小时、两天有 25 小时，除法结果会带上零点几天的小数误差。
正确的周岁算法是年月日逐位比较，不做除法：先算年份差，再比较月和日，如果今年的生日还没到，就减 1。这个逻辑不需要知道一年有几天，也不受时区和闰年影响，因为它只比较日历上的年、月、日三个数。
// 周岁：逐位比较，最稳的写法 function calcAge(birth, now = new Date()) { let age = now.getFullYear() - birth.getFullYear(); const monthDiff = now.getMonth() - birth.getMonth(); // 月份还没到，或者月份相同但日子还没到，就还没过生日 if (monthDiff < 0 || (monthDiff === 0 && now.getDate() < birth.getDate())) { age--; } return age; }这里有个细节值得说：now.getDate() < birth.getDate()用的是严格小于。生日当天算不算过生日？按通行习惯算，当天就是已经过了，所以用小于而不是小于等于。这个一个字符的差别，就是"差一岁"投诉的高发区。
虚岁的算法是另一个体系，传统上按"出生即一岁，每过一个春节长一岁"算，所以虚岁 = 当前年份 - 出生年份 + 1。但它和周岁之间不是简单的加一关系，有些时段会差两岁。如果你要同时展示，建议把两个数并排放在一起，各自标清楚标签，不要试图用一个数字糊弄过去。
2.2 "合适的对象年龄"这个区间是怎么来的
网上流传最广的那套公式，来源是一个流传了一百多年的社交惯例，通常被概括为"半年龄加七"：可接受的最小年龄 = 自己年龄 ÷ 2 + 7。比如你 26 岁，26 ÷ 2 + 7 = 20，下限就是 20 岁。上限则用反向对称的方式推：如果对方年龄是 X，要满足"X ÷ 2 + 7 ≤ 你的年龄"，解出来 X ≤ (你的年龄 - 7) × 2，26 岁对应上限 38 岁。
这个公式的特点是对称、单调、随年龄增长区间自动变宽，所以它在不同年龄段都不会算出太离谱的结果，这也是它能流传这么久的原因。它本质上是一个社交惯例的数学化表达，不是心理学结论，也不是统计数据。你在页面里怎么措辞很重要：写成"一种流行算法的估算"，用户会觉得你在讲实话；写成"科学测算你的最佳伴侣年龄"，就是在给自己找麻烦。
除了这个公式，市面上还流行两种变体。一种是固定差值区间，比如"上下各 3 岁"，简单粗暴，年轻人用起来还行，40 岁以上就显得太窄。另一种是分段区间，20 岁以下 ±2 岁、20 到 30 岁 ±5 岁、30 岁以上 ±8 岁，这种更像产品经理拍脑袋定的，好处是可控，坏处是没有统一逻辑，用户问"为什么"你答不上来。我自己的选择是半年龄公式，理由很简单：它能解释，用户问起来你能讲清楚来源，这比"我们内部定的"要有说服力得多。
// 匹配区间：下限用半年龄加七，上限反向解 function matchRange(age) { if (age < 18) return null; // 低龄段直接不给，避免荒谬结果 const min = Math.floor(age / 2 + 7); const max = (age - 7) * 2; return { min, max }; } // 26 岁 -> { min: 20, max: 38 }Math.floor和Math.round在这里不是随便选的。下限取整应该向下取，因为 20.5 岁的下限说成 20 比说成 21 更宽松，不会把本来在区间内的人踢出去。上限本来就是整数运算，不用处理。这种取整方向的选择，做数据分析的人会很敏感，做前端的人容易忽略，但它确实影响结果的合理性。
2.3 闰日、时区与解析规则：三个必踩的坑
第一个坑是2 月 29 日。如果你的用户在闰年的 2 月 29 日出生，那么平年怎么办？new Date(2025, 1, 29)在 JavaScript 里不会报错，它会自动滚动到 3 月 1 日。这意味着"下次生日倒计时"会算成 3 月 1 日，而用户心里想的是 2 月 28 日或者 3 月 1 日，因人而异。这件事没有标准答案，你必须做产品决策，并且在页面上说明。我一般的处理是：平年按 2 月 28 日算，同时在结果里加一句说明，避免用户觉得你在瞎算。
第二个坑是字符串解析的时区差异。new Date('1998-05-20')这种带连字符的 ISO 格式，按规范会被解析成 UTC 时间；而new Date('1998/05/20')带斜杠的格式，在多数浏览器里按本地时间解析。这两者在北京时间下差 8 小时，如果在凌晨 0 点到 8 点之间出生的人用它算，可能出现日期回退一天、年龄差一岁的情况。这类 bug 极难复现，因为只有特定时间段、特定输入才会触发。
// 不要直接把 input 的字符串丢给 Date // 正确做法：自己拆，用本地时间构造 function parseLocalDate(str) { const [y, m, d] = str.split('-').map(Number); return new Date(y, m - 1, d); // 月份从 0 开始 }第三个坑是天数差的计算。直接用两个时间戳相减除以 86400000，在有夏令时的地区会遇到 23 小时或 25 小时的日子，结果会出现 0.958 天这种小数，四舍五入后差一天。解决办法是把两个日期都归一化到 UTC 零点的同一基准上，只比较日期部分，不比较时刻。
// 天数差：先归一化到 UTC 零点，避开夏令时 function daysBetween(a, b) { const MS = 86400000; const t1 = Date.UTC(a.getFullYear(), a.getMonth(), a.getDate()); const t2 = Date.UTC(b.getFullYear(), b.getMonth(), b.getDate()); return Math.round((t2 - t1) / MS); }这三个坑我都在真实项目里遇到过，其中第二个坑排查了将近两个小时，最后是靠打印getTimezoneOffset()才定位到的。所以我现在的习惯是：任何来自日期输入框的字符串，一律自己拆，绝不直接丢给 Date 构造函数。这一条规则能省掉后续九成以上的日期类 bug。
3. 手把手做一个能跑的版本
3.1 页面结构与交互流程设计
结构上我推荐极简：一屏之内完成输入、计算、结果展示，不要跳转，不要弹窗套弹窗。移动端用户的耐心很短，多一次点击就多一次流失。具体分三块：顶部是标题和一句说明用途的话，中间是输入区，底部是结果区。
输入区最省事的做法是用<input type="date">，浏览器自带日期选择器，手机上会唤起系统滚轮，体验比自己写的下拉框好得多。但它有两个问题：一是老版本浏览器不支持，会退化成一个普通文本框，用户可以输入任何垃圾字符；二是样式在 iOS 和 Android 上差异较大，改样式很受限。如果你的目标用户覆盖比较广，我建议做一个降级方案：用特性检测判断type="date"是否被支持，不支持就换成三个<select>（年、月、日），虽然丑一点，但绝对能跑。
// 特性检测：判断浏览器是否真的支持 date 类型 function supportsDateInput() { const el = document.createElement('input'); el.setAttribute('type', 'date'); return el.type === 'date'; }交互流程上，我倾向于输入即算，不要加"点击计算"按钮。理由有两个：一是少一次操作，二是这类工具的结果是即时可得的，加按钮纯属仪式感。但要加防抖，用户快速改年月日的时候不要每次都重新渲染结果，200 毫秒延迟足够。结果区要留出固定高度，避免数字位数变化导致页面跳动，这个细节在移动端特别影响观感。
还可以加一个小优化：用localStorage记住上次输入的生日。用户下次打开直接出结果，减少重复输入。这里要提醒一句，生日属于个人信息，localStorage是存在用户本机的，不上传服务端，这个边界要守住，后面第四节会细说。
3.2 核心函数实现：从输入到输出的完整链条
我把整个计算链拆成五个函数，每个只做一件事，方便单独测试。这套代码我在几个项目里复用过多轮，改的都是包装层，核心没动过。
// 1. 解析：字符串 -> 本地日期对象 function parseLocalDate(str) { const [y, m, d] = str.split('-').map(Number); return new Date(y, m - 1, d); } // 2. 周岁 function calcAge(birth, now = new Date()) { let age = now.getFullYear() - birth.getFullYear(); const md = now.getMonth() - birth.getMonth(); if (md < 0 || (md === 0 && now.getDate() < birth.getDate())) age--; return age; } // 3. 精确年龄：几岁几个月几天 function preciseAge(birth, now = new Date()) { let years = now.getFullYear() - birth.getFullYear(); let months = now.getMonth() - birth.getMonth(); let days = now.getDate() - birth.getDate(); if (days < 0) { months--; // 取上个月的天数，注意这里也要处理月末 const lastMonth = new Date(now.getFullYear(), now.getMonth(), 0); days += lastMonth.getDate(); } if (months < 0) { years--; months += 12; } return { years, months, days }; } // 4. 已活天数 function daysBetween(a, b) { const MS = 86400000; const t1 = Date.UTC(a.getFullYear(), a.getMonth(), a.getDate()); const t2 = Date.UTC(b.getFullYear(), b.getMonth(), b.getDate()); return Math.round((t2 - t1) / MS); } // 5. 下次生日倒计时 function nextBirthday(birth, now = new Date()) { const today = new Date(now.getFullYear(), now.getMonth(), now.getDate()); let next = new Date(now.getFullYear(), birth.getMonth(), birth.getDate()); if (next < today) { next = new Date(now.getFullYear() + 1, birth.getMonth(), birth.getDate()); } return next; }preciseAge里那个new Date(now.getFullYear(), now.getMonth(), 0)是个常用技巧：月份传 0，日期传 0，会得到上个月的最后一天，正好用来处理"天数不够减要借位"的情况。这行代码我第一次见的时候愣了一下，后来发现它比手写月份天数表干净得多，也不用担心闰年二月。
参数选择上有几个点要交代清楚。第一，所有函数都接受一个可选的now参数，默认当前时间。这不是为了炫技，是为了可测试：你要验证"2024 年 2 月 29 日出生的人在 2025 年 2 月 28 日是几岁"，就得能传一个固定时间进去，否则只能等到明年再测。第二，闰日出生者平年的处理，我在nextBirthday里没有做特殊照顾，new Date(2025, 1, 29)会滚到 3 月 1 日，如果你要按 2 月 28 日算，得在这里手动判断birth.getMonth() === 1 && birth.getDate() === 29再修正。第三，所有输入在进入计算前必须做合法性校验：不能是未来日期，不能早于 1900 年，不能被手动输入成非法格式。校验放在最前面，别等算完再判断。
// 输入校验：先挡住脏数据，再谈计算 function validate(str) { if (!/^\d{4}-\d{2}-\d{2}$/.test(str)) return '格式不对，请重新选日期'; const d = parseLocalDate(str); if (isNaN(d.getTime())) return '这个日期不存在'; const now = new Date(); if (d > now) return '还没出生呢，先别急着算'; if (d.getFullYear() < 1900) return '年份太早了，换个日期试试'; return null; // 校验通过 }3.3 结果文案与分享卡片的生成逻辑
结果文案的设计有个反直觉的经验：不要只给一个数字，要给一组数字加一句解读。单给"你今年 26 岁"，用户看完就走了；给"26 岁 3 个月 12 天，已经活了 9600 天，下次生日是周四，还有 78 天"，用户会觉得这工具挺用心，愿意多停留几秒。
文案分层我一般这么组织：主结果是年龄和匹配区间，这是视觉焦点；次级结果是一组小数据（活了多少天、下次生日倒计时、和某个参照物的对比），用来填充信息密度；底部是一句调侃式的话，用来制造分享动机。那句调侃话最好和结果数字挂钩，比如区间下限定得高一点的时候，配一句"这个范围有点挑"，比固定文案要生动。
分享卡片这块，早期我用的是 canvas 手动绘制，好处是完全可控、能自定义字体和布局，坏处是要处理高清屏的devicePixelRatio缩放，不然在手机上糊成一片。缩放的处理方式是：canvas 的width和height属性设成逻辑尺寸乘以dpr，CSS 尺寸保持逻辑尺寸，然后用ctx.scale(dpr, dpr)把坐标系缩回来。
// canvas 高清屏适配：三行代码解决模糊问题 function setupCanvas(canvas, w, h) { const dpr = window.devicePixelRatio || 1; canvas.width = w * dpr; canvas.height = h * dpr; canvas.style.width = w + 'px'; canvas.style.height = h + 'px'; canvas.getContext('2d').scale(dpr, dpr); }后来我发现一个更省事的方案：如果不需要用户下载图片，只是要"长按保存"，直接用 DOM 渲染一个好看的结果区块，用户截图就行，根本不用碰 canvas。canvas 只在需要生成带二维码、带品牌角标的固定尺寸图片时才值得投入。这个取舍能省掉至少一半的调试时间，尤其是不用纠结字体加载和文字换行。
4. 上线前必须过一遍的排查清单
4.1 "差一岁"问题的定位表
这是这类工具被反馈最多的问题，没有之一。它几乎总是由下面五种原因之一引起，我整理成一张表，方便对着查。
| 现象 | 最可能原因 | 定位方法 | 处理方式 |
|---|---|---|---|
| 生日当天显示还没过生日 | 用了<=而不是< | 检查日期比较的符号 | 改成严格小于 |
| 凌晨输入时年龄少一岁 | 字符串被按 UTC 解析 | 打印getDate()看是否回退 | 自己拆字符串，用本地时间构造 |
| 所有人普遍大一岁 | 年份差算完忘记判断月日 | 断点看monthDiff | 补上月份和日期的比较 |
| 虚岁周岁混用 | 两个数字用了同一个变量 | 搜索变量赋值处 | 拆成两个独立字段 |
| 闰日出生算错 | new Date自动滚动 | 输入 2000-02-29 测 | 手动判断并按 2/28 修正 |
排查这类问题时，我有个笨但有效的办法：准备一组固定测试用例，包括年初年末、生日当天前后一天、闰年 2 月 29 日、闰年 12 月 31 日、1900 年和 2100 年这种世纪年。每次改完日期相关代码，跑一遍这组用例，比肉眼读代码可靠得多。
// 一组能覆盖边界的最小测试用例 const cases = [ ['2000-02-29', '2024-02-28'], // 闰日生日，平年前一天 ['2000-02-29', '2024-02-29'], // 闰日生日，闰年当天 ['1990-12-31', '2024-01-01'], // 跨年 ['1995-06-15', '2024-06-14'], // 生日前一天 ['1995-06-15', '2024-06-15'], // 生日当天 ];提示：这组用例建议直接写成自测脚本挂在开发环境里，上线前扫一眼全绿再发包，比事后在评论区跟用户解释"这个是正常现象"要体面得多。
4.2 兼容性与移动端问题实录
移动端的坑比桌面端多得多，我挑三个最常见的说。
第一是输入框唤起键盘导致页面跳动。手机上点击日期选择器，软键盘或滚轮弹起会把页面顶上去，关闭后位置不一定回到原处。处理方式是给结果区留固定高度，并且监听resize时重新计算滚动位置。这一点在 iOS 上尤其明显，我在两个项目里都因为这个被用户吐槽"点一下就乱了"。
第二是数字字体导致的显示抖动。结果是动态数字，如果用等宽字体之外的字形，数字从 9 变成 10、从 99 变成 100 的时候宽度会变，旁边的文字会跟着左右跳。解决办法是给数字容器设固定宽度或者用font-variant-numeric: tabular-nums，让所有数字等宽。这个 CSS 属性很少有人用，但对数据类小工具来说是刚需。
第三是分享时的截图兼容。如果结果区有渐变背景、圆角、阴影，某些机型截图会丢失圆角或者出现黑边。稳妥做法是结果卡片用纯色或者简单渐变，避免复杂的backdrop-filter，那东西在部分机型上直接渲染成灰块。我在一个项目里用过毛玻璃效果，自己手机上很好看，用户的机型上是一片糊，后来全删了换成纯色，反而没人吐槽。
另外还有一条容易被忽略：结果文案里如果带年份，要注意跨年时刻。12 月 31 日 23 点 59 分算出来的"明年生日"，到 1 月 1 日 0 点就变成"今年生日"了。如果页面长时间挂着不刷新，用户看到的就是过期结果。解决办法是页面重新获得焦点时重新计算一次，成本很低，体验提升明显。
4.3 隐私与体验上的几条底线
这类工具最容易被忽视的风险，是它天然要收集生日。我的原则很明确：能纯前端算的，绝不发请求。年龄、天数、倒计时这些计算完全在浏览器里就能完成，没有理由把生日传到服务器。如果你确实要做统计，那就只上报"计算了一次"这类无信息量的埋点，不上报具体日期。
第二条底线是不做虚假承诺。这个工具的匹配区间是娱乐性质，页面里不能写"预测你的真命天子年龄"，也不能引导用户"输入手机号解锁完整报告"。前者是误导，后者是拿用户的隐私换留存，短期数据可能好看，长期口碑一定崩。
第三条底线是不诱导强制分享。有些页面会做成"分享给三个好友才能看结果"，这种设计在趣味小工具上非常伤用户，因为用户本来只是图一乐，被卡一下就走了。我见过做得最好的版本是：结果直接出，分享是可选的，而且分享出去的内容是用户自己满意的那个截图，不是强制带一堆推广信息。
第四条是文案尺度。匹配区间这种东西天然带有情感话题属性，措辞上要克制，用调侃、轻松的语气，别搞成人生指导。用户是来玩的，不是来听人说教的。这一点听起来是文案问题，实际上决定了这类工具能不能被反复使用。
5. 传播侧的观察：为什么这种东西容易被转发
5.1 结果文案的设计技巧
这类工具能火，靠的不是算法有多精妙，而是结果足够"像我"。心理学上把这叫巴纳姆效应：人容易相信一段模糊而普遍适用的描述是在说自己。匹配区间恰好具备这个特质——它给出的是一个范围，而人在读范围的时候会自动往里找符合自己情况的证据，找到一个就觉得"挺准"。
基于这个认知，结果文案有几条实用技巧。一是给范围但不给结论，说"20 到 38 岁"比说"你适合找 27 岁的"更容易被接受，因为范围给了用户解释空间。二是加一个具体到天的细节，"你已经活了 9600 天"这种数字比"你 26 岁"更有冲击力，因为它显得精确、显得算过。三是留一个可讨论的钩子，"你的区间下限定得比同龄人高"这种带比较的表述，会激发用户去问朋友"你的是多少"，从而带来二次传播。
还有一个反直觉的点：不要追求结果的确定性。如果每次算出来都一样，用户玩一次就走了；如果结果里有一部分是会变化的（比如"今天适合主动一点"这种每日变化的文案），用户会隔几天再来。这个设计的关键是让变化的部分看起来有依据，比如按日期做哈希，同一天所有人看到的相同，不同天不同，用户就不会觉得是随机糊弄。
// 按日期做种子，同一天结果稳定，换天会变 function dailyPick(list, seedDate = new Date()) { const key = seedDate.getFullYear() * 10000 + (seedDate.getMonth() + 1) * 100 + seedDate.getDate(); return list[key % list.length]; }这段代码看着简单，但它解决了一个体验问题：用户刷新页面，文案不会乱跳；第二天再来，文案变了，觉得"这工具是活的"。相比之下，Math.random()每次刷新都换一句，反而显得廉价。
5.2 后续可以扩展的方向
如果这个工具跑起来了，想把留存做长一点，有几个低成本的方向可以试。
第一个是纪念日倒计时。用户存了生日之后，顺手加一个"下次生日还有多少天"的常驻卡片，配合"距离你的生日还有 78 天"这种提示，能把一次性工具变成偶尔打开的小组件。实现成本很低，复用现有的nextBirthday函数就行。第二个是双人生日对比。加一个第二输入框，输出年龄差、谁大谁小、两个人的生日相差多少天，这个功能的情侣使用场景很明确，传播路径也清晰。第三个是时间单位换算的趣味展示，把年龄换算成"你活了多少个小时""你大概呼吸了多少次""你走过多少个满月"，这类数字有天然的分享欲，而且算法完全基于已有的天数，不需要新逻辑。
第四个方向稍微重一点：把计算结果做成可保存的图片。前面说过 canvas 的成本，但如果你的目标是把工具做成一个能反复被截图传播的东西，那这笔投入是值得的，因为固定尺寸的图片在社交场景里比网页链接更容易流转。
我自己的判断是，前三个方向加起来工作量不超过一天，第四个要两三天。如果只是试水，先把前三个做了，看数据再决定要不要碰 canvas。至于年龄计算本身，做到精确、做到边界不出错，就已经跑赢市面上大多数同类小工具了——我见过太多版本连闰日都没处理，用户一测就发现不对，然后就没有然后了。
