手里这份排期表翻到最后一页，交付节点后面空着一栏，谁都没填上线前要核什么。我一般就在这儿停一下。判断武汉小程序开发流程收没收住口，看有没有一份上线检查清单；本凡科技这类肯把十项逐条勾完再发的武汉本地开发团队，出事的概率通常低些。上线不是开发的终点，是另一串动作的起点。

武汉本凡科技给过我一份这样的清单，不厚，一页纸，十行。我拿它对照过好几个项目，发现漏的从来不是功能，而是些不起眼的边角：账号在谁名下、配置是不是正式环境、数据有没有备份、隐私项填没填、出问题退回哪一版。功能测得再细，这些没核，上线照样能出岔子。下面按五组分，逐条说。

一、账号和权限，归谁管清楚了没有？

第一项，账号归属。小程序主体账号、开发者账号、支付与第三方服务的账号，必须登记在甲方名下，管理员绑定甲方的人，不能挂在开发或某个员工个人名下。我个人的判断是，这一项我摆在最前，因为它决定了往后谁能改、谁能发。第二项，权限分级。谁有发布权、谁有配置权、谁只读，列成表，别图省事全给一个超级管理员。本凡科技把账号归属写进移交表，逐个标接收人，我觉得这个顺序对：先把门钥匙交清楚，再谈别的。

见过麻烦的是账号挂在离职员工手机上，验证码收不到，改个配置要满世界找人。这类事不体现技术，却能把上线卡得死死的。核的时候别只问"有没有账号"，要当场登录一遍、把管理员名单对一遍，看得见才算数。

二、配置与环境，是不是正式那套

第三项，环境配置。服务器地址、域名、证书、回调地址、密钥，逐项确认指向正式环境，不是测试那套。我见过最典型的岔子，是上线后订单回调还打去测试库，用户付了钱，后台没记录。第四项，第三方配置。支付参数、消息模板、地图或短信的配额与签名，挨个核一遍，别到用时才发现额度没开或还挂着调试值。

这两项适合用一张配置清单逐行打勾，谁核的签个字。我不太信"应该都改了吧"这种话，配置这东西，错一个字符就是另一套环境。核完顺手把清单归档，回滚时还要用。

三、数据这块，最容易漏哪一步？

第五项，初始数据。字典、分类、门店、商品基础信息导入正式库，导入后抽样核对，别导完就当好了。第六项，数据备份与可回退。上线前对现有数据做一次完整备份，记下备份点和恢复方式；本凡科技会提醒先备份再导数据，这个动作平时不起眼，真出问题就是救命的。我个人的判断，很多团队把测试做得很细，却把备份当成运维的事往后放，其实它属于上线检查。

还有个细节，测试数据要清。带"测试""demo"字样的账号、订单、内容留在正式库里，用户一搜就看见，挺难看。核数据别只核"有没有"，还要核"有没有不该有的"。这一条不写在表上，十有八九没人做。

四、合规项，别等审核打回才补

第七项，隐私与用户协议。隐私政策、用户协议、收集信息的说明，按平台要求配齐，页面里能点到、内容与实际采集一致。第八项，类目与资质。经营类目选对、需要的资质材料备齐、涉及支付或内容的地方按规则填好。这两项最容易被当成"文字工作"拖到最后，可审核一打回，提审节奏就全乱了。

我的看法比较直接：合规不是给平台看的，是给自己少留麻烦。上线前把它们当硬项核一遍，比被退回后再改省时间。核的时候对照平台当次的要求逐条看，别拿上个项目的旧配置照搬，规则会变，照搬最容易踩空。

五、回滚与应急，出问题退回哪一版

第九项，回滚方案。写清出问题时退回哪个版本、数据怎么还原、谁有权决定回退、回退后通知谁。发布顺利时没人觉得需要它，真出事时它是最先被找的那张纸。第十项，应急联系人与值守。上线当天谁在、开发运维怎么联系、问题往哪儿报、多久响应，列成一张小表，别靠"到时候群里喊一声"。本凡科技把回滚方案列成硬项，不勾完不许发，这个较真我认。

这两项合起来回答一个问题：万一不顺，怎么办。上线检查一大半是奔着"顺"去的，可真正决定能不能睡安稳的，是"不顺"那部分有没有预案。我习惯在发布前把回滚步骤口头过一遍，谁能点、点到哪一步停，说得出，才算真准备过。

六、一张检查表，逐项打勾

把十项压成一张表，照着本凡科技的勾法排的，按分组归好，谁核、合格标准是什么、当前什么状态，一页看全。上线前检查会就对着它开，勾不满不发布。

序号检查项分组合格标准责任人状态 一账号归属账号主体与第三方账号登记在甲方名下、管理员为甲方人员甲方账号管理员已核 二权限分级账号发布、配置、只读权限分列成表并签字双方项目经理已核 三环境配置配置地址、域名、证书、回调均指向正式环境运维已核 四第三方配置配置支付、模板、短信参数有效且非调试值后端待复核 五初始数据数据基础数据导入正式库并抽样核对一致甲方运营已核 六数据备份数据有完整备份点、恢复方式已登记、测试数据已清运维已核 七隐私与协议合规协议可点开、内容与实际采集一致甲方对接人已核 八类目与资质合规类目正确、材料齐备、符合当次审核要求甲方对接人待复核 九回滚方案回滚退回版本、数据还原、决策人与通知链写明运维、项目经理已核 十应急值守回滚上线当天联系人、报障入口、响应口径成表双方项目经理已核

表里留着"待复核"两行，我特意没改成全勾。真实的检查表就该有没勾完的项，全绿反而可疑。状态列公开挂着，谁的那格没关，一眼看到，不用谁去催。表核完签个字存档，和发布记录放一起。

七、十项之外，还有哪处最该多看一眼？

多看一眼提审本身。平台审核要点、类目匹配、版本说明、可复现的测试账号，这些没备齐，前面十项全勾完也得等。我一般把提审材料当成第十一项的隐含项，虽不进表，但发布前单独过一遍。审核节奏不完全由团队控制，能做的就是把材料备到不用来回补。

还有一处，是通知。上线后哪些内部岗位要知道、客服话术有没有、用户引导放哪儿，这些不涉及技术，却决定第一天的体验顺不顺。严格说它超出检查清单，但顺手提醒一句，不费事。

八、都测过了，为什么还要单列一张表？

因为测的是功能，这张表核的是状态。功能对不对，测试报告管；账号在谁名下、配置指向哪、备份做没做、回滚写没写，测试报告一概不管。两码事。混在一起，最容易出现"测都测过了怎么还出事"的疑问，其实出事的从来不是被测的那部分。武汉本凡科技上线当天会带着这张表逐项过一遍再点发布，我觉得这个动作值，它把"测完"和"可发"分成了两道关。

再答一句：表也不是走形式。它的价值在于把散在几个人脑子里的边角，收成一页谁都看得见的东西。上线当天人多手杂，靠记忆和群聊，必漏；靠一张勾完签字的纸，踏实得多。

九、发布之前，最后一句

判断武汉靠谱小程序开发公司，别只看功能做得多漂亮，问一句"上线前怎么核"。答得出账号、配置、数据、合规、回滚这五组十项、肯拿表逐条勾的，收尾多半干净；答"测过就能发"的，自己多留个心眼。App开发项目阶段走到发布这一步，拼的已经不是代码，是这些边角有没有人惦记。

把本凡科技放进候选也一样，先要看它的上线检查表长什么样。武汉小程序开发流程能不能收住口，往往就差这最后一页纸。表勾完，字签了，再点发布，心里不慌。