崇左小程序开发启动前的准备清单：账号、类目与提审顺序
为什么这些事要放在开发排期之前
很多小程序项目的返工，不是因为代码写错，而是因为平台侧的账号、类目、资质、域名权限没有提前定下来。开发进度可以靠加人往前赶，但账号主体变更、类目审核、支付商户绑定、域名备案这些环节有固定的等待期，赶不动。
判断一个小程序项目需要提前准备到什么程度，可以先看它是否涉及四类能力：是否需要用户登录、是否涉及支付或收款、是否调用位置等敏感接口、是否收集手机号等个人信息。四项都不涉及的小程序，准备量可以压缩；涉及其中两项以上，账号和资质就应该在需求阶段同步启动，而不是等开发做完再补。
第一步：把页面清单落到入口和操作上
页面清单不要只写“首页、产品、案例、我的”。这样的清单无法判断工作量，也无法判断权限和接口。更实用的做法是按入口来列：用户从扫码、分享卡片、搜索、消息通知分别进入哪一页，每一页上必须出现哪些字段和按钮，数据是后台录入、接口拉取还是写死的。
- 每个页面标注是否需要登录后可见，未登录时展示什么
- 标出所有跳转关系，尤其是分享落地页和消息跳转页
- 标出需要用户授权的动作，比如获取位置、上传图片、绑定手机号
- 标出内容由谁提供，是运营录入还是接口返回
这一步的产出不需要精美的设计稿，草图加文字说明就够用。它的作用是把“页面上有什么”变成“系统要支持什么”，后面的账号类目、接口域名、后台字段都从这里派生。
第二步：确认账号主体和管理员归属
小程序账号的注册主体应当与实际经营主体一致。个人主体在支付能力和部分服务类目上有限制，如果业务后续要收款，用个人号注册往往要推倒重来。注册前先确认几件事：账号使用公司可控的邮箱，管理员微信号由在职且稳定的人员持有，开发成员和体验成员名单明确到人。
容易被忽略的是权限的回收与转交。项目结束后，外包开发者的开发权限是否收回，管理员是否要从个人转给公司指定人员，这些动作如果拖到人员变动时再做，处理周期会很长。账号找回和主体变更都不属于能当天解决的操作。
如果小程序只面向内部使用、不对外发布，账号环节可以简化，但成员权限的管理仍然要做，尤其是涉及内部数据的工具类小程序。
第三步：类目、资质与隐私材料一次对齐
服务类目要按实际功能选，不是按公司行业名称选。同样是一家贸易公司，做商品展示和做在线交易，对应的类目和资质要求并不相同。建议按下面的顺序做，避免反复提交：
- 列出小程序实际提供的功能，逐条写清楚用户能做什么
- 对照平台的服务类目说明，为每个功能找到对应类目
- 确认该类目需要哪些资质材料，注意证件的有效期和经营范围
- 准备隐私政策文本，写清楚收集哪些信息、用于什么目的、如何联系
- 检查授权弹窗的提示文案，是否与实际收集行为一致
隐私部分是最容易在提审阶段被退回的地方。收集手机号、位置、相册、通讯录，都需要在隐私政策中说明用途，并且用户在小程序内要能随时打开这份说明。授权弹窗写“为了更好的体验”这类表述，无法替代具体用途说明。
此外还要确认服务器的域名已完成备案，并使用 https。域名白名单没有配置，开发环境里一切正常，体验版一打开就是请求失败。
第四步：内容与素材先到位，再谈联调
小程序首屏内容为空，除了影响体验，也可能在审核时被认定为内容不完整。需要在开发阶段就准备的内容包括：图标与启动图、首页轮播素材、商品或服务的文案与价格口径、客服联系方式、公司简介、常见问题。这些材料通常由业务方提供，如果不提前排期，就会卡在开发完成之后。
后台录入和接口调试也有先后。字段结构没定就批量录入，等字段调整时往往要重录一遍。先定字段，再录内容，这条顺序在小程序和数据展示类项目里都适用。
第五步：域名、支付与消息通知并行办理
这些事项大多属于平台侧审批，有等待期，应当与开发并行推进，而不是等开发完成再申请。
- 请求、上传、下载、socket 等各类域名白名单，确认都使用 https
- 支付商户号的申请与绑定，注意商户主体与小程序主体是否一致
- 订阅消息模板的申请，明确在什么场景触发、发给谁
- 位置、相册等接口的权限申请与用途说明
- 分享卡片的标题、图片与落地页配置
支付环节尤其要早对齐。商户主体与小程序主体不一致时，绑定和结算都会变复杂，涉及多主体收款的项目，应在合同和排期阶段就把这一条写清楚。
第六步：提审与发布的先后顺序
- 用体验版在真机上走完主要路径，包括未登录、登录后、支付中断等异常情况
- 准备测试账号和测试路径说明，写清楚审核员从哪里进入、点什么按钮
- 提交审核，功能说明要具体，不要只写“用于展示公司信息”
- 审核通过后分阶段发布，先放开一部分入口观察，而不是一次性全量
- 上线首周重点看登录成功率、支付失败原因、页面加载和崩溃情况
- 保留上一版本，出现严重问题时可以回退
审核被驳回的常见原因不是功能缺失，而是审核员找不到入口，或者页面需要登录却没有提供测试账号。这类问题在提交前自己走一遍完整流程就能发现。
容易遗漏的几个检查点
- 小程序名称是否已被占用，是否与已有商标存在冲突
- 客服和留言入口背后是否有真实响应的人，而不是空号
- 正式环境是否残留测试数据、测试手机号和内部备注
- 交付后开发成员权限、体验成员名单是否需要清理
- 版本描述里是否写清了这次改了什么，方便后续追溯
适用边界
展示型、不含交易、不收集个人信息的小程序，第三步和第五步可以大幅简化，重点放在内容准备和提审说明上。涉及在线交易、会员体系、跨主体收款或收集敏感信息的项目，建议把账号、资质、支付、隐私材料单独列成一份前置清单，并给审批留出缓冲时间。这份清单的价值不在于文档本身，而在于把平台侧不可控的等待时间提前暴露出来，别让它出现在上线前一周。