Unity贪吃蛇实战：协程、状态机与碰撞检测的完整设计

读书人钱金铎·2026-08-29·阅读 22 GEO检测（免费）

Unity贪吃蛇协程

|难度：普通|阅读约 39 分钟

做Unity项目一年多了，回头再看贪吃蛇这种入门项目，反倒觉得它是把“游戏循环、输入管理、碰撞检测、状态机、数据组织”这些基本功一次性串起来的最佳练习。市面上的教程很多，但大多只把代码贴一遍，却没讲清楚为什么这么写。这篇笔记不打算重复那些烂大街的步骤，而是把我自己在复刻贪吃蛇过程中踩过的坑、反复调整过的设计，以及最后落地的完整思路，按一个可参考的实战路径记录下来。

1. 为什么用Unity复刻贪吃蛇，而不是用纯代码写一个

1.1 贪吃蛇项目能练到的Unity核心能力

很多人觉得贪吃蛇逻辑简单，用C语言、JavaScript控制台都能写，没必要上Unity。但换个角度想，纯代码版只能验证“算法逻辑”，而Unity版本要处理的东西多了整整一个维度：输入响应、游戏循环节奏、物体实例化、碰撞检测、UI状态切换、视觉反馈、场景搭建，甚至发布到不同平台时的适配问题。这些恰恰是做一个正式游戏绕不开的环节。

Unity里做贪吃蛇，我建议的目标不是“把逻辑跑通”，而是把它当成一个小型可发布的完整游戏来做。也就是说，它要有开始界面、游戏进行态、暂停态、结束态，有分数反馈、有重新开始入口、有合理的视觉层级、运行流畅度可控。这样一来，知识点就密集了，练完这个项目，再去碰那些带角色控制、带养成系统、带商业化的项目，很多思路是相通的。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

1.2 Unity版和纯代码版的本质区别在哪里

纯代码的贪吃蛇，操作对象是数组或链表里的坐标数据，画面上每一帧把数据重新渲染一次。Unity版则完全不同，它默认用场景中的GameObject来代表每一个蛇身节点，用场景里挂载的Collider来做碰撞检测，用协程或计时器来控制移动节奏，用UI组件来显示分数。坐标数据和渲染对象之间是分离的，但又通过组件关联在一起。

这种“场景对象 + 数据驱动”的方式，一开始会让人觉得绕，但理解了就明白，Unity就是把游戏里“逻辑”和“表现”两层拆开了：逻辑层记录方向和身体位置，表现层用Cube或Sprite把位置可视化。我见过很多新手在这个项目里把代码全写在Update里，导致移动速度和帧率挂钩，不同设备上体验完全不同。这个问题的根源，就是没理解Unity游戏循环的运作方式。所以复刻贪吃蛇，本质上是在理解“在Unity的框架里，怎么把实时游戏的逻辑收拢好”。

2. 项目整体设计：先想清楚这三个核心问题

2.1 网格坐标系：让蛇的移动“对齐格子”

贪吃蛇的移动天然是离散的，蛇头每次沿一个方向移动一个固定距离。这里最关键的起步决定是：把移动单位设置为1，让场景里的位置都落到整数网格上。否则蛇头移动方向和身体跟随会出现对不齐、穿模、看似卡顿的视觉问题。

有两种实现方式：一种是直接在2D平面上做，把所有物体放在同一Z轴，用Sprite或Quad表现；另一种是用3D场景，从正上方用正交相机俯视。两者在逻辑上没差别，差别只在表现层。我的建议是新手先用3D场景里的Cube搭，不需要美术素材，一个默认Cube改改了Scale就是蛇身，一个Cube放大压扁就是地面，几面白墙就是边界。这个项目完全不需要考虑面数规范，Primitive自带的面数足够低，不会对性能有任何压力。

实际操作时，我倾向于把坐标锚定在整数网格上，比如蛇头初始位置是(0,0,0)，向右移动一格后变成(1,0,0)，每一次移动的方向向量只能是(1,0,0)、(-1,0,0)、(0,1,0)、(0,-1,0)四选一。这样碰撞判断就退化成了位置比较，两个点相等就说明发生了重叠。这个模型非常干净，可以避免后续用浮点坐标累积误差导致的身体对不齐。

