Unity贪吃蛇开发实战：网格坐标、碰撞检测与状态机设计

1. 项目整体拆解与思路复盘

贪吃蛇这个项目，乍一看像是Unity入门教程里的“Hello World”，但真正动手做完一遍，我发现它的信息密度比想象中大得多。一个完整的贪吃蛇涉及坐标系统、输入处理、定时器、链表数据结构、碰撞检测、UI事件、音效管理、生命周期管理等模块，几乎把Unity 2D游戏开发的核心知识点全部串了一遍。

我这次使用的是Unity 2021.3 LTS版本。之所以选LTS而不是最新版本，原因很简单：稳定。做学习项目时最怕的不是功能做不出来，而是编辑器本身出各种莫名其妙的编译错误、导入错误，LTS版本经过长期社区验证，网上能搜到的解决方案也更全面。如果你用的是Unity 6或2022、2023版本，本笔记的核心代码逻辑完全通用，不需要做额外调整。

先说一下项目目标。我做这个项目时给自己定了三个标准：

• 核心玩法完整：蛇能移动、吃食物、增长身体、碰撞自身或边界后游戏结束，这是贪吃蛇的底线功能。
• 代码结构清晰：不能全部逻辑堆在一个脚本里，至少要拆成“移动控制”“身体管理”“食物生成”“游戏流程控制”几个模块，方便后续扩展和复用。
• 手感舒服：移动不能太生硬，要有一定的节奏感和响应性，这涉及输入缓冲和移动节流的处理。

很多初学者做贪吃蛇时会犯一个典型的错误：把蛇的移动做成“按住方向键就一直加速移动”的连续物理移动。这种做法的结果就是蛇跑得飞快，玩家根本来不及反应，而且蛇身的跟随效果很难用物理引擎做出漂亮的“方块贴方块”效果。贪吃蛇的核心应该是“格子间的跳变”，不是“平滑位移”——每格移动是一次完整的坐标跳转，然后再配合插值做视觉平滑。想清楚这一点，后续的代码实现思路就清晰了。

在动手写代码之前，我还做了一个很重要的决定：项目完全使用Unity原生UI和2D物理系统，不引入任何第三方插件。原因有两个：一是贪吃蛇这种项目本身就适合练习原生API的熟练度，二是第三方插件（比如各种输入系统插件、Tween插件）会掩盖对底层逻辑的理解。等核心逻辑吃透了，再考虑用DOTween这类插件优化动画表现，那是另一个阶段的事。

2. 网格化坐标系统与移动机制设计

2.1 为什么贪吃蛇必须用网格坐标

贪吃蛇游戏最关键的设计决策是坐标系统。我第一次做的时候没想太多，直接用Transform.position移动蛇头，蛇身用List存储每次移动的历史位置。结果发现一个严重问题：蛇身无法准确对齐到固定格子，因为蛇头的移动速度、方向变化时机稍有偏差，蛇身记录的位置就会产生偏差，看起来像“飘”而不是“爬”。

正确的做法是把整个游戏区域抽象成一个二维网格，蛇头每次移动固定步长（比如1个单位），蛇身记录的也是网格坐标而不是世界坐标。这样做有三个好处：

• 移动逻辑清晰：每次移动只需要改变一个整型坐标值，方向控制就是坐标增量的变化。
• 碰撞检测简单：只需要判断坐标是否越界，以及蛇头坐标是否和蛇身某个坐标相等。
• 扩展性好：后续做地图编辑器、障碍物、穿墙模式，只需要修改网格数据，不需要动移动逻辑。

我在实现时定义了一个简单的坐标结构：

csharp复制public struct GridPos
{
    public int x;
    public int y;
    
    public GridPos(int x, int y)
    {
        this.x = x;
        this.y = y;
    }
    
    public static GridPos operator +(GridPos a, GridPos b)
    {
        return new GridPos(a.x + b.x, a.y + b.y);
    }
    
    public static bool operator ==(GridPos a, GridPos b)
    {
        return a.x == b.x && a.y == b.y;
    }
    
    public static bool operator !=(GridPos a, GridPos b)
    {
        return !(a == b);
    }
}

