合同核验工程的最后一个环节不是简单导出一页摘要，而是把条款版本、字段差异、复核责任和证据引用固定到同一份可重读的报告里。前七篇已经完成 service-agreement 的稳定条款编号、跨版本逐段对齐、金额和日期规则、宽屏三栏定位、双人修订冲突、离线核验记录以及 r2→r3 的迁移。到了收尾阶段，页面可以关闭，临时文档句柄可以释放，但 CL-02 和 CL-03 的待复核状态不能因报告生成就被改成已通过。报告必须保留这些尚未解决的工作，并让后来打开记录的人找到明确的来源修订。

例如，CL-03 付款约定在较早版本的字段比较中，金额由人民币120000.00元变为125000.00元，付款截止日期由2026-11-15变为2026-11-20。这两项需要复核，不宜在报告中仅写一句“付款条款更新”。CL-02 的验收标准包含两名修订者之间的不同意见，仍需保留对应的修订来源。r3 又新增 CL-05 资料保管条款，不能因为新增条款尚无旧版字段，就在汇总时把它放进“全部一致”的统计。各类状态要分别计数，避免概览数字掩盖待处理项。

先冻结报告输入，再决定输出格式

最终报告应由某个确定的数据快照生成。这里将文档稳定ID、源修订号、目标修订号、条款键、核验结果、证据摘要和复核状态构成独立的数据结构。原始编辑事件、修订差异以及复核决定保留自己的来源标识，而不是在输出Markdown时重新推断。如果生成过程中另一位编辑更新了条款文本，当前报告应继续使用已冻结的输入；新变化可以产生下一份报告修订，不能在同一份报告的前半部分使用旧数据、后半部分使用新数据。

报告中的每条记录至少包含 clauseId、field、sourceRevision、targetRevision、before、after 和 status。这些字段解决两类常见混淆：其一，CL-03 虽然跨版本仍使用同一个稳定编号，但字段内容已经变化；其二，某项核验标记为 pending 可能只是缺少独立复核，并非代码解析失败。把解析结果和人工决策合并成一个真假值，会使后续无法识别还需要谁处理。对没有旧版对应项的 CL-05，应使用 new_clause 这样的独立状态，而不是塞入金额差异列表。

下面的Node.js片段从固定输入构造有序报告，计算规范化内容摘要，并在创建结果后断言待复核数和条款归属。摘要基于确定顺序的字段生成，便于反复导出同一输入时核对内容是否变化。报告的标识另行由归档过程分配，因此不用以系统时钟生成不可复现的条款内容。

const assert = require('node:assert/strict');
const { createHash } = require('node:crypto');
function makeReport(docId, fromRevision, toRevision, findings) {
  const allowed = new Set(['pending', 'approved', 'new_clause']);
  const rows = findings.map(item => {
    if (!allowed.has(item.status)) throw new Error('invalid status');
    if (!/^CL-\d{2}$/.test(item.clauseId)) throw new Error('invalid clause');
    return { clauseId: item.clauseId, field: item.field,
      before: item.before ?? null, after: item.after ?? null,
      status: item.status, sourceRevision: fromRevision,
      targetRevision: toRevision, evidenceId: item.evidenceId };
  }).sort((a, b) => (a.clauseId + a.field).localeCompare(b.clauseId + b.field));
  const body = { docId, fromRevision, toRevision, rows,
    pending: rows.filter(row => row.status === 'pending').length };
  return { ...body,
    sha256: createHash('sha256').update(JSON.stringify(body)).digest('hex') };
}
const report = makeReport('service-agreement', 'r2', 'r3', [
  { clauseId: 'CL-03', field: 'amount', before: '120000.00',
    after: '125000.00', status: 'pending', evidenceId: 'E-amount' },
  { clauseId: 'CL-03', field: 'dueDate', before: '2026-11-15',
    after: '2026-11-20', status: 'pending', evidenceId: 'E-date' },
  { clauseId: 'CL-02', field: 'acceptance', before: '旧验收文本',
    after: '新验收文本', status: 'pending', evidenceId: 'E-review' },
  { clauseId: 'CL-05', field: 'retention', after: '资料保管条款',
    status: 'new_clause', evidenceId: 'E-new' }
]);
assert.equal(report.pending, 3);
assert.equal(report.rows.length, 4);
assert.equal(report.sha256.length, 64);
console.log(report.docId, report.fromRevision, report.toRevision, report.pending);

