审核被拒三次后，我总结的小程序上线避坑清单

上周帮朋友看一个被拒了三次的小程序，打开后台一看，三次驳回理由分别是「类目与内容不符」「诱导分享」「收集用户信息未声明」。说实话，这三个问题在开发阶段都能规避，但很多人是提审之后才开始补。我自己也踩过类似的坑，这篇就把这几年攒下来的审核经验捋一遍，尽量说人话。

先搞清楚审核到底在查什么

很多人以为审核是看代码质量，其实不是。审核员看不到你的源码，他们只看两样东西：你填的资料和用户点进去能看到什么。所以审核的本质是「资料与呈现是否一致」，代码写得再优雅，页面上一句「分享给3位好友解锁」就能让你打回重来。

我一般把提审前要检查的东西分成三块：类目与资质、页面内容、功能行为。下面逐个说。

类目和资质：最容易翻车的第一步

类目选错是驳回率最高的原因之一。比如你做了个工具类小程序，但里面有个「社区」板块让用户发帖，那类目就得往社交方向靠，光选「工具」是不够的。我的经验是：

• 先列出小程序里所有「用户能干什么」，再对照类目表找最贴近的，别只按主功能选；
• 涉及医疗、金融、教育、直播、招聘这些敏感方向的，提前把资质准备好，别等驳回再补；
• 如果某个功能暂时没资质，先隐藏入口，等资质下来再放出来，别硬着头皮提审。

还有一个细节：小程序名称和简介里不要出现「官方」「第一」「最」这类词，也不要蹭大品牌。我见过一个做记账的，名字里带了某银行的名字，直接被拒，理由是「名称与主体不符」。

页面内容：审核员看到的就是全部

审核员不会注册你的账号去体验完整流程，很多时候他们只能看到首页和几个公开页面。所以首页必须能自解释：你是干什么的、用户能获得什么。如果首页一进去就是登录页，大概率会被判「功能不完整」。

几个高频雷区：

• 空白页和占位内容：开发时留的「敬请期待」「测试数据」一定要清掉，审核看到空页面会认为功能未完成；
• 诱导分享和诱导关注：任何「分享后解锁」「关注公众号才能用」的文案都要删，这是硬红线；
• 用户信息收集：只要调用了获取头像昵称、手机号、位置，就必须有对应的隐私说明，并且在用户拒绝授权时不能卡死流程；
• 虚拟支付：iOS 端涉及虚拟商品交易的，老老实实走规则，别想着绕。

另外，页面里出现的第三方链接、客服二维码、外部联系方式，也要确认是否符合平台规则。有些类目是禁止引导到站外的。

提审前我自己会跑一遍的清单

下面这个清单我基本每次提审都会过一遍，贴在项目里当 checklist：

1. 类目是否覆盖所有功能，敏感功能资质是否齐全
2. 首页能否在不登录的情况下说明产品用途
3. 是否还有测试数据、占位文案、调试入口
4. 所有授权弹窗是否有拒绝后的降级方案
5. 隐私政策是否可访问，收集项是否与实际一致
6. 是否存在诱导分享、诱导关注、强制跳转
7. 分享卡片标题和图片是否正常，无敏感词
8. 提审版本是否关闭了体验版才有的调试开关

这份清单不复杂，但能挡掉八成低级驳回。

被拒了怎么办

被拒不可怕，可怕的是不看理由就重复提交。我的做法是：先逐字读驳回说明，定位到具体页面和功能；如果理由模糊，就在提审备注里写清楚「该功能的位置、用途、对应资质」，审核员是看备注的。改完之后版本号要更新，别用同一个版本反复提，容易触发更严格的复核。

说句实在话，审核规则一直在变，今天能过的写法明天未必能过。与其研究怎么绕，不如把产品做得规矩一点，长期看省的时间更多。

最后提醒一句：上线不是终点。审核通过后如果改了类目相关功能，记得同步更新资料，不然被抽查到一样会下架。做小程序这几年，我越来越觉得审核这件事，本质是逼你把产品边界想清楚，想清楚了，后面反而顺。