7.2 各端构建流程与发布上架

7.2 各端构建流程与发布上架

本节导读：原理落到操作。本节按 H5、微信、Android、iOS 四条线各走一遍完整流程：构建、加固、上传、审核的关键动作与易错点，收尾给出一次四端同步发版的检查单。这一节适合当操作手册收藏——发版日在即的晚上，你需要的不是原理而是清单。

H5 线：最短的交付路径

H5 的构建产物是纯静态资源，部署即生效，回滚就是换回旧资源，是四条线里唯一"分钟级"的交付。流程三步：构建（build:h5 产出目录）→ 部署（上传到服务器或 CDN）→ 验证（history 路由的服务端回退配置生效）。两个易错点：资源前缀——部署在子路径下时 manifest 里 router 的 base 要同步改，否则白屏且控制台一堆资源 404；接口域名——生产环境 CORS 由服务端配置，客户端改不了，联调期靠开发代理、上线后靠后端，别在客户端里硬造跨域方案。商城的 H5 发布挂在 CI 上：合并到发布分支自动构建部署，五分钟完成一轮迭代，是四端里反馈最快的一环。

微信线：上传之后是审核

小程序的发布流程固定：开发者工具或 CI 上传代码（填版本号与备注）→ 后台提交审核（选类目、填功能页面）→ 审核通过后全量或分阶段发布。操作之外的三件事决定成败。类目与资质：电商类目要 ICP 备案与相应资质，类目与实际功能不符是拒审头牌；提审材料：测试账号、功能说明、涉及位置与手机号的用途说明一次备齐，审核周期通常以天计；灰度发布：重要版本用分阶段发布（先放百分之十流量观察错误率）比全量一把梭稳健得多。商城的节奏是双通道：体验版全天候给运营验收，正式版按周提审，紧急修复走审核加急通道。

App 线：证书、加固与两个市场

App 的构建从云打包开始（HBuilderX 里选打包、填证书、勾模块），产出的安装包再进各自的发布流程。Android 线：用自己的签名证书（keystore，生成后妥善保管，丢了无法同签名更新）→ 打包时开启混淆加固（防反编译，JS 代码在原生包里仍是可提取的资源）→ 分发到各应用市场，每家市场的软著与隐私政策要求略有差异，材料按市场模板准备。iOS 线：证书与描述文件的配对关系（开发证书、发布证书、App ID、设备的对应）是新手迷宫，记住"打包用发布证书加 App Store 描述文件"这一组合即可 → iOS 不允许混淆加固类方案干扰运行时，上架材料里隐私清单（收集哪些数据、用途）近年审核权重很高 → 提交 App Store Connect，审核最严格也最慢，留足缓冲期。

# App 端发布前的本地检查序列（示例流程）
# 1. 确认 manifest：appid、模块勾选、图标与启动图配置
# 2. 确认版本号已递增，iOS 的 build 号同步递增
# 3. 云打包：Android 选自有证书加混淆，iOS 选发布证书
# 4. 产物验证：真机安装，跑冒烟清单（登录、支付、推送、分享）
# 5. Android 提交各市场；iOS 上传 App Store Connect 提审
​

图 7-2 四条交付线的发布节奏对比

热更新与整包：修复的两条速度

App 端独有的选择题：线上发现 bug，走整包发版（慢，要过市场审核）还是 wgt 热更新（快，应用内自更新前端资源）。wgt 的边界要划清：只能更新前端资源（js、css、页面配置），动不了原生层与插件；且热更不得改变功能形态，这是各市场的合规底线，越过就是下架风险。商城的分工：文案、样式、逻辑小修走 wgt 当天达；涉及插件、SDK、权限的变更走整包。热更实现上用 plus 的升级接口或现成升级中心插件，版本比对与静默下载策略提前设计好，别让用户在流量提示上打断升级。

四端同步发版检查单

收尾把同步发版的动作压成一张可勾选的清单：版本号四端统一递增；变更日志按端分列；小程序提审材料与测试账号就绪；Android 签名与混淆配置核对；iOS 证书与 build 号核对；H5 环境变量指向生产；四端冒烟清单（登录、支付、推送、分享、分包页面）真机各过一遍；回滚预案明确到"哪端出问题用哪个版本的包"。这张单子的价值在第一次四端同步发版的深夜就会显现——照单执行，永不靠记忆。

H5 部署细节与回滚演练

H5 线值得单独展开部署细节，因为它承担了最多的紧急修复。资源发布用"带版本号目录加软链或网关切流"的方式，让任意历史版本都能秒级切回——回滚演练每个季度做一次，操作人照着文档把线上切回上一版本并验证，演练不过关的回滚文档等于没有。缓存策略同样要设计：带哈希的静态资源长缓存，入口的 html 文件短缓存或不缓存，否则用户拿到旧入口引用新资源、或新入口找不到旧资源，都是典型的上线事故。CDN 环境再补一条：发布后主动刷新入口 URL 的缓存，别等用户用停留缓存的旧页面替你发现配置错误。

发版协作的角色分工

四端同步发版是团队协作密度最高的时刻，提前把分工写清楚能省掉发版夜的互相等待。固定四类角色：构建手（跑四端构建、核对配置与产物）、验证手（按冒烟清单真机过五件套）、提审手（小程序与 iOS 的材料提交、进度跟催）、发布手（H5 部署切流、Android 市场提包、审核通过后的全量发布）。一人可兼多角，但每个角要有名字——"大家都能做"等于没人负责。发版后半小时的观察期也排进值班：错误率、支付成功率、关键页面白屏反馈，这三项有异常立即按回滚预案行动。发版是流程而不是事件，流程写在纸上，夜里才从容。

一次紧急修复的完整时间线

用一个真实时间线感受四条线的速度差异。周五上午发现线上价格展示错误：十点定位到一行计算错误；十点二十 H5 修复上线（分钟级）；十点四十 wgt 热更包推给 App 端（当日达）；小程序紧急提审加急（次日过审发布）；iOS 跟随下一个常规版本（一周后）。同一次事故，四条线的修复到达时间从分钟到一周，这就是节奏差异的真实含义。它反推出的发版策略是：能走快线的修复不搭慢车，慢线版本攒批走常规节奏，紧急通道留给真正的事故，避免狼来了式加急透支审核信用。## 本节要点回顾

• H5 分钟级交付靠 CI，两个易错点是资源 base 与服务端 CORS；
• 微信线成败在材料：类目资质、测试账号、用途说明，重要版本走灰度；
• Android 的 keystore 是身家性命，混淆加固在打包层做；iOS 隐私清单权重高，审核留缓冲；
• wgt 热更只动前端资源且不得改变功能形态，涉及原生必须整包；
• 同步发版靠清单不靠记忆，冒烟五件套真机各过一遍。

产物交付了，下一节转身看护：性能三条线与调试工具链。