2.2 两种身体跟随方案：逐节跟随和历史轨迹

蛇的身体跟随是这个项目最核心的算法问题，思路直接影响代码量级和扩展性。我见过的主流实现有下面两种。

方案一是逐节跟随：蛇头移动后，每一节身体都移动到前一节原来的位置。好处是直观，写起来短，坏处是实现时必须小心，不能让位置数据在循环中被提前污染，否则整条蛇会缩成一团或者“瞬移”到失控。方案二是记录历史轨迹：每移动一步，就把蛇头到达过的最新位置压进一个队列，身体的第N节就去取队列前面对应位置的数据。这个方案的好处是代码稳定，尤其适合以后扩展“蛇尾延迟”“残影”“拖尾”等效果时，直接复用历史数据；坏处是需要维护一个列表，多几行内存操作。

这两种方案我都试过，最终的体会是：求稳就选历史轨迹法，它天然避免了对“上一节位置已被覆盖”这类问题的焦虑。特别是当蛇身达到几十节以后，逐节跟随的某个微小浮点偏差会被逐步放大，画面看起来就感觉蛇在抖。历史轨迹法里每节只负责取一个确定坐标，位置数据全程无中间传递，稳定得多。

2.3 为什么用协程而不是Update

这是新手最容易忽略的坑。很多人习惯把所有逻辑塞进Update，然后觉得移动速度跟帧率挂钩：60帧的机器蛇跑得快，30帧的机器蛇跑得慢，同一个游戏在不同设备上手感完全不一致。解决方式有两个：要么用Time.deltaTime累加计时，要么用协程里的WaitForSeconds。

相比在Update里手写计时器，协程的写法更直观，启动一个无限循环，每次等待固定秒数后执行一次移动。代码读起来和思路完全一致，也方便在游戏结束、暂停时直接停掉协程。我选择协程的另一个原因是，它把“移动节拍”和“输入监听”天然分开了：输入在Update里持续监听，移动在协程里按固定节奏执行，互不干扰。这也更符合真实游戏的架构习惯——逻辑层不依赖帧率，表现层的动画和输入才走Update。

不过要注意，WaitForSeconds在等待过程中不会响应你中途修改的等待时间。也就是说，如果分数提升导致移动间隔从0.2秒变成0.15秒，正在等待的那一次仍然按0.2秒结束后，下一次才会用0.15秒。这个问题不大，甚至会让加速效果感知上更平滑。如果你追求极致精确，可以改成用Time.deltaTime累加的方案，但代码会稍微复杂一点。

3. 移动逻辑的核心实现：从数据到物体的映射

3.1 蛇的数据模型：用方向枚举和位置列表组织数据

我把蛇的移动抽象成三个数据：方向枚举、蛇头位置、身体节点历史位置列表。先定义方向枚举，它让代码的可读性比直接用Vector3加减高很多，也方便后面做防反向判断。

csharp复制public enum MoveDirection
{
    Up,
    Down,
    Left,
    Right
}

在控制器里，我维护了以下几个字段：

csharp复制public class SnakeController : MonoBehaviour
{
    public GameObject segmentPrefab;
    public Transform headTransform;
    public float moveInterval = 0.2f;

    // 蛇头的当前位置
    private Vector3 headPosition;

    // 记录蛇身节点，索引0代表第一节身体，以此类推
    private List<Transform> bodySegments = new List<Transform>();

    // 记录蛇头经过的历史坐标，用于身体跟随
    private List<Vector3> historyPositions = new List<Vector3>();

    private MoveDirection currentDirection = MoveDirection.Right;
    private MoveDirection nextDirection = MoveDirection.Right;
    private bool inputLocked = false;
}

最开始我直接用Transform.position做运算，后来发现每次读位置再改逻辑，容易和实际场景对象耦合。改成把蛇头坐标单独存成Vector3，每一帧移动后同步到transform上，逻辑更清晰。这个数据模型的好处是，后面做存档、回放、碰撞检测，都可以直接基于Vector3和枚举运算，不需要碰场景对象。

这里要补充一个细节：身体节点列表里存的是Transform引用，而不是坐标。原因是移动身体时直接改Transform.position最高效，但如果以后要做更复杂的数据驱动架构，可以考虑把坐标单独存一份。贪吃蛇这个项目里，直接存引用完全够用。

