HarmonyOS 上架资料变更与回退决策的发布门禁【共创稿事节】

阿楠坤

6人浏览 · 2026-10-23 19:06:03

阿楠坤 · 2026-10-23 19:06:03 发布

候选包已经与源码、依赖快照和披露记录绑定以后，上架动作仍可能在最后一段路上偏离计划。产品修改了应用截图，运营更新了功能介绍，隐私政策补充了一段数据处理说明，而负责提交的人手中仍是前一天已经批准的发布材料。如果只检查安装包哈希，这些文案和图片的变化不会触发提醒；如果每次小改动都重新走完整个构建流程，又会让发布协作变得低效。

这一章沿用前几篇的应用发布工作台。已经确认的候选身份仍由包名、versionCode、源码修订和产物摘要组成，前两章的依赖与隐私披露检查也继续有效。新加入的是“上架资料版本”和“审批决策”：资料变化时精准指出变更项，重要字段的修改必须重新复核，提交后遇到问题能找到上一份稳定交付记录，而不是靠聊天记录判断该撤回什么。

上架资料变更与发布决策

将候选包与可编辑资料分开管理

发布记录至少有两种变化频率。构建产物和依赖快照在候选冻结后应该保持不变，应用截图、文字描述、隐私链接及许可材料则可能在提交前调整。把它们全部放进一个可以任意编辑的对象，容易发生“文件没变、审核状态却被无意带过”的问题。我倾向于将发布记录拆成候选包身份和资料修订两部分，分别保留指纹与修改时间。

这里的资料修订不是简单的一组附件路径。截图要记录语言、设备规格或展示位置以及文件摘要；隐私文案要记录版本、目标页面链接与内容摘要；许可证清单要关联发布依赖快照。若只保存“截图共六张”，删除其中一张又补回一张，数量仍是六，但提交材料已经变了。正确的比较对象应该是每一个业务槽位对应的内容，而不是文件数量。

上架表单的展示顺序也值得考虑。对于有顺序意义的截图列表，位置变化本身就是变更；对于没有顺序意义的许可证引用，稳定按名称与版本排序就足够了。把两类资料都当成无序集合，会漏掉首页截图发生调整；把两类资料都按文本原样比较，又会给审核报告制造无关噪声。

用差异项驱动重新复核

第一个代码片段使用 Node.js 标准库，给候选包绑定一份上架资料清单。包摘要、版本编码继续取自上一篇已经核对过的发布记录；这里展示的数据值用于说明清单的存储关系。截图的文件摘要由资料上传流程计算，不能依靠文件名去重。

const crypto = require('node:crypto');
function hash(value) {
  return crypto.createHash('sha256').update(JSON.stringify(value)).digest('hex');
}
const publishedCandidate = {
  bundleName: 'com.sample.projecthub', versionCode: 30201,
  versionName: '3.2.1', candidateKey: 'frozen-candidate-identity'
};
const submitted = {
  candidateKey: publishedCandidate.candidateKey,
  screenshots: [
    { slot: 'phone-home', language: 'zh-CN', digest: hash('首页截图初稿') },
    { slot: 'phone-detail', language: 'zh-CN', digest: hash('详情截图初稿') }
  ],
  privacy: { revision: '1.2', digest: hash('隐私说明版本1.2') },
  licensesDigest: hash(['@sample/ui-kit@1.2.0', '@sample/metrics@0.8.0'])
};
const proposed = structuredClone(submitted);
proposed.screenshots[1].digest = hash('详情截图更新稿');
proposed.privacy = { revision: '1.3', digest: hash('隐私说明版本1.3') };

这类清单还需要保存实际文件的访问位置和可追溯的上传记录。不过比对函数更关心稳定的资料键：同一个语言和展示位置不能同时出现两张相互冲突的截图。隐私版本升级则不只是版本数字改变，还必须重新确认内容和服务端可访问的地址。若引用的许可清单发生变化，关联的依赖快照也应该回到前文的门禁，不能在资料审查阶段悄悄换成另一份。

开发环境中的上架资料核对视图

不要让新修订继承旧状态

发布工作台的审批状态不宜绑在“应用”这个过大的对象上，而应该绑到具体候选身份与资料修订的组合。假设候选包已经通过检查，截图被替换后，如果状态仍显示“已批准”，提交人就可能把未经复核的素材连同原候选一起提交。理想的做法是生成一份差异报告，告诉负责人什么变化、谁需要复核、原批准对象还是否有效。

