企业官网建设流程全解析

1. 项目概述：为什么动态障碍物是AI寻路的“老大难”？

在Unity里做寻路，给静态场景烘焙个NavMesh，再挂个NavMeshAgent组件，这事儿大家都会。但一旦场景里出现了会动的家伙——比如被玩家推着走的箱子、被爆炸炸飞的油桶、或者来回巡逻的敌人——问题就来了。你会发现你的AI角色要么像个愣头青一样撞上去，要么在障碍物周围鬼畜抖动，要么干脆卡死不动。这背后的核心矛盾在于：静态的导航网格（NavMesh）如何应对动态变化的世界？

这就是NavMeshObstacle组件登场的时刻。它不是一个简单的“碰撞体”，而是一个专门为动态寻路设计的“路障信号器”。我见过太多项目，开发者要么只用NavMeshAgent，试图用复杂的脚本逻辑去模拟避障，结果性能开销巨大且效果不佳；要么就是给动态物体加了个NavMeshObstacle，但参数全用默认值，导致避障行为诡异，最后还怪Unity的AI系统不好用。

今天，我们就来彻底拆解这个组件。我会结合我过去在多个RTS、ARPG和潜行类项目中踩过的坑，把Carve、Move Threshold、Time To Stationary这些参数背后的逻辑、适用场景以及那些官方手册里没写的“潜规则”给你讲透。无论你是想让你的小兵聪明地绕开滚动的巨石，还是让NPC优雅地避开玩家临时放置的障碍，这篇文章都能给你一套可直接复用的配置方案。

2. NavMeshObstacle核心机制深度解析

在深入参数之前，我们必须理解NavMeshObstacle与普通碰撞体（如Box Collider）以及NavMeshAgent的根本区别。它不是用来做物理碰撞的，它的唯一职责是与寻路系统（NavMesh）通信，告诉寻路系统：“这里有个东西挡着路，你们规划路径时得绕开。”

2.1 两种工作模式：障碍（Obstacle）与雕刻（Carve）

这是理解所有参数的基础。NavMeshObstacle有两种根本性的影响寻路的方式，通过Carve属性开关。

模式一：障碍模式（Carve = false）这是默认模式，也是最容易误解的模式。在此模式下，NavMeshObstacle不会修改底层的NavMesh数据。你可以把它想象成一个“幽灵力场”。

• 工作原理：NavMeshAgent在寻路时，会实时检测前方是否存在NavMeshObstacle。如果检测到，Agent会尝试进行“局部避障”——也就是在原有路径上做微调，试图绕过这个力场。这完全依赖于Agent自身的Avoidance Priority（回避优先级）和Radius（半径）等参数进行动态避让。
• 行为类比：就像你在人群中走路，看到前面有人挡道，你会不改变既定目的地（比如咖啡店），而是侧身挤过去。如果人太多（障碍太密集），你可能就挤不过去了。
• 核心特点：不修改路径规划，只影响Agent的局部移动。对CPU开销较小，但避障能力有限，在复杂或狭窄空间容易失败。

模式二：雕刻模式（Carve = true）这是“重型”模式。开启后，NavMeshObstacle会在NavMesh上“挖”出一个洞，这个洞的形状和位置会实时更新（根据参数设置）。

• 工作原理：当障碍物被视为“静止”时（后文会详述何为“静止”），系统会在它所占用的导航网格区域标记为“不可行走”。寻路器（Pathfinder）在计算全局路径时，会直接绕过这个被挖掉的区域。
• 行为类比：就像路上突然出现一个施工坑洞，地图APP会直接为你重新规划一条完全不经过这个坑洞的路线。
• 核心特点：直接影响全局路径规划，避障更可靠、更“智能”。但需要实时更新NavMesh数据，CPU开销更大。

注意：一个常见的误区是认为开启了Carve就一劳永逸。实际上，Carve模式下的行为由Move Threshold和Time To Stationary等参数精细控制，理解不当会导致性能浪费或逻辑错误。

2.2 形状（Shape）与尺寸：不仅仅是视觉匹配