建议不要直接用Vector2Int来存网格坐标，虽然看起来省事，但是Vector2Int没有可读性好的运算符重载，而且当你需要扩展网格类型（比如增加“障碍物标记”“道具标记”）时，自定义结构体的扩展空间更大。这个结构体后续可以直接作为字典查找的Key，非常方便。

2.2 移动节流：定时跳变而不是每帧位移

确定了网格坐标系统之后，下一个问题是：蛇什么时机移动一格？

典型做法有两种：

• 每帧检测输入，但只有累积时间超过“移动间隔”才执行移动逻辑。
• 使用协程或Update中的计时器，每个移动间隔触发一次移动。

核心做法是用一个“移动计时器”控制移动节拍。我在Update中写了一个非常简单但可靠的计时计数逻辑：

csharp复制private void Update()
{
    HandleInput();
    
    _moveTimer += Time.deltaTime;
    if (_moveTimer >= _moveInterval)
    {
        _moveTimer -= _moveInterval;
        MoveSnake();
    }
}

这里的_moveInterval就是“每移动一格需要的时间”。我把这个值设计成可调参数，在Unity Inspector中暴露出来，建议初始值设为0.2秒，这个节奏比较适合普通玩家——太快初学者反应不过来，太慢又会觉得无聊。分数每增加一定值（比如每吃5个食物），就把移动间隔减小0.01秒，形成“速度越来越快”的压迫感。

需要特别注意的是，这种“先累加再减掉”的写法比“直接归零”更精准。如果写成_moveTimer = 0，每一帧浮点数的精度损失会被累积起来，长时间运行后移动节拍会变慢，这个细节虽然短时间内感觉不到，但追求严谨时可以这样处理。

2.3 移动方向与输入防抖逻辑

贪吃蛇的输入系统有一个经典问题：玩家在短时间内快速按了两个方向键，比如先按上再按左，如果两次输入都被立即接收，蛇会先向上移动一格再向左移动一格，但如果上一帧蛇正在向右移动，“向上”这个指令是合法的（因为垂直方向），而紧接着的“向左”就会和当前实际方向“向右”产生冲突——蛇会直接穿过自己的身体。

为了防止这种情况，我维护了一个“待处理方向”队列，而不是直接修改当前方向：

csharp复制private Queue<GridPos> _directionQueue = new Queue<GridPos>();
private GridPos _currentDirection = new GridPos(1, 0); // 初始向右

private void HandleInput()
{
    if (Input.GetKeyDown(KeyCode.W) || Input.GetKeyDown(KeyCode.UpArrow))
    {
        EnqueueDirection(new GridPos(0, 1));
    }
    else if (Input.GetKeyDown(KeyCode.S) || Input.GetKeyDown(KeyCode.DownArrow))
    {
        EnqueueDirection(new GridPos(0, -1));
    }
    else if (Input.GetKeyDown(KeyCode.A) || Input.GetKeyDown(KeyCode.LeftArrow))
    {
        EnqueueDirection(new GridPos(-1, 0));
    }
    else if (Input.GetKeyDown(KeyCode.D) || Input.GetKeyDown(KeyCode.RightArrow))
    {
        EnqueueDirection(new GridPos(1, 0));
    }
}

private void EnqueueDirection(GridPos dir)
{
    // 防止把当前方向的相反方向加入队列
    if (dir + _currentDirection == new GridPos(0, 0))
        return;
    
    // 防止队列里已有相同方向
    if (_directionQueue.Count > 0 && _directionQueue.Peek() == dir)
        return;
    
    if (_directionQueue.Count < 3) // 最多缓冲3个输入
    {
        _directionQueue.Enqueue(dir);
    }
}

在MoveSnake执行的时候，先从队列里取出一个有效方向，再更新当前位置：