下面的第二段代码将截图按槽位比较，并把隐私与许可清单作为单独项目。缺失槽位、重复槽位和同名不同摘要都属于需要处理的差异。报告不直接断言某个修改是否合规，而是保留明确的审核任务，防止把程序的字段检查误当成内容审核结论。

function screenshotMap(list) {
  const map = new Map();
  for (const item of list) {
    const key = `${item.language}|${item.slot}`;
    if (map.has(key)) throw new Error(`截图位置重复: ${key}`);
    map.set(key, item.digest);
  }
  return map;
}
function diffMaterials(before, after) {
  if (before.candidateKey !== after.candidateKey) {
    throw new Error('资料关联的候选包身份发生变化');
  }
  const changes = [];
  const a = screenshotMap(before.screenshots);
  const b = screenshotMap(after.screenshots);
  for (const key of new Set([...a.keys(), ...b.keys()])) {
    if (a.get(key) !== b.get(key)) changes.push({ field: `screenshot:${key}`, owner: '设计与产品' });
  }
  if (hash(before.privacy) !== hash(after.privacy)) {
    changes.push({ field: 'privacy', owner: '产品与隐私负责人' });
  }
  if (before.licensesDigest !== after.licensesDigest) {
    changes.push({ field: 'licenses', owner: '三方库维护负责人' });
  }
  return changes;
}

有了差异报告，还需要一个清晰的审批状态流。草稿可以反复编辑，进入复核后应冻结该修订内容，审批完成才能进入待提交。若复核期间又出现修改，应当新建修订，原审批结果留在原来的内容指纹上。若提交人拿到的文件摘要与批准时不同，就暂停放行，而不是临时打一个“已确认”标签绕过校验。

多语言资料要格外细分：简体中文描述已更新，并不意味着其他语言的版本同步完成；图片规格、文案长度和图文含义也可能分别需要检查。运营在同一天提交几次调整时，最好以修订编号串起这些变化，不要用最后修改时间决定哪份算“已审核”。时间可以辅助排序，但无法替代内容摘要和审批引用。

回退应区分包、资料和运营配置

“回退”在发布现场经常指三种完全不同的动作。候选还在待提交状态时，可以撤回本次资料修订并保留上一份已批准记录；已经提交但尚未进入分发阶段时，需要按照当前平台支持的流程处理撤回和重新提交；应用已经分发后，则要结合线上问题范围决定暂停后续投放、切回受控的服务端配置，或准备一个新的修复版本。

对于已分发的安装包，不建议把降低 versionCode 当成客户端回退方案。版本编码涉及应用版本升级关系，回到旧源码也不意味着可以沿用旧的版本编码直接覆盖已安装的新版本。更稳妥的工程路径是把上一个稳定修订作为修复分支的输入，生成递增版本编码的新候选，再重新执行构建与资料门禁。发布平台的操作与候选包变更要分别记录，避免把服务端开关回退与客户端包替换写成同一件事。

第三段代码展示审批前的放行判定和回退决策。代码刻意把“提交动作”留给发布工具和人工授权流程，发布工作台输出的是结构化决策及原因列表，以免一次状态判断就触发不可逆的外部操作。

function releaseDecision({ prior, next, approvedFields, versionCode, previousCode }) {
  const changes = diffMaterials(prior, next);
  const missing = changes.filter(c => !approvedFields.includes(c.field));
  const reasons = missing.map(c => `待复核: ${c.field} / ${c.owner}`);
  if (versionCode <= previousCode) reasons.push('新版本编码需要递增');
  return {
    decision: reasons.length ? 'hold' : 'ready-for-submission',
    reasons, materialFingerprint: hash(next), candidateKey: next.candidateKey
  };
}
function recoveryPath(stage) {
  switch (stage) {
    case 'draft': return '恢复上一份已批准资料修订';
    case 'submitted': return '核对平台提交状态并安排修订复核';
    case 'distributed': return '保留稳定服务配置并规划递增版本修复';
    default: throw new Error('发布阶段不明确');
  }
}
const changes = diffMaterials(submitted, proposed);
const report = releaseDecision({
  prior: submitted, next: proposed, approvedFields: [],
  versionCode: 30201, previousCode: 30200
});
console.log({ changes, report, recovery: recoveryPath('draft') });