NavMeshObstacle提供Box和Capsule两种基本形状。选择哪个不是看模型长什么样，而是看你需要多“保守”的避障空间。

• Box：方形区域。计算效率最高。适用于桌子、箱子、方形柱子等物体。但它的尖角可能导致Agent寻路时贴得太近，甚至卡在角上。实操心得：对于方形障碍，我会将Size设置得比实际视觉模型稍大一些（例如每边扩大0.1-0.2个单位），为Agent的碰撞半径预留安全空间，避免“擦边”导致的抖动。
• Capsule：胶囊体。这是更推荐的选择，尤其对于需要角色绕行的障碍。因为胶囊体没有尖角，寻路系统计算出的绕行路径会更加平滑自然。
• Center & Size/Radius/Height：这些参数定义了障碍物的影响范围。关键点在于：这个范围应该大于或等于物体的物理碰撞体。因为寻路避障和物理碰撞是两个独立系统。如果你用一个很小的NavMeshObstacle配一个很大的Collider，Agent可能会规划出一条路径，看似能通过，但实际上物理上会卡住。

配置示例：一个圆柱形石墩。

• 物理：添加一个Capsule Collider，半径0.5，高度2。
• 寻路：添加NavMeshObstacle，Shape选Capsule。Center设置为(0, 1, 0)（假设原点在底部），Radius设为0.7，Height设为2.2。这样就在物理碰撞体外提供了一个缓冲带，确保AI提前规划绕行。

3. Carve模式下的核心参数精讲

当你勾选Carve后，下面几个参数就变成了调优的关键。它们共同决定了“何时挖洞”、“何时填洞”以及“洞怎么移动”。

3.1 Move Threshold（移动阈值）：定义“动”与“不动”的界限

这是最容易让人困惑的参数之一。它的单位是距离，但它的作用是一个状态切换触发器。

• 官方解释：当障碍物从上一帧到当前帧的移动距离超过此阈值时，Unity将其视为“移动状态”。
• 深入理解：这不是一个“每帧移动多少就开始雕刻”的开关。它的核心作用是减少不必要的NavMesh更新。想象一下，一个受物理影响微微晃动的箱子，如果它每晃动一毫米就触发一次NavMesh重算，那将是巨大的性能浪费。
• 如何设置：
  • 高精度、小范围移动的物体：设为较小的值，如0.05-0.1。例如，一个被精准拖放的箱子。
  • 受物理影响、会抖动或滚动的物体：设为较大的值，如0.5-1.0。例如，一个被击飞后在地面滚动的木桶。这样可以避免因其微小滚动而频繁更新NavMesh。
  • 高速移动的物体（如车辆）：通常不建议为其开启Carve（理由见后文），但如果必须，阈值应设置得大于其一帧内可能移动的典型距离，例如2.0-5.0。

避坑指南：不要将其设为0或极小的值。除非你的障碍物移动是由确定性动画（非物理）驱动且每帧位移恒定，否则物理系统的微小抖动会引发剧烈的性能波动。

3.2 Time To Stationary（静止判定时间）：耐心等待

这个参数与Move Threshold紧密配合。单位是秒。

• 官方解释：将障碍物视为静止状态所需等待的时间。
• 工作流程：
  1. 障碍物停止移动（即连续多帧的位移都小于Move Threshold）。
  2. 系统启动一个计时器，时长即为Time To Stationary。
  3. 在此计时期间，如果障碍物再次移动超过阈值，计时器重置。
  4. 计时器走完后，障碍物才被正式标记为“静止”，此时才会执行Carve操作（在NavMesh上挖洞）。
• 为什么需要它？为了防止“闪烁”。比如一个NPC走到某个点停住，如果它一停就立刻挖洞，那么它脚下的NavMesh瞬间消失，会导致其他试图经过此处的Agent路径计算混乱。给一个短暂的延迟，可以确认这个障碍物是真的停下来了，而不是移动间的短暂停顿。
• 如何设置：
  • 频繁起停的物体：设为较短时间，如0.1-0.3秒。例如，一个跟随玩家走走停停的宠物。
  • 受物理影响、可能静止后又滚动的物体：设为较长时间，如0.5-1.0秒。例如，一个滚到墙边可能回弹一下的木箱。
  • 几乎不停下的物体（如巡逻兵）：如果你为它开启了Carve，这个值可以设得相对短一些，但更常见的做法是直接关闭Carve Only Stationary（见下文）。

