企业官网建设流程全解析

做瓦片地图引擎，有个阶段特别难受：画面已经能拖来拖去、能放缩层级了，但只要一出问题——瓦片对不齐、边界出缝、鼠标点击的位置和预期相差很远——你就只能盯着屏幕靠肉眼猜。我一度靠console.log打印视口四角的经纬度，再手动算当前TileKey，然后在地图上移动鼠标，一边看数字一边对，效率低到爆炸。后来我把两个调试工具直接做进了three.js瓦片运行时里，才算是从“摸黑调”换成了“开灯调”：一个是把每块瓦片的边框线画出来，同时在边框附近显示对应的TileKey；另一个是光标底下的实时三维坐标探针，屏幕上扫到哪，面板里同步显示经纬度、世界坐标、像素坐标和所在瓦片的key。这篇就聊聊这套调试组合的实现思路和踩坑细节。

这是“three.js最小地图运行时”系列的第九篇，前面的内容分别是底图初始化、瓦片四叉树调度、纹理加载、相机控制、LOD切换和可视域裁剪。本篇属于开发调试层，目标是给运行时加一套相互配合的调试可视化工具，帮助排查瓦片索引、层级切换和坐标换算相关的问题。整个方案不依赖额外调试库，所有代码都基于three.js现有API，几百行就能接入现有项目。

1. 为什么瓦片引擎需要“看得见的坐标”

1.1 瓦片地图的调试痛点

地图瓦片引擎本质上是在一个动态变化的金字塔切片集合上做加载和回收。相机近的地方需要更高层级的瓦片，远的地方低层级瓦片就够用。问题是，当几十块瓦片同时出现在场景里时，你肉眼很难判断当前画面属于哪个层级，更难判断某一块缺图区域到底是加载失败、调度延迟，还是行列号算错了。

尤其是灰度影像、地形晕渲这类纹理差异小的数据，叠加到一起之后，不借助辅助信息几乎无法感知瓦片边界。很多时候两个瓦片之间存在接缝，看起来只是一条细线，实际上是因为相邻瓦片的行列号错位，或者是同一区域同时渲染了两个不同层级的瓦片。

TileKey就是这套系统的“坐标索引”。典型结构是“z/x/y”，z是层级，x和y是网格中的行列号。调试时最常做的事，就是确认当前视野中心落在哪个TileKey上、四角落在哪些TileKey上、正在加载的瓦片应该是什么key。如果能直接把key画到场景里，所有索引逻辑正不正确，一眼就能看出来。

1.2 面向调试层的功能设计

我在设计这套工具时定了一个原则：调试代码与运行时主逻辑解耦。瓦片加载、纹理贴图、相机运动都不应该感知调试工具的存在。调试工具通过监听事件和读取状态来获取信息，挂在渲染循环和事件处理流程的外围。

所以在线框和坐标探针的实现上，我采用了独立模块的方式。线框模块维护一张“瓦片key ↔ 调试对象”的映射表，当瓦片加载进来时，调用模块的addTile接口创建对应的边框线；瓦片被回收时，调用removeTile清理边框线。坐标探针模块则是一个独立的浮动面板，订阅鼠标移动事件，通过射线检测把光标位置转换成地理和瓦片坐标。

这样设计的好处很明显：发布生产版本时，整个调试模块可以被一行配置开关摘除，不会对运行时产生任何额外开销。调试代码里踩过的坐标换算问题，也都被隔离在模块内部，不会污染运行时逻辑。

2. TileKey线框可视化：把瓦片边界画出来

2.1 别用material.wireframe

第一次做线框可视化时，很多人会直接修改瓦片Mesh的材质，把wireframe属性设成true。这种写法虽然简单，但视觉上会暴露每个三角形面片的边，画面会变得非常吵。尤其是一个PlaneGeometry分割了较多段数时，三角形密密麻麻，根本看不出瓦片的矩形边界在哪。

我踩过这个坑后直接换了个方向：给每个瓦片生成一个独立的边框几何体，而不是修改原Mesh的渲染状态。具体做法是用EdgesGeometry，把瓦片的平面几何体转换成只保留边界边的LineSegments。

EdgesGeometry的原理是遍历几何体中的所有边，根据相邻三角面的夹角判断这条边是否属于“硬边”。对于默认的PlaneGeometry，内部三角形共享的斜边因为是平面共边，不会被提取出来，最终得到的只是矩形的四条外边。这样视觉上极其干净，一块瓦片就是四根线。

