1. 从旧版导航到 AI Navigation：这次升级到底动了什么
先说结论：如果你还在用 Unity 内置的 NavMesh（Navigation 旧版组件），那你这几年做的地图寻路其实一直处于“能用，但不好扩展”的状态。Unity 从 2022 LTS 开始把导航功能整体挪到了com.unity.ai.navigation这个官方包里面，也就是大家常说的 AI Navigation 包，新 NavMesh 系统。它解决的痛点非常直接：旧版导航网格必须在编辑器里预先烘焙好，一张场景图只能有一套固定的 NavMesh，运行时想动态改路、动态开桥、动态生成地图，基本都要靠 Hack，而且烘焙结果和场景耦合得很死，谁动一下 Terrain 或者挪一堵墙，导航网格就废了。
新版 AI Navigation 的核心变化是把“烘焙”从场景编辑期解耦出来，变成了可编程、可组合、可异步执行的流程。底层寻路算法仍然是 A*，但数据生产和数据使用彻底分开了。你不再需要去 Window > AI > Navigation 面板里点那个 Bake 按钮，而是通过NavMeshSurface组件，把导航网格拆成多块、多层、多 Agent 类型，运行时可以单独调用BuildNavMesh()重新生成某一片区域。这样一来，动态地图、程序化生成地图、MOBA 类技能指示器、RTS 寻路、副本随机地图这些场景才真正有了解法。
这篇我默认你是用过旧版 NavMesh 的，至少知道 NavMeshAgent 是干嘛的、Bake 面板大概长什么样。如果你完全没接触过，也没关系，我会从安装包开始，一步一步讲到运行时动态烘焙、动态链接、区域代价调整，全程按项目实战的方式来。
2. 安装与环境配置：AI Navigation 包的正确打开方式
2.1 包版本怎么选、什么时候必须升级
AI Navigation 包从 2020.3 开始提供预览版，2022.2 之后逐步稳定。你可以在 Package Manager 里搜索AI Navigation，但注意，内置的com.unity.modules.ai模块和新包不是一回事，后者才是当前唯一维护的路线。
我的建议是直接用 1.1.5 以上的正式版本（1.1.x 是 2023 和 2024 LTS 的常见稳定线），包括如下核心程序集：
Unity.AI.Navigation：运行时导航网格组件与构建逻辑Unity.AI.Navigation.Editor：编辑器烘焙窗口、Surface 调试视图
如果你是 2021 LTS，需要先确认 Unity 版本 ≥ 2021.3.21f1，否则会有部分 API 不存在。2022 以后基本没有兼容顾虑了，直接装就行。
安装后你会发现，菜单栏Window > AI > Navigation依然存在，但打开后跟旧版的页面完全不同，它是一个以 NavMeshSurface 为核心调试工具的总览面板。同时，GameObject 的 Inspector 上如果挂载了NavMeshAgent，路径调试、速度调试、剩余距离这些字段会直接显示在 Scene 视图里，不用再靠 Gizmos 手写。
2.2 Agent 类型、Area 类型、Layer：三者的关系别搞混
新手最容易迷糊的是这样几个东西：NavMeshAgent 组件上的 Agent Type，烘焙面板里的 Area Type，以及物理用的 Layer。它们是完全不同的三个维度。
- Agent Type（代理类型）决定寻路时“谁可以走哪张网格”。你可以定义 Humanoid、Ranged、Large 等多个 Agent，每个 Agent 各自烘焙一套数据，互不干扰。
- Area Type（区域类型）是网格上的加权属性，比如道路、草丛、水域，影响同一个 Agent 在不同地块上的寻路代价。
- Layer 是物理碰撞分组，跟寻路没有直接关系，但会影响 Raycast 检测，很多人做动态寻路时 Raycast 打不中地面，就是因为 Layer 配置不对。
从实际项目角度，我的经验是最少配 3 个 Agent Type：正常步行单位、飞行单位、大型单位（比如 BOSS）。飞行单位不依赖 NavMesh，用 CharacterController 直接飞，但如果你要做飞行单位在固定高度跟随地面导航点，那也需要一个单独的 NavMeshSurface，把 Surface 的烘焙高度调成固定数值。
2.3 场景里要走的第一步：把 Surface 组件挂上
新建一个空场景，创建一个 Plane 或者加载你的地形，然后：
- 选中地面 GameObject。
- Inspector 里 Add Component，搜索
NavMeshSurface。 - 确认
Use Geometry选的是Render Meshes还是Physics Colliders。
这一步很多人会选错。Render Meshes模式是直接拿 MeshFilter 的数据烘焙，速度快，不检查碰撞器；Physics Colliders模式是所有碰撞体都参与烘焙，包括 Box Collider、Mesh Collider，适合复杂场景。如果你场景里的地面有凸凹地形、有自定义碰撞边界，我建议用Physics Colliders，因为最终 Agent 移动时碰撞体参与物理交互，如果烘焙数据来渲染网格而碰撞是另一个形态，会出现“导航能走，但撞墙”的怪异现象，而这类问题极难排查。
设置完后，点击 Inspector 上的 Bake 按钮，场景里会出现蓝色的半透明网格，这就说明第一张导航网格已经出来了。注意这一整张网格都属于这个 Surface，如果你场景很大，别让一个 Surface 去覆盖所有地图，性能会有问题，后面第三部分讲拆分。
3. 烘焙参数深度拆解：这张网格是你所有 AI 移动的底层地基
3.1 参数表：别照抄，每一项都要知道后果
AI Navigation 的烘焙参数都集中在NavMeshSurface组件上，跟旧版 Bake 面板长得像，但意义有些不同。
| 参数名 | 默认值 | 影响 |
|---|---|---|
| Agent Radius | 0.5 | 决定通道最小宽度，所有小于两倍半径的缝隙不可通过 |
| Agent Height | 2.0 | 决定最低头顶高度，低于该值的天花板会被视为不可通行 |
| Max Slope | 45° | 超过该角度的坡面会被剔除 |
| Step Height | 0.4 | 允许 Agent 迈上的台阶最大高度 |
| Drop Height | 1.0 | 允许 Agent 从高处跳下的最大高度差 |
| Jump Distance | 2.0 | 跨越缝隙的最大直线距离，用于生成 Link |
| Min Region Area | 2.0 | 小于该面积的孤立区域会被擦除 |
| Traversal Height | 0.0 | 自定义可穿越高度，通常配合洞穴类场景 |
组的核心在于，这些数值不是独立的，而是共同定义一个“胶囊体”的通过能力。Radius 和 Step Height 决定水平方向的通过性；Height 和 Max Slope 决定垂直方向的通过性。
举个例子，你有一个 0.8 米宽的走廊，Agent Radius 设置成 0.5，那这个走廊对寻路来说就是堵墙，烘焙出来的网格不会延伸进去，不管里面有没有宝物。这不是 Bug，是你把它定义成了“过不去”。很多项目里“明明路能走，Agent 就是不走”的问题，80% 出在 Radius 太大，或者 Min Region Area 把可走区域擦掉了。
3.2 动态障碍物：这块网格不是把 Collider 挪开就能解决的
在做动态门、自动升降平台、可破坏墙体时，很多人试着在运行时把障碍物 Collider 隐藏，或者enabled = false，然后等着网格自己更新。这是最普遍的误解。NavMesh 网格是静态数据，Collider 变化不会自动改网格。
正确做法是给障碍物挂载NavMeshObstacle组件，勾选Carve选项，设置Carve Time Stamp和Carve Only When Stationary（如果是移动平台）。这样组件会在障碍物进入区域时实时“挖掉”导航网格里的对应部分，Agent 就能在当前帧得到新的可通行路径。这里有个很关键的细节：Carve Only When Stationary必须勾选上，否则一个挪动的箱子会让避障系统每帧重新挖网格，路径会频繁抖动，单位会像无头苍蝇一样来回抽风。
还有一个坑：NavMeshObstacle 和 NavMeshAgent 不能同时挂在同一个 GameObject 上（其实是允许挂，但行为完全错乱）。动态敌人先挂 NavMeshAgent 寻路，又挂 NavMeshObstacle 阻挡别人——这种做法你看着逻辑没问题，但它会让其他单位对这个敌人同时避让和跟随同一份数据，路径计算会产生不可预知的抖动。
3.3 多人格、大场景：Surface 拆分与多 Agent 并行烘焙
一个很大的开放世界关卡，如果只用一块 NavMeshSurface 全部烘焙，场景加载后第一次寻路会卡很久，而且烘焙数据占内存巨大。正确的做法是按区块拆成多个 Surface，每个 Surface 只负责一块区域，通过NavMeshDataInstance机制在场景加载时把多片数据合并到一张全量 NavMesh 里。
比如一个 4km x 4km 的地图，我按 1km 一块切成 16 块 Surface，每块独立烘焙。加载时用多线程分别调用BuildNavMesh()，即使某一小块需要更新（比如一个街区被炸塌了），也只需要重新烘焙那一小块，其余 15 块不动。这里的性能收益是非常明显的：局部更新烘焙时间从秒级降到几十毫秒级。
实际操作中，合并数据时的边界缝是最大的敌人。两个 Surface 的边界如果参数不一致（尤其 Agent Radius 不同），中间会留出一条寻路走不到的缝。解决办法是让相邻 Surface 往外扩展烘焙范围，这叫CollectObjects标记里的Volume模式加Padding值。我一般设置 Padding 为两倍 Agent Radius，边界缝合得非常完美，单位从一块地走到另一块，路径是完全连续的，不会出现在边界反复掉头的情况。
4. 代码侧核心实现：从烘焙到动态寻路的完整闭环
4.1 运行时烘焙：不预先烘焙，直接代码生成
程序化生成地图时最常见的需求是：地图场景运行时创建，墙体和路障的摆放每局随机，导航网格只能在运行时跟着生成。这个新 NavMesh 系统给你提供了标准方案，核心代码很简单：
using UnityEngine; using Unity.AI.Navigation; public class RuntimeNavBaker : MonoBehaviour { public NavMeshSurface surface; public void BakeCurrentScene() { surface.RemoveData(); surface.BuildNavMesh(); } public void BakeOnlyAround(Vector3 center, float range) { surface.RemoveData(); surface.collectObjects = CollectObjects.Volume; surface.size = new Vector3(range * 2, 20f, range * 2); surface.center = center; surface.BuildNavMesh(); } }看到RemoveData()了吗？这一步非常重要。很多人重复调用BuildNavMesh()却忘了卸载旧数据，结果是每调一次，内存里就多一份 NavMeshData，寻路表现却越来越卡。正确习惯是每次烘焙前先RemoveData()，或者用NavMesh.RemoveAllNavMeshData()做一个全局清理。
需要注意，BuildNavMesh()在主线程执行，如果你在场景加载时同时跑很多逻辑，会产生一个小卡顿。如果你做的是非常零碎、小块的地图更新，可以尝试用NavMeshSurface的异步接口——但官网文档一直标注异步还属于实验性质。我个人建议，小块地图更新直接同步烘焙就行，实测 50m x 50m 的范围烘焙耗时在 20ms 以内，感知不到卡顿。大范围更新该用拆分 Surface 的方式处理，而不是赌异步。
4.2 动态链接：从断崖到吊桥，用 NavMeshLink 连接孤岛
两张静态网格中间如果隔着一条断崖，你想让单位从一处跳到另一处，靠烘焙参数里的 Jump Distance 永远不可靠，因为那是试探性的“有效缝隙”，不是明确指定的路。此时需要手动建一条NavMeshLink。
在场景里创建一个空的 GameObject，挂上NavMeshLink组件。组件上需要指定两个Transform位置作为起点和终点。最核心的字段是Cost Override：这个值决定走这条链接的额外代价，默认 -1 表示不覆盖，用默认代价 1。如果你造了一座独木桥，希望单位尽量少走，就把 Cost 设为 3，单位只有在实在绕不过去的时候才走桥。
实际使用中一个很常见的需求是“自动根据运行时的开关决定桥是否可用”，代码如下：
using UnityEngine.AI; public class BridgeController : MonoBehaviour { public NavMeshLink link; void ToggleBridge(bool isOpen) { link.enabled = isOpen; NavMeshLink.UpdateLinkData(link); } }仅仅enabled = false不够，你还需要调用NavMeshLink.UpdateLinkData()让它把数据从全量 NavMesh 里移除。同一个坑在旧版 OffMeshLink 也出现过——把组件禁用后，网格数据没刷新，单位还是会傻傻地往断崖走。
4.3 区域代价：让 AI 避开沼泽、绕开危险区
你有一片沼泽区，单位踩上去会减速，或者一片雷区，单位走进去就死。正常的 AI 应该尽量绕开这些地方。但完全绕开又不行，地图会变成绕远路走到天荒地老。这时候用 Agent 的Area Mask配合区区域代价来调整：
在烘焙前，把沼泽所在的地形块设置成 Area Type 为Water或自定义类型。然后在代码里动态修改：
using UnityEngine.AI; public class AreaCostExample : MonoBehaviour { public NavMeshAgent agent; void UpdateCost() { int waterArea = NavMesh.GetAreaFromName("Water"); // 把水的代价提升到 10，单位除非无路可走，否则不会主动踩水 agent.SetAreaCost(waterArea, 10f); } }注意SetAreaCost的数值是倍数，不是加法。默认 1，你设成 10，表示寻路算法判定走水路的长度乘 10，所以只有在绕行距离超过水路的 10 倍时，才会选择踩水。这个倍数怎么调，完全看游戏节奏。休闲类游戏我建议保持 5 以内，因为过高的代价会让 AI 在障碍判断时产生“所有路径都贵”的情况，表现上显得非常纠结，原地转圈却拿不出决定。
4.4 路径生成与追踪：不仅仅是 SetDestination
NavMeshAgent.SetDestination()是最基础的，但实战不能只用一个函数就把所有 AI 奔跑做得自然。下面是我自己项目中稳定使用的一套“移动控制 + 转向平滑 + 停止判定”的写法：
public void MoveToPoint(Vector3 dest) { if (!agent.isOnNavMesh) { // 重新投射到最近的 NavMesh 点 if (NavMesh.SamplePosition(dest, out NavMeshHit hit, 5f, NavMesh.AllAreas)) { agent.Warp(hit.position); } return; } agent.isStopped = false; agent.SetDestination(dest); } public bool HasReachedDestination() { if (!agent.pathPending) { if (agent.remainingDistance <= agent.stoppingDistance) { if (!agent.hasPath || agent.velocity.sqrMagnitude == 0f) { return true; } } } return false; }关键的地方在于remainingDistance不是一个可靠的停止信号，因为单位在拐弯、上下坡时这个值会上下跳动。一定要加上速度判断，单位真的完全停下才算到达。另外还有一个隐蔽问题：如果你的 Agent 初始位置没有精确贴在 NavMesh 表面，而是稍微悬空或者在墙里面，SetDestination默认会静默失败，单位原地不动也不报错。排查这种问题最直接的办法是把NavMeshAgent的Warp()调用放到场景初始化的最后一步。
5. 结合技能指示器场景：从寻路到目标范围判定的联动实践
5.1 为什么技能指示器会和 NavMesh 有关系
你可能看到标题里的“技能指示器”一头雾水：技能范围展示跟 AI 导航有什么关系？有，而且关系很大。MOBA 和 ARPG 类游戏里，非指向性技能需要在地面上画出扇形、圆形、矩形指示范围。而这块指示区域是否合法（是否在障碍物后面、是否超出地形边界、是否被墙体遮挡）恰恰需要一个基于地面几何数据的判断机制。
Unity 原生的Physics.Raycast是无法判断这些的，它只能告诉你有没有 Collider 被击穿，而 NavMesh 本身就是一张完整的可地面数据网格。用 NavMesh 做技能指示器的地面合法性检测，有两个天然优势：一是它自带可走性标记，墙体后的地面根本没有网格；二是它自带区域类型，你可以针对不同地面区域决定技能是否可用。
5.2 用 NavMesh 做技能地面检测的写法
假设你做一个圆形范围技能，需要判断这些事：圆心是否在可走地面内，范围内是否有不可通行的大片区域，以及受击单位站在网格上的哪个位置。这个用 NavMesh API 可以实现如下：
using UnityEngine; using UnityEngine.AI; public class SkillGroundValidator : MonoBehaviour { public bool IsCircleAreaAvailable(Vector3 center, float radius) { if (!NavMesh.SamplePosition(center, out NavMeshHit hit, 1f, NavMesh.AllAreas)) return false; int sampleCount = 12; for (int i = 0; i < sampleCount; i++) { float angle = (360f / sampleCount) * i * Mathf.Deg2Rad; Vector3 point = center + new Vector3(Mathf.Cos(angle), 0f, Mathf.Sin(angle)) * radius; if (!NavMesh.SamplePosition(point, out NavMeshHit edgeHit, 0.5f, NavMesh.AllAreas)) return false; } return true; } }把圆的周围 12 个点分别做SamplePosition检测，任何一个点落不到导航网格上，就认为这个技能中心或范围被墙体卡掉或者卡到了不可走地面。边界上的点是技能最容易被墙体挡掉的地方，如果中心点合法但边缘点不合法，我会让技能前摇阶段额外播放一个“不可用”的红色提示。
这套逻辑在项目里实测表现非常顺畅，它的性能开销小到可以忽略，SamplePosition本身就类似查字典，不用像 Physics 检测那样做几何碰撞。缺点是不能检测空中单位，空中单位请走自己的判定方案（高度差判断 + 扇形角度数学），不要混用。
6. 性能调优与动态烘焙常见坑
6.1 主线程卡顿的排查顺序
如果每次局部烘焙都出现明显帧率波动，我的排查步骤是：
- 查 Surface 的
collectObjects设置。如果还是All，每次烘焙会把全场景对象全部重新收集一遍，性能必然崩。改成Volume后只收集范围内的物体，CPU 开销能降一个数量级。 - 查 Collider 数量。
Physics Colliders模式下，烘焙要读取所有碰撞体数据，一个场景几千个 Collider，光收集数据就几十毫秒。用Render Meshes模式的话，烘焙就完全跳过碰撞体，性能极快，缺点是没有物理耦合。 - 查 Agent 数量。每一张 NavMesh 上如果同时有 100 个以上的 NavMeshAgent 在寻路，即使网格生成再快，每帧的寻路路径计算也是不小的开销。这种情况要做 LOD 寻路，离玩家远的小兵不逐帧寻路，每隔 0.5 秒更新一次目的地。
6.2 运行时路径抖动
单位在移动中每帧调用SetDestination()去追一个移动的玩家，会出现路径抖动，这是正常现象，不是 BUG。原因是寻路找到一个新路径后，Agent 依照当前速度执行转向，下一帧数据更新，又产生新路径，反复循环导致身体来回晃。
解决办法：
public class SmoothChase : MonoBehaviour { NavMeshAgent agent; Transform target; float updateInterval = 0.3f; float nextUpdateTime = 0f; void Update() { if (Time.time > nextUpdateTime) { nextUpdateTime = Time.time + updateInterval; agent.SetDestination(target.position); } } }把SetDestination的调用频率卡在 0.3 秒一次，路径更新不会影响追击手感，抖动明显消失。同时把 Agent 的Angular Speed调低，比如 120 到 360 之间，太高反而让身体转得比路径变更还快，看起来像精神分裂。
6.3 被 NavMesh 卡出世界的场景
我的角色模型自己在跑，但莫名的某一次寻路时突然消失或者瞬移了。这个几乎都是Warp的锅。Warp是强行走网格传送，如果目标点在此帧的网格数据上是空洞（正在被 NavMeshObstacle 挖掉），那 Warp 就会把单位送到网格边界外，甚至掉到 Y 轴负方向。做法是在 Warp 前先做SamplePosition检测，确认目标点存在网格数据再传送，必要时加一个最大尝试次数，连续失败就终止行为，不要无限传送。
6.4 多 Agent Type 烘焙数据串场
如果场景里同时有 Humanoid 和 Ranged 两个 Agent Type，而对应 Surface 的agentTypeID没有分别指向各自类型，烘焙出来的 NavMesh 会只有一个类型的数据，导致某些 Agent 完全无法寻路。我遇到过最鬼畜的表现是：单位站在原地，isOnNavMesh返回 true，但目标路径怎么都不生成。原因就是它的 Agent Type 没有对应到任何 Surface 烘焙数据。用NavMeshAgent的agentTypeID属性检查，运行时直接打出来看，千万别只在编辑器里猜。
7. 一些实操经验与最终建议
我前前后后在新旧导航系统之间切换了差不多一年多，踩过不少坑，有几个体会特别深。
第一，新 AI Navigation 包最值得投入的其实是可编程烘焙和运行时动态更新这块能力。如果你的项目还停留在“编辑器手动 Bake”的阶段，那新系统带来的提升感知不会太强，甚至会觉得 API 变复杂了。但你一旦开始做随机地图、动态地形、RTS 多单位调度，回头看旧版，会发现旧版那些所谓的 OffMeshLink、动态障碍物方案在工程化面前完全不够看。
第二，Map 生成逻辑和导航烘焙逻辑不要写进同一个脚本。最理想的做法是把地图数据生成、导航烘焙、路径行为三个模块完全分开。地图脚本只负责放置方块和墙体，导航脚本只监听地图生成完毕的事件然后唤醒烘焙，行为脚本去申领 Agent 并下发移动目标。这样代码调试和性能定位都清晰得多。
第三，多件套方案不要混用。有些同学觉得 NavMeshAgent 的单位需要避开另一个移动单位，就给两个单位都加 NavMeshObstacle，结果就是相互克制，经常卡死。移动单位的互相避让应该用 NavMeshAgent 自身的Obstacle Avoidance参数（Radius、Quality 这些）来处理，而不是堆组件。NavMeshObstacle 这个组件只服务于真正的静态或可破坏障碍物。
最后说一个很多人直到项目上线都没发现的小细节：NavMeshAgent的Auto Traverse OffMesh Link默认是开启的。它在典型场景下会帮你自动走 NavMeshLink，但在你通过代码动态管理链接可用性时，如果你没关掉它，可能会出现 Agent 自己走过去然后又走回来的死循环。如果你需要完全控制移动，就把这个选项关掉，用自己的状态机控制哪里该执行跳跃动画、哪里该自动走桥。尤其是跳跃类动作游戏，这个选项必须关，否则角色的跳跃动作永远跟路径系统打架。
这个内容后续如果你要继续深入，我建议从NavMeshQuery系统入手，它允许你在运行时用 Raycast、Pathfinding 的底层查询接口做更细粒度的控制，比如做技能寻路范围算法、多单位分组寻路，都会比现在基于组件的写法更高效。但那是后话了，先把 Surface 烘焙、动态障碍和链接这套基础打牢，你的 AI 移动系统就能应付绝大多数游戏场景了。