代码按核验记录条目统计待复核数，所以这里得到3条待复核字段，并不意味着有3个不同的条款；其实际涉及 CL-02 与 CL-03 两个条款。报告顶部可以同时展示“待复核记录3条”和“涉及条款2项”，避免看起来矛盾。证据ID是应用内的引用键，不能仅凭一个短标签推断文件仍然存在；归档前需要验证对应的内容摘要、版本关联和可访问权限。若证据已经迁移到新的保存位置，应保持引用身份并更新位置映射，不要直接改写原核验事件。

将可读报告与机器记录分开

同一批核验事实通常需要两种视图：供开发人员或业务复核阅读的Markdown报告，以及供后续批量检查重新加载的结构化记录。前者强调段落、变更和待复核原因；后者强调精确字段、数据类型和版本标识。不要把一段自然语言摘要当作新的事实来源。特别是金额比较应保留两位小数字符串，避免在多次JSON与浮点数转换之间出现格式变化。日期只记录明确的日历日期或带时区的时间戳，不能默认把所有字段当作当地时间。

Markdown输出可从同一份已冻结的结构生成。表格里的竖线和换行要转义，否则合同条款内容可能意外破坏表格结构。输出中的“待复核”需要原样保留，不能因为文件成功写出而自动改成“已通过”。下方片段把报告转换为Markdown，并检查文档名、修订关系与异常状态都在文本中；它生成的是可阅读的业务报告正文，不依赖其他文件目录，也不包含稿件创作类字段。

const assert = require('node:assert/strict');
function safeCell(value) {
  return String(value ?? '—').replace(/\|/g, '\\|').replace(/\r?\n/g, ' ');
}
function renderReport(report) {
  const labels = { pending: '待复核', approved: '已确认', new_clause: '新增条款' };
  const lines = [
    '# 合同字段核验报告',
    '',
    `文档：${safeCell(report.docId)}`,
    `版本：${safeCell(report.fromRevision)} → ${safeCell(report.toRevision)}`,
    '',
    '| 条款 | 字段 | 原值 | 新值 | 状态 |',
    '|---|---|---|---|---|'
  ];
  for (const row of report.rows) {
    lines.push(`| ${safeCell(row.clauseId)} | ${safeCell(row.field)} | ` +
      `${safeCell(row.before)} | ${safeCell(row.after)} | ${labels[row.status]} |`);
  }
  return lines.join('\n') + '\n';
}
const output = renderReport({ docId: 'service-agreement',
  fromRevision: 'r2', toRevision: 'r3', rows: [
    { clauseId: 'CL-02', field: 'acceptance', before: 'A|B',
      after: 'A与B', status: 'pending' },
    { clauseId: 'CL-05', field: 'retention', before: null,
      after: '资料保管', status: 'new_clause' }
  ] });
assert.match(output, /service-agreement/);
assert.match(output, /A\\\|B/);
assert.match(output, /待复核/);
assert.match(output, /新增条款/);
console.log(output);

对于外部共享，导出应使用平台支持的文件选择与URI授权流程，用户可以查看目标位置并决定是否分享。HarmonyOS的File Sharing文档给出了URI访问授权的基础接口，应用不应把沙箱路径当成任何接收方都能使用的公共路径。报告包含合同金额、日期和修订意见等信息时，还需要按业务规则限制能够导出的字段；工作区仅存储本地非敏感示例数据，并不意味着正式业务的权限判断可以省略。报告内容与文件读取权限应由不同模块负责，避免导出成功后一直保留多余授权。

用版本快照和内容摘要完成归档

归档不是把当前文件覆盖到一个固定名称上就结束。每份报告应绑定文档ID、源修订、目标修订、报告自身修订以及所有依赖的证据摘要；发生补充复核时，再产生新的报告版本并关联旧版本。这样才能解释：在 r3 的第一次批量核验中 CL-02 仍待确认，随后复核结果如何产生，以及新的结论依据是哪份条款正文。历史核验记录应保持可追踪，不能用新的“通过”状态直接覆盖原来的冲突事件。

如果报告由多个异步数据源组成，最好在组装前校验它们的修订边界。例如条款列表属于 r3，金额规则结果却标记为 r2，就应中止这次快照生成并提示重新核验。针对快照文件可使用临时文件、内容摘要和写入确认降低部分写入风险；真正需要多文件原子更新时还必须设计独立事务或提交索引，不应把单文件重命名扩大解释成整个报告目录的原子归档。归档索引可以只保存报告ID、版本关系与摘要，详细证据继续由受控的证据仓库管理。

