1. 两个生日输入框背后用户想看到的到底是什么前阵子有位做前端的朋友丢给我一个页面说这东西三天里访问量翻了十几倍代码加起来两百多行问我能不能看看有没有性能隐患。我打开一看页面极简两个日期选择框一个按钮下面一张结果卡片。输入双方生日点一下出来一行字——“你们相差 3 岁 5 个月适合指数 87%属于‘吵完架还能一起吃饭’那一类”。就是这种年龄计算器被叫作恋爱对象生日测试、适合你的对象计算器在各类社交平台上被反复转发。很多人第一反应是“这不就是玄学吗”。拆开看完全不是。它由四块拼起来一块是精确的日期运算负责算出周岁、年龄差、下一个生日倒计时一块是规则表负责把年龄差、星座、生肖翻译成可解释的维度分一块是确定性伪随机保证同一天输入永远出同一个结果最后一块是结果卡片负责让用户愿意截图。这四块里只有第一块要求绝对准确后三块要的是“稳定、好看、有话说”。这篇内容适合三类人看。第一类是想自己做个小工具页面的前端照着代码改改就能上线第二类是对日期计算一直心里没底的人时区、闰年、2 月 29 日这几个坑会一次性讲清楚第三类是做趣味测试类产品的这里面的规则设计和传播逻辑其实是通用的。我下面会把整套东西从规则设计一路写到上线自测代码都是能直接跑的不玩伪代码。先说一个反直觉的判断这类工具的核心难点不在“匹配算法”而在“日期不许错”。用户输入自己的生日看到年龄显示少了一岁会立刻关掉页面后面写得再花哨也没用。可匹配度给 87% 还是 86%没有人会去验证。所以真正该抠细节的地方和大多数人以为的恰好相反。1.1 输入输出的真实清单一个看起来只有两个框的页面实际要处理的信息比想象中多。输入侧通常包括双方出生日期有时加性别、昵称、所在城市。输出侧至少要给出各自的周岁年龄、两人年龄差精确到岁和月、谁年长、年长一方下一个生日还有多少天、各自的星座、生肖以及一个综合匹配分和一段结果文案。把这些列成清单你会发现只有前三项是需要严格计算的硬数据后面全是软数据。软数据的特点是用户不会较真但会拿来对比。同一个人今天测是 87%明天再测变成 62%用户立刻觉得这工具在乱来。所以软数据的核心指标不是“准”而是“可复现”。这两类数据的处理策略必须分开混在一起写代码后面一定出事。1.2 用户点下按钮那一刻的心理预期我观察过一批这类页面的用户行为有个很明显的规律大部分人会先输入自己和某个具体的人看结果然后改成自己和另一个生日再测一次接着会把自己生日改一个数字看看结果变化大不大。也就是说用户实际在做的是“对比实验”而不是“查询计算结果”。这个行为直接决定了三件事。第一结果必须足够快最好在一秒内出不能有加载动画。第二结果必须落在同一屏内不能让用户滑动才看到关键数字。第三也是最重要的——同一个输入必须永远得到同一个输出否则用户做对比实验时会发现破绽信任瞬间归零。这就是为什么后面所有跟分数有关的地方都不能用Math.random()必须用带种子的确定性随机。1.3 三种常见玩法的算法侧重完全不同我把市面上这类工具归成三类它们的实现重心差别很大选错方向会白做很多功。玩法类型典型输出算法重心容易翻车的地方纯年龄差型相差几岁几个月、谁大谁小、生日倒计时日期运算精度时区解析、闰年、跨月天数星座生肖型双方星座、生肖搭配、性格关键词边界日期表星座交界日、生肖以春节还是立春为界综合评分型百分比分数、等级、一段文案维度加权 确定性随机同输入结果不稳定、分数分布全挤在中段纯年龄差型最容易做也最容易被挑错因为它的输出是可验证的客观事实。星座生肖型的难点全在边界日2 月 18 日出生的人到底算水瓶还是双鱼写错一次就会被评论区抓住。综合评分型看起来最复杂实际上最好调因为分数没有对错只要分布够散、文案够有意思就行。我的建议是三者都做但开发顺序反过来先把日期运算这块啃死再做规则表最后做评分和文案。很多人一上来就琢磨文案库结果日期算错前面全白搭。2. 把“适合你的恋爱对象”翻译成一张可落地的规则表“适合”这个词没法直接计算。要让它变成代码必须拆成若干条能判定真假、能打分的规则。这一步是整个项目里最需要想清楚的因为规则一旦定下来后面所有代码都是围着它转。我见过不少人跳过这步直接写写到一半发现规则之间互相打架只能推倒重来。2.1 年龄区间的几种流行算法及取舍最常见的是坊间流传的一个经验公式通常被叫作“半龄加七”年长一方的年龄除以二再加七得到可接受年龄下限上限则是自己的年龄乘二减七。举个例子28 岁的人下限是 28÷2721上限是 28×2-749。这个说法流传很广但它只是一个民间俗语没有任何科学依据写进页面时必须明确标注为娱乐参考。第二种是固定差值法直接给 ±3 岁、±5 岁的区间。优点是直观好懂用户一眼就明白缺点是所有人看到的区间形状完全一样缺少“为我定制”的感觉。第三种是同龄优先加容忍度先判断是否同龄再按差值递减打分。我的实际做法是把三者叠起来用先用半龄公式算出一个宽区间作为主展示再用固定差值算一个窄区间作为“高匹配区间”两个区间都显示出来。这样既有定制感又有明确的对比。需要注意无论用哪种公式都要在页面上写清楚这是趣味参考不能让用户误以为是某种权威结论。2.2 星座和生肖边界日期是唯一的硬骨头星座好办十二个分界日是固定的写一张表就能覆盖。真正的坑在生肖。民俗上以春节为界传统历法上以立春为界两个标准在某些年份会差出十几天。1 月下旬到 2 月中旬出生的人用不同标准算出来的生肖是不一样的。我的处理方式是二选一不要试图两个都算。如果页面主打“民俗趣味”就用春节如果主打“传统属性”就用立春。立春的日期在公历 2 月 3 日到 5 日之间浮动做个近似取 2 月 4 日误差最多一天对趣味工具来说完全够用。想做到精确就得维护一张逐年立春时刻表那是另一个量级的工作性价比很低。星座的分界表我直接给出来这张表我用了很多次没有再手写过// 每个月的星座分界日当日及以后属于后一个星座 const SIGN_EDGE [20, 19, 21, 20, 21, 22, 23, 23, 23, 24, 23, 22]; const SIGN_NAMES [摩羯,水瓶,双鱼,白羊,金牛,双子, 巨蟹,狮子,处女,天秤,天蝎,射手,摩羯]; function getSign(month, day) { // month: 1-12 return day SIGN_EDGE[month - 1] ? SIGN_NAMES[month - 1] : SIGN_NAMES[month]; }这段逻辑值得多看一眼。SIGN_NAMES有 13 个元素首尾都是摩羯这样SIGN_NAMES[month-1]和SIGN_NAMES[month]就分别对应“本月之前的星座”和“本月分界之后的星座”不需要写任何 if 分支。1 月 19 日返回摩羯1 月 20 日返回水瓶12 月 21 日返回射手12 月 22 日返回摩羯四个边界我都验过。2.3 匹配分怎么造才不像随便写的分数要让人信服关键在“可解释”。如果只给一个百分比用户会觉得是随机数如果给出“年龄接近度 82 分、星座契合 75 分、生日数字共振 91 分”用户就会觉得这工具挺认真。所以我一般拆成四到五个维度每个维度 0 到 100 分再加权求和。维度一年龄接近度。差值越小分越高但要留一个缓冲不要线性递减到底。我的写法是Math.max(0, 100 - diff * 8)差 0 岁 100 分差 5 岁 60 分差 12 岁 4 分。维度二星座元素。火象、土象、风象、水象同元素加分相邻元素次之对冲元素再减。这张对应表可以自己定但一旦定了就不能改否则老用户回来看结果变了会出问题。维度三生日数字。把两个生日的年月日数字加起来反复求和到个位数两边相同给高分相差 1 给次高分。这一步纯属趣味但对用户来说“数字共振”听起来很有说服力。维度四生肖关系。三合、六合给高分相冲给低分其余给中间值。最后一步也是最容易被忽略的一步用一个确定性的伪随机数在加权总分上加一个很小的扰动范围控制在正负 3 分以内。这一步的作用是打破整数规律让 84、87、91 这种数字看起来更自然。但种子必须来自双方生日字符串本身不能用时间戳否则同一个人刷新两次结果就不一样了。function hashStr(s) { let h 2166136261; for (let i 0; i s.length; i) { h ^ s.charCodeAt(i); h Math.imul(h, 16777619); } return h 0; } function seededRandom(seed) { let s seed 0; return function () { s (Math.imul(s, 1664525) 1013904223) 0; return s / 4294967296; }; }这两段是我常用的组合先把字符串压成一个 32 位整数再用线性同余生成器造一个随机序列。同样的生日字符串永远得到同一个序列扰动是稳定的前端、后端算出来也一致不需要把分数存数据库。2.4 文案库的分档与选取方式分数出来之后得配一句话。文案不能每条单独写要分档。我一般分四档85 分以上、70 到 84、55 到 69、55 以下。每档准备八到十二条用前面那个确定性随机数取模选一条。分档的关键是分寸感。85 分以上不能写得像营销号什么“天生一对”“命中注定”用户会尴尬55 分以下也不能真写“你们不合适”那等于给用户添堵。我的经验是高分档写具体生活场景比如“属于吵完架还能一起吃饭的那种”低分档写“节奏不同但互补”把负面转成正面的差异化描述。用户要的是能发出去不丢人的一句话不是判决书。还有一个细节文案里最好留一处可以替换的成分比如把双方星座或者年龄差嵌进去。同样是高分档一条写“你们相差两岁步调几乎是同步的”另一条写“相差七岁但聊天完全不卡壳”比通用文案的传播效果明显好。这个替换用字符串模板就能做成本很低。3. 从零搭一个能直接跑的单页版本规则想清楚了代码其实不长。我按自己习惯的顺序写先搭 HTML 骨架再写日期核心函数然后接规则表最后做结果卡片。每一步都能单独验证出问题好定位。3.1 HTML 骨架与交互流程页面不需要框架原生就行。核心元素就几个两个日期输入框、一个按钮、一个结果容器、一个隐藏的 canvas。div classcalc label你的生日 input typedate idbirthA/label label对方生日 input typedate idbirthB/label button idcalcBtn开始计算/button div idresult classresult hidden/div canvas idcard width750 height1000 hidden/canvas /div用typedate有个好处移动端会直接弹出日期选择器用户不会乱输格式。但它也有个坑不同浏览器对空值和非法值的处理不一样有些返回空字符串有些在某些旧版本里会返回奇怪的占位值。所以在读取时一定要做格式校验不能直接扔给new Date()。交互流程我固定成三步校验输入、计算结果、渲染卡片。中间任何一步失败都直接提示不做静默降级。比如日期格式不合法就明确告诉用户“请选择完整日期”不要显示一个 0 岁的结果糊弄过去。3.2 日期核心函数精度优先这几个函数是整个项目的底座我单独拎出来讲因为它们决定了结果可不可信。// 严格解析 YYYY-MM-DD返回本地时区的 Date function parseDateLocal(str) { const m /^(\d{4})-(\d{2})-(\d{2})$/.exec(String(str).trim()); if (!m) return null; const y m[1], mo m[2], d m[3]; const dt new Date(y, mo - 1, d); if (dt.getFullYear() ! y || dt.getMonth() ! mo - 1 || dt.getDate() ! d) { return null; // 拦截 2 月 30 日这类非法日期 } return dt; } // 在参考日期当天的周岁 function ageOn(birth, ref) { let a ref.getFullYear() - birth.getFullYear(); const m ref.getMonth() - birth.getMonth(); if (m 0 || (m 0 ref.getDate() birth.getDate())) a--; return a; } // 年龄差返回 {years, months, days}保证 a 早于 b function diffAge(a, b) { if (a b) { const t a; a b; b t; } let years b.getFullYear() - a.getFullYear(); let months b.getMonth() - a.getMonth(); let days b.getDate() - a.getDate(); if (days 0) { months--; const prevMonthDays new Date(b.getFullYear(), b.getMonth(), 0).getDate(); days prevMonthDays; } if (months 0) { years--; months 12; } return { years, months, days }; }diffAge里那个new Date(b.getFullYear(), b.getMonth(), 0).getDate()是取上个月的天数第二个参数传 0 就自动回到上个月最后一天。这是 JS 里一个很好用但很多人不知道的写法比手写一张各月天数表省事也不会漏掉闰年的 2 月。parseDateLocal里那段回读校验千万别省。new Date(2023, 1, 30)不会报错它会自动变成 3 月 2 日。用户手动输入日期时这种情况不常见但接口传参、URL 带参的时候遇到非法值没有这层校验就会算出一个看着正常其实错得很离谱的结果。3.3 规则表与匹配分的组装有了日期函数剩下的就是把规则接上。我一般写一个evaluate(dateA, dateB)函数返回一个对象把所有要展示的数据一次性算完这样渲染层不用关心计算逻辑。function evaluate(dA, dB) { const today new Date(); const seedStr ${dA.getFullYear()}-${dA.getMonth()}-${dA.getDate()}| ${dB.getFullYear()}-${dB.getMonth()}-${dB.getDate()}; const rnd seededRandom(hashStr(seedStr)); const diff diffAge(dA, dB); const absDiffYears diff.years (diff.months 6 ? 1 : 0); // 维度一年龄接近度 const scoreAge Math.max(0, 100 - absDiffYears * 8); // 维度二星座元素 const signA getSign(dA.getMonth() 1, dA.getDate()); const signB getSign(dB.getMonth() 1, dB.getDate()); const scoreSign signScore(signA, signB); // 维度三数字共振 const numA digitalRoot(dA), numB digitalRoot(dB); const scoreNum numA numB ? 90 : Math.max(40, 90 - Math.abs(numA - numB) * 12); // 维度四生肖关系 const scoreZodiac zodiacScore(dA, dB); const base scoreAge * 0.4 scoreSign * 0.25 scoreNum * 0.2 scoreZodiac * 0.15; const final Math.round(Math.min(99, Math.max(41, base (rnd() * 6 - 3)))); return { diff, absDiffYears, signA, signB, final, seed: hashStr(seedStr) }; }注意最后那个夹取范围我限定在 41 到 99 之间。为什么不从 0 开始因为这类页面的用户心理很微妙给个 23% 会让人不舒服给 99% 又显得假41 到 99 这个区间看起来最自然也保证了不会出现两位数以下的分数。这只是经验值可以按自己页面的调性调整。权重也不是随便定的。年龄占四成因为用户最在意这个星座两成半因为它最常被拿来讨论数字共振两成属于听觉上很有说服力的趣味项生肖一成半主要是给有这类偏好的用户一个交代。权重调完之后一定要用一批样本跑一遍看分数分布是不是挤在一起。如果九成结果都落在 70 到 80 之间说明各项区分度不够得加大权重差异。3.4 用 canvas 把结果画成可保存的卡片用户愿不愿意转发八成取决于卡片好不好看。canvas 方案的好处是纯前端实现画完直接toDataURL()就能保存。function drawCard(ctx, data) { const W 750, H 1000; ctx.fillStyle #fdf6f0; ctx.fillRect(0, 0, W, H); ctx.fillStyle #2b2b2b; ctx.font bold 48px sans-serif; ctx.textAlign center; ctx.fillText(${data.signA} × ${data.signB}, W / 2, 180); ctx.font bold 160px sans-serif; ctx.fillStyle #e2694f; ctx.fillText(${data.final}%, W / 2, 400); ctx.font 36px sans-serif; ctx.fillStyle #555; ctx.fillText(你们相差 ${data.diff.years} 岁 ${data.diff.months} 个月, W / 2, 500); ctx.fillText(data.text, W / 2, 600); ctx.font 26px sans-serif; ctx.fillStyle #999; ctx.fillText(趣味测试仅供娱乐, W / 2, H - 60); }这段代码里有几个实操细节。第一canvas 的尺寸要设成实际像素的两倍左右750×1000 在手机上看清晰度刚好设太大会内存吃紧太小会糊。第二字体一律用sans-serif不要指定具体字体名不同设备上缺失字体会回退成奇怪的样子导致文字错位。第三底部那句免责说明别省它既是合规需要也是让用户觉得这工具“有点分寸”的小细节。文字长度也得控制。结果文案我一般限制在 18 个字以内超过就会在 canvas 里换行换行逻辑写不好很容易压到下一行。与其在绘制阶段折腾自动折行不如在文案库里就把长度卡死省一大截事。4. 日期计算里那些能让结果差一天的细节这部分是我踩坑最多的地方。前面说过日期数据是用户会较真的差一天就露馅。下面这几个问题几乎每个做这类工具的人都会遇到至少一个。4.1 new Date(1998-03-05) 的时区陷阱这可能是最经典的一个。new Date(1998-03-05)里的短横线格式按规范会被解析成 UTC 时间也就是 1998 年 3 月 5 日零点零分零秒 UTC。如果你在 UTC8 时区转换成当地时间就是 3 月 5 日早上 8 点没问题但如果你在 UTC-5 时区就变成 3 月 4 日晚上 7 点getDate()返回的是 4。结果就是同一份代码不同时区的用户看到的生日差了一天。更麻烦的是这种 bug 很难复现你的测试机在东八区一切正常用户在西半球就报错。解决办法就是前面那个parseDateLocal把字符串拆成数字再用new Date(y, m-1, d)构造。这种写法明确表示“本地时间的这个日期”完全绕开时区解析。我现在的习惯是凡是涉及用户输入日期的一律不走字符串直接构造全部手动拆。写法解析方式风险new Date(1998-03-05)按 UTC 解析负时区日期回退一天new Date(1998/03/05)按本地时间解析各浏览器历史上实现不一致new Date(1998, 2, 5)明确本地时间推荐无歧义手动拆分后构造明确本地时间可同时做合法性校验最稳4.2 2 月 29 日出生的人怎么算生日闰日出生是个绕不开的边界。到了平年2 月 29 日出生的人没有对应的日期。有几种处理方式各有各的道理。第一种平年按 2 月 28 日过。好处是日期不会跨月坏处是差一天。第二种平年按 3 月 1 日过这在某些地区的习惯里更常见。第三种不特殊处理直接按“下一个 2 月 29 日”算那就是四年一次倒计时会显示一千多天用户看到会懵。我的做法是计算周岁年龄时按 3 月 1 日算也就是 2 月 28 日当天还不满3 月 1 日才满计算下一个生日倒计时时同样按 3 月 1 日。这样两个地方口径一致不会出现“年龄已经满 20 但倒计时还显示 300 天”这种自相矛盾的情况。关键是口径统一选哪个都能接受前后不一致才是最糟的。4.3 倒计时的边界今天算不算“距离下一个生日还有 X 天”这个 X 在今天恰好是生日的时候应该是 0 还是 365看起来是个小问题实际影响很大。如果今天就是生日算成 365 天用户会觉得这工具连自己生日都识别不出来。正确的写法是把时间都归零到当天零点再相减避免因为时分秒不同导致结果多一天或少一天。function daysToNextBirthday(birth, today) { const t new Date(today.getFullYear(), today.getMonth(), today.getDate()); let next new Date(t.getFullYear(), birth.getMonth(), birth.getDate()); // 2 月 29 日出生平年顺延到 3 月 1 日 if (next.getMonth() ! birth.getMonth()) { next new Date(t.getFullYear(), birth.getMonth() 1, 1); } if (next t) { next new Date(t.getFullYear() 1, birth.getMonth(), birth.getDate()); if (next.getMonth() ! birth.getMonth()) { next new Date(t.getFullYear() 1, birth.getMonth() 1, 1); } } return Math.round((next - t) / 86400000); }这里必须用Math.round而不是Math.floor。因为夏令时切换的日子一天可能是 23 小时或 25 小时直接除会得到 0.958 或 1.042 这样的数向下取整就会错一天。这个问题在不少地区真实存在本地测试永远测不出来一定要用Math.round兜住。4.4 年龄差里“几个月”的口径问题两个人相差 1 年 11 个月 30 天和相差 2 年 0 个月 0 天哪个说法更准确这取决于你怎么定义“一个月”。按自然月算和按 30 天算结果会差好几天。我用的是自然月口径也就是前面diffAge那套逻辑先算年和月再处理天数借位。这样 1 月 31 日到 3 月 1 日会被算成 1 个月 1 天。看起来有点怪但它和人们日常说的“差了一个月”是一致的。另一种口径是按总天数除以 30.44 再拆好处是数学上更平滑坏处是用户拿日历一对就发现对不上。既然这类页面的用户核心动作是“验证”那就必须选能被日历验证的口径。这条经验适用范围很广凡是用户会核对的数字都要优先选择“符合直觉”而不是“数学上更优雅”的实现。5. 结果页决定传播半径卡片、文案与二次打开算得再准如果结果页做得没意思用户看完就关。这类工具的价值几乎全在结果页所以这一块值得单独花时间。5.1 结果卡片的排版优先级我见过不少页面把一个巨大的百分比放在正中其他信息全挤在下面一行小字里。这个优先级是反的。用户真正会截图发出去的理由从高到低大概是一句有意思的文案、两个星座的组合、年龄差、分数。分数其实排最后因为分数谁都有文案才是差异化的地方。所以我的排版顺序是顶部放双方星座或者生肖的组合标题中间放那句文案字号要大占视觉重心下面一行放年龄差和分数字号中等最底下放一个日期或者一句小尾巴。整体配色控制在三色以内主色只用在分数和一两个关键词上其他地方留白。还有一个细节是安全边距。用户截图的时候不一定按整张卡片截边距留得太少文字容易被裁掉一半。我一般四周各留 60 像素以上底部再额外留 80 像素避免被聊天框的输入栏挡住。5.2 分享文案的三套模板卡片是一回事用户发出去配什么文字是另一回事。很多人会直接复制页面上的文案所以页面上必须提供一句“可以直接抄”的话。我常用三套模板。第一套是结论型直接给判断比如“我们相差三岁适合指数 87%好像有点道理”。第二套是反问型制造互动比如“87% 是什么概念有人来对一下吗”。第三套是自嘲型适合低分结果比如“41%行吧确实经常吵架”。三套覆盖了高、中、低三种分数的情绪用户不管测出什么都能找到合适的表达。这里有个小技巧在结果页给一个“复制文案”按钮把文案和分数一起复制到剪贴板。别看这一步简单它能把分享率拉高一截因为用户不用自己想说什么。剪贴板 API 在部分环境里需要用户手势触发所以一定要绑在点击事件上不要放在页面加载时自动调用。5.3 让人愿意再打开一次的钩子一次性的工具用户测完就走。想让他再来得留个钩子。我试过效果比较好的有两种。一种是“换个生日再测”。在结果页底部放一句“换个人的生日试试”并且把对方生日的输入框保留在上一次的值只清空自己这一侧。用户下次来测另一个人一个框都不用改。这个设计的核心是减少操作步骤从三次点击降到一次。另一种是“今日限定”。用日期做种子每天的结果文案不同但同一天内保持稳定。用户发现今天和昨天看到的话不一样会再点一次。注意这里必须用日期做种子而不是随机数否则同一天刷新两次结果就变了反而破坏信任。种子取当天的年月日拼接字符串就行和前面那套确定性随机的逻辑完全复用。5.4 低端机和长截图的性能细节这类页面经常在手机上打开而且很多是老旧机型。canvas 绘制有两个地方容易卡一是尺寸设得太大二是字体渲染。尺寸方面750×1000 的 canvas 在多数手机上是没问题的但如果再加阴影、渐变、模糊效果绘制耗时会明显上升。我的原则是卡片上的装饰元素不超过两个尽量用纯色块代替渐变。另一个容易出问题的是toDataURL()。在部分浏览器里如果 canvas 尺寸过大这个调用会返回空字符串。解决办法是绘制完成后先检查返回值长度如果太短就降级到另一种尺寸重绘一次或者干脆提示用户直接截屏。这个兜底逻辑看起来多余但线上真的会遇到。6. 上线前的自测清单与线上问题的定位路径写到这儿功能基本齐了。但这类工具的性质决定了它一定会被用户拿去“找茬”所以自测环节不能省。我整理了一份自己每次都跑的用例表覆盖了绝大多数会被挑出来的问题。6.1 一份可以照着跑的测试用例表用例输入预期结果关注点同日出生两边生日完全相同相差 0 岁 0 月分数应偏高不能出现负数年龄差一天1990-05-01 与 1990-05-020 岁 0 月 1 天天数不能因为时区变生日当天今天是某方生日倒计时为 0不能显示 365闰日出生2000-02-29平年按 3 月 1 日处理年龄与倒计时口径一致跨年1999-12-31 与 2000-01-01相差 1 天年份计算不能差 1非法日期2023-02-30明确提示格式错误不能静默变成 3 月 2 日未来日期生日填 2099 年提示不可用或年龄为负的处理不能出现荒谬结果重复计算同一输入连点五次五次结果完全一致验证确定性随机这张表我一般会加上时区模拟把设备时区改到 UTC-8 再跑一遍。很多日期相关的 bug 只有换时区才暴露本地怎么点都正常。6.2 用户反馈“算错了”的三步定位线上收到这类反馈不要急着改代码先按顺序排查三个地方。第一步问清楚用户输入的具体日期和看到的输出。很多时候不是算错是用户自己填错了年份或者用了虚岁去对比周岁。这类占了相当大的比例。第二步确认时区。如果用户的设备时区和你不一样前面说的字符串解析问题就会显现。让用户报一下结果页显示的年龄和实际年龄差多少差一天基本可以锁定是这个问题。第三步确认生日是否落在边界日。2 月 29 日、星座交界日、生肖分界日附近都是高发区。这几个地方的处理逻辑本来就特殊用户产生疑问是完全正常的。我遇到过一次比较典型的用户反馈同一个人测两次分数不一样。查下来发现代码里有一处复合分数用到了new Date().getSeconds()做扰动。这个值每秒都在变自然不稳定。这类问题靠看代码很难发现必须靠“同一输入连点五次”的用例去卡。6.3 数据侧只看三个指标如果页面接了统计指标不要堆太多看三个就够。第一个是计算完成率也就是打开页面到点下按钮的比例。这个数低说明输入框设计有问题或者用户不知道要填什么。第二个是卡片保存率也就是结果出来后点击保存或截图的估算比例这个数直接反映结果页的吸引力。第三个是重复计算率同一设备短时间内多次计算的占比它衡量的是用户有没有在做对比实验。这三个指标比访问量有用得多。访问量涨可能只是某条内容碰巧火了但重复计算率高说明工具本身留得住人。我自己调这类页面时改文案和改卡片优先级通常比改算法带来的数据变化大得多。6.4 措辞上的分寸感最后说个容易被忽略的点页面上的措辞。这类工具本质是娱乐但用户会把它当回事尤其涉及年龄和关系的时候。所以有几句话必须有结果仅供娱乐参考、分数不代表任何真实判断、不要用它做决定。这些话不要做成弹窗就放在结果页底部一行小字既不打扰体验又表明了态度。另外输入框旁边的提示语也值得琢磨。写“请选择你的生日”比写“请输入出生年月日”亲和写“对方的生日”比写“TA 的出生日期”自然。这类小细节不涉及技术但对完成率的影响比想象中大。我自己反复做下来最深的体会是这类工具的技术门槛极低真正拉开差距的是对“用户会怎么用”的预判。用户不是来查年龄的他是来验证一个心里已有的猜测然后找一句话替自己说出来。所以日期必须准到一分不差文案必须软到不像下结论中间那套评分规则只要稳定、可解释、有变化就足够了。做这类东西先把日期运算这几行代码写扎实再谈其他顺序错了会返工很多次。
1. 两个生日输入框背后用户想看到的到底是什么前阵子有位做前端的朋友丢给我一个页面说这东西三天里访问量翻了十几倍代码加起来两百多行问我能不能看看有没有性能隐患。我打开一看页面极简两个日期选择框一个按钮下面一张结果卡片。输入双方生日点一下出来一行字——“你们相差 3 岁 5 个月适合指数 87%属于‘吵完架还能一起吃饭’那一类”。就是这种年龄计算器被叫作恋爱对象生日测试、适合你的对象计算器在各类社交平台上被反复转发。很多人第一反应是“这不就是玄学吗”。拆开看完全不是。它由四块拼起来一块是精确的日期运算负责算出周岁、年龄差、下一个生日倒计时一块是规则表负责把年龄差、星座、生肖翻译成可解释的维度分一块是确定性伪随机保证同一天输入永远出同一个结果最后一块是结果卡片负责让用户愿意截图。这四块里只有第一块要求绝对准确后三块要的是“稳定、好看、有话说”。这篇内容适合三类人看。第一类是想自己做个小工具页面的前端照着代码改改就能上线第二类是对日期计算一直心里没底的人时区、闰年、2 月 29 日这几个坑会一次性讲清楚第三类是做趣味测试类产品的这里面的规则设计和传播逻辑其实是通用的。我下面会把整套东西从规则设计一路写到上线自测代码都是能直接跑的不玩伪代码。先说一个反直觉的判断这类工具的核心难点不在“匹配算法”而在“日期不许错”。用户输入自己的生日看到年龄显示少了一岁会立刻关掉页面后面写得再花哨也没用。可匹配度给 87% 还是 86%没有人会去验证。所以真正该抠细节的地方和大多数人以为的恰好相反。1.1 输入输出的真实清单一个看起来只有两个框的页面实际要处理的信息比想象中多。输入侧通常包括双方出生日期有时加性别、昵称、所在城市。输出侧至少要给出各自的周岁年龄、两人年龄差精确到岁和月、谁年长、年长一方下一个生日还有多少天、各自的星座、生肖以及一个综合匹配分和一段结果文案。把这些列成清单你会发现只有前三项是需要严格计算的硬数据后面全是软数据。软数据的特点是用户不会较真但会拿来对比。同一个人今天测是 87%明天再测变成 62%用户立刻觉得这工具在乱来。所以软数据的核心指标不是“准”而是“可复现”。这两类数据的处理策略必须分开混在一起写代码后面一定出事。1.2 用户点下按钮那一刻的心理预期我观察过一批这类页面的用户行为有个很明显的规律大部分人会先输入自己和某个具体的人看结果然后改成自己和另一个生日再测一次接着会把自己生日改一个数字看看结果变化大不大。也就是说用户实际在做的是“对比实验”而不是“查询计算结果”。这个行为直接决定了三件事。第一结果必须足够快最好在一秒内出不能有加载动画。第二结果必须落在同一屏内不能让用户滑动才看到关键数字。第三也是最重要的——同一个输入必须永远得到同一个输出否则用户做对比实验时会发现破绽信任瞬间归零。这就是为什么后面所有跟分数有关的地方都不能用Math.random()必须用带种子的确定性随机。1.3 三种常见玩法的算法侧重完全不同我把市面上这类工具归成三类它们的实现重心差别很大选错方向会白做很多功。玩法类型典型输出算法重心容易翻车的地方纯年龄差型相差几岁几个月、谁大谁小、生日倒计时日期运算精度时区解析、闰年、跨月天数星座生肖型双方星座、生肖搭配、性格关键词边界日期表星座交界日、生肖以春节还是立春为界综合评分型百分比分数、等级、一段文案维度加权 确定性随机同输入结果不稳定、分数分布全挤在中段纯年龄差型最容易做也最容易被挑错因为它的输出是可验证的客观事实。星座生肖型的难点全在边界日2 月 18 日出生的人到底算水瓶还是双鱼写错一次就会被评论区抓住。综合评分型看起来最复杂实际上最好调因为分数没有对错只要分布够散、文案够有意思就行。我的建议是三者都做但开发顺序反过来先把日期运算这块啃死再做规则表最后做评分和文案。很多人一上来就琢磨文案库结果日期算错前面全白搭。2. 把“适合你的恋爱对象”翻译成一张可落地的规则表“适合”这个词没法直接计算。要让它变成代码必须拆成若干条能判定真假、能打分的规则。这一步是整个项目里最需要想清楚的因为规则一旦定下来后面所有代码都是围着它转。我见过不少人跳过这步直接写写到一半发现规则之间互相打架只能推倒重来。2.1 年龄区间的几种流行算法及取舍最常见的是坊间流传的一个经验公式通常被叫作“半龄加七”年长一方的年龄除以二再加七得到可接受年龄下限上限则是自己的年龄乘二减七。举个例子28 岁的人下限是 28÷2721上限是 28×2-749。这个说法流传很广但它只是一个民间俗语没有任何科学依据写进页面时必须明确标注为娱乐参考。第二种是固定差值法直接给 ±3 岁、±5 岁的区间。优点是直观好懂用户一眼就明白缺点是所有人看到的区间形状完全一样缺少“为我定制”的感觉。第三种是同龄优先加容忍度先判断是否同龄再按差值递减打分。我的实际做法是把三者叠起来用先用半龄公式算出一个宽区间作为主展示再用固定差值算一个窄区间作为“高匹配区间”两个区间都显示出来。这样既有定制感又有明确的对比。需要注意无论用哪种公式都要在页面上写清楚这是趣味参考不能让用户误以为是某种权威结论。2.2 星座和生肖边界日期是唯一的硬骨头星座好办十二个分界日是固定的写一张表就能覆盖。真正的坑在生肖。民俗上以春节为界传统历法上以立春为界两个标准在某些年份会差出十几天。1 月下旬到 2 月中旬出生的人用不同标准算出来的生肖是不一样的。我的处理方式是二选一不要试图两个都算。如果页面主打“民俗趣味”就用春节如果主打“传统属性”就用立春。立春的日期在公历 2 月 3 日到 5 日之间浮动做个近似取 2 月 4 日误差最多一天对趣味工具来说完全够用。想做到精确就得维护一张逐年立春时刻表那是另一个量级的工作性价比很低。星座的分界表我直接给出来这张表我用了很多次没有再手写过// 每个月的星座分界日当日及以后属于后一个星座 const SIGN_EDGE [20, 19, 21, 20, 21, 22, 23, 23, 23, 24, 23, 22]; const SIGN_NAMES [摩羯,水瓶,双鱼,白羊,金牛,双子, 巨蟹,狮子,处女,天秤,天蝎,射手,摩羯]; function getSign(month, day) { // month: 1-12 return day SIGN_EDGE[month - 1] ? SIGN_NAMES[month - 1] : SIGN_NAMES[month]; }这段逻辑值得多看一眼。SIGN_NAMES有 13 个元素首尾都是摩羯这样SIGN_NAMES[month-1]和SIGN_NAMES[month]就分别对应“本月之前的星座”和“本月分界之后的星座”不需要写任何 if 分支。1 月 19 日返回摩羯1 月 20 日返回水瓶12 月 21 日返回射手12 月 22 日返回摩羯四个边界我都验过。2.3 匹配分怎么造才不像随便写的分数要让人信服关键在“可解释”。如果只给一个百分比用户会觉得是随机数如果给出“年龄接近度 82 分、星座契合 75 分、生日数字共振 91 分”用户就会觉得这工具挺认真。所以我一般拆成四到五个维度每个维度 0 到 100 分再加权求和。维度一年龄接近度。差值越小分越高但要留一个缓冲不要线性递减到底。我的写法是Math.max(0, 100 - diff * 8)差 0 岁 100 分差 5 岁 60 分差 12 岁 4 分。维度二星座元素。火象、土象、风象、水象同元素加分相邻元素次之对冲元素再减。这张对应表可以自己定但一旦定了就不能改否则老用户回来看结果变了会出问题。维度三生日数字。把两个生日的年月日数字加起来反复求和到个位数两边相同给高分相差 1 给次高分。这一步纯属趣味但对用户来说“数字共振”听起来很有说服力。维度四生肖关系。三合、六合给高分相冲给低分其余给中间值。最后一步也是最容易被忽略的一步用一个确定性的伪随机数在加权总分上加一个很小的扰动范围控制在正负 3 分以内。这一步的作用是打破整数规律让 84、87、91 这种数字看起来更自然。但种子必须来自双方生日字符串本身不能用时间戳否则同一个人刷新两次结果就不一样了。function hashStr(s) { let h 2166136261; for (let i 0; i s.length; i) { h ^ s.charCodeAt(i); h Math.imul(h, 16777619); } return h 0; } function seededRandom(seed) { let s seed 0; return function () { s (Math.imul(s, 1664525) 1013904223) 0; return s / 4294967296; }; }这两段是我常用的组合先把字符串压成一个 32 位整数再用线性同余生成器造一个随机序列。同样的生日字符串永远得到同一个序列扰动是稳定的前端、后端算出来也一致不需要把分数存数据库。2.4 文案库的分档与选取方式分数出来之后得配一句话。文案不能每条单独写要分档。我一般分四档85 分以上、70 到 84、55 到 69、55 以下。每档准备八到十二条用前面那个确定性随机数取模选一条。分档的关键是分寸感。85 分以上不能写得像营销号什么“天生一对”“命中注定”用户会尴尬55 分以下也不能真写“你们不合适”那等于给用户添堵。我的经验是高分档写具体生活场景比如“属于吵完架还能一起吃饭的那种”低分档写“节奏不同但互补”把负面转成正面的差异化描述。用户要的是能发出去不丢人的一句话不是判决书。还有一个细节文案里最好留一处可以替换的成分比如把双方星座或者年龄差嵌进去。同样是高分档一条写“你们相差两岁步调几乎是同步的”另一条写“相差七岁但聊天完全不卡壳”比通用文案的传播效果明显好。这个替换用字符串模板就能做成本很低。3. 从零搭一个能直接跑的单页版本规则想清楚了代码其实不长。我按自己习惯的顺序写先搭 HTML 骨架再写日期核心函数然后接规则表最后做结果卡片。每一步都能单独验证出问题好定位。3.1 HTML 骨架与交互流程页面不需要框架原生就行。核心元素就几个两个日期输入框、一个按钮、一个结果容器、一个隐藏的 canvas。div classcalc label你的生日 input typedate idbirthA/label label对方生日 input typedate idbirthB/label button idcalcBtn开始计算/button div idresult classresult hidden/div canvas idcard width750 height1000 hidden/canvas /div用typedate有个好处移动端会直接弹出日期选择器用户不会乱输格式。但它也有个坑不同浏览器对空值和非法值的处理不一样有些返回空字符串有些在某些旧版本里会返回奇怪的占位值。所以在读取时一定要做格式校验不能直接扔给new Date()。交互流程我固定成三步校验输入、计算结果、渲染卡片。中间任何一步失败都直接提示不做静默降级。比如日期格式不合法就明确告诉用户“请选择完整日期”不要显示一个 0 岁的结果糊弄过去。3.2 日期核心函数精度优先这几个函数是整个项目的底座我单独拎出来讲因为它们决定了结果可不可信。// 严格解析 YYYY-MM-DD返回本地时区的 Date function parseDateLocal(str) { const m /^(\d{4})-(\d{2})-(\d{2})$/.exec(String(str).trim()); if (!m) return null; const y m[1], mo m[2], d m[3]; const dt new Date(y, mo - 1, d); if (dt.getFullYear() ! y || dt.getMonth() ! mo - 1 || dt.getDate() ! d) { return null; // 拦截 2 月 30 日这类非法日期 } return dt; } // 在参考日期当天的周岁 function ageOn(birth, ref) { let a ref.getFullYear() - birth.getFullYear(); const m ref.getMonth() - birth.getMonth(); if (m 0 || (m 0 ref.getDate() birth.getDate())) a--; return a; } // 年龄差返回 {years, months, days}保证 a 早于 b function diffAge(a, b) { if (a b) { const t a; a b; b t; } let years b.getFullYear() - a.getFullYear(); let months b.getMonth() - a.getMonth(); let days b.getDate() - a.getDate(); if (days 0) { months--; const prevMonthDays new Date(b.getFullYear(), b.getMonth(), 0).getDate(); days prevMonthDays; } if (months 0) { years--; months 12; } return { years, months, days }; }diffAge里那个new Date(b.getFullYear(), b.getMonth(), 0).getDate()是取上个月的天数第二个参数传 0 就自动回到上个月最后一天。这是 JS 里一个很好用但很多人不知道的写法比手写一张各月天数表省事也不会漏掉闰年的 2 月。parseDateLocal里那段回读校验千万别省。new Date(2023, 1, 30)不会报错它会自动变成 3 月 2 日。用户手动输入日期时这种情况不常见但接口传参、URL 带参的时候遇到非法值没有这层校验就会算出一个看着正常其实错得很离谱的结果。3.3 规则表与匹配分的组装有了日期函数剩下的就是把规则接上。我一般写一个evaluate(dateA, dateB)函数返回一个对象把所有要展示的数据一次性算完这样渲染层不用关心计算逻辑。function evaluate(dA, dB) { const today new Date(); const seedStr ${dA.getFullYear()}-${dA.getMonth()}-${dA.getDate()}| ${dB.getFullYear()}-${dB.getMonth()}-${dB.getDate()}; const rnd seededRandom(hashStr(seedStr)); const diff diffAge(dA, dB); const absDiffYears diff.years (diff.months 6 ? 1 : 0); // 维度一年龄接近度 const scoreAge Math.max(0, 100 - absDiffYears * 8); // 维度二星座元素 const signA getSign(dA.getMonth() 1, dA.getDate()); const signB getSign(dB.getMonth() 1, dB.getDate()); const scoreSign signScore(signA, signB); // 维度三数字共振 const numA digitalRoot(dA), numB digitalRoot(dB); const scoreNum numA numB ? 90 : Math.max(40, 90 - Math.abs(numA - numB) * 12); // 维度四生肖关系 const scoreZodiac zodiacScore(dA, dB); const base scoreAge * 0.4 scoreSign * 0.25 scoreNum * 0.2 scoreZodiac * 0.15; const final Math.round(Math.min(99, Math.max(41, base (rnd() * 6 - 3)))); return { diff, absDiffYears, signA, signB, final, seed: hashStr(seedStr) }; }注意最后那个夹取范围我限定在 41 到 99 之间。为什么不从 0 开始因为这类页面的用户心理很微妙给个 23% 会让人不舒服给 99% 又显得假41 到 99 这个区间看起来最自然也保证了不会出现两位数以下的分数。这只是经验值可以按自己页面的调性调整。权重也不是随便定的。年龄占四成因为用户最在意这个星座两成半因为它最常被拿来讨论数字共振两成属于听觉上很有说服力的趣味项生肖一成半主要是给有这类偏好的用户一个交代。权重调完之后一定要用一批样本跑一遍看分数分布是不是挤在一起。如果九成结果都落在 70 到 80 之间说明各项区分度不够得加大权重差异。3.4 用 canvas 把结果画成可保存的卡片用户愿不愿意转发八成取决于卡片好不好看。canvas 方案的好处是纯前端实现画完直接toDataURL()就能保存。function drawCard(ctx, data) { const W 750, H 1000; ctx.fillStyle #fdf6f0; ctx.fillRect(0, 0, W, H); ctx.fillStyle #2b2b2b; ctx.font bold 48px sans-serif; ctx.textAlign center; ctx.fillText(${data.signA} × ${data.signB}, W / 2, 180); ctx.font bold 160px sans-serif; ctx.fillStyle #e2694f; ctx.fillText(${data.final}%, W / 2, 400); ctx.font 36px sans-serif; ctx.fillStyle #555; ctx.fillText(你们相差 ${data.diff.years} 岁 ${data.diff.months} 个月, W / 2, 500); ctx.fillText(data.text, W / 2, 600); ctx.font 26px sans-serif; ctx.fillStyle #999; ctx.fillText(趣味测试仅供娱乐, W / 2, H - 60); }这段代码里有几个实操细节。第一canvas 的尺寸要设成实际像素的两倍左右750×1000 在手机上看清晰度刚好设太大会内存吃紧太小会糊。第二字体一律用sans-serif不要指定具体字体名不同设备上缺失字体会回退成奇怪的样子导致文字错位。第三底部那句免责说明别省它既是合规需要也是让用户觉得这工具“有点分寸”的小细节。文字长度也得控制。结果文案我一般限制在 18 个字以内超过就会在 canvas 里换行换行逻辑写不好很容易压到下一行。与其在绘制阶段折腾自动折行不如在文案库里就把长度卡死省一大截事。4. 日期计算里那些能让结果差一天的细节这部分是我踩坑最多的地方。前面说过日期数据是用户会较真的差一天就露馅。下面这几个问题几乎每个做这类工具的人都会遇到至少一个。4.1 new Date(1998-03-05) 的时区陷阱这可能是最经典的一个。new Date(1998-03-05)里的短横线格式按规范会被解析成 UTC 时间也就是 1998 年 3 月 5 日零点零分零秒 UTC。如果你在 UTC8 时区转换成当地时间就是 3 月 5 日早上 8 点没问题但如果你在 UTC-5 时区就变成 3 月 4 日晚上 7 点getDate()返回的是 4。结果就是同一份代码不同时区的用户看到的生日差了一天。更麻烦的是这种 bug 很难复现你的测试机在东八区一切正常用户在西半球就报错。解决办法就是前面那个parseDateLocal把字符串拆成数字再用new Date(y, m-1, d)构造。这种写法明确表示“本地时间的这个日期”完全绕开时区解析。我现在的习惯是凡是涉及用户输入日期的一律不走字符串直接构造全部手动拆。写法解析方式风险new Date(1998-03-05)按 UTC 解析负时区日期回退一天new Date(1998/03/05)按本地时间解析各浏览器历史上实现不一致new Date(1998, 2, 5)明确本地时间推荐无歧义手动拆分后构造明确本地时间可同时做合法性校验最稳4.2 2 月 29 日出生的人怎么算生日闰日出生是个绕不开的边界。到了平年2 月 29 日出生的人没有对应的日期。有几种处理方式各有各的道理。第一种平年按 2 月 28 日过。好处是日期不会跨月坏处是差一天。第二种平年按 3 月 1 日过这在某些地区的习惯里更常见。第三种不特殊处理直接按“下一个 2 月 29 日”算那就是四年一次倒计时会显示一千多天用户看到会懵。我的做法是计算周岁年龄时按 3 月 1 日算也就是 2 月 28 日当天还不满3 月 1 日才满计算下一个生日倒计时时同样按 3 月 1 日。这样两个地方口径一致不会出现“年龄已经满 20 但倒计时还显示 300 天”这种自相矛盾的情况。关键是口径统一选哪个都能接受前后不一致才是最糟的。4.3 倒计时的边界今天算不算“距离下一个生日还有 X 天”这个 X 在今天恰好是生日的时候应该是 0 还是 365看起来是个小问题实际影响很大。如果今天就是生日算成 365 天用户会觉得这工具连自己生日都识别不出来。正确的写法是把时间都归零到当天零点再相减避免因为时分秒不同导致结果多一天或少一天。function daysToNextBirthday(birth, today) { const t new Date(today.getFullYear(), today.getMonth(), today.getDate()); let next new Date(t.getFullYear(), birth.getMonth(), birth.getDate()); // 2 月 29 日出生平年顺延到 3 月 1 日 if (next.getMonth() ! birth.getMonth()) { next new Date(t.getFullYear(), birth.getMonth() 1, 1); } if (next t) { next new Date(t.getFullYear() 1, birth.getMonth(), birth.getDate()); if (next.getMonth() ! birth.getMonth()) { next new Date(t.getFullYear() 1, birth.getMonth() 1, 1); } } return Math.round((next - t) / 86400000); }这里必须用Math.round而不是Math.floor。因为夏令时切换的日子一天可能是 23 小时或 25 小时直接除会得到 0.958 或 1.042 这样的数向下取整就会错一天。这个问题在不少地区真实存在本地测试永远测不出来一定要用Math.round兜住。4.4 年龄差里“几个月”的口径问题两个人相差 1 年 11 个月 30 天和相差 2 年 0 个月 0 天哪个说法更准确这取决于你怎么定义“一个月”。按自然月算和按 30 天算结果会差好几天。我用的是自然月口径也就是前面diffAge那套逻辑先算年和月再处理天数借位。这样 1 月 31 日到 3 月 1 日会被算成 1 个月 1 天。看起来有点怪但它和人们日常说的“差了一个月”是一致的。另一种口径是按总天数除以 30.44 再拆好处是数学上更平滑坏处是用户拿日历一对就发现对不上。既然这类页面的用户核心动作是“验证”那就必须选能被日历验证的口径。这条经验适用范围很广凡是用户会核对的数字都要优先选择“符合直觉”而不是“数学上更优雅”的实现。5. 结果页决定传播半径卡片、文案与二次打开算得再准如果结果页做得没意思用户看完就关。这类工具的价值几乎全在结果页所以这一块值得单独花时间。5.1 结果卡片的排版优先级我见过不少页面把一个巨大的百分比放在正中其他信息全挤在下面一行小字里。这个优先级是反的。用户真正会截图发出去的理由从高到低大概是一句有意思的文案、两个星座的组合、年龄差、分数。分数其实排最后因为分数谁都有文案才是差异化的地方。所以我的排版顺序是顶部放双方星座或者生肖的组合标题中间放那句文案字号要大占视觉重心下面一行放年龄差和分数字号中等最底下放一个日期或者一句小尾巴。整体配色控制在三色以内主色只用在分数和一两个关键词上其他地方留白。还有一个细节是安全边距。用户截图的时候不一定按整张卡片截边距留得太少文字容易被裁掉一半。我一般四周各留 60 像素以上底部再额外留 80 像素避免被聊天框的输入栏挡住。5.2 分享文案的三套模板卡片是一回事用户发出去配什么文字是另一回事。很多人会直接复制页面上的文案所以页面上必须提供一句“可以直接抄”的话。我常用三套模板。第一套是结论型直接给判断比如“我们相差三岁适合指数 87%好像有点道理”。第二套是反问型制造互动比如“87% 是什么概念有人来对一下吗”。第三套是自嘲型适合低分结果比如“41%行吧确实经常吵架”。三套覆盖了高、中、低三种分数的情绪用户不管测出什么都能找到合适的表达。这里有个小技巧在结果页给一个“复制文案”按钮把文案和分数一起复制到剪贴板。别看这一步简单它能把分享率拉高一截因为用户不用自己想说什么。剪贴板 API 在部分环境里需要用户手势触发所以一定要绑在点击事件上不要放在页面加载时自动调用。5.3 让人愿意再打开一次的钩子一次性的工具用户测完就走。想让他再来得留个钩子。我试过效果比较好的有两种。一种是“换个生日再测”。在结果页底部放一句“换个人的生日试试”并且把对方生日的输入框保留在上一次的值只清空自己这一侧。用户下次来测另一个人一个框都不用改。这个设计的核心是减少操作步骤从三次点击降到一次。另一种是“今日限定”。用日期做种子每天的结果文案不同但同一天内保持稳定。用户发现今天和昨天看到的话不一样会再点一次。注意这里必须用日期做种子而不是随机数否则同一天刷新两次结果就变了反而破坏信任。种子取当天的年月日拼接字符串就行和前面那套确定性随机的逻辑完全复用。5.4 低端机和长截图的性能细节这类页面经常在手机上打开而且很多是老旧机型。canvas 绘制有两个地方容易卡一是尺寸设得太大二是字体渲染。尺寸方面750×1000 的 canvas 在多数手机上是没问题的但如果再加阴影、渐变、模糊效果绘制耗时会明显上升。我的原则是卡片上的装饰元素不超过两个尽量用纯色块代替渐变。另一个容易出问题的是toDataURL()。在部分浏览器里如果 canvas 尺寸过大这个调用会返回空字符串。解决办法是绘制完成后先检查返回值长度如果太短就降级到另一种尺寸重绘一次或者干脆提示用户直接截屏。这个兜底逻辑看起来多余但线上真的会遇到。6. 上线前的自测清单与线上问题的定位路径写到这儿功能基本齐了。但这类工具的性质决定了它一定会被用户拿去“找茬”所以自测环节不能省。我整理了一份自己每次都跑的用例表覆盖了绝大多数会被挑出来的问题。6.1 一份可以照着跑的测试用例表用例输入预期结果关注点同日出生两边生日完全相同相差 0 岁 0 月分数应偏高不能出现负数年龄差一天1990-05-01 与 1990-05-020 岁 0 月 1 天天数不能因为时区变生日当天今天是某方生日倒计时为 0不能显示 365闰日出生2000-02-29平年按 3 月 1 日处理年龄与倒计时口径一致跨年1999-12-31 与 2000-01-01相差 1 天年份计算不能差 1非法日期2023-02-30明确提示格式错误不能静默变成 3 月 2 日未来日期生日填 2099 年提示不可用或年龄为负的处理不能出现荒谬结果重复计算同一输入连点五次五次结果完全一致验证确定性随机这张表我一般会加上时区模拟把设备时区改到 UTC-8 再跑一遍。很多日期相关的 bug 只有换时区才暴露本地怎么点都正常。6.2 用户反馈“算错了”的三步定位线上收到这类反馈不要急着改代码先按顺序排查三个地方。第一步问清楚用户输入的具体日期和看到的输出。很多时候不是算错是用户自己填错了年份或者用了虚岁去对比周岁。这类占了相当大的比例。第二步确认时区。如果用户的设备时区和你不一样前面说的字符串解析问题就会显现。让用户报一下结果页显示的年龄和实际年龄差多少差一天基本可以锁定是这个问题。第三步确认生日是否落在边界日。2 月 29 日、星座交界日、生肖分界日附近都是高发区。这几个地方的处理逻辑本来就特殊用户产生疑问是完全正常的。我遇到过一次比较典型的用户反馈同一个人测两次分数不一样。查下来发现代码里有一处复合分数用到了new Date().getSeconds()做扰动。这个值每秒都在变自然不稳定。这类问题靠看代码很难发现必须靠“同一输入连点五次”的用例去卡。6.3 数据侧只看三个指标如果页面接了统计指标不要堆太多看三个就够。第一个是计算完成率也就是打开页面到点下按钮的比例。这个数低说明输入框设计有问题或者用户不知道要填什么。第二个是卡片保存率也就是结果出来后点击保存或截图的估算比例这个数直接反映结果页的吸引力。第三个是重复计算率同一设备短时间内多次计算的占比它衡量的是用户有没有在做对比实验。这三个指标比访问量有用得多。访问量涨可能只是某条内容碰巧火了但重复计算率高说明工具本身留得住人。我自己调这类页面时改文案和改卡片优先级通常比改算法带来的数据变化大得多。6.4 措辞上的分寸感最后说个容易被忽略的点页面上的措辞。这类工具本质是娱乐但用户会把它当回事尤其涉及年龄和关系的时候。所以有几句话必须有结果仅供娱乐参考、分数不代表任何真实判断、不要用它做决定。这些话不要做成弹窗就放在结果页底部一行小字既不打扰体验又表明了态度。另外输入框旁边的提示语也值得琢磨。写“请选择你的生日”比写“请输入出生年月日”亲和写“对方的生日”比写“TA 的出生日期”自然。这类小细节不涉及技术但对完成率的影响比想象中大。我自己反复做下来最深的体会是这类工具的技术门槛极低真正拉开差距的是对“用户会怎么用”的预判。用户不是来查年龄的他是来验证一个心里已有的猜测然后找一句话替自己说出来。所以日期必须准到一分不差文案必须软到不像下结论中间那套评分规则只要稳定、可解释、有变化就足够了。做这类东西先把日期运算这几行代码写扎实再谈其他顺序错了会返工很多次。
