patch 集管理：不动共享副本

框架与上游源码集中共享后，一个尖锐问题立刻出现：OHOS 适配总要改源码，改在哪里？Air 系列的答案制度化为一句话：补丁集管理，不动共享副本。这篇讲补丁集的纪律。

▍问题的由来
如果直接在共享源码树里改：改动对所有共用工程生效（你可能只想改自己的行为）；改动无版本记录（上游一升级全丢）；两个工程的改动互相覆盖。早期 Air 系列用过就地标记模式，吃过亏后全面转为补丁模式。

▍补丁集的形态
每个工程一个补丁目录，按主题组织补丁文件：平台后端类、构建修复类、功能裁剪类。每个补丁是标准的版本差异格式，可应用可回退。工程构建流程：检出或链接上游共享树，应用本工程补丁集，进入构建。上游升级时补丁集重放，冲突的补丁显式失败——失败是好事，它告诉你适配点要人工复审。

▍纪律条目
一，补丁原子化：一个补丁只干一件事，方便定位与重放。二，补丁有头注：写明动机、影响面、验证方法。三，补丁不跨层：框架的补丁不捎带应用逻辑，应用专属改动不进框架补丁。四，分叉要登记：某补丁与共享栈彻底不兼容、必须独立副本时，按流程复制带工程后缀的副本并在登记文件写明原因。五，能上游化的补丁推动上游合并，合并成功后本地补丁退役。

▍常见错误
一，构建中顺手改了源码忘了提补丁：下次重建适配消失。防御：构建脚本每次从干净树应用补丁集开始，本地的临时改动活不过一次重建。二，补丁叠补丁无序：补丁间有依赖时要编号定序。三，补丁集与上游版本脱钩：记录每个补丁对应的上游版本基线。

▍价值
补丁集让工程的适配资产可携带、可审计、可重放——工程复制给别人，补丁集就是全部秘密。

有疑问欢迎在本板块直接发帖，我们会逐条回复。