引用资源要按所有权释放

合同对照页面同时打开 r2 与 r3 时，可能持有正文缓冲区、临时URI、文件描述符、渲染缓存以及多个后台查询。报告生成后，即使页面导航到归档列表，也不能默认所有资源都会自动消失。最常见的问题是多个组件引用同一份证据对象，一处提前关闭导致另一处失效；反过来，谁都不负责释放又会让页面重复进入时不断积累句柄。引用池应该记录明确的借用次数，只有最后一位使用者归还后才执行底层清理。

下面用纯Node.js实现一个带引用计数的资源池：同一键只创建一份对象，多次获取分别返回可释放句柄，归还动作具备幂等性。关闭池时拒绝创建新引用，但已有引用仍可按顺序归还。这里的dispose回调可以在具体工程里连接到关闭文件句柄、取消订阅或释放缓存的动作，不能直接等同于平台系统自动完成了文件授权撤销。

const assert = require('node:assert/strict');
class ReferencePool {
  constructor() { this.entries = new Map(); this.closed = false; }
  acquire(key, factory, dispose) {
    if (this.closed) throw new Error('pool closed');
    let entry = this.entries.get(key);
    if (!entry) {
      entry = { value: factory(), count: 0, dispose };
      this.entries.set(key, entry);
    }
    entry.count += 1;
    let released = false;
    return {
      value: entry.value,
      release: () => {
        if (released) return;
        released = true;
        entry.count -= 1;
        if (entry.count === 0) {
          this.entries.delete(key);
          entry.dispose(entry.value);
        }
      }
    };
  }
  close() {
    this.closed = true;
    if (this.entries.size > 0) throw new Error('references still active');
  }
}
let disposed = 0;
const pool = new ReferencePool();
const first = pool.acquire('r3:CL-03', () => ({ body: '付款约定' }),
  () => { disposed += 1; });
const second = pool.acquire('r3:CL-03', () => { throw new Error('duplicate'); },
  () => { disposed += 1; });
assert.strictEqual(first.value, second.value);
first.release();
assert.equal(disposed, 0);
second.release();
second.release();
assert.equal(disposed, 1);
pool.close();
assert.throws(() => pool.acquire('new', () => ({}), () => {}), /closed/);
console.log('引用释放计数', disposed);

在ArkUI界面中，证据预览的生命周期与业务报告的保存时间并不一致。Navigation的NavDestination页面隐藏或销毁时，应取消该页面持有的临时订阅和查询，把跨页共享资源交由更长生命周期的持有者管理。处理异步加载时还应加入报告快照ID判断，防止用户切换到另一份合同时，上一份合同的迟到结果覆盖当前对照界面。对可读报告使用列表展示时，稳定的报告ID和条款ID比行索引更可靠，能在宽屏三栏与手机单栏之间保持定位关系。

让系列收尾保持可解释性

报告输出、归档和资源释放是三个可以分别失败的步骤。生成Markdown成功但归档失败时，界面应保留可重试状态；归档完成但部分证据不可访问时，报告应显示具体缺项，而不是修改历史核验结果；资源释放失败则需要定位仍被哪个界面或任务持有。清晰记录每一步的输入快照、完成状态和错误类别，才能避免把“页面关闭”误认为“所有核验工作完成”。

华为开发者的Preferences接口可用于少量配置和最近报告键，使用时需注意不同存储模式的落盘行为与并发限制；Navigation文档给出了页面隐藏及销毁阶段；File Sharing接口涉及文件URI授权。将这些平台能力同应用层报告生成器、引用池分开封装，可以在不同终端上保留一致的业务含义，而不依赖某种固定窗口宽度或私有文件路径。

相关技术资料：华为开发者Navigation子页面生命周期、Preferences键值持久化、文件URI共享授权、ArkUI列表开发。

八篇合同核验连载至此形成从条款身份、跨版本字段差异到多人复核、迁移与报告归档的一条完整工程链。稳定引用确保找到正确内容，明确状态保留未解决问题，快照保证报告可重现，资源所有权让页面可以安全退出。只要这些关系不因一次导出或布局切换被破坏，合同核验记录就能在持续修订中保持清楚、可追踪的技术结构。