3.2 协程驱动的移动主循环

移动主循环是游戏的心脏，整个蛇的移动按固定间隔运行，直到游戏结束或暂停才停止。我把它单独封装成一个协程，方便精确控制启停。

csharp复制private IEnumerator MoveLoop()
{
    while (true)
    {
        yield return new WaitForSeconds(moveInterval);
        MoveSnake();
        CheckCollision();
    }
}

MoveSnake负责把蛇头往前推一格，再把身体各节依次更新到位。这里我采用了“先记录全体旧位置，再统一更新”的写法，避免循环中位置互相覆盖：

csharp复制private void MoveSnake()
{
    // 1. 在真正移动前，应用用户预存的下一步方向
    currentDirection = nextDirection;

    // 2. 记录所有位置旧值
    Vector3 oldHeadPos = headTransform.position;
    Vector3[] oldBodyPos = new Vector3[bodySegments.Count];
    for (int i = 0; i < bodySegments.Count; i++)
        oldBodyPos[i] = bodySegments[i].position;

    // 3. 蛇头向前进一格
    headPosition += GetDirectionVector(currentDirection);
    headTransform.position = headPosition;

    // 4. 身体跟随：第一节去蛇头旧位置，第二节去第一节旧位置，以此类推
    for (int i = 0; i < bodySegments.Count; i++)
        bodySegments[i].position = (i == 0) ? oldHeadPos : oldBodyPos[i - 1];
}

GetDirectionVector就是把枚举映射成方向向量：

csharp复制private Vector3 GetDirectionVector(MoveDirection dir)
{
    switch (dir)
    {
        case MoveDirection.Up: return Vector3.up;
        case MoveDirection.Down: return Vector3.down;
        case MoveDirection.Left: return Vector3.left;
        case MoveDirection.Right: return Vector3.right;
        default: return Vector3.right;
    }
}

这个方案的亮点是“全部旧坐标一次性记下后统一写入”，彻底规避了逐节循环中由于先更新了第一节、再更新第二节时引用到已被修改数据的风险。这也是我踩坑之后才意识到必须改成这种写法的，后面会详述。

3.3 吃食物变长：这里的插入顺序必须注意

贪吃蛇吃到食物后会变长，变长的实现方式决定了代码是否容易出Bug。常见做法是，在移动结束、且检测到和食物位置重叠时，在蛇尾后面增加一个新节点。

问题在于节点加入的时刻。如果你在移动结束后追加，那么新节点本来就该出现在蛇尾之后；如果你在移动前追加但没调整历史位置，新节点会出现在原地不动的位置，看起来像多出一块“浮空身体”。

我的做法是：在MoveSnake完成后单独走一个EatFood判断。如果吃到了，就在身体节点列表的末尾添加一个新段，并把它放在当前蛇尾的旧位置上。因为移动后所有身体已经就位，这个旧位置正好是整条蛇最后停留的位置，视觉上会自然形成“尾部多了一节”的效果。

csharp复制private void AddSegment()
{
    Vector3 tailPos = bodySegments.Count > 0
        ? bodySegments[bodySegments.Count - 1].position
        : headTransform.position;

    Transform newSegment = Instantiate(segmentPrefab, tailPos, Quaternion.identity).transform;
    bodySegments.Add(newSegment);
}

这里还要注意方向问题。给身体赋旋转时，如果蛇身用Cube表现，默认旋转没关系；但如果用了带纹理的Sprite，就需要根据这段身体相对于前一段的方向来设置旋转，这是让视觉表现整齐的关键。

4. 输入、碰撞与食物生成：新手最容易栽的地方

4.1 输入缓冲：解决“快速按两个方向导致反向自撞”

输入处理是贪吃蛇项目最反直觉的地方之一。看着很简单，就是上下左右控制方向，但实际运行时经常出现这种情况：蛇正往右走，你快速依次按了“上”和“左”，因为两次按键都发生在同一帧或者同一移动间隔内，程序收到“上”后立即生效，紧接着又收到“左”，蛇直接掉头往左，撞上自己。

这个问题的本质是输入监听的即时处理和移动逻辑的离散节拍不一致。解决办法是引入“待执行方向”的概念：Update里只记录下一个预期的方向，但要先判断它是否和当前方向相反；MoveSnake一开始才把待执行方向真正应用到蛇头上。这样同一移动节拍内多次按键不会互相覆盖，也不会出现反向自撞。