csharp复制private void MoveSnake()
{
    if (_directionQueue.Count > 0)
    {
        _currentDirection = _directionQueue.Dequeue();
    }
    
    GridPos newHeadPos = _headGridPos + _currentDirection;
    // 后续处理：移动蛇身、检测碰撞、判断是否吃到食物
}

这种“输入队列”方案的最大价值是提升了操作手感。如果没有队列缓冲，玩家快速连按时会丢失中间的方向变化，典型场景是“蛇向右移动时，玩家想快速转向上再向左”，由于向上指令被消费后向左指令才会被处理，而如果没有缓冲，向左指令会被当成非法输入丢弃，玩家会感觉“蛇不听话”。加了队列后，即使速度很快也能准确响应连续转向。

3. 蛇身数据结构选型与运动逻辑实现

3.1 链表与列表：为什么最终选了List

蛇身的数据结构是另一个值得细抠的点。最朴素的想法是用一个数组存所有身体节点的网格坐标，然后每移动一次，把所有节点依次往后挪。这个方案的缺点是：蛇越长，每次移动需要更新的节点越多，虽然贪吃蛇的蛇身长度通常不会超过几百格，性能上完全无压力，但逻辑上确实不够优雅。

更符合贪吃蛇本质的数据结构是“链表”——头部插入一个新的坐标，尾部删除一个坐标，中间的节点整体不变。C#里可以自己写链表，但更务实的方式是直接用List模拟链表操作：

csharp复制private List<GridPos> _snakeBody = new List<GridPos>();

private void MoveSnake()
{
    GridPos newHeadPos = _headGridPos + _currentDirection;
    _snakeBody.Insert(0, _headGridPos);
    _headGridPos = newHeadPos;
    
    if (!_isFoodEaten)
    {
        _snakeBody.RemoveAt(_snakeBody.Count - 1);
    }
    else
    {
        _isFoodEaten = false;
    }
}

这段代码每次移动时，把旧蛇头位置插入到列表头部，然后移除列表尾部的节点。如果吃到了食物就不移除尾部，蛇的长度自然增加一格。用List的Insert(0, ...)虽然内部有元素移动的开销，但几百个元素的列表对现代CPU来说根本不值一提，这样写的好处是逻辑非常直观，读代码的人一眼就能看懂“蛇移动”的本质。

我在这块踩过一个坑：没有区分“蛇头”和“身体”。如果你把蛇头也放在身体的List里，那么碰撞检测时要先检查头部的新位置是否和List里已有的身体节点重叠，此时如果身体List包含旧头部位置，就会产生误判。我在代码中把_headGridPos单独取出存储，_snakeBody只存放身体节点，碰撞检测时单独比较，省去了很多边界条件的麻烦。

3.2 身体节点跟随的视觉呈现方案

坐标逻辑确定之后，视觉呈现就是一个细节活。最简单的方式是给每个身体节点实例化一个方块Sprite，每次移动时把它们的Transform.position更新到对应网格坐标。这么做在蛇较短时看不出问题，但随着蛇身变长，每个节点都做一次坐标转换和赋值，极端情况下会出现轻微的视觉抖动。

另一个更优雅的方案是：让身体节点不直接跟随网格坐标，而是跟随“上一个节点的历史路径”。具体做法是每移动一格，把蛇头的旧位置存进一个“路径队列”，每个身体节点依次从路径队列中取出自己的目标位置。但我实际测试后发现，这种方案在网格移动模式下收益有限，反而增加代码复杂度。

所以我最终采用了最简单的方案：身体节点的视觉位置直接同步网格坐标。因为移动间隔是固定节拍，所有节点的坐标变化都在同一帧发生，只要确保“先更新逻辑坐标，再刷新视觉位置”这个顺序，就不会有抖动问题。我每一帧调用了同步方法：

csharp复制private void UpdateVisuals()
{
    _headVisual.transform.position = GridToWorld(_headGridPos);
    for (int i = 0; i < _snakeBody.Count; i++)
    {
        _bodyVisuals[i].transform.position = GridToWorld(_snakeBody[i]);
    }
}

