一个2D项目里，我需要做一个在固定平台上来回走动的机器人守卫，功能听上去特别简单：从A点走到B点，再掉头走回A点，循环往复。当时我心想，这不就是几行transform.position += Vector3.right * speed * Time.deltaTime;再判断一下位置就完事吗。结果这个"几行代码"的需求，让我连续调试了两个晚上，踩遍了物理移动、边界检测、朝向翻转、状态切换这些坑之后才明白："来回巡游"是2D游戏AI里最基础、也最容易被低估的功能。
这篇文章，我想把我做Unity 2D机器人巡游功能时完整的思考过程、代码方案和踩坑记录整理出来。不管你是刚接触Unity的新手，还是已经写过一阵子战斗AI的老手，应该都能在里面找到点有用的东西。
1. 理解"来回巡游"这个需求，先认清背后的三个关键问题
1.1 巡游的本质：方向、速度、边界，三者缺一不可
所谓"来回巡游"，拆开来看其实就是三个要素在不停地相互作用：
- 方向：机器人当前朝左还是朝右，决定了位移向量是正还是负。
- 速度：每秒移动多少米（Unity物理单位），它决定了巡游的节奏感。
- 边界：到达什么条件必须折返，这是整个巡游逻辑中最核心的判定逻辑。
很多新手（包括当时的我）只盯着"方向"和"速度"写代码，把"边界"当成一个简单的if条件随手处理，结果就会出现下面这几种典型症状：
- 机器人走到平台边缘直接掉下去，因为没有检测地面是否悬空。
- 机器人撞到墙壁后卡在原地疯狂抖动，因为碰撞体挡住了移动，但方向翻转逻辑还在继续。
- 机器人从A点走到B点的距离永远不对，因为用了
transform.Translate后受到物理引擎的位置修正。
所以你一开始就要问自己：我的机器人巡游，"边界"到底由什么决定？
根据不同的游戏场景，边界通常有几种来源：平台两侧的悬崖边、左右两道墙壁、一个虚拟的活动半径、甚至是一个计时器。每一种来源对应的实现方式完全不同，后面我会逐一展开。
1.2 巡游是后续AI行为的地基
你可能会觉得，巡游不就是个移动脚本吗？但在真实项目里，巡游往往是一个完整AI状态机的起点。
我做那个机器人守卫的时候，需求后来追加了：机器人巡游时如果玩家进入视野范围，它要停止巡游并追踪玩家；玩家离开视野后，它要回到巡逻路线上继续走。你看，从"走来走去"到"有反应地走来走去"，中间就是状态切换。如果最开始巡游代码写得乱七八糟，后面加任何行为逻辑都很难收拾。
所以这篇文章虽然是讲巡游，但我强烈建议你把巡游当作一个"状态"来设计，而不是一个"脚本"来堆代码。第4部分我会专门讲状态机怎么写。
2. 移动方式选型：Transform位移和Rigidbody2D，这一步决定后面所有坑的数量
2.1 为什么"移动方式"比代码本身还重要
如果你搜索Unity 2D巡逻，十篇教程里有八篇会给你看这行代码：
transform.Translate(Vector2.right * speed * Time.deltaTime);这句话本身没有错，但它有一个大前提：角色的移动完全不受物理系统约束。也就是说，角色身上不能挂Rigidbody2D，或者你不指望它和别的物体发生碰撞。
但一个需要"来回巡游"的机器人，大概率是需要碰撞的——它有体积，会被墙挡住，不能掉下平台，甚至可能和玩家碰撞产生伤害。一旦角色身上挂了Rigidbody2D，再用Transform.Translate或者直接改transform.position，问题就来了：
物理引擎每帧会根据刚体的速度、摩擦力、碰撞约束来重新计算位置，而你的代码又在物理计算之外直接修改了Transform，两套系统抢着控制同一个位置，表现就是抖动、卡顿、甚至直接把机器人挤到地面下方。
我在那个项目里就遇到过：机器人明明在地面上走，突然就穿模掉到平台下面去了。检查了半天，发现就是因为我每帧用transform.position += ...强行移动，导致刚体碰撞约束没来得及生效。
结论：只要角色挂了Rigidbody2D，移动逻辑就要交给物理系统。
2.2 用velocity还是MovePosition？我的选择是velocity
Rigidbody2D提供两种主流的移动控制方式：
| 方式 | 特点 | 适用场景 |
|---|---|---|
rb.velocity | 直接设定速度向量，物理引擎持续推动刚体 | 持续匀速巡游、受物理影响 |
rb.MovePosition() | 每帧计算期望位置并移动，略带插值 | 精确控制位置、避免高速穿透 |
对巡游这种"持续行走"的需求，我更推荐rb.velocity。原因很简单：
- 它和物理系统的交互最自然，碰撞检测稳定，不会出现走走停停的顿挫感。
- 你不用自己手动计算并累加位移，只需要在方向翻转时把速度向量的x分量取反就行。
- 后续如果要加摩擦力、加推力、加减速，velocity方式都更好扩展。
MovePosition也不是不能用，但它的手感更偏向"传送"，速度快的时候反而容易错过一些极短距离的碰撞事件。巡游是持续动作，所以选择velocity是最稳妥的起点。
2.3 巡游起点与边界参数化：一次性写好，后面不用返工
写巡游代码时，很多人会把起点写死在Start里，然后只用Mathf.Abs(当前位置 - 起点)做距离判断。这个方式够用，但不够灵活。
我建议直接在Inspector上暴露两个边界位置，用世界坐标去判断：
public float leftBoundaryX = -5f; public float rightBoundaryX = 5f;为什么这么做？因为很多时候，你希望机器人只在某个特定区域内巡游，而不是以出生点为圆心对称地走。暴露边界值，策划或者你自己调参时，直接在Inspector里拖数值就行，不用改代码。
如果场景里就是用两个空物体标记边界，你也可以用Transform引用的方式，运行时读取它们的x坐标，这样更直观：
public Transform leftBoundaryMarker; public Transform rightBoundaryMarker;我个人习惯是：原型阶段用公开的float变量，功能稳定后再改成Transform引用或者场景标记点。这样前期调参方便，后期又不缺灵活性。
3. 三种边界判断方案：距离、射线、碰撞检测，各自的脾气和适用场景
3.1 方案一：固定距离折返，最省钱但限制也最明显
最直接的方案：定义机器人从左边界到右边界，走够一定距离就折返。用代码如下：
using UnityEngine; public class PatrolRobot : MonoBehaviour { [Header("巡游设置")] public float moveSpeed = 2f; public float patrolDistance = 4f; private Rigidbody2D rb; private float startX; private int direction = 1; // 1为向右，-1为向左 private void Awake() { rb = GetComponent<Rigidbody2D>(); } private void Start() { startX = transform.position.x; } private void FixedUpdate() { rb.velocity = new Vector2(direction * moveSpeed, rb.velocity.y); if (Mathf.Abs(transform.position.x - startX) >= patrolDistance) { direction *= -1; } } }这版代码的思路是：在Start时记住起始位置，走到离起点patrolDistance远的地方就掉头。看起来很合理，有两个问题需要注意：
- 机器人必须从没有碰撞的位置启动。如果Start时角色旁边就有墙，那它会在到达距离边界之前就被墙挡住，永远触发不了折返。代码里的条件一直不满足，机器人就一直顶着墙跑。
- 距离是相对于起点而不是绝对边界。如果机器人中途被外力推了一段距离（比如碰到被打了），它的往返中心就偏移了，表现为巡逻范围整体漂移。
所以"固定距离折返"只适合那种没有斜坡、没有外力、地面平坦的简单演示场景，真正用在游戏里容易出幺蛾子。
3.2 方案二：射线检测悬崖边缘，防止机器人掉下平台
在实际2D平台游戏里，最常见也最实用的边界方案是：用射线检测前方脚下是否还有地面。没有地面了，就说明到了平台边缘，该掉头了。
这个方案的关键在于，射线是从机器人的"脚下偏前方"发射的，而不是从中心点发射。否则机器人走到边缘时，直接悬空才会检测到，这时候掉头往往已经晚了，半个身子已经出了平台。
正确做法是在机器人底部加一个子物体作为脚下检测点，位置放在角色脚底靠前一点，然后向下发射一条射线：
using UnityEngine; public class PatrolRobot : MonoBehaviour { [Header("巡游设置")] public float moveSpeed = 2f; [Header("边缘检测")] public Transform groundCheckPoint; // 脚下检测点 public float groundCheckDistance = 0.4f; public LayerMask groundLayer; private Rigidbody2D rb; private int direction = 1; private void Awake() { rb = GetComponent<Rigidbody2D>(); } private void FixedUpdate() { rb.velocity = new Vector2(direction * moveSpeed, rb.velocity.y); CheckGroundAhead(); } private void CheckGroundAhead() { // 从检测点向下打一条射线，看是否还有地面 RaycastHit2D hit = Physics2D.Raycast(groundCheckPoint.position, Vector2.down, groundCheckDistance, groundLayer); Debug.DrawLine(groundCheckPoint.position, groundCheckPoint.position + Vector3.down * groundCheckDistance, Color.green); // 射不到地面 = 前方脚下已经悬空 if (hit.collider == null) { Flip(); } } private void Flip() { direction *= -1; } }注意我用了Debug.DrawLine，这是调试射线检测最好用的工具。你会清楚地看到射线在场景视图里的位置，而不是靠猜。
至于groundCheckPoint放在哪，我的经验是：
- 不要放到角色脚下正中，否则机器人走到平台边缘时，射线还在平台范围内，会继续走一段才检测到悬空。
- 放到脚底靠近移动方向的那一侧，提前量给足，给"减速+转身"留出空间。
如果你不想手动创建子物体，也可以在代码里偏移：
Vector2 origin = transform.position + new Vector3(direction * 0.3f, -0.2f, 0); RaycastHit2D hit = Physics2D.Raycast(origin, Vector2.down, groundCheckDistance, groundLayer);这种写法更省事，但不够灵活，0.3f和-0.2f这种偏移值需要根据角色体型硬调。我建议还是建一个子物体更好，因为后续如果换了角色模型，只需要调子物体位置，不用改代码。
3.3 方案三：碰撞检测墙角折返，适合有墙的走廊或房间
如果机器人巡游的区域是两边有墙的场景，那么"撞墙掉头"就是最自然的方案。使用OnCollisionEnter2D检测碰到的墙壁：
using UnityEngine; public class WallDetectRobot : MonoBehaviour { [Header("巡游设置")] public float moveSpeed = 2f; public LayerMask wallLayer; private Rigidbody2D rb; private int direction = 1; private void Awake() { rb = GetComponent<Rigidbody2D>(); } private void FixedUpdate() { rb.velocity = new Vector2(direction * moveSpeed, rb.velocity.y); } private void OnCollisionEnter2D(Collision2D collision) { if ((wallLayer.value & (1 << collision.gameObject.layer)) != 0) { direction *= -1; } } }这里有个关键问题：碰撞事件只有在发生的那一刻才会触发。如果你的机器人移动速度很高，物理引擎可能产生穿透（隧道效应），碰撞事件根本没有触发就穿过去了。
解决穿透问题的方法：
- 控制巡游速度，2D巡游一般不超过5m/s，超过就可能出现穿透。
- 使用
Rigidbody2D的Interpolate配合CollisionDetectionMode2D.Continuous，让它更灵敏。 - 尽量不依赖唯一的碰撞事件，而是同时用射线检测前方墙壁作为兜底。
我把碰撞检测和射线检测结合使用过：
private void FixedUpdate() { rb.velocity = new Vector2(direction * moveSpeed, rb.velocity.y); RaycastHit2D wallHit = Physics2D.Raycast(transform.position, new Vector2(direction, 0), 0.5f, wallLayer); if (wallHit.collider != null) { direction *= -1; } }这样即便碰撞事件没触发，射线也能提前捕捉到墙，机器人不会干站在墙边发抖。
3.4 三种方案的适用场景对照
| 方案 | 定义的边界 | 典型场景 | 潜在风险 |
|---|---|---|---|
| 固定距离折返 | 与起点相距一定距离 | 平坦无人干扰的演示 | 起点被外力推走、撞墙不折返 |
| 射线检测悬崖 | 脚下地面是否悬空 | 平台跳跃、敌人在平台边缘巡逻 | 射线位置错误、层级过滤不严谨 |
| 碰撞检测墙壁 | 碰到墙面 | 走廊式关卡、房间内守卫 | 高速穿透、碰撞事件丢失 |
我的建议是：能上射线检测悬崖就用射线检测，它在2D平台游戏里是最通用、最稳定的一种边界判据。有墙的场景再加一个墙壁射线作为补充。固定距离折返可以作为一开始的验证逻辑，但别依赖它承担正式的游戏逻辑。
4. 给巡游加状态机：从"傻走"变成"有节奏地巡游"
4.1 四个基本状态：待机、巡游、转身、追踪
如果你认真观察一个像样的游戏AI，"来回巡游"从来不会是一个单调循环。"走来走去"之外，通常还夹杂着"停顿观察一下""到边缘时停下来看看""发现目标后追上去"这些行为。
所以我在机器人巡游方案里，引入了最简单的枚举状态机：
public enum BotState { Idle, // 待机，站着不动 Patrol, // 巡游，持续移动 Turn, // 转身，短暂停顿 Chase // 追踪玩家（后续扩展） }状态机的好处是：每个状态的入口和出口都很清晰，新增行为时不用在Update里继续堆if-else，而是增加一个新的状态和处理分支。改代码时思路清晰，不会互相干扰。
4.2 状态机的代码骨架
下面是一个带待机和巡逻状态的骨架代码，两个状态之间用计时器切换：
using UnityEngine; public class PatrolStateMachine : MonoBehaviour { [Header("巡游参数")] public float moveSpeed = 2f; public float patrolTime = 3f; public float idleTime = 1f; [Header("边缘检测")] public Transform groundCheckPoint; public float groundCheckDistance = 0.4f; public LayerMask groundLayer; private Rigidbody2D rb; private BotState currentState; private float stateTimer; private int direction = 1; private void Awake() { rb = GetComponent<Rigidbody2D>(); currentState = BotState.Idle; stateTimer = idleTime; } private void FixedUpdate() { switch (currentState) { case BotState.Idle: HandleIdle(); break; case BotState.Patrol: HandlePatrol(); break; case BotState.Turn: HandleTurn(); break; } } private void HandleIdle() { rb.velocity = new Vector2(0, rb.velocity.y); stateTimer -= Time.fixedDeltaTime; if (stateTimer <= 0) { currentState = BotState.Patrol; stateTimer = patrolTime; direction = 1; } } private void HandlePatrol() { rb.velocity = new Vector2(direction * moveSpeed, rb.velocity.y); stateTimer -= Time.fixedDeltaTime; CheckEdge(); CheckPatrolTimer(); } private void CheckEdge() { RaycastHit2D hit = Physics2D.Raycast(groundCheckPoint.position, Vector2.down, groundCheckDistance, groundLayer); if (hit.collider == null) { currentState = BotState.Turn; stateTimer = 0.3f; } } private void CheckPatrolTimer() { if (stateTimer <= 0) { currentState = BotState.Idle; stateTimer = idleTime; } } private void HandleTurn() { rb.velocity = new Vector2(0, rb.velocity.y); stateTimer -= Time.fixedDeltaTime; if (stateTimer <= 0) { direction *= -1; currentState = BotState.Patrol; stateTimer = patrolTime; } } }我把"转身"单独作为一个状态来处理，而不是直接在发现边缘的瞬间翻转方向。为什么？因为原地掉头如果是在高速移动中瞬间完成的，视觉上会很突兀，而且在2D物理环境下，瞬间翻转速度向量还会带去一部分惯性问题。加一个0.3秒的停顿，让机器人看起来是在"观察边缘"，反而更自然。
4.3 状态机带来的扩展空间
这个骨架最大的价值在于：你可以顺着它继续扩展。比如在Patrol状态里每帧发射一条扇形射线检测玩家，如果碰到玩家就切到Chase状态；Chase状态里追踪玩家，追丢了再切回Patrol。这种状态切换逻辑清晰，而且不会污染巡游本身的代码。
后面我把这个机器人做成"发现玩家就追，追不上就回去继续巡游"的效果时，基本就是在这个状态机上加了两个分支，改动成本很低。这就是我不建议在一个Update里堆一堆布尔值标记来切换行为的原因——200行之后你就看不懂自己在写什么了。
5. 朝向与动画：机器人巡游时Sprite翻转的几个隐蔽坑
5.1 SpriteRenderer.flipX 和 localScale.x 翻转的区别
巡游时，机器人需要面朝移动方向。最常用的两种做法是：
- 修改
SpriteRenderer.flipX - 修改
transform.localScale.x的正负值
两者都能实现朝向翻转，但差别不小。
flipX只是把Sprite本身镜像翻转，不会影响子物体、不会影响碰撞体位置、不会影响角色身上挂的武器或眼睛位置。这是最安全也最推荐的方式，尤其适合那种结构的角色（身体、武器、特效都是分开子物体的）。
localScale.x *= -1是把整个GameObject坐标系镜像翻转了，子物体也会跟着翻转，碰撞体形状也会左右颠倒。如果你没有额外处理，会出现一个很烦人的现象：机器人朝左走时，原本挂在右侧的武器跑到左侧去了，碰撞体也跟着歪掉。
所以我的建议是：没有特殊需求，一律用SpriteRenderer.flipX翻转朝向。
5.2 子物体翻转导致碰撞体错位的坑
有一个很经典的坑，我亲眼见一个朋友在项目里调试了两天：
他把机器人做成了一个父物体，下面挂了Sprite子物体和碰撞体子物体。翻转的时候他直接翻转父物体localScale.x，结果整个父物体和所有子物体都镜像了，碰撞体的偏移量也变成了负数，机器人和墙的接触位置完全对不上。表现为机器人离墙还有很大距离就开始"撞墙掉头"。
如果你必须用localScale.x翻转（比如你自己项目的历史代码已经这么写了），那碰撞体的Offset也要跟着做对称处理。要么所有子物体坐标都写成对称的，要么干脆别用这个方案。
在这类问题上，我最终统一改成SpriteRenderer.flipX之后，所有碰撞相关的毛病都消失了。所以你在写巡游之前，先想好朝向翻转方案，可以省掉大量后期调试时间。
5.3 让动画切换和状态切换同步
如果你的机器人身上有Animator，巡游、待机、转身最好都有对应的动画状态。否则机器人明明已经进入待机状态，动画还在播走路，看起来特别假。
我习惯的做法是：在状态切换的代码位置同时发送动画参数，比如：
private void SetState(BotState newState) { currentState = newState; animator.SetBool("IsMoving", currentState == BotState.Patrol); }Animator的Transition再根据IsMoving和IsTurning这类布尔值跳转。要注意的是：
- 转身动画的时长最好和
HandleTurn里的stateTimer一致，这样视觉和逻辑不脱节。 - 不要让Animator的动画直接修改Sprite的朝向，动画只负责播放，朝向交给代码里的
flipX控制，互不干扰。
6. 实测中反复踩到的四个坑和解决办法
6.1 FixedUpdate里用了Time.deltaTime
C#新手特别容易犯这个错，包括我也犯过：把移动代码写在FixedUpdate里，却用Time.deltaTime计算增量。但FixedUpdate的调用频率不一定等于渲染帧率，应该用Time.fixedDeltaTime配合。
如果你用rb.velocity设置速度，根本不涉及增量时间，所以不容易出错。但如果你用transform.Translate写在FixedUpdate里又用Time.deltaTime，移动距离就会忽快忽慢。
规则很简单：
Update里用Time.deltaTimeFixedUpdate里用Time.fixedDeltaTime- 物理移动尽量放
FixedUpdate
6.2 射线过滤不彻底导致误折返
我在做射线检测时遇到过一个很隐蔽的问题：射线并不是只检测到地面，而是把机器人自己的子物体（比如脚底阴影、脚下的武器碰撞体）也当成地面了。结果就是射线永远能打中东西，机器人永远不会在边缘折返，直直地走下平台。
解决办法是：给地面单独设一个Layer，比如Ground，然后在检测时传groundLayer，只让射线和这个Layer发生交互。这一步不只是为了性能，更重要的是逻辑严谨——你不希望机器人因为一个飘过的粒子特效或者另一个碰撞体而误判边界。
public LayerMask groundLayer; // 在Inspector中把groundLayer设置为Ground层6.3 机器人卡在平台缝隙和墙角
如果你的关卡是多个小平台拼接的，平台之间难免有肉眼看不见的微小缝隙。机器人的射线检测点如果恰好落在缝隙上方，会检测不到地面而突然转身，表现成在平台上"神经质地抽搐"。
这是射线检测方案无法完全避免的问题。我的缓解办法是把groundCheckPoint的位置稍微向移动方向前方偏移一点，并且把groundCheckDistance适当调大，让射线不容易落入细小的缝隙里。
另外，在墙角转弯时，如果直角墙根处有很小的碰撞体边缘，也可能让机器人反复左右折返。解决办法是给墙角加一个轻微倒角，或者在转向逻辑里加一个最短转向间隔——比如0.3秒内不允许再次转向：
private float lastTurnTime; private void Flip() { if (Time.time - lastTurnTime < 0.3f) return; direction *= -1; lastTurnTime = Time.time; }这个小技巧在很多需要防抖的场景都有效。
6.4 高速巡游时的穿透问题
机器人速度调太快（比如5m/s以上），再加上薄墙，穿模概率会显著增加。这个问题的根源是物理引擎默认的碰撞检测模式在高速移动时会产生"隧道效应"。
解决办法：
- 把
Rigidbody2D.CollisionDetectionMode设置为Continuous，它会让物理引擎更细地检测移动轨迹上的碰撞。 - 把
Interpolate设置为Interpolate，让渲染更平滑，减少视觉上的抖动。 - 如果还不够，就用射线检测墙壁提前折返，让机器人永远有机会在真正碰到墙之前掉头。
本质上，巡游机器人属于"已知路径循环移动"的类型，射线检测兜底永远比单纯依赖碰撞事件靠谱。
7. 最后再分享一点实现体会
做这个Unity 2D机器人巡游功能，让我收获最大的不是代码本身，而是逐渐养成了一套调试思路：先把移动方式定下来（物理驱动），再把边界条件定下来（射线优先），最后把行为状态拆开（状态机）。按照这个顺序走，哪怕需求后面再怎么变，基础结构都不会散架。
如果你现在正被"机器人走着走着掉下平台""撞墙后卡住狂抖""转向后动画朝向不对"这些问题折磨，我建议你回到这一篇，从第2部分的移动方式开始自查。八成的问题都出在最底层的两个选择上：你是不是用了Transform位移却挂着刚体，或者你是不是根本没想清楚边界由什么决定。
巡游是2D AI的地基，把这个地基打牢了，后面你做再复杂的AI行为，心里都会特别有底。