3.3 Carve Only Stationary（仅雕刻静止物体）：性能与效果的权衡

这是一个复选框，是Carve模式下最重要的性能优化开关。

• 开启（默认推荐）：只有当一个障碍物被判定为“静止”（即满足了Move Threshold和Time To Stationary条件）后，它才会在NavMesh上雕刻出一个洞。在它移动过程中，它仅作为一个普通的“障碍”（Obstacle模式）来影响其他Agent的局部避让，而不会触发耗时的NavMesh更新。
• 关闭：只要障碍物移动距离超过Move Threshold，它就会在每一帧（或按一定频率）更新它在NavMesh上雕刻的洞的位置。这意味着移动的障碍物也会实时地“挖洞”。

决策矩阵：如何选择？

一个关键洞见：Carve Only Stationary开启时，移动中的障碍物对寻路系统的影响是“弱”的（局部避障）。这可能导致一个现象：一群Agent可能会被一个缓慢移动的障碍物“推着走”，因为它们只尝试局部避开，而不会重新规划全局路径绕到障碍物前面去。这是设计选择，不是Bug。

4. 实战配置：从场景到参数的一站式方案

理论说完了，我们来看怎么用。我会给出几个经典场景的完整配置步骤和参数建议。

4.1 场景一：可推动的物理箱子（解谜/互动场景）

目标：玩家可以推动箱子。箱子移动时，NPC应被推开；箱子停下后，NPC应将其视为固定障碍绕行。

1. 组件添加：给箱子GameObject添加Rigidbody（用于物理）、Box Collider（物理碰撞）、NavMeshObstacle。
2. NavMeshObstacle配置：
   • Shape:Box（与模型匹配）。
   • Center/Size: 匹配或略大于Box Collider的尺寸。例如，Collider的Size是(1,1,1)，这里可以设为(1.2, 1.2, 1.2)。
   • Carve:勾选。
   • Move Threshold:0.3。箱子推动时通常不是平滑移动，可能有抖动，这个值可以过滤微小抖动。
   • Time To Stationary:0.5。给一个半秒的确认时间，防止箱子刚好卡在某个位置轻微抖动时被误判为静止。
   • Carve Only Stationary:勾选（默认）。这是关键！箱子移动时不影响全局路径，停下后才“挖洞”。
3. NPC的NavMeshAgent配置：确保其Avoidance Priority设置合理（数字越小优先级越高），并且Radius不为0，以便在箱子移动时能进行有效的局部避让。

4.2 场景二：缓慢移动的平台（平台解密/电梯）

目标：平台沿固定路径循环移动。NPC需要能够走到平台上，或等待平台离开后通过。

1. 组件添加：给平台添加NavMeshObstacle。如果平台需要承载Agent，还需在平台表面烘焙Walkable的NavMesh。
2. NavMeshObstacle配置：
   • Shape: 根据平台形状选择Box。
   • Carve:勾选。
   • Move Threshold:0.01。平台移动通常是平滑的动画或脚本控制，位移精确，阈值可以设得很小，确保移动状态被及时识别。
   • Time To Stationary:1.0或更大。因为平台可能永远不会“静止”，这个值主要用于平台在路径端点暂停的情况。设大一些避免在短暂停顿时就雕刻。
   • Carve Only Stationary:取消勾选！这是核心。我们必须让平台在移动时也实时雕刻NavMesh，这样在下面的Agent才会知道路被堵住，从而等待或寻找其他路径。
3. 寻路逻辑补充：对于需要“搭乘”平台的NPC，你需要编写额外的逻辑。例如，当NPC的目标点在移动平台上时，它的目标位置应该设置为平台的当前位置（或一个相对偏移），并定期更新。同时，当NPC在平台上时，可以临时禁用它的NavMeshAgent，或者将其父级设置为平台，让其随平台移动。

