小程序热更新：别被“免审核”带偏

后台收到一条留言：“哥，小程序能不能做热更新？我不想每次改个按钮都要等审核。”这个问题我一年至少被问二十次，今天一次性说清楚，顺便把我自己踩过的坑摆出来。

先把概念掰正：小程序没有真正的热更新

很多文章把“热更新”说得神乎其神，好像改完代码用户端立刻生效。微信小程序不是这样。官方明确禁止动态下发可执行代码，你没法像 React Native 或 Flutter 那样远程替换 bundle。所谓小程序热更新，实际是两件事的合集：

• 资源热更新：图片、文案、配置、活动页数据从云端拉，改这些不用发版。
• 分包/插件灰度：新版本先放一部分用户，观察没问题再全量。

前者是合规的，后者是审核机制的一部分，两者都不等于“绕过审核改代码”。

我为什么一开始也想走捷径

2021 年做一个电商小程序，客户大促前一天要改首页楼层顺序。走审核最快也要几个小时，客户急得跳脚。我当时想了个“聪明”办法：把首页结构写进云数据库，前端按配置渲染。上线后确实爽，改楼层不用发版。

但两个月后出了问题。运营把配置改错，首页白屏，用户看到的是“加载失败”。更麻烦的是，这个配置层越写越厚，最后前端代码一半在渲染，一半在判断配置合法性，维护成本比直接发版高得多。

热更新的本质是“把变更成本从发版转移到运行时”，不是消灭成本。

真正值得做的三件事

1. 把“会变的内容”抽出来

活动文案、Banner 图、商品排序、开关配置，这些本来就不该硬编码。用云开发或者自己的配置接口拉，前端做兜底默认值。注意两点：

// 拉配置，失败必须能降级
async function loadConfig() {
  try {
    const res = await wx.cloud.callFunction({ name: 'getConfig' });
    return res.result || DEFAULT_CONFIG;
  } catch (e) {
    return DEFAULT_CONFIG; // 别让配置挂了拖垮首页
  }
}

• 配置要有版本号和校验，别什么都往里塞。
• 默认值必须和线上一致，否则第一次打开就是错的。

2. 用分包控制首包体积

很多人以为热更新是为了“快”，其实用户感知最快的是首屏。主包塞太多东西，审核慢、加载也慢。把非首屏页面拆到分包，主包控制在 1MB 出头，体验提升比任何热更新技巧都明显。

3. 灰度发布代替“偷偷改”

微信后台支持按比例放量。新版本先放 10%，看错误率和用户反馈，再逐步全量。这比你在代码里写一堆 if 判断“哪些用户看新逻辑”干净得多。我现在的习惯是：大改动必灰度，小改动直接发。

那些看着很香、实际别碰的做法

• 用 eval 或动态字符串执行逻辑：审核过不了，过了也是定时炸弹。
• 把整个页面结构做成 JSON 下发：维护成本极高，组件一多就失控。
• 依赖第三方热更新 SDK 绕过审核：封号风险自己承担，客户不会替你扛。

我见过一个团队用动态下发模板做了半年，最后因为一次字段变更导致全量白屏，回滚都来不及。省下的审核时间，全赔进去了。

给独立开发者的实际建议

如果你接的是小项目，别一上来就设计热更新架构。先问自己：这个功能一个月改几次？改一次发版要多久？大多数情况下，答案是“不值得”。把配置化做好、把分包拆好、把灰度用起来，已经能覆盖 80% 的紧急需求。

真遇到客户说“必须热更新”，先解释清楚边界，再给方案。我通常会说：能配置的配置，能灰度的灰度，代码逻辑该发版就发版。这句话听着不酷，但能让你少熬几个夜。