csharp复制private void Update()
{
    // 这里只设置nextDirection，不直接改currentDirection
    if (Input.GetKeyDown(KeyCode.W) || Input.GetKeyDown(KeyCode.UpArrow))
        TrySetDirection(MoveDirection.Up);
    else if (Input.GetKeyDown(KeyCode.S) || Input.GetKeyDown(KeyCode.DownArrow))
        TrySetDirection(MoveDirection.Down);
    else if (Input.GetKeyDown(KeyCode.A) || Input.GetKeyDown(KeyCode.LeftArrow))
        TrySetDirection(MoveDirection.Left);
    else if (Input.GetKeyDown(KeyCode.D) || Input.GetKeyDown(KeyCode.RightArrow))
        TrySetDirection(MoveDirection.Right);
}

private void TrySetDirection(MoveDirection newDir)
{
    // 不允许直接反向
    if (IsOpposite(currentDirection, newDir))
        return;

    nextDirection = newDir;
}

判断反向的逻辑非常简单：

csharp复制private bool IsOpposite(MoveDirection a, MoveDirection b)
{
    return (a == MoveDirection.Up && b == MoveDirection.Down)
        || (a == MoveDirection.Down && b == MoveDirection.Up)
        || (a == MoveDirection.Left && b == MoveDirection.Right)
        || (a == MoveDirection.Right && b == MoveDirection.Left);
}

要注意的是，这个反向判断必须基于currentDirection，而不是nextDirection。如果基于nextDirection判断，又会出现连续两次转向绕过限制的问题。比如当前向右，用户输入“上”，nextDirection变成“上”；紧接着输入“左”，如果拿nextDirection（上）来判定，左和上不反向，就会放行，结果蛇头最终往左，而它上一刻实际还没往左，视觉上可能从“正要往上”突然变成“往左”，也被接受，但如果你不允许这种半拍内的二次变向，就会更稳妥。更严格的方案是再加一个输入锁，在每次移动执行后解锁，移动前锁定。这个细节可以根据你想要的手感来取舍，但对贪吃蛇来说，锁定在“上一次移动节拍内只接受一次转向”会让手感更稳。

4.2 碰撞检测：撞墙、撞身体、吃食物

碰撞检测有两条路线：一是依赖Unity的Collider和OnTriggerEnter，二是自己在代码里做坐标比较。两条路我都走过，最终建议是：这个项目完全用坐标比较，不需要给蛇身加Collider。

原因有二。第一，物理碰撞检测在这个项目里有些“杀鸡用牛刀”，蛇只用到了“两个坐标是否相等”这一件事，没必要让物理引擎参与；第二，采用坐标比较后，碰撞检测不依赖场景里的Collider配置，边界可以做成不可见数据常量，发布到不同平台时逻辑统一。

撞墙检测比较简单，我预定义了四边边界值，每次蛇头移动后判断坐标是否超出：

csharp复制private bool IsOutOfBoundary(Vector3 pos)
{
    return pos.x < minX || pos.x > maxX || pos.y < minY || pos.y > maxY;
}

撞自己则是遍历身体节点：

csharp复制private bool IsCollideWithSelf(Vector3 pos)
{
    for (int i = 0; i < bodySegments.Count; i++)
    {
        if (bodySegments[i].position == pos)
            return true;
    }
    return false;
}

这里有一个细节：判断撞自己时，蛇头和第一节身体的位置在移动时天然会相邻，如果移动后蛇头位置和第一节身体位置相等，这是不是算碰撞？很多实现里容易误判。比如蛇头从(2,0)移到(3,0)，第一节身体从(1,0)移到(2,0)，蛇头(3,0)和第一节(2,0)不重合，就没有误判。但如果蛇身的排列本身就是一条直线上连续几个坐标，蛇头移动后和第二节等远距离节点重合，那确实是碰撞。按照“位置严格相等”来判断，基本能覆盖所有真实碰撞情况。

4.3 食物生成：别让食物落进蛇身体里

食物生成表面上是随机取坐标，实际需要注意两个点：坐标必须在网格内，且不能和蛇身任何一段重合。