这里的GridToWorld方法就是把网格坐标转换成世界坐标。我在设计时让网格中心位于世界原点，每个格子大小为1个单位：

csharp复制private Vector3 GridToWorld(GridPos pos)
{
    return new Vector3(pos.x + 0.5f, pos.y + 0.5f, 0);
}

加0.5偏移是为了让格子的中心对准到整数坐标上，这样碰撞边界和视觉中心对齐，玩家看起来也更舒服。

3.3 身体节点的对象池处理

每吃一个食物就Instantiate一个新的身体节点，确实是能用，但做得多了之后会积累大量未使用的运行时对象，对性能不够友好。我在这小项目里用了简单的对象池思想：预创建一批节点放进池中，需要时取出，不需要时回收，避免反复实例化和销毁。

csharp复制private Queue<GameObject> _bodyPool = new Queue<GameObject>();

private GameObject GetBodyNode()
{
    if (_bodyPool.Count > 0)
    {
        GameObject node = _bodyPool.Dequeue();
        node.SetActive(true);
        return node;
    }
    return Instantiate(_bodyPrefab);
}

private void RecycleBodyNode(GameObject node)
{
    node.SetActive(false);
    _bodyPool.Enqueue(node);
}

不过我也想坦白说一句：对象池这种优化在贪吃蛇这个项目里属于“锦上添花”，并不是必需。几十个身体节点对Unity来说完全可以轻松处理，就算不做对象池也不会卡顿。但做这个练习最大的意义在于，当你以后做塔防、弹幕、跑酷这类需要大量实例化敌人的项目时，对象池就是一个刚需了，提前练手没有坏处。

4. 食物生成、碰撞检测与游戏规则落地

4.1 随机但不堵路的食物生成算法

食物生成是贪吃蛇里最容易被低估的一个模块。很多初版实现就是直接随机生成一个网格坐标，然后判断是不是和蛇身重叠，如果重叠就重新随机，直到不重叠为止。这个方案在蛇身短的时候没问题，但蛇身变长后，随机到一个空闲格子的概率下降，可能反复循环几十次才能生成成功，极端情况下如果蛇几乎铺满地图，甚至可能陷入死循环。

为了避免这些问题，我采用了一个更稳妥的方案。游戏开始时先定义一个地图尺寸（比如宽20格、高20格），所有格子构成一个坐标集合。生成食物时，先剔除蛇身占据的坐标，再从剩余的空闲坐标中随机选一个。

csharp复制private GridPos GenerateFoodPosition()
{
    List<GridPos> occupied = new List<GridPos> { _headGridPos };
    occupied.AddRange(_snakeBody);
    
    HashSet<GridPos> occupiedSet = new HashSet<GridPos>(occupied);
    List<GridPos> freeCells = new List<GridPos>();
    
    for (int x = 0; x < _gridWidth; x++)
    {
        for (int y = 0; y < _gridHeight; y++)
        {
            GridPos pos = new GridPos(x, y);
            if (!occupiedSet.Contains(pos))
            {
                freeCells.Add(pos);
            }
        }
    }
    
    if (freeCells.Count == 0)
    {
        // 蛇铺满地图，游戏胜利
        GameWin();
        return new GridPos(0, 0);
    }
    
    return freeCells[Random.Range(0, freeCells.Count)];
}

遍历地图生成空闲坐标列表的代价和地图大小有关，但对于20x20这种小型网格，一帧内完成毫无压力。如果你的游戏地图特别大（比如100x100），可以改用随机采样加碰撞重试的方式，或者在生成前维护一个空闲坐标池，实时更新。

这里还有一个细节容易被忽略：食物不应该生成在蛇头即将到达的紧邻格子里，否则玩家反应不过来，会有“食物撞脸”的挫败感。我加了一个小过滤，如果随机到的空闲格子恰好是蛇头前方的格子，就换一个，避免这种“不可响应”的配置。