4.3 场景三：作为动态障碍的敌人（RTS/混战场景）

目标：敌方单位对我方寻路单位构成障碍，需要被绕开，但敌人自身也在移动。

1. 方案选择：这是一个经典难题。为每个敌人开启Carve且不勾选Carve Only Stationary在单位数量多时是性能灾难。
2. 推荐方案——分层处理：
   • 对于近距离、高威胁的动态避让：不为敌人添加NavMeshObstacle。而是利用NavMeshAgent自带的避让（Avoidance）功能。确保敌我双方的NavMeshAgent都设置了合理的Radius、Speed和Avoidance Priority。这样，他们在接近时会像现实中人流一样自然分开。这是处理大量动态单位间避障的最高效方式。
   • 对于长时间静止的敌人（如狙击手、炮台）：可以为这些特定的敌人添加NavMeshObstacle，并开启Carve和Carve Only Stationary。当它们进入蹲守、瞄准等静止状态时，就会被刻入NavMesh，成为地形的一部分，迫使我方单位全局绕行。
   • 对于巨型单位（如BOSS）：由于其体型大，局部避让可能失效，可以考虑为其添加NavMeshObstacle，Shape匹配其体型，并关闭Carve。利用其巨大的“障碍力场”迫使其他Agent提前进行局部路径调整。同时可以调低其NavMeshAgent（如果有）的优先级，让其他小单位主动避开它。

5. 性能优化与高级技巧

动态导航网格更新是CPU敏感操作。不当使用NavMeshObstacle会导致帧率下降。

5.1 性能监控与瓶颈识别

在Profiler中，关注Navigation.Preprocess和Navigation.UpdateObstacles这两个项。如果它们耗时很高，说明你的动态障碍物设置可能有问题。

• Preprocess激增：通常是因为有大量障碍物同时触发Carve更新（例如，一堆箱子同时被炸飞然后判定静止）。
• UpdateObstacles持续偏高：说明有大量障碍物处于移动雕刻状态（Carve Only Stationary关闭）。

5.2 实战优化策略

1. 优先使用“障碍模式”：对于大多数持续移动的物体，先问问自己是否真的需要Carve。很多时候，仅靠Agent间的避让和障碍模式已经足够。
2. 善用代理半径（Agent Radius）：在烘焙NavMesh时，设置的Agent Radius会生成等宽的“边缘”。适当增大这个值，可以让生成的路径更远离静态障碍，为动态避让留出更多空间，减少对动态障碍的依赖。
3. 分帧更新：如果你有数十上百个需要雕刻的动态障碍（比如大规模可破坏环境），可以考虑编写一个管理器，每帧只更新其中一部分障碍物的状态，将NavMesh更新负载分摊到多帧。
4. 动态启用/禁用组件：对于一个物体，如果它大部分时间静止，偶尔移动（如一扇被炸开的门），可以在它开始移动时通过代码GetComponent<NavMeshObstacle>().carve = false禁用雕刻，移动结束后再启用。这需要精细的状态管理。
5. 谨慎使用NavMeshAgent.Stop()/Resume()：停止一个Agent的寻路并不会移出它的NavMeshObstacle影响。如果你想让一个单位完全“隐形”于寻路系统，需要禁用或销毁它的NavMeshObstacle组件。

5.3 与NavMesh查询的延迟问题

手册最后提到一个至关重要但常被忽略的警告：使用NavMesh查询方法（如NavMesh.CalculatePath,NavMesh.SamplePosition）时，要考虑到NavMeshObstacle的更新存在一帧延迟。

这意味着什么？假设你在某一帧计算一条路径，而一个障碍物刚好在这一帧移动并触发了雕刻更新。你计算出的路径可能没有避开这个刚刚移动的障碍物，因为雕刻更新要在下一帧才生效。

解决方案：

