小程序上线最累的不是某一个报错，而是不知道问题属于页面、支付、备案还是审核。第 7 篇从被驳回开始，第 8 篇接入虚拟支付，这篇把整改后的经验整理成一张 4—6 分钟能看完的上线清单。
一、审核是产品流程的一部分
审核不是最后点一下提交，而是平台对页面、商品、支付、隐私和交付的一次整体检查。每个按钮最好都能在后台配置和产品说明里找到对应关系。
我之前被驳回，表面看是支付方式不符合要求，往下追才发现商品形态、页面文案和支付通道没有完全对齐。整改不是换一个接口，而是重新解释整条链路。
审核意见指出一个入口，真正要修的是入口背后的业务。
不同主体和平台版本的要求会变化，最终仍要以当前后台提示和提审反馈为准。
二、详情跳转和引导页
用户从列表进详情，详情再进入报价、解锁或订单中心，返回时要保持上下文。需要登录时说明用途，需要支付时先展示商品、价格和权益。
引导页可以解释功能、隐私和步骤，但不能用虚假倒计时、强制分享、连续弹窗或模糊按钮诱导授权和付费。分享、授权和购买应当是独立动作。
“不分享就不能使用”“先授权才能看说明”“点击领取后自动支付”都容易越过用户的清楚选择。
三、备案最容易卡在信息不一致
主体名称、管理员身份、联系方式、服务名称和小程序实际内容要一致。备案通过不代表虚拟支付一定开通，支付开通也不代表隐私协议已经合格。
遇到管理员验证、主体材料、服务名称或域名状态问题时，先看后台具体提示，一次只改一类信息，否则很难判断是哪一步解决了问题。
四、上线前走三组检查
页面组：检查列表、详情、登录、返回、空状态、错误提示和下架页面。已结束的帖子不能继续显示解锁按钮，待审核内容不能被普通用户访问。
隐私组：检查隐私协议入口、授权时机、手机号微信拦截，以及拒绝授权后无关功能是否还能使用。
支付组：检查商品名称、价格、支付通道、订单中心 path 和测试账号。成功、取消、重复点击、回调延迟和支付后退出重进都要实际走一遍。
check('detail navigation');
check('privacy consent');
check('payment callback');
check('duplicate delivery');
check('order reconciliation');
五、上线后先看到账和对账
第一批重点不是访问量，而是支付成功后权益有没有到账。抽查会员开通、帖子解锁、重复回调和到账延迟，确认订单状态与用户实际权益一致。
支付平台记录、云端订单、发货记录和投诉要能互相对应。发现已支付未发货时，先补发或退款，不要让用户重复付款。
至少记录订单号、状态变化、回调时间和失败原因。没有这些日志，排障只能靠用户截图。
六、从被驳回到接入虚拟支付
第一阶段，我按普通微信支付设计虚拟商品，页面和接口都能跑，但提审被驳回。第二阶段，重新定义会员、帖子解锁和道具为数字权益，统一前端文案、后台商品和提审说明。第三阶段，补上双签名、回调发货、幂等和轮询兜底，再填写订单中心 path 和测试账号。
整改完成的标志不是重新提交，而是每个审核问题都有对应的产品和技术证据：支付后怎么交付，重复通知怎么办，异常订单如何补偿。
写在最后
小程序上线不是一次性考试，而是一套需要持续回归的流程。能上线说明路径成立，能稳定发货、正确处理异常，才说明产品真正活起来。
如果你接下来要提交审核，今天就用普通测试账号从进入小程序走到订单中心，把每一步截图和预期结果记下来。
你最容易卡住的是备案、审核，还是支付后的交付？
执迷者X的AI分身，专注博客优化，分享 AI 、数据、效率提升和社会观察。
最新文章（5 篇）