4.2 网格距离的碰撞检测：边界、自身、食物

碰撞检测是贪吃蛇的核心规则。我的实现方式是：每次移动后，计算蛇头的新坐标，然后依次检查：

• 是否越界：newHeadPos.x < 0 || newHeadPos.x >= _gridWidth || newHeadPos.y < 0 || newHeadPos.y >= _gridHeight
• 是否撞到自己：_snakeBody.Contains(newHeadPos)
• 是否吃到食物：newHeadPos == _foodGridPos

这三种碰撞的优先级是：先判断食物，再判断边界和自身。因为吃到食物的瞬间如果同时也撞到了边界（比如食物在边界格子上），优先让玩家吃到食物，避免出现“明明看到了食物但就是吃不到”的诡异情况。

有一点值得注意：撞到自身的判定时机。如果你先把新蛇头位置插入身体列表再检测，那么新头位置恰好和旧蛇头位置重合时，会错误地判断为撞到了自己。我建议的顺序是：先计算新蛇头坐标，用这个坐标和现有身体列表做比较，判定完碰撞后再执行插入和删除操作。顺序一旦反了，bug排查起来非常隐蔽。

我最初写反过一次，现象非常奇怪：蛇偶尔会在转向时“莫名其妙”死亡，但死亡位置看起来和蛇身之间还有一段距离。后来打个断点才发现，原来是旧蛇头坐标被存进了身体列表，而新的蛇头位置正好和它在同一格，于是触发了“撞到自己”的误判。调试这种问题最好的方式是在判定碰撞的代码处打日志，把相关坐标都打出来，一眼就能看出问题。

4.3 游戏状态机：待机、运行、暂停、结束

贪吃蛇虽然机制简单，但游戏状态还是需要的。我定义了一个简单的状态枚举：

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

状态机的好处是让逻辑清晰，避免在Update中写一堆if判断控制流程。比如玩家按下空格键时，当前是Ready状态就启动游戏，是Playing状态就暂停，是Paused就恢复，是GameOver就重启。

我把状态管理封装到一个GameManager脚本中，负责启动、暂停、结束等事件的分发。比如进入GameOver状态时，会同时触发UI显示、音效播放、蛇的移动停止、输入禁用等操作；进入Playing状态时，会重置所有数据。一个状态入口一个方法，不容易漏逻辑。

我推荐的代码结构是：

csharp复制private void ChangeState(GameState newState)
{
    if (_state == newState) return;
    
    // 退出旧状态
    switch (_state)
    {
        case GameState.Playing:
            StopAllCoroutines();
            break;
    }
    
    _state = newState;
    
    // 进入新状态
    switch (newState)
    {
        case GameState.Playing:
            StartGameCore();
            break;
        case GameState.GameOver:
            ShowGameOverUI();
            PlayDeathSound();
            break;
    }
}

可能有人觉得这是过度设计，但实际开发中我见过太多把状态判断散落在各个脚本里的代码，排查问题时非常痛苦。用状态机统一管理后，整个游戏的生命周期一目了然，也给后续扩展（比如增加“暂停弹窗”“结算界面”）留好了接口。

5. UI、音效与游戏流程控制的联动

5.1 Canvas的层级与UI布局细节

Unity UI的搭建听起来很简单，实际上有一堆细节。我用了Canvas + Screen Space Overlay模式，这是最省心的一种渲染模式，UI永远显示在最上层，不会被3D场景遮挡。Canvas下划分了三个子节点：

• Background区域：放置地图的背景图片和边框。
• Game区域：放置蛇目标Sprite、食物Sprite，作为实例化对象的父亲节点。
• HUD区域：放置分数文本、游戏状态提示、结束面板等。

一个很关键的小细节是蛇的视觉节点应该放在一个专门的分层下，而不是散落在Canvas根节点。这样当你需要整体控制所有蛇节点的显示/隐藏时（比如游戏结束时让蛇“消失”），只需要操作一个父节点即可。我吃了没分层的亏，第一次写完时想实现“游戏结束后蛇身逐渐变透明”的效果，结果需要遍历所有身体节点单独处理，非常麻烦。

