做空间重建时，一个容易被忽略的问题是：任务列表显示“素材已齐”，并不意味着每个文件仍然是采集时登记的内容。图片从拍摄端传到工作站，再被清理工具改名、同步到共享目录，任意一次覆盖都可能让同名文件变成另一份数据。等到3DGS重建结果出现异常，才回头找是哪一帧变化，往往已经错过最容易定位的时机。

我把这次工程问题限定在重建调用之前：为已有采集帧生成不可混用的清单，逐条计算SHA-256，与登记时的摘要比较；发现不一致，就把当前批次隔离，让上一次可用场景继续保持可见。示例项目叫FrameProof，任务号FP-808，采集批次RECON-42，预设14帧，其中13帧一致、FRAME-009一帧不一致，业务门禁为QUARANTINED，继续展示旧场景SCENE-041。这些数字属于明确写在Demo中的构造数据，不能当作空间重建接口已经实测的结果。

一、先把“文件存在”与“文件可信”拆开

对3DGS来说，输入帧缺失、内容变化、拍摄覆盖不足是不同问题。前两项能在本地文件层检查，后一项涉及画面质量与算法适用条件，必须由重建能力和业务流程继续判定。把三种原因混成一个“采集失败”状态，会让用户不知道应该补拍还是重传。

华为的空间计算介绍将3DGS端侧重建列为场景建模能力，但这并不等于系统自动提供本文的SHA-256采集清单。我这里使用的是Node.js标准库，在应用外的素材预处理阶段实施。FrameProof不伪造Spatial Recon Kit的回调、枚举或性能指标，也不把一张通过哈希检查的图片说成一定满足建模质量要求。

这套清单的关键不是“有14行”，而是每行都能对应一份可信来源。业务ID使用FRAME-001到FRAME-014，实际文件可叫frames/001.jpg等，ID和磁盘文件名分离；重命名不会改变ID，文件覆盖却会改变摘要。若清单和文件一起被恶意替换，单纯比对仍可能给出一致，因此正式发布应对清单的生成者、签名或可信交付渠道再做约束。

二、清单登记只发生在确定采集完成之后

录入时先冻结批次ID，再登记每帧相对路径、字节数与SHA-256。不要在每一次预览刷新时重新计算“期望摘要”，否则被污染的文件会被当成新的正确版本。摘要应来自采集确认时的可信输入，校验器只是消费清单，不负责修改其期望值。

下面第一段是登记端核心方法，使用Node.js的readFile与createHash。路径安全、重复ID检查和清单签名应由外围入库流程补齐，避免这段短代码被误当成完整安全系统。

import { readFile } from 'node:fs/promises';
import { createHash } from 'node:crypto';

async function registerFrame(id, relativePath, root) {
  const bytes = await readFile(new URL(relativePath, root));
  return {
    id,
    path: relativePath,
    bytes: bytes.byteLength,
    sha256: createHash('sha256').update(bytes).digest('hex')
  };
}

这里使用URL形式的根目录只是为了讲明登记过程，生产项目应统一使用明确的文件目录边界，并禁止目录逃逸与符号链接绕过。上一篇涉及路径约束的工程问题不在本篇重复展开。本篇只研究“可信清单已经建立以后，如何发现内容漂移”，两道防线不能互相替代。

一批素材中可能同时存在原图、缩略图和推理缓存，不能把它们放在同一种语义里。清单只登记进入重建的原始采集帧；缓存文件可重建，不应由于缓存丢失就把原帧批次标记为损坏。同样，文件扩展名为.jpg不等于内容就是合法JPEG，后续仍需通过解码检查和采集质量规则。

三、复核要按流读取，也要给出可解释的失败条目

移动设备拍摄的图像可能很大。一次把14帧全部读进内存虽然示例也能工作，但会让批次越大越容易出现峰值内存压力。复核阶段采用文件流逐块计算摘要，单个文件读取完成后再进入下一条。业务量增长后可以引入有限并发，但不要为了追求速度放开不受控的并行数。

第二段代码返回MATCH或MISMATCH；如果文件读取中途失败，抛出I/O错误，调用者应将它记为UNREADABLE，不能把它简单伪装成哈希不一致。两种情况的修复方式不同，日志和用户提示也要不同。

import { createReadStream } from 'node:fs';
import { createHash } from 'node:crypto';

async function hashFile(filePath) {
  const hash = createHash('sha256');
  for await (const chunk of createReadStream(filePath)) {
    hash.update(chunk);
  }
  return hash.digest('hex');
}

async function compareOne(row, absoluteFile) {
  const actual = await hashFile(absoluteFile);
  return { id: row.id, status: actual === row.sha256 ? 'MATCH' : 'MISMATCH' };
}