我初始写的版本是直接在合法网格内Random.Range，结果偶尔会看到食物生成到蛇身上，然后被蛇“瞬移吃掉”，体验很奇怪。后来我改成“候选坐标列表 + 排除蛇身占用”的方案：

csharp复制private Vector3 GenerateFoodPosition()
{
    List<Vector3> candidates = new List<Vector3>();

    for (int x = minX; x <= maxX; x++)
    {
        for (int y = minY; y <= maxY; y++)
        {
            Vector3 pos = new Vector3(x, y, 0);
            bool occupied = false;

            foreach (Transform segment in bodySegments)
            {
                if (segment.position == pos)
                {
                    occupied = true;
                    break;
                }
            }

            if (headTransform.position == pos)
                occupied = true;

            if (!occupied)
                candidates.Add(pos);
        }
    }

    if (candidates.Count == 0)
        return Vector3.zero;

    return candidates[Random.Range(0, candidates.Count)];
}

这个方法在网格不大（比如20x20）时非常直接。如果以后地图变得很大，比如1000x1000，遍历所有坐标就低效了，可以改成先随机撞运气尝试N次，不行再遍历。但贪吃蛇项目里根本不用担心这个性能问题，简单可靠就好。

5. 升级版功能实现：重新开始、加速和UI状态机

5.1 用游戏状态机管理Ready、Playing、Paused、GameOver

我在第一版代码里是靠一组bool变量控制游戏流程的，比如isPlaying、isPaused、isGameOver，写到后面发现它们之间的组合越来越乱。吃食物时该不该加分？游戏结束按空格该不该重开？暂停时协程继续跑怎么办？这些问题靠bool根本理不清。

后来我引入了简单的状态机：

csharp复制public enum GameState
{
    Ready,
    Playing,
    Paused,
    GameOver
}

核心逻辑按状态分流。比如输入监听只响应Ready和Playing这两种状态；移动协程只在Playing时运行；Paused状态下协程暂停更新、UI显示暂停文本；GameOver状态弹出重新开始按钮。状态切换时统一处理事件，比如进入Playing就重置所有数据、启动协程，进入Paused就停协程。

这样做的好处是，每个功能的触发条件一目了然，不会再出现“明明是游戏结束界面，蛇还在动”的诡异现象。特别是当你想加“重新开始按钮”，没有状态机时很容易把重置逻辑重复写三四遍，状态机只需要在Ready和GameOver的某个入口调用一次ResetGame。

5.2 重新开始按钮：重置数据不能漏掉任何一项

“重新开始”是热搜里频繁提到的一个新增功能，实现起来看似简单，却特别容易漏东西。我踩过的坑是：只重置了蛇头位置和身体节点，却忘了清理历史位置列表，导致重新开局后身体节点跟着乱飞。

完整的重置逻辑应该是：

csharp复制private void ResetGame()
{
    // 停止当前移动协程，防止重置过程中又移动了一次
    StopAllCoroutines();

    // 销毁所有已有身体节点
    foreach (Transform segment in bodySegments)
    {
        if (segment != null)
            Destroy(segment.gameObject);
    }
    bodySegments.Clear();
    historyPositions.Clear();

    // 蛇头回到初始位置
    headTransform.position = Vector3.zero;
    headPosition = Vector3.zero;

    // 方向重置
    currentDirection = MoveDirection.Right;
    nextDirection = MoveDirection.Right;

    // 分数重置
    score = 0;
    UpdateScoreUI();

    // 重新生成初始的三节身体
    for (int i = 0; i < initialBodyCount; i++)
        AddSegment();

    // 重新生成食物
    SpawnFood();

    // 设置游戏状态
    ChangeState(GameState.Playing);

    // 重新启动移动协程
    StartCoroutine(MoveLoop());
}

重置顺序也有讲究，先销毁旧节点、再重建新节点，不然节点列表里混着旧引用，后面操作就会报错。我建议把这段逻辑单独封装成一个函数，不管是从按钮触发，还是从GameOver后的键盘按键触发，都统一调用，不要各处复制代码。

5.3 分数越高速度越快：移动间隔的动态调整