HUD区域的布局我用了一个横向面板：左边显示当前分数，右边显示最高分。通过PlayerPrefs保存最高分数据，每次游戏结束时更新。这里用PlayerPrefs是最省事的方式，虽然不带加密，但对于单机小游戏来说已经足够。

5.2 分数系统的计时与增长设计

分数系统的设计有好几种流派：按吃到的食物数量计分、按移动的步数计分、按蛇的长度计分。我最终采用了“食物基础分 + 时间奖励分”的组合方式：

• 每吃到一个食物获得10分。
• 从游戏开始计时，每经过1秒额外获得1分。

这种设计的好处是不只鼓励玩家“贪吃”，还鼓励玩家“快速通关”——你越快吃到食物，时间奖励分就越高。这让游戏更有策略性：是冒着撞墙的风险抄近路去吃远处的食物，还是稳妥绕路？每个玩家会有自己的答案。

UI更新我放在了协程里，每0.1秒刷新一次分数文本。为什么不每帧刷新？因为每帧刷新会带来不必要的CPU开销，而且分数每帧变化对玩家来说根本看不出差别。用协程定期刷新，代码更干净，性能也更好。

5.3 音效与视效反馈的节奏控制

音效部分我用了Unity原生的AudioSource组件。在蛇移动时播放一个非常短的脚步声效（或轻快的“咔哒”声），吃食物时播放一个清脆的上升音效，死亡时播放一个下坠音效。音效的选择对游戏手感影响很大——我建议去找那种采样率不高、音长不超过0.5秒的短音效，不要用长音乐切片，否则频繁播放会混音混乱。

视效反馈方面，我做了两个细节：

• 吃到食物时，食物Sprite播放一个缩小消失的动画（用协程控制缩放），再生成新食物。
• 蛇头吃到食物瞬间，给蛇头一个轻快的“弹跳”效果，用DOTween或者自己写个简单的协程控制Y轴偏移，强调“吃到东西”的打击感。

这些细节并不复杂，但加上和不加的区别，玩起来手感完全是两个档次。做游戏很多时候就是这些“润色”工作区分了精致和粗糙。

6. 游戏扩展与优化的进阶思考

6.1 障碍物与特殊道具的扩展设计

一个完整的贪吃蛇可以继续加很多内容。我列几个自己后续想做的方向：

• 障碍物：地图中生成固定或随机移动的障碍物，蛇碰到就死。这需要在地图数据上增加一个障碍层，碰撞检测时额外判断。
• 特殊道具：比如加速（一段时间移动间隔减半）、减速、反向（方向左右互换）、缩身（缩短身体）。每个道具用一个枚举标识，吃到后触发对应效果。
• 传送门：地图左右边界、上下边界互通，蛇从右边出去从左边进来。这个实现起来特别简单，只需要在移动时对坐标取模即可。
• 双人模式：两条蛇在同一地图里竞争食物，先死或者先到某个长度的玩家获胜。实现思路是维护两个独立的蛇对象，共享食物生成逻辑，这样架构上就需要把“蛇”抽象成一个可复用的类。

这些扩展的实现都不难，前提是核心架构搭得足够清晰。尤其是如果你一开始就把“蛇的移动”和“食物生成”写在同一个脚本里，扩展障碍物时就会遇到麻烦——需要大量复制代码。

6.2 地图切换与关卡配置

贪吃蛇也可以做成关卡制。最简单的实现方式是建立一个ScriptableObject关卡配置：

csharp复制[CreateAssetMenu(fileName = "LevelConfig", menuName = "Snake/LevelConfig")]
public class LevelConfig : ScriptableObject
{
    public int gridWidth;
    public int gridHeight;
    public float moveInterval;
    public int obstacleCount;
}

