版本迭代到发布前夕，风险并不只来自新功能本身。即使代码完成了修改，旧版本产生的配置记录、资源索引和业务草稿仍然可能采用另一套字段结构。只比较versionCode，无法解释旧数据能否被新业务正确读取；只准备旧安装包，也不足以处理用户数据已经迁移的情况。因此，发布门禁必须同时记录版本快照、迁移步骤和异常后的业务回退路径。

ReleaseGuard前六篇固定了com.example.releaseguard、产品default、基线版本1.2.3和整数版本1000203，构建候选文件2项、已完成摘要0项。门禁状态为CONFIG_PASS、MANIFEST_PENDING、PRIVACY_REVIEW、RESOURCE_REVIEW、SIGNING_REVIEW，总体为HOLD。上篇问题闭环关闭了英文资源缺失键privacy_retention_notice，但仍有4项开放问题，其中包括资源占位符差异、隐私用途、签名关联和产物摘要。本篇沿用这些记录，不从一个全新的“发布成功”状态开始。

一、版本编号和业务数据结构是两条独立轴线

准备评估下一候选1.2.4 / 1000204时，首先需要把新版本编号与已有数据结构分开。versionName方便阅读，versionCode用于区分发布构建，业务数据仍可能保留schema=2格式。设立新数据格式schema=3，主要目的在于把分散的门禁状态整理进gates对象，并保留原问题主键。应用层迁移不能因为版本名称出现“1.2.4”就自动写入成功标志；迁移完成与发布许可必须分别计算。

华为Hvigor配置实践说明给出了读取和设置app.json5中versionCode的工程级配置方法，多产品与构建模式定制介绍了产品和构建模式的区别。ReleaseGuard将这些字段作为输入快照核对项，具体业务数据迁移则由独立的应用层函数处理。这样既能保持构建配置和业务逻辑一致，也能避免把产品配置的变化误判为用户数据需要重写。

const release = {
  bundleName: 'com.example.releaseguard', product: 'default',
  baseline: { versionName: '1.2.3', versionCode: 1000203 },
  candidate: { versionName: '1.2.4', versionCode: 1000204 },
  candidateArtifacts: 2, digested: 0,
  gates: {
    config: 'CONFIG_PASS', manifest: 'MANIFEST_PENDING',
    privacy: 'PRIVACY_REVIEW', resource: 'RESOURCE_REVIEW',
    signing: 'SIGNING_REVIEW'
  },
  issues: { open: 4, closed: 1 }, overall: 'HOLD'
};
function compareBuildVersion(a, b) {
  return Number.isInteger(a) && Number.isInteger(b) && b > a;
}
console.log(compareBuildVersion(1000203, 1000204));

二、迁移之前保存能够解释旧结构的快照

一次可追踪的迁移，输入不应只有待写入的数据，还应包含来源结构版本、目标结构版本、原始摘要和业务问题主键集合。对schema=2的旧记录，要保存资源门禁、隐私门禁等现有字段，逐项映射到schema=3的结构。迁移后的新对象保留旧问题主键、原版本标识和迁移状态，防止后续排查时无法对应之前的处理记录。

迁移快照最好是不可变副本。开始写入新结构前，先复制旧记录并计算摘要；完成后对必要字段进行检查，再以单次提交方式替换目标记录。如果迁移过程中遇到格式不一致或部分字段缺失，应当返回结构化的失败结果并保留旧副本。对实际持久化存储，还需根据存储类型考虑事务、原子替换及崩溃恢复机制，不宜只靠页面内的一个布尔值表示已经保存。

旧记录中可能包含敏感业务数据，因此快照需要明确存储位置、访问权限和清理周期。应用日志与质量台账保留摘要、结构版本和问题数量即可，不需要复制完整的用户文本或签名材料。以前登记的.p12、.cer、.p7b材料引用仍按受控权限管理，迁移过程只处理引用状态，不对材料文件重新命名或导出。

三、数据迁移必须保持业务主键和门禁语义

此处用一份精简记录说明schema=2到schema=3的转换。原有resourceGate、privacyGate字段搬入gates对象，四项开放问题和一项已关闭问题的主键集合保持不变。转换前后分别确认数组主键不重复，确保同一问题不会因格式变化而被计算两次。迁移标志只表示结构符合预期，不会改动原始问题的关闭状态。

const source = {
  schema: 2, releaseCode: 1000203,
  resourceGate: 'RESOURCE_REVIEW', privacyGate: 'PRIVACY_REVIEW',
  issueIds: ['resource:release_version','privacy:purpose',
    'signing:relation','manifest:digest'], closed: ['resource:privacy_retention_notice']
};
function migrateToThree(input) {
  if (input.schema === 3) return structuredClone(input);
  if (input.schema !== 2 || !Array.isArray(input.issueIds)) {
    throw new Error('UNSUPPORTED_SCHEMA');
  }
  if (new Set(input.issueIds).size !== input.issueIds.length) {
    throw new Error('DUPLICATE_ISSUE');
  }
  return {
    schema: 3, sourceSchema: 2, releaseCode: input.releaseCode,
    gates: { resource: input.resourceGate, privacy: input.privacyGate },
    issues: [...input.issueIds], closed: [...(input.closed || [])]
  };
}
console.log(migrateToThree(source).issues.length);