代码可以这样写：

import * as THREE from 'three'; function createTileWireframe(width, height, key, offsetY = 0.1) { // 用 PlaneGeometry 生成瓦片外框，然后旋转到水平面 const geo = new THREE.PlaneGeometry(width, height); geo.rotateX(-Math.PI / 2); // 放到 XZ 平面 // 提取边缘线 const edgesGeo = new THREE.EdgesGeometry(geo); const mat = new THREE.LineBasicMaterial({ color: 0x00ffaa, transparent: true, opacity: 0.7, }); const wire = new THREE.LineSegments(edgesGeo, mat); // 位置由瓦片中心坐标决定 wire.position.set(centerX, offsetY, centerZ); wire.userData.tileKey = key; return wire; }

注意PlaneGeometry默认生成在XY平面且法线朝Z方向，需要先旋转一次再放到水平面上，否则框线会立起来。

2.2 把TileKey绑到每一块瓦片上

边框线只是让人看到边界，如果想直接知道这块瓦片到底对应哪个key，还得在场景里显示文字。最省事的方案是使用CSS2DRenderer，在three.js业务里额外渲染一个HTML标签层。这样做的好处是文字始终面向屏幕，清晰度好，无论相机怎么旋转都不会被拉伸变形。

但CSS2DRenderer毕竟是额外引入的一个渲染器，对“最小运行时”来说有点重。另一个方案是把文字渲染到Canvas上，再生成Sprite贴图放进场景。这个做法的默认问题是Sprite永远面向相机，文字在屏幕上始终可读，视觉稳定性同样不错。唯一的缺点是文字分辨率受Canvas大小限制，放大后会发虚，但作为调试图层完全够用。

我实际用的是Sprite方案，主要是少引入一个渲染器，整体环境更干净：

function createTileLabel(key) { const canvas = document.createElement('canvas'); canvas.width = 256; canvas.height = 64; const ctx = canvas.getContext('2d'); ctx.fillStyle = 'rgba(0, 0, 0, 0.45)'; ctx.fillRect(0, 0, canvas.width, canvas.height); ctx.font = '28px monospace'; ctx.fillStyle = '#ffffff'; ctx.fillText(`${key.z}/${key.x}/${key.y}`, 8, 40); const texture = new THREE.CanvasTexture(canvas); const material = new THREE.SpriteMaterial({ map: texture, depthTest: false }); const sprite = new THREE.Sprite(material); sprite.scale.set(8, 2, 1); sprite.position.set(centerX, offsetY + 0.5, centerZ); sprite.renderOrder = 1000; return sprite; }

Sprite要设置depthTest为false，否则旋转视角到边缘时，文字可能被瓦片遮挡得看不清楚。调试图层就是要“压”在所有内容上面，优先保证可读性。

2.3 线框浮空与防闪烁

边框线和瓦片mesh贴得太近时，移动相机会出现典型的z-fighting闪烁，尤其是看倾斜视角下的远处瓦片，边界线会一跳一跳的。要解决这个问题，最直接的办法是让线框浮起来一段距离。

浮空高度不能拍脑袋定。以墨卡托投影为例，世界坐标中1个单位对应像素的比例会随层级变化，直接把position.y设成0.1还是0.01，在不同层级下效果完全不同。我的做法是让浮空高度跟随当前瓦片的几何尺寸线性变化，也就是offsetY约等于瓦片世界宽度乘以一个很小的系数，比如千分之一到两千分之一。

还有一种更稳妥的方式是修改线框的渲染状态。把depthWrite设成false，线框就不写入深度缓冲，绘制顺序靠后也能显示出来；再把renderOrder设大一点，让线框在地表纹理之后绘制。两种手段配合使用，能把闪烁问题的出现概率降得很低。

我实际推荐组合是：浮空高度按瓦片尺寸动态计算，同时关闭深度写入。这样既不会影响后续加载的瓦片线框，也不需要为每个线框单独维护深度offset。

2.4 线框与瓦片调度的生命周期同步

调试层的线框必须跟随运行时中瓦片的创建和销毁。如果瓦片被回收了，但线框还留在场景里，那画面就会出现“鬼影”，让人误以为瓦片还在。如果线框创建滞后，则可能漏看瓦片首次加载的位置。

我建立了一个同步机制。运行时在加载瓦片mesh时会额外触发一个内部事件：

tileManager.on('tile-added', ({ mesh, key, bounds }) => { debugLayer.addTile({ key, bounds }); }); tileManager.on('tile-removed', ({ key }) => { debugLayer.removeTile(key); });

在DebugLayer内部，用一个Map来记录key与线框对象的映射，删除时就可以通过key精确清理。同时我给瓦片Mesh的name设置了统一的命名规则，比如tile_12_3412_1522，这样直接从Three.js场景图里做排查时，也只需扫描名称即可定位到目标瓦片。

class DebugTileLayer { constructor(scene) { this.scene = scene; this.wireMap = new Map(); // key => wire object array } addTile(key, width, height, centerX, centerZ) { const wire = createTileWireframe(width, height); const label = createTileLabel(key); wire.position.set(centerX, offsetY, centerZ); label.position.set(centerX, offsetY + 0.8, centerZ); this.scene.add(wire); this.scene.add(label); this.wireMap.set(`${key.z}/${key.x}/${key.y}`, { wire, label }); } removeTile(key) { const obj = this.wireMap.get(`${key.z}/${key.x}/${key.y}`); if (obj) { this.scene.remove(obj.wire); this.scene.remove(obj.label); this.wireMap.delete(`${key.z}/${key.x}/${key.y}`); } } }

这一步一定要放在瓦片真正加入场景之后执行，不然线框的position和瓦片的位置会存在一帧的视觉偏差。

3. cursor坐标探针：让光标位置变成调试数据

3.1 从屏幕像素到三维世界的坐标管线

坐标探针的第一件事，是把鼠标在屏幕上的二维位置换算成three.js场景内的三维坐标。这个过程分两步：

先把像素坐标归一化到NDC坐标。three.js的NDC坐标中，x方向从左到右是-1到1，y方向从下到上是-1到1。但浏览器中的鼠标坐标通常以左上角为原点，向下为正，所以要做一个翻转：

function screenToNDC(clientX, clientY, rendererDom) { const rect = rendererDom.getBoundingClientRect(); const x = ((clientX - rect.left) / rect.width) * 2 - 1; const y = -((clientY - rect.top) / rect.height) * 2 + 1; return { x, y }; }

有了NDC坐标，就可以借助相机创建射线。three.js的Raycaster封装了从相机出发的射线检测逻辑，输入NDC坐标后，可以返回射线与场景内物体的交点。

const raycaster = new THREE.Raycaster(); const pointer = new THREE.Vector2(); function updatePointer(clientX, clientY, dom) { const ndc = screenToNDC(clientX, clientY, dom); pointer.set(ndc.x, ndc.y); } function raycastGround() { raycaster.setFromCamera(pointer, camera); const hits = raycaster.intersectObjects(tileMeshes); return hits.length > 0 ? hits[0] : null; }

核心思路非常简单。如果项目中已经维护了“当前可见瓦片列表”，可以直接把这个列表作为射线检测的目标数组，比遍历整个场景高效得多。

3.2 射线检测的缺点与适用优化

直接遍历所有瓦片Mesh有一个隐性问题：瓦片数量多的时候，每移动一次鼠标都做一次全量相交计算，性能压力会很明显。地图瓦片Mesh的三角形数量通常不多，但数量可能达到几十上百，频繁检测还是会产生不必要的计算量。

更高效的做法是先用数学方法求射线与地面的平面交点，再根据交点去判断这个位置属于哪块瓦片。因为所有地层级瓦片都平铺在近似高度平面上，求交点的计算量几乎是常数级，和瓦片数量无关。

Three.js内部没有直接提供“射线与无限平面求交”的公开工具，但可以用数学方法实现。射线方程是P = origin + t * direction，平面方程是dot(P, normal) = distance。联立求解出t后，回代就能得到交点。

function rayPlaneIntersect(ray, planeY) { const dir = ray.direction; if (Math.abs(dir.y) < 1e-8) return null; // 射线平行于平面 const t = (planeY - ray.origin.y) / dir.y; if (t < 0) return null; return { x: ray.origin.x + dir.x * t, z: ray.origin.z + dir.z * t, }; }

对于地形起伏较大的场景，平面交点就不够精确了，还是得保留Raycaster去和具体瓦片Mesh相交取第一个交点。我做了两层策略：先对平面求交拿到大致区域，再只对相交点附近的一小块瓦片做精确Mesh检测。两层策略可以兼顾性能和精度。

3.3 从世界坐标反算经纬度

拿到世界坐标(x, z)之后，坐标探针才真正开始发挥威力。如果地图使用平面投影，比如等距圆柱投影，经纬度换算只是线性反算。如果使用Web墨卡托投影，就得做反投影变换。

Web墨卡托的正算公式是：

x = longitude * R z = -R * ln(tan(PI / 4 + latitude / 2))

这里取负号是为了让z轴朝南时和普通地图习惯一致。反算时解出经度和纬度，就涉及自然指数和反正切运算。

我实际项目的坐标转换函数长这样：

function worldToLonLat(x, z) { const lon = (x / R) * 180 / Math.PI; const lat = (Math.atan(Math.exp(z / R)) - Math.PI / 4) * 2 * 180 / Math.PI; return { lon, lat }; }

如果项目的瓦片坐标原点不在(0,0)，也就是初始World坐标偏移过，则还需要先把世界坐标减去原点偏移量，再做反算。

3.4 从经纬度计算当前层级TileKey

得到了经纬度，就可以算出当前层级下的瓦片坐标。以Web墨卡托瓦片切分规则为例，任意缩放层级z下，世界被划分为2^z列和2^z行。经度-180对应x=0，经度180对应x=2^z - 1。列号计算公式：

xTile = floor((lon + 180) / 360 * 2^z)

行号相对复杂一点，涉及墨卡托投影的y方向映射：

function lonLatToTile(lon, lat, z) { const n = Math.pow(2, z); const xTile = Math.floor((lon + 180) / 360 * n); const latRad = lat * Math.PI / 180; const yTile = Math.floor( (1 - Math.log(Math.tan(latRad) + 1 / Math.cos(latRad)) / Math.PI) / 2 * n ); return { z, x: xTile, y: yTile }; }

TileKey看起来只是一串“z/x/y”，但查错时非常有用。比如探针显示当前位置的TileKey是12/3412/1522，而你预期这里应该显示13层级的瓦片，那说明层级切换逻辑存在偏差，可以进一步追踪。

3.5 探针面板的信息组织

探针面板不能只放一堆孤零零的数字，最好把信息分成几区，每区对应一个坐标系。我的面板从上到下依次显示：

每一帧鼠标移动事件触发面板更新时，所有数据都走同一套坐标转换管线，保证各部分数值是严格一致的。

鼠标移动事件的监听也有一点讲究。坐标探针需要实时更新，但不能让每一帧都对新位置重算所有数据。从浏览器性能角度考虑，可以用requestAnimationFrame机制来节流，同一帧内即使触发了多次鼠标移动，也只计算一次：

let isDirty = false; dom.addEventListener('pointermove', (e) => { lastPointer = { x: e.clientX, y: e.clientY }; isDirty = true; }); function onRenderLoop() { if (isDirty) { isDirty = false; updateProbe(lastPointer.x, lastPointer.y); } renderer.render(scene, camera); requestAnimationFrame(onRenderLoop); }

这样能保证探针更新的频率与渲染频率一致，不会因为高频鼠标事件产生额外异步开销。

3.6 支持touch事件

在移动端测试时，桌面端的mousemove监听完全失效，必须适配触摸事件。three.js官方的PointerLockControls或OrbitControls都用了pointer系列事件，坐标探针也应该跟随使用pointermove、pointerdown。PointerEvent同时覆盖鼠标和触摸，少写一套分支。

唯一要注意的是触摸缺少hover概念。移动端上需要在touchstart和touchmove时更新探针，同时要避免地图拖动时一直高亮目标，通常做法是结合一个“长按500ms进入探针模式”的开关，或者不做高亮，只更新数值面板。

4. cursor坐标探针与TileKey线框的联动调试

4.1 探针拾取瓦片自动高亮

坐标探针单独工作时，面板里会显示一堆数值。想要定位到具体瓦片，还是要在画面上给点视觉反馈。最直接的做法是：当鼠标悬停到某个瓦片上时，将对应瓦片的边框线高亮为另一种颜色。

实现方式很简单，探针拿到射线命中结果后，读取命中Mesh的userData.tileKey，再把这个key传给DebugLayer的highlight方法。线框模块内部遍历Map找到对应的线框对象，修改LineBasicMaterial的颜色为黄色，同时把原先所有高亮的线框恢复为默认色。

function highlightTile(key) { debugLayer.resetHighlight(); const obj = debugLayer.wireMap.get(key); if (obj) { obj.wire.material.color.setHex(0xffaa00); obj.wire.material.opacity = 1.0; } }

这种联动模式让我在排查问题时省了巨量时间。以前需要一边盯控制台一边分析瓦片属于哪一层，现在鼠标一扫，线框自然点亮，旁边还有Sprite标签直接显示key，任何坐标换算问题都会以“发光瓦片和预期不符”的形式暴露出来。

4.2 用途一：验证瓦片预加载与视野范围

相机移动过程中，瓦片调度器会在幕后预加载相邻区域的瓦片。线框可视化配合探针，能直接看到当前视野内瓦片集合的边缘在哪。如果视野向右平移了一段距离，预加载的新瓦片应该沿着右边边界开始出现，如果实际加载的是左侧一片，那瓦片调度逻辑的视野范围计算肯定有误。

我经常用探针查看视野四角TileKey，把它和代码中视锥体裁剪计算出来的瓦片范围做对比。四角TileKey一致，说明视锥计算和四叉树遍历逻辑是正确的。如果偏了一块，往往是因为镜头之间的世界坐标转换没有考虑相机在初始帧时的朝向。

4.3 用途二：排查坐标绑定类标记点问题

加入一个新标记点时，如果物体的经纬度坐标在地图上发生偏移，很难发现是因为坐标做了某种偏移变换，还是容器中心没对齐。坐标探针能直接告诉你真实的地面位置对应什么经纬度。比如在场景中点击一个位置，探针显示lon=116.xxx、lat=39.xxx，但鼠标下的线框高亮TileKey是13/6612/3355，而你预期13层级的6612/3356才覆盖点击点，说明标记物坐标叠加时y方向搞反了或TileKey行号算法没有做Web墨卡托投影修正。

这种问题如果只靠肉眼观察城市边界线，很难定位到行列号上，但线框加探针几秒就能锁定。

4.4 用途三：复盘瓦片加载与回收策略

当你的瓦片引擎在帧率下降时怀疑是瓦片加载过多，可以打开线框和探针，拖拽相机绕场景一圈。仔细观察每一帧场景中的线框数量以及线框对应的TileKey层级。如果远处的低层级瓦片和高层级瓦片同时存在，或者大范围区域存在同层级的重复瓦片，马上就能发现问题。

我还习惯在调试面板里加一个实时计数器，统计当前线框对象数量。运行时回收瓦片时，如果计数器迟迟不减少，说明内存中积累了大量未被正确释放的瓦片Mesh，这对排查纹理内存增长问题很有帮助。

5. 实际开发中踩过的坑

5.1 线框不显示或显示不全

线框没显示，最常见的原因是EdgesGeometry生成的几何体，没有正确旋转到瓦片所在平面。如果瓦片mesh是通过加载GeoJSON地形数据生成的，而线框是用PlaneGeometry生成的，两者顶点顺序不一致，就可能导致线框穿插到地表下方。

我在排查时用了两步确认：第一步，直接把线框的position.y设成一个很大的值，比如100，看它是否出现在场景中；第二步，关闭线框的材质深度测试，看它是否被其他Mesh挡住。通过这两个测试，能快速把问题锁定在“旋转错误”“位置偏移”还是“深度被遮挡”上。

5.2 探针读到的坐标总是偏一个固定值

探针显示的世界坐标与真实地表位置始终错开了一部分，说明地面瓦片整体偏移了。这个问题常出现在瓦片坐标系定义时，把“瓦片左上角坐标”和“瓦片中心坐标”混用了。

PlaneGeometry默认以几何中心为锚点，我记得这是最典型的错误：创建瓦片Mesh时，传入的是该瓦片左上角的世界坐标，但Three.js会把它当几何中心坐标来放置，导致整块瓦片往右下偏移了宽度和高度的各一半。修正方法有两种，一是mesh.position赋中心坐标，二是几何体直接translate偏移半个宽高，把锚点改到左上角。

坐标探针面板中看到偏移值恰好是瓦片尺寸比例，基本就是这个原因。

5.3 高DPI屏幕上坐标不准

在MacBook或高分屏Windows设备上，坐标探针如果不处理devicePixelRatio，读取的像素坐标会和Canvas实际渲染尺寸不一致。要特别注意，three.js的canvas可以是CSS尺寸和内部渲染尺寸不同，浏览器mouse事件返回的是CSS像素坐标，而Raycaster使用的是渲染像素坐标。

处理方式：事件处理器里计算的rect.left和rect.top用的是CSS像素，但计算NDC时要在target坐标系内换算。代码中使用getBoundingClientRect恰好规避了这个问题，只要视口尺寸就是CSS尺寸。如果项目中手动指定了viewport尺寸，就需要把clientX和clientY乘上分辨率比例。

5.4 触摸结束后，探针还停留在最后位置

在移动端使用完坐标探针后，触摸一松开，面板会一直停在最后一个点的位置不动，造成视觉干扰。我给探针面板加了一个透明度自动衰减逻辑：touch结束后600ms无人操作，就对面板做一个淡出。触摸开始后又重新恢复高亮。这个细节对移动端演示体验提升非常明显。

5.5 线框加载跟不上瓦片新出现的节奏

在快速移动相机跨越多个层级时，调试线框的创建速度会滞后于瓦片Mesh加载速度，导致某几帧画面里出现了瓦片纹理，但线框还没画出来。解决方式是在DebugLayer中做个简单的本帧批处理，收集这一帧所有待添加的瓦片，统一在渲染循环末尾一次性创建，避免每帧多次插入DOM或场景对象。

6. 调试工具接入的工程化建议

6.1 用开关控制DebugLayer启用和停用

我在项目里用一个URL参数控制调试层是否加载。生产构建时该模块默认不加载，只有调试环境才打包进去。写法可以参考：

const debugEnabled = new URLSearchParams(location.search).has('debug'); if (debugEnabled) { import('./debug/DebugLayer.js').then(({ default: DebugLayer }) => { const debugLayer = new DebugLayer(scene, camera, renderer.domElement); tileManager.on('tile-added', debugLayer.addTile); tileManager.on('tile-removed', debugLayer.removeTile); }); }

动态import配合条件判断，可以把调试模块彻底与主流程分离。我在构建时配置了webpack的magic comments，让调试代码单独成包，正常访问完全不会加载，调试时再手动追加参数打开。

6.2 对瓦片命名做统一约定

为了配合调试层，所有瓦片Mesh和对应的线框都采用同一个userData结构。这样无论用Three.js的scene.getObjectByName查询，还是用Map查询，都能快速定位。长期工程中，这个约定对同事协作也很有价值，所有人能在这个地图运行时中一眼看懂瓦片对象的身份。

6.3 探针数据可以导出成临时标记

坐标探针虽然只是显示数值，但调试时经常需要把某个点的TileKey或经纬度记下来，去日志里搜索。我额外加了一个快捷键，按一下“C”就把当前探针数据复制到剪贴板。这个小功能看似不起眼，实际用起来极大提高了排查效率，不需要再手动抄写。

7. 后续扩展思路

线框加坐标探针这套方案，本质上是在给地图运行时做一个可视化调试框架。后续可以考虑把探针显示的结果直接画到另一层调试Canvas上，配合瓦片调度记录形成更丰富的时间序列分析。例如显示每一帧加载瓦片的数量、平均加载时长、纹理内存占用等。

TileKey线框的样式也可以进一步优化，按照层级或者瓦片状态使用不同颜色显示，比如红色代表加载中，绿色代表已加载完成，黄色代表正在被回收。这样地图引擎的实时状态不必依赖日志，直接肉眼观察画面颜色就能定位性能瓶颈和异常行为。

从我个人体验来说，这套工具做好之后，真正改变的不是调试速度和效率，而是排查问题时的思考方式。以前我会下意识怀疑是不是瓦片加载错了、坐标转错了、缓存挤占了，反复试错；现在只要开线框和探针，看到问题出在哪，直接改代码，调试地图引擎的心理负担下降了不止一个档次。如果你也在做three.js相关的地图可视化、瓦片渲染器或者LOD地形系统，建议尽早把线框和探针这套基础设施搭起来，后续所有坐标和加载相关的排查都会变得顺畅很多。