“分数越高速度越快”听起来是改一个数值的问题，但其实影响的是整个游戏手感曲线。如果用线性加速，比如每吃一个食物间隔减少0.002秒，那到30分以后间隔就趋近于0，游戏变成几乎不可能操作。所以需要对速度变化做限制。

我用的公式是：

csharp复制private void UpdateSpeed()
{
    float interval = baseInterval - score * speedFactor;
    moveInterval = Mathf.Max(interval, minInterval);
}

baseInterval是初始间隔，比如0.2秒；speedFactor是每次吃食物减少的秒数，比如0.002；minInterval是最小间隔，比如0.05秒。这样速度不会无限制加快，保证了可玩性。

这个曲线在不同难度下都可以调节，实际上就是一份难度参数表。想做不同关卡时，把baseInterval和speedFactor配置成可序列化字段，就能在Inspector里直接微调，不用改代码。

6. 场景搭建与视觉手感优化

6.1 摄像机设置：正交俯视视角

贪吃蛇的视角本身不需要透视效果，我建议直接用正交相机，从Z轴正方向看向负方向，场景所有物体放在Z=0的平面上。相机设为正交后，就不会出现远处的物体变小、近处的物体变大这类透视干扰。

我的相机参数参考如下：

Projection: Orthographic
Size: 12（根据地图大小调整）
Position: (0, 0, -10)
Background: 深色背景或纯色

如果你做的是大地图，蛇移动范围超过一屏，就需要考虑“摄像机跟随”的问题。两种方案：一种是固定视野，蛇在边界内活动，永不越界；另一种是摄像机跟随蛇头，背景是一个更大的地图。对入门项目来说，第一种更省事，也不会暴露地图拼接和视野管理的复杂性。如果一定要做跟随，可以用平滑跟随的写法：

csharp复制private void LateUpdate()
{
    Vector3 target = snakeHead.position;
    target.z = cameraTransform.position.z;
    cameraTransform.position = Vector3.Lerp(cameraTransform.position, target, 0.1f);
}

用LateUpdate而不是Update，是为了让相机在蛇头移动完成后再跟随，避免出现一帧的延迟抖动。

6.2 蛇身视觉：用颜色和简单材质区分头部与身体

这个项目不需要美术素材，直接用Primitive的Cube就能表达。但为了让画面更清晰，我把蛇头设置成“稍大的Cube”或者“不同颜色的Cube”，身体则用统一的正常尺寸Cube。两种颜色选取对比度高的搭配，比如蛇头亮绿色，身体深绿色，食物红色，背景深灰。

这里有个经验：地面不要做得太亮，否则高亮的蛇身和食物会看不清边界。我习惯用暗色背景配合发光或饱和度高的物体颜色，对比度一下子就出来了。

如果你觉得纯Cube太单调，可以把蛇头替换成Capsule，或者给材质设置不同的Emission自发光，让默认着色器下的物体更有质感。这都不影响逻辑，纯粹是表现层的小技巧。以后再想加材质、加描边效果，都可以在这层扩展。

6.3 手感调优：从移动间隔到输入宽容度

手感这个东西，看似主观，其实是可量化、可调优的。贪吃蛇的核心手感因素就两个：移动间隔和输入响应窗口。

移动间隔决定了游戏的节奏。0.2秒一移动是比较舒适的中速，新手能跟上；0.1秒就是明确的高难度了。我建议把这个参数做成public字段，在Inspector里直接调整，用不到一分钟就能找到适合目标玩家的节奏。

输入响应窗口则是指，在两次移动之间，是否允许预存按键。我的做法是维护nextDirection，用户在任何时刻按键都记录到nextDirection，下一次移动时生效。这样即使玩家在移动节拍的“后半段”按了方向键，也不会错过，游戏感受会更跟手。如果你不做输入缓冲，玩家快速操作时就会觉得“按了没反应”，这是最常见的手感差原因。

7. 常见问题与排查实录

7.1 蛇身抖动、断裂、折叠：位置更新的顺序问题

蛇身最经典的Bug就是抖动和折叠。有一次我把移动代码写成：

csharp复制for (int i = 1; i < bodySegments.Count; i++)
{
    bodySegments[i].position = bodySegments[i - 1].position;
}