这段代码返回新对象，不直接覆盖source。生产工程仍需为迁移定义稳定的提交点，并在失败时恢复先前快照。对于新结构未识别的附加字段，应设置明确策略：重要业务字段进行保留或显式迁移，临时缓存可在适当阶段重建，未知敏感字段不能随意塞进日志。迁移后的重复执行应具备幂等性，schema=3的数据直接返回副本，避免把已迁移字段再次拼接到数组中。

四、回退是恢复业务可用性，不是简单降低版本号

候选构建出现异常后，可以采用多种应用层回退方式：关闭新功能路径、恢复旧的业务配置、暂停新数据写入、恢复先前的受控快照，或者以新的修复版本替换存在问题的候选。哪条路径适用，取决于是否已经产生不可逆的数据变更。某些迁移若删除了旧字段且没有保留快照，就不能仅靠切换界面开关恢复原数据。判断时应分别记录dataRestorable、featureSwitchAvailable和schemaCompatible，不能把三者合并成一个“支持回退”。

应用市场版本管理还有自己的版本约束。发布策略应以当前渠道要求和实际在架版本为依据；应用层的恢复旧配置并不意味着可以把低版本编号的软件包直接重新提交。本文的BASELINE_RETAINED说明稳定业务配置仍被保留，HOLD说明候选尚未取得发布许可，两者共同构成当前状态。因此，版本回退策略必须和发布配置检查保持独立。

五、将数据迁移结论接入现有五项门禁

对ReleaseGuard而言，迁移能否进行与发布能否放行是两个判断。迁移结构检查通过后，仍要重新读取产物摘要、签名关联、隐私用途和资源占位符的检查结果。哪怕新业务数据已经成功转换，如果摘要仍为0/2、签名关联待复核或多语言参数尚不一致，整体决策也必须维持HOLD。这样既能在开发环境中验证新结构的处理规则，也能避免把迁移函数的一次成功执行误当成整体发布已经准备就绪。

function decideRelease(snapshot, migration) {
  const required = ['config','manifest','privacy','resource','signing'];
  const passing = { config: 'CONFIG_PASS', manifest: 'MANIFEST_PASS',
    privacy: 'PRIVACY_PASS', resource: 'RESOURCE_PASS',
    signing: 'SIGNING_PASS' };
  const blocked = required.filter(k => snapshot.gates[k] !== passing[k]);
  if (!migration.dataRestorable) blocked.push('DATA_RESTORE');
  if (!migration.schemaCompatible) blocked.push('SCHEMA_COMPAT');
  return {
    decision: blocked.length ? 'HOLD' : 'READY',
    blocked, baseline: 'BASELINE_RETAINED'
  };
}
const gates = { config:'CONFIG_PASS', manifest:'MANIFEST_PENDING',
  privacy:'PRIVACY_REVIEW', resource:'RESOURCE_REVIEW',
  signing:'SIGNING_REVIEW' };
console.log(decideRelease({ gates },
  { dataRestorable:true, schemaCompatible:true }).decision);

blocked列表会保留四个未满足门禁，避免单个HOLD状态掩盖真实原因。后续某项资源检查修复后，只更新对应门禁，再使用同一个函数重算结果，其他问题不能被顺带关闭。版本号与迁移结构也应绑定：当候选从1000204推进到新的整数版本，已有迁移报告可以作为参考，但必须明确它验证的来源快照、目标结构和候选构建标识。

六、让迁移和回退状态便于追踪

质量页面在顶部继续展示基线1.2.3 / 1000203与候选1.2.4 / 1000204，下方列出schema 2 → schema 3、四项开放问题、一项已关闭问题和五项门禁。数据恢复能力显示为SNAPSHOT_READY，候选决策为HOLD，稳定配置保留为BASELINE_RETAINED。这些标签描述的是工程工作流的当前记录，不需要依赖未经核实的发布后台状态。

遇到迁移失败时，界面应记录输入结构、失败阶段、可恢复快照是否存在，并阻止继续写入。对于用户主动返回旧页面的情况，若底层数据已经采用新结构，旧页面仍需通过兼容读取器读取必要字段；若兼容读取器不存在，就应关闭该入口而不是显示不完整信息。对审计数据保持最小化：问题主键、结构版本、候选版本和恢复操作结果足够定位，大量原始业务数据不应随着页面跳转持续复制。

七、用确定的状态结束本次版本评估

本阶段的结果是：ReleaseGuard保留稳定版本1.2.3 / 1000203，将1.2.4 / 1000204纳入候选评估；数据结构转换规则由schema=2推进到schema=3，旧问题主键不变，快照恢复路径明确。现有四项开放问题仍未关闭，产物摘要完成数保持0/2，五项门禁依旧是一项通过、四项待处理，所以发布决策继续HOLD。下一篇可以沿用这些事实完成审计收口，将每一个状态关联到对应的版本快照与检查依据，而无需反复重建问题台账。