小程序审核常见驳回原因与提交前的自查清单

昆山小程序开发做到提交那天，团队往往盯着功能有没有做完，很少有人专门去核类目。周五下午点完提交，周一收到一条「服务类目与实际内容不符」，改完再排一次审核，上线日期就往后挪了几天。功能其实没问题，卡住的是几张材料和一个下拉选项。把提交前该核的东西列成清单逐项过，比驳回之后再补省事得多。

本文要点

• 类目、名称、经营内容与资质材料四者要对齐，材料名称以平台当期要求为准
• 隐私保护指引与授权弹窗在提审前配好，用户点拒绝时页面仍需能继续浏览
• 提审备注写清测试账号与演示路径，审核人员走不到核心流程容易被退回

类目与主体资质

服务类目不是随手选的标签。它决定了页面内容该长什么样、需要备哪些材料，以及支付场景能不能开。选了「工具」类目却整页在卖货，或者选了「电商平台」却拿不出对应材料，都是常见的退回理由。

上表是核对方向，具体要交哪几份、叫什么名称，以平台当期公示的小程序类目资质要求为准，提交前重新翻一遍比照着旧经验办稳妥。

主体信息同样要对：企业或个体工商户的统一社会信用代码、法人验证、管理员微信号，三者别出现两套身份。小程序名称也受类目约束，名称、简介、首页内容要说的是同一件事，别用宽泛词去蹭不相关的经营范围；名称还不能与已有账号重复，起名时先查一遍。昆山小程序开发的项目里，主体与支付商户号主体不一致，是后面开支付时才暴露的隐患，建议在这一节就并到一处核。

隐私与用户授权

《小程序用户隐私保护指引》要在后台按实际采集项配置，写清收集哪些信息、用来做什么、存多久。没配置或声明与实际调用对不上，涉及隐私的接口会被拦，页面表现是点了没反应，审核也容易退回。

接口调用有各自的触发条件。wx.getUserProfile 需要用户主动点击后才可取信息；取手机号要用 button 的 open-type="getPhoneNumber"，由用户点一次换一次，不能进页面就静默取号。位置、相册、相机这类权限对应 scope.userLocation、scope.writePhotosAlbum、scope.camera 等作用域，调用前先判断授权状态，未授权时给说明再申请。

判断标准落到一句话：把「用户点拒绝之后会怎样」逐个页面走一遍。拒绝定位要能手动填地址，拒绝相册要能跳过上传，拒绝手机号要能继续浏览商品。卡在空白页或反复弹窗，都算没走通。微信小程序审核规则里对授权时机的要求常被低估，功能做完了却因为一进首页连弹两个框被退，属于可以提前避开的返工。

常见情形是，首页加载即申请位置与用户信息，用户顺手全点拒绝，结果商品列表因为拿不到城市而空白。改成「先用默认城市展示，点定位按钮再申请授权」，功能没变，用户不再被弹框打断，审核时也少一处争议。

支付与交易类要求

支付环节先核三处绑定：微信支付商户号 mch_id 与小程序 AppID 完成绑定，商户号主体与小程序主体一致，签约的经营类目与实际售卖内容对得上。API 密钥、证书、回调地址配置完，用一笔小额真实订单从下单走到回调，别只靠沙箱或模拟数据。

虚拟商品与虚拟支付有额外限制，课程、会员充值、点数这类内容要注意端侧规则，别做成引导到外部渠道完成支付。交易链路也得完整：能下单，就要能看到订单、找到售后入口、读到退款说明，不能只有收款没有售后路径。价格、单位、运费规则写清楚，别让审核人员在页面上猜。

页面行为上也有几条硬约束：不做诱导分享、诱导关注，不放跳转到外部下载的链接；若要用 web-view 嵌 H5，域名需要配置为业务域名并把校验文件放到指定位置，否则嵌进去也是白屏。这些在微信小程序审核规则里属于反复出现的条目，逐条对照比凭印象判断可靠。

判断标准是留痕：把下单、支付成功、申请退款、退款到账四步各截一张图，连同订单号存进提交材料。遇到需要复核时，这几张图能省掉一轮来回。

页面内容自查

功能之外，页面上还留着不少「临时状态」，提审前要清干净。

• 测试数据与测试账号：删掉「测试商品」「1 元试用」这类占位内容，别让它们出现在首页或列表首屏。
• 占位素材：替换 lorem ipsum、灰块图、默认头像，检查图片链接是否可访问。
• 空白页与死按钮：每个入口点进去都要有内容，返回与关闭路径可用。
• 协议与客服：用户协议、隐私政策能点开且内容完整，客服入口能发起会话。
• 文案合规：价格、单位、售后条款写明确，宣传用语避开夸大表述。
• 小屏适配：375px 宽度下不横向溢出，长链接与长编号用 word-break 处理，宽表格允许横向滚动。
• 外链与二维码：不在页面里放引导跳转站外的二维码或链接。

常见情形是，首页 banner 还挂着联调时用的「测试商品 1 元」，提交后被判内容不完整退回。这类问题不涉及一行代码，却在驳回原因里占比不低。昆山小程序开发的收尾清单里，页面自查适合交给没参与开发的人做，眼睛不熟反而更容易看见占位内容。

测试账号与演示路径

小程序审核不通过，有时不是功能有缺陷，而是审核人员没走到那个功能。需要登录才能看的会员页、要有特定商品才能触发的分销结算、得先下一单才出现的售后入口，都得在提审备注里写明怎么进。

备注建议按点击顺序写，不写「自行体验」：测试账号与密码、当前环境是体验版还是生产版、从首页点哪几步到目标页面、是否需要预先造一条订单数据、演示用的商品名称、以及一个能联系到的技术对接人。涉及资质的页面，额外注明材料对应哪一项类目。

判断标准简单：找一个没参与开发的人，只给这份备注，让他从头走一遍。能走通再提交，走不通就把卡住的那一步补进备注。顺手把首页、核心流程、涉资质页面各留一张截图归档，复核时能直接对上。

演示路径还牵出一个细节：如果核心流程依赖后台开关或定时状态（比如某个活动只在特定时段开放），提审期间要保持可访问，别让审核撞上活动已结束的状态。把这类时间条件也写进备注，比事后解释省事。

提交前检查清单

把前面五节收成一张表，按角色分工逐行打勾，通过标准写具体，不写「已检查」。

清单之外再留一句提醒：类目与资质要求会调整，上次能过的材料这次未必够用，每回提交都按当期公示重核一遍。逐行打完勾，可以对照 服务与解决方案 里的交付物说明收尾，或到 行业动态栏目 按同簇读下去；有拿不准的条目，走 免费咨询 问一声即可。

小结

驳回大多落在几个可提前核对的位置：类目与资质对不对得上、隐私与授权有没有兜底、支付链路走不走得通、页面上还留没留测试痕迹、备注里有没有一条能照着点完的路径。明天就能做的一件事，是把上面那张十行清单打印出来，指定每个角色的负责人逐行打勾，再把测试账号与演示路径写进提审备注。做完这一步，昆山小程序开发的提交就从「碰运气」变成「按表核」。本文为行业经验与技术分享，不构成效果承诺；具体交付范围、周期与资费以书面方案为准。