小程序版本更新机制是怎样的？如何提示用户更新？

简化版

小程序发布新版本后，用户不一定立刻使用到新包。运行中的小程序通常会在下次冷启动或检查更新后应用新版本。工程里可使用 wx.getUpdateManager() 监听更新检查、下载成功和失败，在新版本下载完成后提示用户重启应用更新。

详细版

典型写法：

const updateManager = wx.getUpdateManager()

updateManager.onCheckForUpdate((res) => {
  console.log(res.hasUpdate)
})

updateManager.onUpdateReady(() => {
  wx.showModal({
    title: '更新提示',
    content: '新版本已准备好，是否重启应用？',
    success(res) {
      if (res.confirm) updateManager.applyUpdate()
    }
  })
})

updateManager.onUpdateFailed(() => {
  wx.showToast({ title: '更新失败', icon: 'none' })
})

要注意灰度、兼容、接口版本和强制更新边界。前端提示更新只是体验层，关键接口兼容要由后端和版本策略兜住。

完整版教学

一、小程序更新不是用户手动安装 App

小程序不像原生 App 那样从应用商店下载安装新版本。开发者提交审核并发布后，微信平台会管理包的分发，用户再次打开或触发更新检查时才可能拿到新版本。

开发者上传 -> 审核 -> 发布
       -> 用户访问
       -> 微信客户端检查版本
       -> 下载新包
       -> 下次启动或 applyUpdate 生效

这意味着发布后存在新旧版本并存窗口。用户 A 可能已经是新版本，用户 B 还停留在旧版本。后端接口不能假设所有用户瞬间升级。

面试里要说清楚“发布成功”和“所有用户使用新版本”不是同一件事。

二、UpdateManager 用来处理运行时更新提示

小程序提供更新管理能力，开发者可以检查是否有新版本、监听下载完成并提示用户应用更新。

App({
  onLaunch() {
    if (!wx.getUpdateManager) return

    const manager = wx.getUpdateManager()

    manager.onCheckForUpdate((res) => {
      console.log('hasUpdate', res.hasUpdate)
    })

    manager.onUpdateReady(() => {
      wx.showModal({
        title: '更新提示',
        content: '新版本已下载完成，重启后生效。',
        success: (res) => {
          if (res.confirm) manager.applyUpdate()
        }
      })
    })
  }
})

applyUpdate() 会强制小程序重启并使用新版本，所以不要在用户正在支付、填表、提交订单时突然重启。提示时机要考虑业务场景。

如果新版本修复严重 bug，可以提示更强；如果只是普通 UI 优化，可以弱提示或等下次冷启动。

三、新旧版本并存要求接口兼容

发布后一段时间内，新旧前端会同时访问后端。后端接口如果立即删除旧字段、改变枚举含义或强制新参数，就可能让旧小程序崩掉。

旧小程序 v1：提交 { skuId, count }
新小程序 v2：提交 { skuId, count, channel }

后端应兼容 channel 缺失，而不是直接报错

假设日活 10 万，发布 1 小时后仍有 30% 用户在旧版本，那么不兼容接口会影响 3 万用户。小程序发布越依赖平台分发，越要重视兼容窗口。

变更类型	风险	建议
新增可选字段	低	后端给默认值
删除旧字段	高	延迟删除、版本判断
枚举改含义	高	新增枚举，不复用旧值
接口路径变更	中高	保留旧接口一段时间

四、强制更新要谨慎设计

有些场景需要强制用户更新，例如严重安全问题、支付流程错误、协议不兼容。但强制更新会打断用户操作，设计不好会造成体验事故。

启动时检查版本
  -> 低版本且必须升级
  -> 展示不可关闭弹窗
  -> 引导重启或退出

强制更新通常需要后端配置最低可用版本，例如 minVersion=2.3.0。小程序启动时请求配置，如果当前版本低于最低版本，就提示更新。

但小程序不一定能像 App 那样跳应用商店。更多时候是提示用户重启小程序或等待新版本下载。若更新失败，要提供降级文案和客服路径。

五、灰度发布和回滚要配合监控

小程序发布不是点一下就万事大吉。成熟流程会先体验版测试，再灰度，再全量，并观察错误率、接口失败率、支付转化、白屏和关键路径。

体验版 -> 测试通过 -> 灰度 5%
      -> 观察 30 分钟
      -> 灰度 30%
      -> 全量
      -> 监控和回滚预案

如果新版本导致某个页面 JS 报错率从 0.1% 升到 5%，应立即暂停或回滚，并确保后端兼容旧版本。没有监控的发布，只能靠用户反馈发现问题。

数字例子：核心下单页转化率平时 12%，发布后降到 8%，即使页面没有明显报错，也可能是版本更新引入了交互或接口问题。

六、缓存、分包和静态资源也会影响更新感知

小程序包更新之外，接口数据、本地缓存、图片资源、CDN 资源也可能导致用户看到“旧内容”。因此版本更新要和缓存策略一起考虑。

代码包版本
接口数据版本
本地 storage 缓存
CDN 图片和配置

例如新版本把缓存结构从 { name } 改成 { profile: { name } }，如果不做缓存迁移，旧缓存可能让页面读取报错。解决方案是给缓存加版本号，启动时按版本迁移或清理。

分包场景下，低频分包可能在用户进入对应页面时才加载。更新后某些问题只有访问分包页面才暴露，所以测试和监控不能只看首页。

记忆钩子：小程序更新不是一个按钮，而是一条链路：代码包、接口兼容、缓存迁移、监控回滚都要一起看。

七、常见误区与追问

误区：发布后所有用户立刻都是新版本。 平台分发和用户启动时机不同，新旧版本会并存。
误区：前端更新能解决所有兼容问题。 后端接口必须兼容旧版本一段时间，不能立即删除旧协议。
误区：有新版本就应该立刻强制重启。 支付、提交、填写表单中重启会伤害体验，提示时机要谨慎。
追问：UpdateManager 主要监听什么？ 检查更新、更新下载完成、更新下载失败，并可调用 applyUpdate 应用更新。
追问：如何做强制更新？ 后端下发最低可用版本，前端比较当前版本并提示更新，同时保留失败兜底。
追问：缓存结构变更怎么处理？ 给缓存加版本号，启动时迁移或清理，避免旧缓存破坏新代码。

八、加强记忆

更新机制按“发布、下载、生效、兼容、监控”记：发布不等于立刻生效，下载完成可提示重启，新旧版本要接口兼容，缓存要迁移，灰度和监控决定能不能安心全量。

简化版

详细版