在RECON-42的构造输入中，只有FRAME-009的内容与登记摘要不同；匹配13帧，不匹配1帧。这个结果不能直接推成“模型会错”或“模型不会错”，只能严谨地表达成“输入批次没有通过一致性门禁”。用户应优先看FRAME-009的采集时间与来源，再选择重传可信原帧或另起批次重采；不应悄悄把期望摘要改成现状。

如果文件路径不可读、清单不存在、清单JSON无法解析或同一ID重复，整批进入QUARANTINED也可以，但报告需要单列READ_ERROR、BAD_MANIFEST、DUPLICATE_ID等内部原因，不然开发和运营只能看到一个笼统的红色标记。例子没有故意填入不存在的官方错误码，因为上述状态完全是自建工具的业务枚举。

四、发布指针只能在整批通过后更新

另一类问题发生在校验完成之后：界面还在读取旧场景，新的批次突然被设置为当前场景，导致缩略图、模型包和元数据来自不同版本。解决方法不是依赖“用户不会此时打开”，而是把可见场景看成一个已发布指针，在候选批次完整通过之前不修改它。

第三段用本地同文件系统的临时文件和重命名表达最小发布过程。代码接受上游已确认的ok，不假装自己完成3DGS算法；候选失败时仅产出隔离报告，不覆盖current-scene.json。正式工程还应对写入持久性、进程崩溃恢复和跨文件系统行为补充验收。

import { writeFile, rename } from 'node:fs/promises';

async function publishAfterAudit(ok, batchId, report) {
  if (!ok) {
    return { taskId: 'FP-808', gate: 'QUARANTINED', active: 'SCENE-041' };
  }
  const temp = 'state/current-scene.json.tmp';
  const target = 'state/current-scene.json';
  await writeFile(temp, JSON.stringify({ batchId, scene: report.scene }) + '\n');
  await rename(temp, target);
  return { taskId: 'FP-808', gate: 'PUBLISHED', active: report.scene };
}

这个顺序的实际意义很明确：发布操作失败，旧指针原则上仍是可恢复的基线；校验失败时，更不应进入替换步骤。rename在同一文件系统内通常可实现名字切换，但它不是完整数据库事务，也不自动保证多个资源包一致提交。上架或跨端同步场景还要把文件生命周期和元数据版本一起纳入发布协议。

五、手机端应该展示“隔离”，而不是假装重建成功

FrameProof的演示页只展示采集状态卡片，不承担真正的3DGS处理引擎。预设任务为FP-808、批次RECON-42、总帧数14、匹配13、异常1、异常帧FRAME-009、门禁QUARANTINED，仍在展示的已发布场景为SCENE-041。示意时间固定在16:40，和开发演示图使用同一份数据约定。

HiLog风格的模拟记录依次是16:40:10 manifest=RECON-42 frames=14、16:40:12 matched=13 mismatch=1、16:40:12 gate=QUARANTINED frame=FRAME-009。这三行文字只是视觉解释状态机，不是运行过华为重建SDK的证据。把状态和日志约定写在文章里，可以避免后续生成配图时把一帧错误画成两帧、把隔离误写成完成。

六、验收时重点看四个边界

第一，重复校验同一份文件应得到相同摘要，且不会修改任何输入字节。第二，把FRAME-009替换成另一份内容后应稳定进入隔离状态，恢复可信原件后才允许重新发起审核。第三，删除一帧要得到读取错误，而非从14帧悄悄减少成13帧继续发布。第四，用户在审核中途离开页面，校验任务不应持有已经失效的UI引用，结果必须通过批次ID回收。

这里还存在一个容易忽视的并发问题：一个校验任务开始于RECON-42，执行期间用户切换到RECON-43，前一个任务的迟到报告不能覆盖当前批次的判断。报表应携带批次ID与任务代次，提交时核对是否仍为当前待审对象；过期结果只能存历史记录，不能推动发布指针。这个约束比把进度条做得更平滑更重要。

最终结论很克制：SHA-256清单解决的是传输与存储后的字节一致性，不是覆盖率、重建精度或模型质量；QUARANTINED是应用自定义的预发布门禁，不是官方错误码。本篇没有调用Spatial Recon Kit，也没有进行真实3DGS计算。把这道边界放在重建流程外层，才便于后续接入真实能力时明确“谁负责验原件、谁负责算模型、谁负责发布”。

参考资料：华为HarmonyOS空间计算与3DGS能力介绍 https://developer.huawei.com/consumer/cn/features/spatialization ；华为3DGS端侧重建流程文档 https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/spatial-recon-c-spatial-recon-pipeline ；Node.js crypto文档 https://nodejs.org/api/crypto.html 。