运行起来整条蛇缩成了一团。原因很简单：循环从左往右更新，第一节先被更新到了蛇头旧位置，等循环到第二节时，取到的bodySegments[1-1]已经不是第一节的旧位置了，而是更新后的新位置，相当于第二节直接跳到了蛇头附近。如此循环下去，整条蛇全部塌缩到蛇头旧位置附近。

解决办法要么像我前面那样“先存旧位置，再统一更新”，要么从尾到头倒序遍历。从尾到头能行，但代码可读性略差，而且一旦以后加“每节独立延迟”，这种写法就不够灵活了。综合来看，“记录旧位置数组”是最稳妥的通用方案。

7.2 食物一直生成在蛇身上：随机范围没考虑占用网格

另一个高频问题就是食物和蛇身重叠。表现为蛇头经过食物所在格时，没有触发得分，或者食物刚生成就消失了。根源是随机坐标时只做了边界判断，没排除蛇身网格。

在这个项目里，候选坐标列表方案虽然代码多一点，但绝对可靠。还有一个优化点：用HashSet或Dictionary记录已占用坐标，判断会更快，也能避免重复遍历。比如蛇身有50节、地图400格时，逐格子遍历并且每个格子检查50次，性能也能接受；但如果地图更大，用HashSet能把随机生成食物的复杂度降下来。我建议进阶版本把这条优化做上，这也是从“能用”到“好用”的一次跨越。

7.3 协程重复启动导致蛇越走越快

这是协程写法一个隐蔽的坑。我在加“重新开始”功能时，因为只调用StartCoroutine(MoveLoop())却没有先StopAllCoroutines，导致每次点击重新开始都会再启动一个新的移动协程。旧协程没停，新协程又起，蛇每帧移动次数翻倍，速度越来越快，最终直接失控。

所以任何可能被重复调用的启动逻辑里，先执行StopAllCoroutines总没错。如果你用的是Update+Deltatime计时器，也要小心计时器变量没归零导致类似问题。

7.4 性能隐忧：蛇身长了之后Draw Call变多怎么办

贪吃蛇如果只用默认简单材质，蛇身数量几十节时，Draw Call会随着蛇身数量上涨。这对PC端可能没感觉，但如果目标平台是移动端或微信小游戏，就要留意。

解决方案有几个思路：一是所有蛇身共享同一个材质，尽量让引擎合批；二是用GPU Instancing，把每节的位置、旋转以实例数据方式提交，而不是独立GameObject；三是更进一步，直接用一个Mesh，在顶点层级控制所有节的立方体位置。这三种方案复杂度递增，但优化原理是一样的：把“多个物体的重复渲染请求”合并成“一次渲染请求”。

对入门项目来说，我建议先了解思路，不必在这个阶段过度优化。但如果你做的是超休闲游戏，准备投放到小游戏平台做广告变现，这个优化点就是必须考虑的，因为它直接影响包体和运行帧率，进而影响玩家留存和广告展示效果。

7.5 发布和真机测试要注意的几个点

如果打算把贪吃蛇发布到手机端，有几个小问题提前知道能省很多时间。一是默认的横竖屏设置，要在Player Settings里配好；二是移动端触摸输入要额外写一套响应逻辑，不能依赖鼠标键盘；三是小游戏平台打包时，要注意IL2CPP裁剪对代码的影响，个别反射相关操作可能会被裁掉。

我在真机测试时还遇到过分辨率适配问题，Canvas里的按钮在不同分辨率的屏幕上位置偏移。解决方法是让UI根节点用CanvasScaler配合“按屏幕尺寸缩放”的模式，并选择以宽度或高度为基准做缩放。这个配置在项目开始时就设好，后面省去很多调整成本。

结尾

这个项目我自己复刻过两遍，第一遍是跟着教程敲，第二遍是丢掉教程强制自己从设计到实现完整走一遍。第二遍的收获明显大于第一遍，因为只有在独立思考时，才会意识到输入缓冲、重置顺序、协程重复启动这些坑到底为什么存在。如果你也是Unity新手，我建议拿到这篇笔记后，不要只是复制代码，而是先自己尝试设计数据结构，在踩坑之后再对照这篇内容排查，收益会大得多。最后想说的是，贪吃蛇虽然古老，但它作为训练“游戏感”的载体完全不落伍，把细节打磨到你满意为止，你会发现自己对Unity整体架构的理解已经悄悄跨过了一个台阶。