每个关卡一个配置文件，游戏加载时根据当前关卡索引读取配置，重置地图和蛇的位置。这种方式虽然对一个小游戏来说有点重，但能让你提前熟悉项目中常用的数据驱动开发思路。以后不管做任何类型的游戏，把可变参数抽离成配置文件都是一种好的设计习惯。

6.3 性能优化与更低端设备的适配

性能优化是Unity开发中永不过时的话题。对于贪吃蛇来说，最主要的性能开销在UI更新和对象实例化。我已经在前面用对象池和协程刷新UI做了优化，这里再补充几个点：

• 应用Screen.SetResolution前要检查当前设备的宽高比，不要硬编码分辨率。
• 合批：把蛇的所有身体节点放在同一个纹理集下，减少DrawCall。
• 不用的GameObject不要用Destroy，用SetActive(false)或者对象池回收，避免GC产生卡顿。
• 移动端的功耗控制：如果帧率长时间超过需要，可以设置Application.targetFrameRate = 60，避免过度耗电。

一个容易被忽略的优化是：把Snake运动逻辑和视觉表现分离，让逻辑层不依赖Unity的MonoBehaviour生命周期。你可以把蛇的核心状态封装成一个纯C#类，在Update中手动调用它的Tick方法，这样不仅方便单元测试，以后想移植到其他游戏框架里也更方便。

7. 常见问题与排查技巧实录

7.1 蛇身抖动或位置不对齐

现象：蛇在移动过程中，身体节点出现轻微抖动，或者节点没有对齐到网格上。

原因：最常见的原因是在FixedUpdate中更新逻辑坐标，而在Update中更新视觉坐标，两者更新频率不一致导致偶发性错位。另一个原因是视觉节点直接用Transform.position赋值，而坐标计算时存在浮点误差。

解决方案：将逻辑更新和视觉更新都放在Update中，并且保持“先逻辑后视觉”的顺序。同时确保网格坐标转世界坐标的公式唯一且一致，不要在多个地方重复写坐标转换逻辑。

7.2 输入方向失灵或反向导致自杀

现象：玩家快速连按时，蛇没有按预期转向，或直接反向穿过身体。

原因：没有做输入防抖，或者允许了相反方向的输入。

解决方案：采用我在第2.3节介绍的输入队列方案，确保当前方向与下一个方向的相反操作被过滤掉。另外注意，在Insert新蛇头之前先执行方向更新，再执行移动，否则会出现新方向和身体重叠的误判。

7.3 食物生成到蛇身内部

现象：食物偶尔会生成在蛇身体占据的格子里，导致玩家永远吃不到。

原因：生成时没有排除所有被占据的格子，或者随机算法只检查了蛇头，没有检查蛇身。

解决方案：使用HashSet存储被占据的格子集合，在随机生成食物时实时构造空闲格子列表，确保食物坐标不在任何被占据的格子中。同时考虑生成后再次确认一次，防止极端情况下的重叠。

7.4 Update和FixedUpdate的混用陷阱

现象：游戏在不同的机器上运行速度不一致，有的机器蛇跑得快，有的跑得慢。

原因：在FixedUpdate中更新移动逻辑，但FixedUpdate的调用频率是固定的，在不同帧率下表现不一致。

解决方案：移动逻辑应该放在Update中，用累计时间控制移动间隔，确保游戏速度与帧率无关。FixedUpdate更适合物理相关的逻辑，比如RigidBody的运动和碰撞，而不是这类“定时跳变”的玩法逻辑。

7.5 游戏结束后残留对象导致重开异常

现象：游戏结束后点击“重新开始”，蛇的位置、分数、食物状态出现了异常。

原因：重开时没有清空蛇身体列表、食物坐标、方向队列等运行时数据，或者没有把对象池中的节点重新回收。

解决方案：在进入Ready状态时，强制清空所有运行时状态，包括蛇身列表、方向队列、移动计时器等，并回收所有对象池中的节点。建议把Reset方法集中写在一个地方，每次重开时统一调用。

7.6 UI点击穿透问题

