当天修好 1.2 用户的支付；1.3 照常过审；后端等旧版用户很少了才删字段。
手机 App · 上架与更新
版本更新App Updates
App 新版过审后由用户自己更新，旧版本会长期存在，所以接口要兼容旧版。强制更新要自己做最低版本检查；热更新能快速换掉 JS 和资源，但改不了原生代码，也不能用来改变 App 的主要功能。
12 部手机上的版本墙
按钮大致按顺序点：先热更新修 JS，再试热更新加原生功能，然后发 1.3、过一周、删旧字段、设最低版本。每一步看哪些手机变了色。
任务打卡 App 1.2 的支付有 bug。下面是 12 位用户手机上的版本。用热更新、发新版和后端开关处理它，看每台手机怎么变。
改 App
后端
在 1.3：0 / 12支付失败：7崩溃：0停在更新页：0
- 用户 11.0旧版，但能用
- 用户 21.0旧版，但能用
- 用户 31.1旧版，但能用
- 用户 41.1旧版，但能用
- 用户 51.1旧版，但能用
- 用户 61.2支付失败
- 用户 71.2支付失败
- 用户 81.2支付失败
- 用户 91.2支付失败
- 用户 101.2支付失败
- 用户 111.2支付失败
- 用户 121.2支付失败
现在：7 台 1.2 的手机支付失败。下一步：先试「热更新修复支付（只改 JS）」。
知识点：App 的更新在用户手里
版本墙上已经演过，这里只给命名。
- 发版 ≠ 都更新了：新版过审上架后，用户自己更新或等自动更新，旧版本会长期存在。
- 接口要向后兼容：后端改字段前，先确认还有多少人在用旧版；旧字段要留到旧版用户足够少。
- 强制更新：App 启动时问后端「最低支持版本」，低了就挡在更新页。安卓可用 Google Play 的应用内更新；iOS 没有现成接口，要自己做。
- 热更新：Expo 等方案能在下次打开时换掉 JS、样式和图片，修 bug 很快；原生代码改动必须发新版。
- 平台规则划了线：Apple 允许下载解释执行的代码，但不能改变 App 的主要用途；Google Play 禁止绕过商店更新自身或下载可执行代码。
什么时候用、怎么用
线上出 bug，先判断它在 JS 里还是原生里，再决定怎么推。
- 信号：线上 bug 要马上修、准备改接口字段、某个旧版有安全或资金问题。
- 只改 JS 或文案：热更新，记得先在测试渠道验证再推给所有人。
- 动了原生模块、权限或配置：发新版过审；接口同时兼容新旧两版。
- 最短路径：让 AI 上线时就带上「最低版本检查」和热更新能力 → 修 bug 前先问 AI 改动是否涉及原生代码 → 改接口前看版本分布。
正反例：同一个支付 bug
bug 一样，差别只在怎么让用户拿到修复。
一半用户还在旧版，打开就崩；只好紧急恢复字段，再上强制更新把所有人挡在更新页。
快速自测
AI 说「新加的蓝牙计步功能已经通过热更新推送给所有用户了」。你最该怀疑什么？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。