移动端打包、签名与热更新：APK/AAB、keystore 与 OTA 机制
讲清 Android 从源码到安装包的构建与签名链路、APK 与 AAB 的区别、版本号规则、iOS 签名简述，以及混合应用如何打包、如何在不发版的情况下做资源热更新与强制更新
- 理解应用为什么必须签名、Android keystore 与签名方案的作用和保管要点
- 分清 APK 与 AAB、versionCode 与 versionName、多渠道包与加固
- 知道 iOS 证书+描述文件的签名体系与 TestFlight 的位置
- 理解混合应用打包链路，以及 OTA 资源热更新与强制更新的实现与平台红线
写完代码到用户安装，中间隔着「构建与签名」
Web 页面改完刷新即可，但原生/混合 App 要经过编译、打包、数字签名，变成用户能安装的安装包，再通过商店或下载分发。理解这条链路，你才看得懂 versionCode 为什么只能递增、签名丢了为什么等于丢了 App、什么能热更新什么必须发新版。朋友好学是 Capacitor 混合应用（界面是本地网页、外壳是原生），我们以它为线索讲。
Android 构建链路：源码怎么变成安装包
混合应用(朋友好学)的打包链路
① Next.js 静态导出 -> 网页产物(HTML/JS/CSS)
② Capacitor 把网页产物拷进原生工程(copy)
③ Gradle 构建：编译原生壳 -> 合并资源 -> 打成 APK/AAB
④ 用 release keystore 数字签名（不签名无法安装/上架）
⑤ 对齐、产出正式安装包，校验版本号与文件完整性后分发纯原生 Android 还多一步把 Kotlin/Java 编译成 DEX 字节码的过程；混合应用的业务逻辑主要在网页产物里，原生壳很薄，这也是它能在线更新网页资源的前提。
签名：Android 应用的「身份证」，丢了后果严重
Android 要求每个安装包必须用证书数字签名才能安装。签名建立「包名 + 签名证书」的唯一绑定：系统据此判断安装包是不是同一个 App 的合法更新（签名一致才能覆盖升级，不一致会被拒绝）；Android 据此做应用间权限隔离。release 签名用你自己生成的 keystore（密钥库），debug 签名是开发工具自动生成的、绝不能用于上架。
release keystore 一旦丢失且无备份，你将无法再用相同签名发布更新，用户也无法原地升级，只能换包名当新 App、老用户全部流失；keystore 泄露则别人可以冒充你的 App 发更新。务必：离线多处备份 keystore 和它的密码、不进 Git、不和安装包放一起。应用升级时 versionCode 必须比上一版大（整数单调递增），versionName 是给人看的版本名（如 2.25.0），商店和系统用 versionCode 判断新旧。
APK 与 AAB、多渠道与加固
AAB 不是直接安装文件，而是交给 Google Play、由商店针对不同设备分辨率/ABI 生成优化后的 APK；国内安卓商店生态分散，普遍仍上传 APK，并常为不同渠道打渠道包、过一遍安全加固与合规检测。朋友好学当前同时产出自托管的正式签名 APK（用于自有下载与 OTA）。
iOS 签名体系（简述）
iOS 的签名更严格，核心是「证书 + 描述文件（Provisioning Profile）」：证书证明开发者身份、描述文件把设备/应用 ID/证书/权限绑定在一起。上架走 App Store Connect、先用 TestFlight 做内测再审核发布；iOS 不允许像安卓那样随便下载安装包侧载（企业证书、TestFlight 是受限例外）。这部分 Stage16 会从中外上架流程角度展开，这里只需建立「Android 用 keystore、iOS 用证书+描述文件」的对应认知。
OTA：哪些能热更新、哪些必须发版
混合应用的优势在于：界面与业务逻辑是网页资源，可以在不更新原生壳、不上架审核的情况下，从服务器下载最新网页包替换本地资源，这就是 OTA 热更新（朋友好学的应用内更新检查、下载安装包/资源、MD5 校验就是这类机制的工程化）。但有明确边界：
能走 OTA 热更新（不改原生壳）：
- JS/HTML/CSS 等网页资源、课程内容、图片、配置
- 纯逻辑在网页层、且不改变已审核的核心功能性质
必须发新版、走商店审核：
- 原生插件/权限/原生代码变更（Capacitor 原生层、Android/iOS 原生）
- 新增权限、改变应用主要功能与用途
- 安卓 APK 本体升级、iOS 任何二进制变更苹果明确禁止通过热更新改变应用已审核的核心行为、绕过审核（JSPatch 类方案曾被大规模下架警告）；国内对 App 热更新也有合规要求，不得借热更上线违规内容或改变备案登记的功能。稳妥做法：热更新只用于资源/内容/不改变功能性质的网页层修复，涉及原生与权限、主要功能的变更老老实实发版。
客户端启动时请求一个版本接口（返回最新 versionCode、下载地址、文件校验值、是否强制更新、更新说明）：低于最低支持版本则强制更新（不给继续用），介于之间则可跳过的温和提示。发布可灰度（先放给一定比例/指定版本），安装包要用 MD5/SHA 校验防下载损坏或被篡改。朋友好学的 release-meta 正是承载这些字段，服务端可动态控制而无需 App 改动。
下列关于 Android 签名与版本的说法，正确的是？
本节小结
混合应用链路：Next静态导出→Capacitor拷进原生壳→Gradle构建→release keystore签名→对齐产出APK/AAB分发。Android 每个包必须签名，签名绑定包名身份、覆盖升级必须同签名，keystore要离线多备份、不进Git，丢了无法续更；versionCode整数单调递增判新旧、versionName展示用。APK可直接装(国内/自托管)、AAB交Google Play按需下发、国内多渠道包+加固。iOS用证书+描述文件、TestFlight内测后审核。OTA可热更网页资源/内容/配置，原生层/权限/主要功能变更必须发版走审核，苹果与国内都禁止借热更绕过审核改变核心功能；强制更新靠版本接口(最新versionCode/地址/校验值/强制标志/说明)+灰度+MD5校验。
资深工程师加餐
底层原理 · 大厂视角 · 工程经验，点卡片展开
从浏览器到你的应用，一次请求依次经过 DNS 解析、TCP 三次握手、TLS 握手、反向代理、上游应用，再到数据库或缓存，沿原路返回。每一跳都可能是延迟或故障点，所以排错要分层推进：先确认域名解析和端口连通，再看证书是否有效，最后看应用日志与依赖，而不是出问题就先重启。能把链路一层层说清，定位线上故障会快一个数量级。