3DGS 场景第二次打开出现破洞：HarmonyOS 7 分块缓存校验与原子替换怎么做

第一次加载 3DGS 场景正常，弱网中途退出后第二次打开却出现破洞；清缓存又恢复。问题通常不是模型突然损坏，而是下载中的半文件被当成完整分块复用。空间数据体积大、分块多，任何一块缺字节都可能变成局部黑斑、漂浮点或解析失败。缓存必须从“文件存在”升级为“内容可验证且替换原子化”。

验证范围：官方页面用于核对 HarmonyOS 7/API 26 的能力方向与开发边界；文中代码只验证应用侧状态机、预算或一致性模型。当前电脑是 API 24 SDK，且没有连接 HarmonyOS 7 真机，所以下面的断言不等同于 API 26 编译、真机性能或上架审核结果。

用中断下载稳定制造坏分块

把一个场景拆成多个分块，在第 4 块下载到一半时终止进程；重启后禁止联网，观察加载器是否把临时文件当成正式缓存。记录期望长度、实际长度、hash 和清单版本。

案例一：单块损坏只重取该块

清单版本一致且只有一个 hash 失败时，隔离坏块并重取，不必删除整个场景。加载器在修复前显示占位而不是错误点云。

案例二：模型清单升级后整组失效

分块本身 hash 正确，但场景 manifest 版本变化，旧块与新索引不能混用。应切到新的缓存命名空间，完成后一次切换。

缓存命中至少要过三关

直接把响应写入正式路径，进程被杀时会留下“存在但不完整”的文件。若命中规则只检查文件名，坏缓存会在每次启动稳定复现。

type Tile={id:string;expected:number;actual:number;hashOk:boolean;manifest:string};
function valid(t:Tile,current:string){return t.manifest===current&&t.expected===t.actual&&t.hashOk;}
const partial={id:'4',expected:1024,actual:600,hashOk:false,manifest:'v2'};
if(valid(partial,'v2')) throw new Error('半文件被当成有效分块');

这段模型用确定输入验证“分块只有版本、长度和哈希同时通过才允许进入场景”。它适合先发现应用侧边界错误，但不会冒充平台接口或设备性能测试。

修复策略怎么选

方案	适用范围	主要风险
只看文件是否存在	本地演示	半文件长期污染
出错清空全场景	场景很小	浪费流量和时间
临时文件加清单校验	正式大场景	需要维护版本与回收

下载写入临时文件，完成后校验长度与 hash，再原子重命名；场景清单升级使用新命名空间，避免新旧分块混装。

建立分块清单和临时区

封装 VerifiedTileStore，统一管理 manifest、临时区、校验、原子替换和定额回收。渲染层只获取“已验证分块”，不碰下载中的文件。

空间场景验收不能只看首开

• 下载中断后不会留下可命中的正式块。
• 单块失败只重取单块。
• manifest 升级不会混用旧索引。
• 离线状态能区分缺块和坏块。
• 二次、三次打开都要验收。

大型空间资产最怕“看起来缓存成功”。把完整性校验放在命中之前，才能让第二次打开和第一次一样可信。

官方资料

• 空间计算与 3DGS
• 3DGS 端侧重建介绍
• HarmonyOS 应用开发指南