产假计算器这个小程序是我花了一个周末从想法到落地的小项目核心玩法很简单输入末次月经或预产期勾选几个条件立刻算出产假起止日期和剩余天数。第一版同时发布到了微信小程序、抖音小程序、快手小程序三个平台都开了流量主靠看广告变现后来把代码整理好放到了 GitHub 上开源。今天就把这条完整链路拆开讲清楚从需求定位、技术选型、广告接入到上架审核和开源工程化一条线写下来给准备做小工具类小程序、想搞懂流量主接入、或者正打算试着开源项目的朋友做参考。1. 项目定位与需求拆解1.1 为什么偏偏做一个“产假计算器”先聊需求。准妈妈最关心的一类是“我到底能休多少天”“从哪天开始休”HR 和行政最怕的是被员工问“我这个情况按政策怎么算”。产假计算器正好卡在这个高频答疑点上输入日期、选择附加条件几十秒出结果。它不像社区或资讯应用需要长期留存但用户一旦要用就是真需求愿意停下来认真操作。工具型小程序还有一个好处需求边界清晰。不需要账号体系、不需要后端重逻辑、不需要内容运营。第一版我甚至没有接后端所有计算全在本地完成。这意味着可以很轻地跑起来也能很快复制到多个平台。不要想着第一版就做成“孕期全能助手”。加入孕期百科、产检提醒、在线咨询复杂度会指数级上升审核风险也变大。我的原则是垂直场景、单点突破把“算产假”这一件事做到极致。1.2 “微信抖音快手”三平台分发的用户场景很多开发者做小程序只盯微信其实抖音和快手的生态价值很容易被低估。微信端核心是搜索和朋友群转发。公司同事之间互相转发宝妈群里传播熟人信任链让工具类小程序天然好传播。抖音端用户刷到产假相关短视频后点击关联小程序直接算属于“视频种草、小程序承接”的典型场景。快手端老铁经济下的信任感更强家庭群、亲友群分享率高很多用户愿意把结果截图发群里帮别人算。三端共用一套业务逻辑就够了。由于我刻意不做账号体系用户数据只存在本地不需要服务端同步跨平台复制成本很低。这也是把目标定为“三端同时上线”的关键前提。2. 技术选型与核心逻辑设计2.1 用 uni-app 一套代码跑三端选型时我认真对比过三条路原生分别写三套、Taro 跨端、uni-app 跨端。原生写三套基本不现实同样的页面要维护三个工程广告组件、存储 API、导航栏适配全部要各写一遍对个人开发者来说是巨大的维护成本。Taro 我也试过React 语法写起来顺手但当时对抖音小程序和快手小程序的支持还不够稳定踩坑成本高。最终选了 uni-app。原因有三个它对微信小程序、抖音小程序、快手小程序的支持比较成熟条件编译机制可以让我针对平台差异代码做精细控制。Vue 语法上手快周边插件和开源模板多出问题容易搜到解决方案。HBuilderX 内置“发行到各小程序平台”的能力一个项目能直接输出三端代码包不用手动搬文件。开发工具层面我会同时打开微信开发者工具、抖音开发者工具、快手开发者工具每次改完代码后用 HBuilderX 重新发行到对应平台在真机上验证。注意这几个工具之间没有联动需要手动刷新流程上要有点耐心。2.2 产假计算逻辑怎么建模计算逻辑本身不复杂但容易写死。我强烈建议把规则和代码分离不要在前端把数字写死。我用一个leaveRule配置对象来承载规则参数// config/leaveRule.js // 注意上线前请把 0 替换为你所在地区的真实政策参数 // 也可以由后端接口下发改了规则不用发版 export const LEAVE_RULE { baseDays: 0, // 基础产假天数 prenatalDays: 0, // 预产期前可以休假的天数 extraDystociaDays: 0, // 难产/剖宫产额外天数 extraMultipleDays: 0, // 每多一胎额外天数 startOffsetFromEdd: 0 // 起始日相对预产期的偏移天数-15表示预产期前15天 }实际计算结果时核心函数大概是这个逻辑import dayjs from dayjs export function calcMaternityLeave(lmp, options {}) { const rule { ...LEAVE_RULE, ...options.rule } const lmpDay dayjs(lmp) if (!lmpDay.isValid()) { return null } // 预产期 末次月经第一天 280 天 const edd lmpDay.add(280, day) // 产假起始日 预产期 可配置偏移 const startDate edd.add(rule.startOffsetFromEdd, day) // 总天数 基础天数 附加天数 const extraDystocia options.isDystocia ? rule.extraDystociaDays : 0 const extraMultiple (Math.max((options.babyCount || 1) - 1, 0)) * rule.extraMultipleDays const totalDays rule.baseDays extraDystocia extraMultiple // 结束日要减 1因为总天数包含了起始日当天 const endDate startDate.add(totalDays - 1, day) return { startDate: startDate.format(YYYY-MM-DD), endDate: endDate.format(YYYY-MM-DD), totalDays } }为什么要把配置拆出来因为各地的产假天数和附加规则差异很大而且政策可能有调整。把规则做成配置后后面如果规则变了要么改一份 JSON 再发版要么直接从接口拉不需要动计算逻辑降低出 bug 的概率。2.3 日期计算的边界与测试日期计算最大的坑是边界条件闰年、跨月、跨年、2 月 29 日、12 月 31 日。这些地方最容易算错。我建议用 dayjs 而不是 moment。dayjs 体积小得多API 风格和 moment 几乎一样在工具类小程序里能省不少包体积。测试用例我提前列了一张表覆盖典型场景末次月经日期场景说明预产期计算结果280天后2024-01-01闰年中的普通日期2024-10-082023-12-31跨年2024-10-072024-02-29闰年 2 月 29 日2024-12-052025-01-31跨月且跨小月2025-11-07上面只是普通预产期推算的技术示例不构成任何医学建议。实际业务里还要考虑用户可能输入预产期而不是末次月经所以我在页面里提供了两种输入方式最终都归一化成“预产期”再来算。3. 广告变现与流量主接入3.1 流量主开通先看门槛再发力三个平台对流量主开通都设了门槛一般和累计独立访客数UV挂钩具体数值请以各平台后台最新规则为准。它们的通用流程是注册并认证小程序开发者。发布小程序并通过审核积累一定的真实 UV。达到门槛后在后台申请开通流量主。开通后创建广告位拿到adUnitId。将广告位 ID 填进代码发版上线。微信小程序一般是在小程序后台左侧菜单的“流量主”里申请很多团队卡在累计 UV 指标上。我的做法是开发完成后先在同事群、朋友群、宝妈群里做小范围分享让大家真的使用、真的转发而不是去刷量。刷量在小程序风控体系下非常危险轻则流量主功能被限制重则整个账号被处理得不偿失。抖音小程序和快手小程序的流量主开通条件类似也需要达到平台要求的 UV 后在“变现”“推广与广告”等菜单中申请。两个平台都可以创建激励视频和 Banner 广告位代码位 ID 的用法逻辑和微信大同小异。3.2 广告位怎么设计不赶客小工具做广告最怕的是用户刚算完结果迎面就是一堆弹窗和横幅直接劝退。我的广告位策略是底部 Banner放在结果页最底部作为常驻广告高度固定不能遮挡主要操作按钮。激励视频用户主动点击“完整保存计算报告”“分享给朋友”时才弹出完整观看后发放奖励不强制、不诱导误点。插屏广告第一版先不上工具类页面操作路径太短插屏容易打断心情体验风险大。等收益模型跑通后再 A/B 测一下要不要加。核心原则是先给用户价值再谈广告。用户看到计算结果已经获得了核心服务此时再插入广告的抵触情绪会小很多。3.3 三端广告代码接入示例uni-app 里可以用条件编译处理三个平台的广告 API 差异。比如激励视频的创建封装一个工具函数// utils/ad.js export function createRewardedVideoAd(adUnitId) { // #ifdef MP-WEIXIN return wx.createRewardedVideoAd({ adUnitId }) // #endif // #ifdef MP-TOUTIAO return tt.createRewardedVideoAd({ adUnitId }) // #endif // #ifdef MP-KUAISHOU return ks.createRewardedVideoAd({ adUnitId }) // #endif }调用时监听关闭事件判断用户是否完整看完const ad createRewardedVideoAd(adUnitId) ad.onClose((res) { if (res res.isEnded) { unlockFullReport() // 完整看完解锁完整报告 } else { toast(完整观看视频后才能保存报告哦) } })Banner 广告更简单三个平台基本都是ad unit-idxxx这种写法在 uni-app 中同样可以用条件编译分别填不同的广告位 ID。还有一点很重要广告拉取不一定每次都成功。用户点击“保存报告”时如果广告拉取失败必须做兜底不能直接让功能不可用。我的兜底策略是广告加载失败超过 3 秒直接放行让用户使用功能尽量不因为广告毁了核心体验。3.4 收益预期管理流量主收入不是做出来就能躺着赚钱的。工具类小程序 eCPM 通常不高广告收入大致等于“曝光量 × eCPM ÷ 1000”一个小体量工具每月可能只有几十到几百块别抱暴富预期。我更看重的是这条路本身的验证价值。通过这个项目你能把“开发 → 上线 → 变现 → 开源”的完整链路跑通之后再做任何垂直工具类小程序都能直接复用这套模板。4. 开源工程化与代码分发4.1 开源前先把仓库收拾干净代码开源不是把整个工程往 GitHub 一推就完事。一个合格的仓库至少要处理好几个点敏感信息必须移除包括微信/抖音/快手的 AppSecret、广告位 ID、请求域名和内部接口地址。这些信息一旦泄露轻则被薅广告费重则账号被风控。用.gitignore过滤掉不该提交的文件比如node_modules/ dist/ unpackage/ .env src/config/private.js .env.local目录结构要让陌生人一眼看懂。我最终整理出来的结构大致是leave-calculator/ ├── src/ │ ├── pages/ │ │ ├── index/ │ │ └── result/ │ ├── utils/ │ │ ├── calc.js │ │ └── ad.js │ ├── config/ │ │ └── leaveRule.js │ └── manifest.json ├── .gitignore ├── LICENSE ├── README.md └── package.json项目上线后我先开了私有仓库等所有敏感信息都抽离干净后再切换成公开仓库。这是最稳的流程强烈建议不要先公开再清理因为 Git 历史里的泄露很难彻底抹掉。4.2 README 是门面开源项目的 README 决定了别人会不会用、会不会顺手 star、甚至会不会提 PR。我的 README 包含了这几块项目简介一两句话说明这个计算器能做什么。效果展示放一张结果页截图或录屏 GIF直观得多。支持平台矩阵用表格列出微信、抖音、快手分别支持到哪个功能。快速开始npm i、导入 HBuilderX、填 AppID、配置广告位、运行。参与贡献说明提 issue、提 PR 的规范。免责声明计算结果仅供参考请以实际医嘱和政策为准。GitHub 的 Topics 也不要浪费可以打上wechat-miniprogram、douyin-miniapp、kuaishou-miniapp、mini-program、ad-monetization这类标签方便被检索。开源之后我收到了不少 issue有人指出日期计算的边界 bug还有人问能不能新增本地的政策参数这些都是真实反馈对项目完善很有帮助。4.3 开源和流量主收益冲突吗很多人担心开源了代码别人复制拿去上线会抢自己流量。实际影响很小。流量主的收益核心在于账号积累、运营推广和平台分发代码只是其中最不稀缺的部分。每个小程序账号是独立的别人复制代码也复制不了你的用户和口碑。而且开源能带来额外的价值技术社区关注度、简历加分、潜在的协作机会。我还基于这个开源项目接到了一个小需求帮对方做了一份定制规则版本这反而是闭源状态下不会出现的收入。5. 三端上架与审核避坑5.1 三个平台审核要求差异三个平台的审核侧重点不完全一样但工具类小程序整体比较容易过。微信小程序要求小程序备案类目选择要准确比如“工具 信息查询”。后台需要配置隐私保护指引页面里也要有用户协议和隐私政策入口。抖音小程序审核时会真机打开计算页面确认基本功能可用。抖音对“诱导分享”“诱导关注”等行为比较敏感文案里不要出现“分享后才能算”“转发解锁”这类措辞。快手小程序同样看重页面功能完整性和广告行为合理性避免出现明显的“诱导点击广告”设计。工具类目通常不需要额外资质但涉及“孕期”这种偏医疗健康的词我建议在页面底部加一句免责声明计算结果仅供参考不构成医学意见请以实际医嘱和政策为准。这句话能挡掉大量审核风险。5.2 隐私政策和合规声明怎么写因为项目没有账号体系、不收集个人信息我就可以把隐私政策做得很简单。但“简单”不等于“没有”。三个平台都会要求小程序配置隐私政策我在“关于”页面放了完整文本并确保用户能一眼看到入口。合规声明方面除了医疗免责还要给广告行为做说明小程序内展示的广告由平台提供用户可自主选择是否观看激励视频不影响核心计算功能。5.3 审核被拒的真实案例我在上架过程中实际踩过的坑整理成三个典型 caseCase 1Banner 遮挡按钮被拒。第一版把 Banner 放在页面底部固定定位结果在部分机型上把“重新计算”按钮挡住了。解决方式是给底部操作区预留安全距离Banner 高度固定并加safe-area-inset-bottom适配。Case 2文案出现绝对化用语。简介里写了“最准确的产假计算器”审核直接打回提示涉嫌夸大宣传。改成“结果仅供参考”之后才通过。Case 3抖音端广告拉不出来。广告位是新建的但没有在后台先提交审核真机测试时经常拉取失败。虽然核心功能是好的但审核人员打开页面看到广告区域空白体验不好。正确操作是提前把广告位审核过了再发版。6. 常见问题与排查技巧实录6.1 广告组件调不起来怎么办排查顺序按这个来基本不会漏确认adUnitId是否对应正确的平台三端的广告位 ID 不能混用。到平台后台确认广告位状态是不是“已通过”或“生效中”。看开发者工具控制台的报错信息记下错误码去搜。一定要真机测试开发者工具里广告组件和真机表现经常不一致。如果后台显示广告位正常但前端拉取失败先检查当前小程序的 AppID 是否和广告位所属账号一致。很多人会用测试号开发测试号里广告位大概率拉不出来。6.2 三端样式兼容跨端最容易出问题的就是自定义导航栏。微信、抖音、快手的胶囊按钮位置不同需要动态获取const rect uni.getMenuButtonBoundingClientRect() // 返回 { top, bottom, left, right, width, height }拿到胶囊位置后把自定义导航栏的高度和左右留白按照 rect 动态设置这样三端才能保持统一。另外rpx 在不同平台下的换算比例可能略有差异涉及绝对定位的样式要多真机验证。6.3 计算逻辑的边界 bug 清单这个项目的核心计算逻辑出现过两个印象深刻的 bug一是日期格式化问题。dayjs默认格式化是YYYY-MM-DD但如果用户时区设置异常个别机型会在跨日时产生偏差。解决方式是输入输出都用平台提供的picker组件类型统一为日期字符串避免手输导致的格式污染。二是“总天数是否减 1”的语义问题。从 1 号休到 3 号如果天数写 3结束日要算成 3 号而这实际上是“3 - 1 1 3”天。很多新手会把结束日直接加总天数导致多算一天。这个逻辑我加了单测也建议你加到 CI 里后续改规则不容易回归。如果你也想跑一遍“开发 → 多端上线 → 流量主变现 → 开源”的完整闭环我最大的建议是别做大而全的东西找一个你身边真实存在的垂直需求小切口、快上线、再迭代。产假计算器只是其中一个例子你每天工作中那些小到不好意思提的麻烦往往就是最好的切入点。最后再分享一个重要教训广告位 ID 和 AppSecret 千万记得放进.gitignore我因为这个疏忽在开源仓库里留过一次敏感配置虽然发现后马上删了并换了 key但过程相当被动。开源是好事前提是把家门收拾干净。
