三维场景五段链路的资源与依赖排查

一、现象与复现条件

同一套三维场景，在 A 机器打开正常，到 B 机器出现图层缺失、样式错乱或整体偏移；有时加载很慢，有时分析结果对不上。复现条件通常有三个共同点：换了机器、换了网络环境、换了数据目录。

这类问题不适合直接从渲染层查。把链路拆成五段------数据接入、场景构建、三维分析、交付打包、多端运行------先定位是哪一段的依赖没带过去，再谈参数。以下排查方法来自一次演示链路的实测，样本有限，结论用于定位方向，不替代逐项验证。

二、五段各自要确认什么

数据接入

在线服务先确认地址可达、坐标系和范围。WMTS/WMS 看 rectangle 与 tileMatrixSet 是否匹配；3D Tiles 看 boundingVolume 与根节点变换。本地切片目录重点看路径和权限，路径变化会让原来的相对引用失效。
场景构建

图层树、样式、图例、标注是场景的一部分，不是渲染的附属品。排查时先列图层清单：名称、类型、数据源、样式来源。条件样式依赖字段时，要确认字段在目标数据里仍然存在。
三维分析

剖面、挖填方、通视、水淹等结果通常带参数和记录。结果对不上，先核对输入范围、采样间距和高度基准，再核对是否使用了缓存结果。分析记录如果只在内存里，换端就会丢。
交付打包

交付物要能独立还原。只给工程文件时，目标机器需要同样的插件、路径和服务；打包场景时，要确认图层树、样式、矢量一起进入包内。交付前在一台干净机器上导入一次，是最直接的验证。
多端运行

浏览器、桌面端、移动端、离线版的渲染能力和依赖不同。离线版通常不带在线服务，也不带 AI 能力；有相关需求时要在选型阶段确认，不要等到交付前才发现。

三、排查顺序

建议固定为：数据源可达性 → 坐标系与范围 → 场景依赖清单 → 分析输入与记录 → 交付包完整性 → 多端能力边界。

顺序反了会出现"调了相机偏移还在、调了模型切片又偏"的情况，因为基准一直没统一。

四、一段可以直接用的验证代码

js 复制代码

// 1) 确认影像服务范围与切片矩阵
const provider = new Cesium.WebMapTileServiceImageryProvider({
  url: '/proxy/wmts',
  layer: 'base',
  style: 'default',
  format: 'image/jpeg',
  tileMatrixSetID: 'EPSG:3857'
});
console.log(provider.rectangle, provider.tileMatrixSet);

// 2) 量化模型离地高度
const boundingSphere = model.boundingSphere;
console.log(Cesium.Cartographic.fromCartesian(boundingSphere.center));

代码只做两件事：把服务声明的范围打印出来，把模型中心转成经纬高。先有可比较的数字，再决定调服务还是调模型。

五、验证清单

同一场景在干净机器上能打开；
图层数量、名称、样式与源机器一致；
分析结果的范围、间距、高度基准一致；
交付包不依赖源机器的绝对路径；
断网/内网环境能启动；
多端打开后交互可用，不只是能看到画面。

六、结论

三维场景的问题大多不是"渲染不对"，而是某一段的依赖没有跟着走。按五段拆开、按固定顺序排查，比在渲染层反复试参数更省时间。

这篇只讨论排查方法，不涉及具体产品和项目。