• 对于关键路径（如玩家单位的关键移动），可以在计算路径后，手动进行一轮射线检测或Overlap检查，看看路径上是否有已知的动态障碍物，如果有，则延迟一帧再请求路径或进行局部调整。
• 或者，对于非常重要的动态障碍，可以将其位置变化事件通知给寻路系统，在障碍物移动的同一帧就强制进行路径重算（但这更耗性能）。

6. 常见问题排查与解决方案实录

以下是我在项目中真实遇到过的问题和解决方法。

问题1：Agent在障碍物边缘“抽搐”或卡住。

• 可能原因：NavMeshObstacle的Shape尺寸与物体的物理碰撞体尺寸完全一致，没有留出缓冲空间。Agent的路径紧贴障碍物边缘，而它的物理碰撞体又与之相交，导致每帧在“寻路推挤”和“物理碰撞”之间振荡。
• 解决：将NavMeshObstacle的尺寸设置得比物理碰撞体稍大。确保NavMeshObstacle的Center也正确，使其覆盖范围包含整个物体。

问题2：障碍物明明停了，但Agent还是不把它当障碍，直接穿过去（或撞上去）。

• 可能原因1：Time To Stationary设置过长，障碍物还未被系统判定为静止。
• 可能原因2：障碍物的移动从未真正“停止”。检查其Rigidbody是否因为微小的力（如重力不平衡、关节马达）而持续有velocity。即使视觉上不动，物理引擎可能认为它在动。
• 解决：对于原因2，可以在脚本中判断，当速度小于一个极小值（如0.001）时，直接设置Rigidbody.velocity = Vector3.zero和angularVelocity = Vector3.zero，并可能强制将障碍物设置为运动学（isKinematic = true）来确保其静止。

问题3：大量可破坏物体被摧毁时，游戏卡顿。

• 可能原因：每个被摧毁的物体上都有NavMeshObstacle，且开启了Carve。当它们被销毁时，Unity需要从NavMesh中移除所有对应的雕刻，这是一个同步的、可能很耗时的操作。
• 解决：对于即将被销毁的障碍物，在销毁前的一帧（例如在播放死亡动画时），通过脚本将其NavMeshObstacle组件的carve属性设为false。这样，系统会先移除雕刻，然后再销毁物体，可以将计算压力分摊开。

问题4：移动平台上的Agent路径计算错误，掉下平台。

• 可能原因：Agent的路径是在平台位于A点时计算的。当Agent开始移动时，平台已经移动到了B点。Agent仍然试图走向A点那个已经“不存在”的导航网格位置。
• 解决：这超出了NavMeshObstacle的能力范围。你需要编写自定义逻辑：当Agent的目标是移动平台上的某个相对位置时，你应该每帧（或定期）更新这个目标的世界坐标，并调用NavMeshAgent.SetDestination()。或者，更高级的做法是使用NavMeshAgent的SetDestination配合OnDestinationReached这类回调，实现分段移动。

问题5：两个都开启了避让（Avoidance）的Agent，面对面“僵住”，谁也不让谁。

• 注意：这不是NavMeshObstacle的问题，但常与之混淆。这是NavMeshAgent避让系统的典型“死锁”场景。
• 解决：引入简单的决策打破对称。例如，随机给其中一个Agent一个短暂的停顿（isStopped = true），或者让其中一个Agent主动进行一个小幅度的横向移动。也可以根据单位类型设置不同的Avoidance Priority，让低优先级单位主动避让高优先级单位。

最后，记住一个核心原则：NavMeshObstacle是连接动态游戏世界与静态寻路数据的桥梁。它的参数没有银弹，最佳配置永远取决于你的具体游戏需求——是更注重性能，还是更注重寻路的精确性和智能性。我的习惯是，在项目初期为所有动态障碍物使用一套保守的参数（开启Carve Only Stationary，较大的Move Threshold），然后在实际测试中观察，遇到特定问题再对特定类别的物体进行微调。多利用Scene视图的Navigation面板可视化障碍物的影响范围，结合Profiler监控性能，你就能找到最适合你项目的那个平衡点。