3DGS 重建产物常常不是单个文件。为了分段交付，团队会在自己的中间素材格式里维护若干瓦片与引用关系：某个瓦片需要先准备相邻层级的纹理，另一个瓦片依赖某份几何数据。如果构建链路没有在进入重建或分发前检查依赖图，路径看起来都存在，也不代表它可以按顺序装配。最典型的两种问题就是引用了不存在的节点，以及两个节点互相等对方完成。本篇不假装调用了华为重建算法的内部 API。用一个名为 TileGraphGuard 的 Node.js 小工具检查团队自定义的 tiles.json 清单，只在本地数据层做完整性预检。示例任务 TG-1810 有五个瓦片节点 T01—T05，T02 → T03 → T02 构成一个环，T04 → T09 则指向缺失的 T09。界面最终状态为 HOLD_GRAPH，并非真实重建失败回调。## 一、先规定清单的含义，再谈检查器不要因为文件里写了 deps 字段，就把它说成某个 3DGS SDK 的公开参数。这里的依赖清单由上游资源预处理脚本生成，格式和规则由团队控制，目标只是让失败原因从“构建超时”提前变成“具体哪个节点存在问题”。后续若换成别的资源清单，需要写转换层，而不是把本篇 JSON 原封不动传给重建接口。五个样例节点只保留最基本的 id 和 deps。T01 依赖 T02，T02 依赖 T03，T03 又依赖 T02；T04 依赖 T09，但索引里没有 T09；T05 没有依赖。示例故意让两种异常同时出现：若检查器遇到第一个环就停止，便会漏掉后面的缺失节点，误以为处理了清单中的全部问题。下面的 JSON 先解决测试输入必须可复现的问题。它不是相机采集记录、不是官方 3DGS 结构定义，也不承诺能由任意空间计算 Kit 直接识别。json{ "taskId": "TG-1810", "nodes": [ { "id": "T01", "deps": ["T02"] }, { "id": "T02", "deps": ["T03"] }, { "id": "T03", "deps": ["T02"] }, { "id": "T04", "deps": ["T09"] }, { "id": "T05", "deps": [] } ]}在实际工程中，除 id、deps 外，通常还需要哈希、文件大小、资源类型等独立检查。那些信息解决“文件内容是否可信”，依赖图解决的是“组装顺序是否有解”，不要拿一个检查替代另一个。此前已经做过清单路径越界与引用拦截，本篇刻意不重复路径安全问题，改为分析图的拓扑合法性；同样是发布前预检，但算法、不变量和错误恢复策略并不相同。## 二、Map 加索引，DFS 保存递归路径对于小规模清单，先把节点放入 Map，再遍历依赖关系比每次用数组 find 扫描更直观。找不到目标节点时记录一次 MISSING；沿当前递归路径再次遇到已经进入但尚未退出的节点时记录 CYCLE。这里要特别区分“全局已访问”与“当前递归路径”：某个节点被两个不同入口共同依赖是合法复用，不是环。实现时以颜色或集合表示这两种状态。active 存正在处理的节点，done 存已经完整走过的节点。为了得到能展示给人的 T02 → T03 → T02，还需要一个 stack 保留当前路径。遇到环以后不直接抛异常退出全局扫描，而是记下环并继续检查其余顶层节点，这样 T09 缺失也能报告。下面的 JavaScript 代码解决循环与缺失同时诊断的问题，运行位置为 tools/graph-audit.mjs。它使用 Node.js 原生 Map、Set，没有引入虚构的空间重建接口。jsexport function auditGraph(nodes) { const byId = new Map(); for (const node of nodes) { if (byId.has(node.id)) throw new Error(`duplicate: ${node.id}`); byId.set(node.id, node); } const active = new Set(); const done = new Set(); const stack = []; const missing = new Set(); const cycles = []; const cycleKeys = new Set(); function visit(id) { if (!byId.has(id)) { missing.add(id); return; } if (active.has(id)) { const begin = stack.indexOf(id); const cycle = stack.slice(begin).concat(id); const key = cycle.slice(0, -1).sort().join('|'); if (!cycleKeys.has(key)) { cycles.push(cycle); cycleKeys.add(key); } return; } if (done.has(id)) return; active.add(id); stack.push(id); for (const nextId of byId.get(id).deps) visit(nextId); stack.pop(); active.delete(id); done.add(id); } for (const node of nodes) visit(node.id); return { nodes: nodes.length, missing: [...missing], cycles, state: missing.size || cycles.length ? 'HOLD_GRAPH' : 'GRAPH_READY' };}````active` 与 `done` 的关系是本段算法核心：如果仅存一个 `visited` 集合，`T02` 再次出现时并不能判断它来自重复共享还是回到当前路径。`stack.indexOf` 用来找形成环的起点。代码通过 `cycleKeys` 避免相同节点组被简单重复记录，但它不是完整的图同构算法；两个不同方向且节点集合相同的环可能被合并。这符合“先定位有问题的节点组”的用途，却不适合要求枚举所有简单环的数学分析工具。实际清单巨大时，还要考虑递归深度与内存上限，可以切成显式栈迭代方式。![](https://i-blog.csdnimg.cn/direct/52c1525147704daaa0ab80fc07ec3623.png)## 三、诊断结果不应以“首错即停”掩盖第二个问题按照上面的构造数据，扫描五个节点后应得到 `nodes=5`、`missing=['T09']`、`cycles=[['T02','T03','T02']]`。这里的 **5** 是清单中声明的节点数，不是成功重建瓦片数量；**1 个环**是算法报告的环组数量，也不是传感器错误次数。界面把两个异常分开显示，是为了让修复者知道先补文件还是先更正配置。第三段代码解决命令行读取、输出与退出码的工程连接点。JSON 语法错误与依赖图不合法应区分；文件不存在、权限问题和格式问题也需要在外围捕获。Node.js 的 `readFile` 是文件读取接口，`process.exitCode` 负责告诉 CI 当前进程是否通过本地门禁，二者不是鸿蒙应用上架平台的审核接口。jsimport { readFile } from ‘node:fs/promises’;import { auditGraph } from ‘./graph-audit.mjs’;async function main() { const raw = await readFile(‘./data/tiles.json’, ‘utf8’); const doc = JSON.parse(raw); if (!Array.isArray(doc.nodes)) throw new Error(‘invalid nodes’); const report = auditGraph(doc.nodes); console.log([TileGraphGuard] ${doc.taskId} nodes=${report.nodes} + missing=${report.missing.join(',') || 'none'} cycles=${report.cycles.length}); console.log([TileGraphGuard] ${doc.taskId} state=${report.state}); if (report.state !== ‘GRAPH_READY’) process.exitCode = 2;}main().catch((error) => { console.error(error); process.exitCode = 1; });```在本篇样例里，期望日志严格为 [TileGraphGuard] TG-1810 nodes=5 missing=T09 cycles=1 和 [TileGraphGuard] TG-1810 state=HOLD_GRAPH，进程退出码为 2。这些字符串是可用 Node.js 本地脚本验证的构造测试期望，不代表华为空间重建任务状态。脚本建议在构建前单独执行，只有 GRAPH_READY 才允许进入后续管道，但不应承诺后续重建一定成功。process.exitCode 的优点是让当前调用栈可以正常处理输出和清理，而不是直接调用 process.exit() 截断仍在写入的日志。另一方面，这里选择固定文件 ./data/tiles.json，如果脚本工作目录改变会报找不到文件；生产实现应按脚本路径或显式参数解析输入路径，且与之前已有的路径越界审计联合使用，不能把本段简化演示当作安全防护。## 四、开发演示图中哪些值必须彼此对应DevEco 风格演示图左侧显示 TileGraphGuard 的 tools/graph-audit.mjs、data/tiles.json；中央强调 auditGraph 与 active、done、stack 的用途；右边手机演示屏标明 TG-1810、节点 5、缺失 T09、环 T02 ↔ T03、状态 HOLD_GRAPH。底部日志展示相同的任务号和异常数。生成图片不是实际执行了 Node.js 或 DevEco 的证据，正文代码才是可以复制到本地检查的逻辑参考。从修复路径看，缺失节点与环路要分别处理。如果 T09 原本应当属于本批次，就补齐对应节点及资源并重新生成清单；如果它属于已经取消的历史资源，就删除或改正 T04 的引用。对环路则需要确认依赖方向：究竟 T02 应依赖 T03，还是 T03 应依赖 T02？不能为了让检查通过就随意删一条边，这可能让材质或层级解析次序变得错误。修复后重新执行同一个检查器，比较前后图结构，而不只是修改界面提示文字。## 五、把预检结果放回真正的 3DGS 工程边界3DGS 资产形式、瓦片粒度和管线输入由实际引擎与生产工具决定，不同团队的依赖意义并不一样。比如有的清单表达必须先生成的资源，有的表达运行时可选引用；后者缺失是否应阻断，需要结合业务规则。本文把全部 deps 设定成强依赖，是为了展示环路检测这一个工程问题；把某个可选贴图也按强依赖处理，会制造误报。这次预检不涉及拍摄设备姿态、点云重建质量、推理耗时、场景回源或 GPU 内存，也没有声称运行了 Spatial Recon Kit。应把它放在“自定义资产清单 → 静态完整性检查 → 资源打包 → 真实重建/渲染验证”的第一道闸口。它能提前指出依赖图错误，却不能推断模型视觉质量、端侧帧率及应用审核结果。还有几项测试值得在工程落地前完成：无环但存在共享依赖时应通过；自引用 T05 → T05 应报告一个环；相同 ID 出现两次时应拒绝不确定索引；文件读取损坏时应返回解析错误而不是空集合“校验通过”；节点数上万时要评估深度优先递归的栈限制。只有这些反例都被明确覆盖，才能把“不会卡死”当作经过验证的工程结论。## 六、技术结论与资料边界依赖图审计不是瓦片路径合法性检查的另一个名字。路径防护回答“引用指向了哪里”，图审计回答“引用关系能否形成有限、可解释的装配顺序”。用 Map 建索引、active 识别当前路径、done 缓存已处理节点，能够以少量标准 JavaScript 逻辑发现本篇设计的两类典型异常，并把缺失与环路同时反馈给构建工具。HOLD_GRAPH 是自定义构建门禁，不能误写为系统 Kit 的枚举或某次真实重建失败。资料依据： 华为空间重建管线指南（能力范围参考）；Node.js 文件系统 API；Node.js Process API。其中华为页面在本轮在线打开时出现超时，本篇没有据此虚构任何 API 签名；Node.js readFile 和 process.exitCode 已按一手文档核对。运行结果仍需在实际项目中复核，不能把生成示意图当作测试日志。