企业官网建设流程全解析

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÷2+7=21，上限是 28×2-7=49。这个说法流传很广，但它只是一个民间俗语，没有任何科学依据，写进页面时必须明确标注为娱乐参考。

第二种是固定差值法，直接给 ±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 class="calc"> <label>你的生日 <input type="date" id="birthA"></label> <label>对方生日 <input type="date" id="birthB"></label> <button id="calcBtn">开始计算</button> <div id="result" class="result" hidden></div> <canvas id="card" width="750" height="1000" hidden></canvas> </div>

用type="date"有个好处，移动端会直接弹出日期选择器，用户不会乱输格式。但它也有个坑：不同浏览器对空值和非法值的处理不一样，有些返回空字符串，有些在某些旧版本里会返回奇怪的占位值。所以在读取时一定要做格式校验，不能直接扔给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。如果你在 UTC+8 时区，转换成当地时间就是 3 月 5 日早上 8 点，没问题；但如果你在 UTC-5 时区，就变成 3 月 4 日晚上 7 点，getDate()返回的是 4。

结果就是：同一份代码，不同时区的用户看到的生日差了一天。更麻烦的是这种 bug 很难复现，你的测试机在东八区，一切正常，用户在西半球就报错。

解决办法就是前面那个parseDateLocal，把字符串拆成数字，再用new Date(y, m-1, d)构造。这种写法明确表示“本地时间的这个日期”，完全绕开时区解析。我现在的习惯是，凡是涉及用户输入日期的，一律不走字符串直接构造，全部手动拆。

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 一份可以照着跑的测试用例表

这张表我一般会加上时区模拟，把设备时区改到 UTC-8 再跑一遍。很多日期相关的 bug 只有换时区才暴露，本地怎么点都正常。

6.2 用户反馈“算错了”的三步定位

线上收到这类反馈，不要急着改代码，先按顺序排查三个地方。

第一步，问清楚用户输入的具体日期和看到的输出。很多时候不是算错，是用户自己填错了年份，或者用了虚岁去对比周岁。这类占了相当大的比例。

第二步，确认时区。如果用户的设备时区和你不一样，前面说的字符串解析问题就会显现。让用户报一下结果页显示的年龄和实际年龄差多少，差一天基本可以锁定是这个问题。

第三步，确认生日是否落在边界日。2 月 29 日、星座交界日、生肖分界日附近，都是高发区。这几个地方的处理逻辑本来就特殊，用户产生疑问是完全正常的。

我遇到过一次比较典型的：用户反馈同一个人测两次分数不一样。查下来发现，代码里有一处复合分数用到了new Date().getSeconds()做扰动。这个值每秒都在变，自然不稳定。这类问题靠看代码很难发现，必须靠“同一输入连点五次”的用例去卡。

6.3 数据侧只看三个指标

如果页面接了统计，指标不要堆太多，看三个就够。

第一个是计算完成率，也就是打开页面到点下按钮的比例。这个数低，说明输入框设计有问题，或者用户不知道要填什么。第二个是卡片保存率，也就是结果出来后点击保存或截图的估算比例，这个数直接反映结果页的吸引力。第三个是重复计算率，同一设备短时间内多次计算的占比，它衡量的是用户有没有在做对比实验。

这三个指标比访问量有用得多。访问量涨可能只是某条内容碰巧火了，但重复计算率高，说明工具本身留得住人。我自己调这类页面时，改文案和改卡片优先级，通常比改算法带来的数据变化大得多。

6.4 措辞上的分寸感

最后说个容易被忽略的点：页面上的措辞。这类工具本质是娱乐，但用户会把它当回事，尤其涉及年龄和关系的时候。所以有几句话必须有：结果仅供娱乐参考、分数不代表任何真实判断、不要用它做决定。这些话不要做成弹窗，就放在结果页底部一行小字，既不打扰体验，又表明了态度。

另外，输入框旁边的提示语也值得琢磨。写“请选择你的生日”比写“请输入出生年月日”亲和，写“对方的生日”比写“TA 的出生日期”自然。这类小细节不涉及技术，但对完成率的影响比想象中大。

我自己反复做下来，最深的体会是：这类工具的技术门槛极低，真正拉开差距的是对“用户会怎么用”的预判。用户不是来查年龄的，他是来验证一个心里已有的猜测，然后找一句话替自己说出来。所以日期必须准到一分不差，文案必须软到不像下结论，中间那套评分规则只要稳定、可解释、有变化，就足够了。做这类东西，先把日期运算这几行代码写扎实，再谈其他，顺序错了会返工很多次。