小程序上线前要检查什么：一份发布前的自查清单
为什么要把上线检查单独拿出来做
开发阶段关注的是功能能不能跑通，上线阶段关注的是这套东西能不能对外。两者检查的东西不一样。代码写完、测试通过，仍然可能因为主体信息没补齐、某个页面空白、请求的域名没配置而卡住。把检查做成一份固定清单，比临发布时临时找人问要稳妥。
账号与主体信息
这部分通常由企业侧负责，但技术方要提前确认，否则会拖住发布节奏。
- 小程序账号的主体是否与企业营业执照一致；
- 管理员、项目成员是否已添加，权限是否覆盖开发与发布；
- 服务类目与实际提供的功能是否对应，避免上线后被要求调整；
- 涉及用户信息的场景，隐私说明是否已准备并挂到对应位置。
平台的具体审核要求和时长以官方当前说明为准，这里不做推测。能控制的是提交材料是否齐全、描述是否与实际功能一致。
功能与配置检查
建议按“用户从进入到完成目标动作”的路径走一遍，而不是按开发模块走。走查时重点看这些点：
- 首次进入的页面在无缓存、未登录状态下是否正常显示；
- 需要登录的功能，登录失败、授权被拒绝时是否有提示；
- 所有网络请求指向正式环境，而不是测试地址；
- 涉及地图、支付、客服等能力的配置项是否已在正式环境生效；
- 表单提交后是否有成功反馈，后台是否真的收到数据；
- 分享出去的页面标题、图片、落地页是否正确。
其中“请求指向正式环境”这一条最容易被忽略。测试环境跑得通，正式环境一片空白，多半就是这里出的问题。
内容与页面自查
技术之外，内容问题同样是退回的常见原因。发布前把主要页面截屏过一遍，检查有没有测试文字、占位图片、空白的列表页。列表类页面如果初始没有数据，要考虑给一个空状态提示，而不是留白。
文案上注意两点：一是描述要跟实际功能对得上，不夸大；二是不要出现与实际经营范围不符的表述。这类问题改起来快，但发现得晚就会影响发布。
数据与回退准备
发布前确认后台能否看到真实数据、数据存储在哪里、出现异常时谁能处理。同时留一个回退办法：如果新版发布后出现严重问题，能否快速切回上一版本，或者临时关闭某个入口。对使用频率高的工具类小程序，这一步尤其值得做。
适用范围上需要说明：这套清单适用于以内容展示、表单收集、轻量交易为主的小程序。如果小程序涉及复杂的业务流程或与内部系统深度联动，检查项还要增加接口联调、权限分级和数据处理规则的核对，不能只按上面几条走。
发布之后的一周
上线不是终点。发布后的一周内，重点看访问是否正常、提交是否成功、有没有用户反馈卡在某一步。把这段时间发现的问题集中记录，作为下一轮调整的依据，比分散地随时改更容易控制节奏。