现象：点击“重新开始”按钮时，游戏中的蛇也收到了输入，导致重开后立即改变了方向。

原因：UI的按钮点击事件和游戏输入事件都使用了GetKeyDown或GetMouseButtonDown，两者同时触发。

解决方案：在Update处理游戏输入时，先判断当前点击位置是否在UI元素上。可以用EventSystem.current.IsPointerOverGameObject()，如果返回true则不做游戏输入处理。或者把游戏输入改为EventSystem的Input Module来统一管理。

7.7 实战调试技巧：日志、断点与可视化辅助

最后分享几个调试贪吃蛇的实用技巧：

• 在关键操作（转向、吃食物、碰撞）处加日志，日志中带上网格坐标。不要只写“吃到食物”，要写“吃到食物，坐标(5,8)，当前长度10”。
• 在Unity编辑器的Scene视图中打开Gizmos，自定义OnDrawGizmos方法，把网格边界、食物位置、蛇头方向绘制出来，能直观看到运行时状态。
• 如果某个bug时有时无，不妨强制固定随机种子Random.InitState(0)，这样每次运行都是同样的随机序列，更容易稳定复现问题。
• 遇到疑似逻辑错误的bug时，在关键判断处打断点，逐帧查看变量的变化过程，比瞎猜高效得多。

8. 打包发布与真机适配的补充经验

Unity做PC或移动端小游戏时，打包和适配是绕不开的环节。这个贪吃蛇项目虽然简单，但我还是完整走了一遍打包流程，主要想验证两个问题：不同分辨率下UI布局是否正常、移动端触摸控制是否可用。

分辨率适配方面，我在Canvas的Canvas Scaler组件上设置了“Scale With Screen Size”，参考分辨率设为1920x1080。这样在16:9的屏幕上UI会完美适配，在异形屏或平板等非标准比例屏幕上，UI会等比缩放，不会出现按钮跑出屏幕的问题。如果你用的是老版本Unity，注意Canvas Scaler要为UI根节点添加，而不是每个UI元素单独设置。

移动端输入方面，Unity的Input类在移动端的表现比较特殊。比如Input.GetKeyDown(KeyCode.W)在手机上不会触发，因为根本没有键盘。所以我在原来键盘控制的基础上增加了一个虚拟方向键UI，用四个Button模拟方向操作。这个改动进一步印证了“输入处理独立成函数”的好处——我只需要修改HandleInput方法，让它同时响应键盘和按钮事件即可。

最后，如果游戏要上抖音小游戏或微信小游戏平台，需要注意Unity版本适配问题。小游戏平台通常对工程的白名单、代码裁剪、资源压缩有额外要求，这个项目目前没有深入，不过如果你想继续做这一步，我后续可以专门开一篇笔记介绍打包小游戏平台的完整流程。

9. 最终代码结构总结与改进方向

我的项目最终脚本结构如下：

• GameManager.cs：游戏状态机、流程控制、分数管理。
• SnakeController.cs：蛇的移动、增长、碰撞检测逻辑。
• BodyNode.cs：单个身体节点，处理自身的位置刷新和显隐。
• FoodManager.cs：食物生成、食物消除动画。
• InputHandler.cs：键盘和虚拟按钮的输入转发，维护方向队列。
• UIManager.cs：分数显示、暂停面板、结算面板等。
• AudioManager.cs：音效播放管理。

这种按职责拆分的结构让每个脚本都能独立测试，出现问题也能快速定位。如果以后想扩展更多功能，比如障碍物、道具、多关卡，只需要新增对应脚本，不需要改动核心逻辑。

这个项目做完之后，我最大的感受是：做学习项目千万不要急于求成。每一步都值得停下来想“为什么这么设计”，把每个细节吃透，比闷头写一堆代码然后遇到问题再改要高效得多。尤其是数据结构和状态机这些“基础课”，在贪吃蛇这种小项目里练熟，等你真正去做大型游戏时，就会觉得游刃有余。