开场：在开发开放世界游戏时，团队曾遭遇 NPC 频繁卡在建筑接缝处的诡异问题。美术反复调整碰撞体，程序反复修改寻路参数，却始终无法根治。直到我们把烘焙出的 NavMesh 三角面一层层展开看，才发现真相：两个相邻模型因为Navigation Static标记遗漏，网格在接缝处断开了十几厘米的缺口，而 Agent 的 Radius 又恰好大于缺口宽度——NPC 不是"卡住"，是寻路系统根本认为那里"没有路"。这类问题的共同根源是：大多数开发者只把 NavMesh 当成一个"烘焙按钮"，对烘焙出来的到底是什么数据、寻路器拿这些数据怎么算路，完全没有概念。本文就从底层数据结构出发，把 NavMesh 的"体素化 → 多边形网格 → 图搜索 → 路径平滑"这条完整链路拆开讲清楚，最后落到动态场景下的工程实践。前置知识：建议先了解 A* 搜索的基本概念；本文侧重数据结构与工程机制，不再展开讲启发式搜索本身。一、NavMesh 到底是什么：从碰撞网格到"配置空间"先纠正一个最常见的误解：NavMesh 不是场景碰撞网格的简化版，也不是"能走的三角形集合"这么简单。NavMesh 是配置空间（Configuration Space，C-Space）的离散化表达。什么是配置空间？想象 Agent 是一个半径为 r、高为 h 的圆柱体。地面上一个半径为 R 的圆形障碍，对"点"来说是 R 的禁区，但对圆柱体 Agent 来说，禁区是 R+r——这叫障碍在配置空间中的闵可夫斯基和（Minkowski Sum）膨胀。NavMesh 记录的不是"场景里哪里