1. 从游戏终点说起一个被低估的关卡收尾设计做Unity 2D项目的人几乎都写过到达终点就切场景这种逻辑。听起来简单到不值一提但我见过太多项目在这个环节翻车玩家碰到终点旗子后场景切了但分数没结算或者切场景时角色被销毁了两次触发空引用报错再或者通关后回到主菜单发现上一局的临时数据还赖在内存里没清干净。这些问题的根源往往不是代码写错了而是没有把游戏终点当成一个完整的状态机节点来设计。这篇内容围绕一个典型的2D平台跳跃类项目的收尾环节展开核心是讲清楚当玩家角色抵达关卡终点时从碰撞检测、状态冻结、数据结算到场景切换这一整条链路应该怎么搭才稳。涉及的关键技术点包括Box Collider 2D的触发器配置、OnTriggerEnter2D的回调时机、SceneManager的场景加载策略以及一个自己写的LevelManager如何承担关卡流程调度的职责。适合已经能跑通基础移动和跳跃、正准备给项目补上通关逻辑的Unity开发者也适合那些通关逻辑能跑但总觉得不够干净、想重构一遍的人。我个人的习惯是把游戏终点拆成三个独立阶段来处理触发检测、结算处理、场景过渡。这三个阶段各自有各自的坑混在一起写就是灾难。下面按这个思路一层层展开。2. 终点触发区到底该怎么摆Box Collider 2D的配置细节2.1 触发器与碰撞体的本质区别很多人一开始会把终点区域做成一个实心碰撞体结果玩家撞上去被弹开或者卡在旗子前面过不去。这里必须先厘清一个基础概念在Unity 2D物理系统里Box Collider 2D有两种工作模式——实体碰撞和触发器Is Trigger。实体碰撞会产生物理反弹和阻挡触发器则只负责检测重叠不参与物理响应。终点区域显然属于后者。你需要做的是在终点物体上添加Box Collider 2D组件勾选Is Trigger选项调整Size和Offset让触发范围覆盖玩家可能经过的路径这里有个容易忽略的点触发器的尺寸不能太小。我见过有人把终点触发区设成刚好和旗子一样宽结果玩家高速移动时因为物理帧的离散采样直接穿过去了OnTriggerEnter2D根本没触发。这不是bug是物理引擎的固有特性——碰撞检测发生在固定时间步长上速度过快时两次采样之间物体已经越过了检测区域。2.2 触发区尺寸的实测经验值我的做法是终点触发区的宽度至少设为玩家角色宽度的1.5倍高度覆盖玩家站立和跳跃两种状态。具体来说如果玩家胶囊体高度是1.8个单位触发区高度设2.5到3个单位比较稳妥。另外触发区应该稍微向玩家来的方向偏移一点让检测提前发生给后续的结算逻辑留出缓冲时间。还有一个细节如果终点区域同时需要视觉表现比如旗子飘动动画和逻辑检测建议把这两者拆成父子物体。父物体挂触发器和脚本子物体只负责渲染。这样调整视觉元素时不会误动碰撞体参数反之亦然。这个习惯在项目变大之后会省下大量排查时间。2.3 图层与碰撞矩阵的配合触发器能不能被检测到还取决于图层碰撞矩阵。玩家和终点必须在同一个碰撞层组里或者至少终点图层要勾选与玩家图层的交互。我一般会建一个专门的Trigger图层放所有触发类物体然后在Project Settings Physics 2D Layer Collision Matrix里只让它和Player层交互。这样做的好处是触发区不会误触发其他杂物性能上也更干净。提示改完图层矩阵后如果发现触发器没反应先检查两个物体的图层是否真的在矩阵里勾上了。这个坑我踩过不止一次排查半天代码结果是矩阵没配对。3. OnTriggerEnter2D的触发时机与常见误判3.1 回调到底在什么时候执行OnTriggerEnter2D是Unity物理系统在检测到两个触发器开始重叠时调用的消息方法。它的执行时机是在FixedUpdate之后、物理模拟完成的那一帧。这意味着它和Update不在同一个时间线上如果你在OnTriggerEnter2D里直接读取输入或者做依赖帧率的操作行为可能和预期不一致。一个典型的误判是有人在OnTriggerEnter2D里直接调用SceneManager.LoadScene结果场景切换发生在物理帧中间导致某些物理状态没来得及清理。正确的做法是在回调里只做标记把实际处理放到下一帧的Update里执行。比如private bool levelCompleted false; private void OnTriggerEnter2D(Collider2D other) { if (other.CompareTag(Player) !levelCompleted) { levelCompleted true; } } private void Update() { if (levelCompleted) { LevelManager.Instance.CompleteLevel(); } }这个levelCompleted标志位还有第二个作用防止重复触发。玩家碰到终点后如果因为惯性在触发区里来回移动OnTriggerEnter2D可能被多次调用。加个布尔锁是最简单有效的防护。3.2 标签判断与组件判断的取舍判断进来的是不是玩家有两种常见方式比较Tag或者尝试获取玩家组件。用Tag更快但依赖项目标签规范用组件更可靠但多一次GetComponent开销。我的建议是两者结合——先用CompareTag做快速过滤再在结算逻辑里通过组件确认关键数据。private void OnTriggerEnter2D(Collider2D other) { if (!other.CompareTag(Player)) return; var player other.GetComponentPlayerController(); if (player null) return; // 记录玩家数据用于结算 lastPlayerHealth player.CurrentHealth; lastPlayerScore player.Score; levelCompleted true; }这样写的好处是即使场景里有其他带Player标签的物体比如玩家的分身技能也不会误触发结算。3.3 触发丢失的三种排查方向如果你确认代码没问题但OnTriggerEnter2D就是不触发按这个顺序排查排查项检查内容常见问题碰撞体配置双方是否都有Collider 2D玩家只有Rigidbody没Collider触发器勾选至少一方勾了Is Trigger两边都是实体碰撞刚体设置至少一方有Rigidbody 2D两个静态碰撞体不触发图层矩阵两层是否允许交互新建图层默认不勾选脚本挂载脚本是否挂在激活物体上物体被禁用导致回调不执行这张表基本覆盖了我遇到过的所有触发失效场景。其中两个静态碰撞体不触发是最隐蔽的——Unity 2D物理要求至少一方有Rigidbody 2D才能产生触发事件。玩家通常有刚体所以问题一般出在终点物体上但终点不需要移动加个Rigidbody 2D设成Static或者Kinematic就行。4. LevelManager的职责边界别让一个脚本什么都管4.1 为什么需要一个独立的关卡管理器很多小项目会把通关逻辑直接写在玩家脚本里检测到终点、加分、切场景全塞在PlayerController里。项目小的时候没问题但一旦关卡变多、结算规则变复杂玩家脚本就会膨胀成一个什么都干的怪物。更麻烦的是场景切换后玩家对象会被销毁如果结算数据存在玩家身上切场景的瞬间数据就丢了。LevelManager的核心价值是把关卡流程从玩家行为里剥离出来。玩家只负责报告我碰到终点了至于怎么结算、什么时候切场景、切到哪个场景全部由LevelManager决定。这样职责清晰也方便做单例访问。public class LevelManager : MonoBehaviour { public static LevelManager Instance { get; private set; } [SerializeField] private float transitionDelay 1.5f; [SerializeField] private string nextSceneName; private LevelResult currentResult; private void Awake() { if (Instance ! null Instance ! this) { Destroy(gameObject); return; } Instance this; DontDestroyOnLoad(gameObject); } public void CompleteLevel(LevelResult result) { currentResult result; StartCoroutine(TransitionRoutine()); } private IEnumerator TransitionRoutine() { // 冻结玩家输入 GameState.SetInputEnabled(false); // 播放结算表现 yield return new WaitForSeconds(transitionDelay); // 保存结算数据 SaveManager.SaveLevelResult(currentResult); // 加载下一场景 SceneManager.LoadScene(nextSceneName); } }4.2 单例的初始化顺序陷阱上面这段代码有个关键点DontDestroyOnLoad必须在Awake里调用而且单例赋值要在销毁重复实例之前完成。我见过有人把Instance this写在Start里结果场景切换时新场景的LevelManager先执行了Awake发现Instance还是旧的把自己销毁了然后旧的那个在切场景时也被销毁最后Instance变成空引用。正确的顺序永远是检查重复 → 赋值单例 → 标记不销毁。如果项目里每个场景都有一个LevelManager那就要确保重复的那个在Awake阶段就被清理掉而不是等到Start。4.3 结算数据的承载方式结算数据用什么结构承载取决于项目复杂度。最简单的做法是定义一个LevelResult结构体[System.Serializable] public struct LevelResult { public int levelIndex; public int score; public float completionTime; public int starsEarned; public bool isPerfect; }这个结构体在触发终点时填充传给LevelManager再由LevelManager决定是存本地、发网络请求还是直接展示。把数据结构和流程控制分开后续加字段、改规则都不会牵一发动全身。注意如果结算数据需要跨场景传递不要用static变量硬存。static在编辑器里停止播放时不会自动重置容易造成上一局的数据带到下一局的诡异现象。用ScriptableObject或者序列化到本地文件更稳妥。5. SceneManager的场景切换策略与过渡处理5.1 同步加载与异步加载的选择SceneManager.LoadScene是同步加载会阻塞主线程直到场景加载完成。对于小场景这点卡顿可能只有几十毫秒肉眼几乎察觉不到。但如果下一关资源量大同步加载会造成明显的卡顿甚至假死。这时候应该用LoadSceneAsyncprivate IEnumerator LoadNextSceneAsync(string sceneName) { var op SceneManager.LoadSceneAsync(sceneName); op.allowSceneActivation false; while (op.progress 0.9f) { float progress Mathf.Clamp01(op.progress / 0.9f); LoadingUI.SetProgress(progress); yield return null; } // 加载完成等待玩家确认或直接激活 yield return new WaitForSeconds(0.5f); op.allowSceneActivation true; }这里有个反直觉的点LoadSceneAsync的progress在到达0.9之后就不再增长剩下的0.1要等allowSceneActivation设为true才会完成。所以进度条最多只能显示到90%最后那段要自己补一个过渡动画或者等待时间否则玩家会觉得进度条卡住了。5.2 场景切换时的对象清理切场景时当前场景的所有物体默认会被销毁。但有几类东西需要特别处理DontDestroyOnLoad的对象比如LevelManager、音频管理器、存档管理器。这些对象要确保在切换时状态正确不会带着上一关的临时数据进入下一关。事件订阅如果玩家脚本在OnEnable里订阅了事件切场景时OnDisable会取消订阅但如果是静态事件或者跨场景的单例事件容易造成重复订阅。我的习惯是在LevelManager切场景前手动清理一遍事件监听。对象池如果项目用了对象池切场景时池子里的对象要么跟着销毁重建要么手动重置状态。带着上一关的池子进下一关很容易出现子弹还在飞的诡异画面。5.3 过渡动画的插入位置场景切换的过渡动画淡入淡出、遮罩推进等应该由LevelManager统一控制而不是散落在各个场景里。我的做法是在LevelManager下挂一个全屏Canvas里面放一个Image做遮罩通过调整alpha实现淡入淡出。这个Canvas的sortingOrder设成最高确保盖住所有内容。private IEnumerator FadeOut(float duration) { float elapsed 0f; Color c fadeImage.color; while (elapsed duration) { elapsed Time.unscaledDeltaTime; c.a Mathf.Clamp01(elapsed / duration); fadeImage.color c; yield return null; } }注意这里用的是Time.unscaledDeltaTime而不是Time.deltaTime。因为结算时我们通常会暂停游戏Time.timeScale 0如果用deltaTime过渡动画会直接卡住不动。这个细节不注意的话表现就是点了通关画面黑了一半就不动了。6. 通关流程中的状态冻结与输入屏蔽6.1 为什么必须冻结玩家输入玩家碰到终点后如果还能继续操作角色会出现各种奇怪的情况角色在结算动画播放期间继续移动、跳跃甚至掉出地图触发死亡逻辑和通关逻辑打架。所以触发终点的第一件事应该是立即屏蔽玩家输入。屏蔽输入有两种粒度一种是只禁用移动和跳跃保留UI交互另一种是全局禁用连暂停菜单都打不开。通关结算期间通常用后者因为这时候玩家不应该做任何操作只需要看结算表现。public static class GameState { private static bool inputEnabled true; public static void SetInputEnabled(bool enabled) { inputEnabled enabled; OnInputStateChanged?.Invoke(enabled); } public static bool IsInputEnabled inputEnabled; public static event System.Actionbool OnInputStateChanged; }玩家脚本在读取输入前先检查GameState.IsInputEnabled这样屏蔽逻辑集中在一处不用去每个脚本里改。6.2 物理状态的收尾处理冻结输入之后还要处理角色的物理状态。如果角色在触发终点时正处于跳跃或下落状态直接切场景会让角色停在半空视觉上很突兀。我的做法是在结算开始时把角色的Rigidbody2D速度归零并切换到Kinematic模式private void FreezePlayer(PlayerController player) { var rb player.GetComponentRigidbody2D(); rb.velocity Vector2.zero; rb.bodyType RigidbodyType2D.Kinematic; player.enabled false; }把bodyType改成Kinematic而不是直接禁用刚体是因为禁用刚体会导致触发器回调中断如果结算逻辑还依赖物理检测就会出问题。Kinematic模式下刚体不受重力影响但触发器仍然工作是更安全的选择。6.3 计时器与分数的最终结算如果关卡有计时触发终点的瞬间要停止计时。这里有个精度问题计时器如果是在Update里累加Time.deltaTime那么从触发到实际停止之间可能多算了几帧。对于追求精确的项目应该在触发回调里记录Time.time作为结束时间戳而不是依赖计时器脚本的当前值。分数结算同理所有加分项应该在触发终点时一次性汇总而不是分散在各个脚本里各自加。我一般会在LevelManager里维护一个ScoreAccumulator各个系统通过接口往里提交分数最后统一结算。7. 从终点回到起点重玩与关卡循环的处理7.1 重玩时的状态重置清单通关后玩家选择重玩或者从主菜单重新进入关卡需要确保所有状态回到初始值。这个清单我建议在项目早期就列出来每加一个系统就补一项玩家位置、速度、朝向生命值、能量值、分数关卡内所有可交互物体的状态开关、门、收集品计时器归零对象池清空事件监听重置相机位置复位漏掉任何一项都会造成重玩后某个东西不对劲的bug。最稳妥的做法是让每个系统自己实现一个ResetState接口LevelManager在关卡开始时统一调用。7.2 关卡索引与进度保存如果项目是多关卡结构LevelManager需要知道当前是第几关、下一关是什么。我通常用一个LevelConfig的ScriptableObject来配置关卡列表[CreateAssetMenu(fileName LevelConfig, menuName Game/LevelConfig)] public class LevelConfig : ScriptableObject { public string[] sceneNames; public int[] starThresholds; }这样关卡顺序和星级门槛都在资源文件里配置改关卡不用动代码。LevelManager根据当前关卡索引查表得到下一关场景名通关时递增索引并保存。7.3 通关后的循环设计游戏终点这个标题其实暗示了一个更深的问题通关之后呢是回到主菜单、进入下一关还是展示制作人员名单这取决于游戏类型。平台跳跃类通常是进入下一关解谜类可能回到选关界面叙事类可能播放结局。不管哪种LevelManager都应该提供一个统一的OnLevelCompleted事件让UI层去决定展示什么。流程控制归LevelManager表现归UI这个边界要守住。我见过把UI跳转逻辑写进LevelManager的项目后期改个按钮位置都要翻管理器代码非常痛苦。8. 几个实际项目中反复出现的坑8.1 场景切换后单例重复前面提过DontDestroyOnLoad的单例问题这里再强调一个变体如果LevelManager挂在场景里的物体上同时又是DontDestroyOnLoad那么每次加载新场景都会创建一个新的LevelManager旧的还在。如果Awake里的重复检查写得不严谨就会出现两个管理器同时响应通关事件场景被加载两次。我的做法是LevelManager不放在场景里而是通过一个Bootstrapper场景在游戏启动时创建之后一直存在。这样从根源上避免了重复创建。8.2 触发器在场景加载时的误触发新场景加载完成后如果玩家出生点恰好和某个触发器重叠OnTriggerEnter2D会在场景加载后的第一帧触发。如果这个触发器是终点玩家一出生就通关了。避免这个问题的方法是在关卡开始后加一个短暂的保护期比如0.5秒内忽略所有触发private float levelStartTime; private void Start() { levelStartTime Time.time; } private void OnTriggerEnter2D(Collider2D other) { if (Time.time - levelStartTime 0.5f) return; // 正常处理 }这个保护期还能顺便解决玩家出生时和地面触发器重叠导致误判落地的问题一举两得。8.3 异步加载时的输入穿透用LoadSceneAsync时如果allowSceneActivation设为true的瞬间玩家还在按跳跃键新场景加载后角色可能会立刻跳一下。解决办法是在加载开始时就屏蔽输入加载完成后延迟几帧再恢复。这个延迟不用太长两三帧就够但必须有。8.4 结算UI和场景切换的时序竞争结算UI的显示和场景切换如果都用协程控制要注意它们的执行顺序。我遇到过结算面板还没完全显示出来场景就切走了的情况。原因是两个协程的等待时间没对齐。我的做法是把结算UI的显示也纳入LevelManager的过渡协程里按顺序执行冻结输入 → 显示结算 → 等待玩家确认 → 淡出 → 加载场景。所有步骤串在一个协程里时序就不会乱。9. 关于这套流程的扩展思路这套触发检测 → 结算处理 → 场景过渡的结构其实不只能用在游戏终点。检查点、传送门、关卡入口本质上都是同一类问题检测到特定条件后执行一系列流程操作。把这套逻辑抽象成一个通用的TriggerFlow组件配置不同的条件和动作能覆盖项目里大部分场景交互需求。我在最近一个项目里就是这么做的TriggerFlow接受一个条件列表标签匹配、组件存在、变量比较和一个动作列表播放动画、修改状态、加载场景通过ScriptableObject配置。终点只是其中一种配置。这样加新交互不用写新脚本策划自己就能配。当然这是项目规模上来之后的优化小项目直接写LevelManager完全够用。另外如果项目要做多平台发布场景切换的加载时间在不同平台上差异很大。移动端加载大场景可能要好幾秒PC端可能一瞬间。过渡动画的时长最好根据实际加载进度动态调整而不是写死一个固定值。这个细节在PC上测试时很容易被忽略等到打包到移动端才发现过渡动画早就播完了场景还没加载好。 Unity 2D通关逻辑设计：从触发检测到场景切换的完整流程
1. 从游戏终点说起一个被低估的关卡收尾设计做Unity 2D项目的人几乎都写过到达终点就切场景这种逻辑。听起来简单到不值一提但我见过太多项目在这个环节翻车玩家碰到终点旗子后场景切了但分数没结算或者切场景时角色被销毁了两次触发空引用报错再或者通关后回到主菜单发现上一局的临时数据还赖在内存里没清干净。这些问题的根源往往不是代码写错了而是没有把游戏终点当成一个完整的状态机节点来设计。这篇内容围绕一个典型的2D平台跳跃类项目的收尾环节展开核心是讲清楚当玩家角色抵达关卡终点时从碰撞检测、状态冻结、数据结算到场景切换这一整条链路应该怎么搭才稳。涉及的关键技术点包括Box Collider 2D的触发器配置、OnTriggerEnter2D的回调时机、SceneManager的场景加载策略以及一个自己写的LevelManager如何承担关卡流程调度的职责。适合已经能跑通基础移动和跳跃、正准备给项目补上通关逻辑的Unity开发者也适合那些通关逻辑能跑但总觉得不够干净、想重构一遍的人。我个人的习惯是把游戏终点拆成三个独立阶段来处理触发检测、结算处理、场景过渡。这三个阶段各自有各自的坑混在一起写就是灾难。下面按这个思路一层层展开。2. 终点触发区到底该怎么摆Box Collider 2D的配置细节2.1 触发器与碰撞体的本质区别很多人一开始会把终点区域做成一个实心碰撞体结果玩家撞上去被弹开或者卡在旗子前面过不去。这里必须先厘清一个基础概念在Unity 2D物理系统里Box Collider 2D有两种工作模式——实体碰撞和触发器Is Trigger。实体碰撞会产生物理反弹和阻挡触发器则只负责检测重叠不参与物理响应。终点区域显然属于后者。你需要做的是在终点物体上添加Box Collider 2D组件勾选Is Trigger选项调整Size和Offset让触发范围覆盖玩家可能经过的路径这里有个容易忽略的点触发器的尺寸不能太小。我见过有人把终点触发区设成刚好和旗子一样宽结果玩家高速移动时因为物理帧的离散采样直接穿过去了OnTriggerEnter2D根本没触发。这不是bug是物理引擎的固有特性——碰撞检测发生在固定时间步长上速度过快时两次采样之间物体已经越过了检测区域。2.2 触发区尺寸的实测经验值我的做法是终点触发区的宽度至少设为玩家角色宽度的1.5倍高度覆盖玩家站立和跳跃两种状态。具体来说如果玩家胶囊体高度是1.8个单位触发区高度设2.5到3个单位比较稳妥。另外触发区应该稍微向玩家来的方向偏移一点让检测提前发生给后续的结算逻辑留出缓冲时间。还有一个细节如果终点区域同时需要视觉表现比如旗子飘动动画和逻辑检测建议把这两者拆成父子物体。父物体挂触发器和脚本子物体只负责渲染。这样调整视觉元素时不会误动碰撞体参数反之亦然。这个习惯在项目变大之后会省下大量排查时间。2.3 图层与碰撞矩阵的配合触发器能不能被检测到还取决于图层碰撞矩阵。玩家和终点必须在同一个碰撞层组里或者至少终点图层要勾选与玩家图层的交互。我一般会建一个专门的Trigger图层放所有触发类物体然后在Project Settings Physics 2D Layer Collision Matrix里只让它和Player层交互。这样做的好处是触发区不会误触发其他杂物性能上也更干净。提示改完图层矩阵后如果发现触发器没反应先检查两个物体的图层是否真的在矩阵里勾上了。这个坑我踩过不止一次排查半天代码结果是矩阵没配对。3. OnTriggerEnter2D的触发时机与常见误判3.1 回调到底在什么时候执行OnTriggerEnter2D是Unity物理系统在检测到两个触发器开始重叠时调用的消息方法。它的执行时机是在FixedUpdate之后、物理模拟完成的那一帧。这意味着它和Update不在同一个时间线上如果你在OnTriggerEnter2D里直接读取输入或者做依赖帧率的操作行为可能和预期不一致。一个典型的误判是有人在OnTriggerEnter2D里直接调用SceneManager.LoadScene结果场景切换发生在物理帧中间导致某些物理状态没来得及清理。正确的做法是在回调里只做标记把实际处理放到下一帧的Update里执行。比如private bool levelCompleted false; private void OnTriggerEnter2D(Collider2D other) { if (other.CompareTag(Player) !levelCompleted) { levelCompleted true; } } private void Update() { if (levelCompleted) { LevelManager.Instance.CompleteLevel(); } }这个levelCompleted标志位还有第二个作用防止重复触发。玩家碰到终点后如果因为惯性在触发区里来回移动OnTriggerEnter2D可能被多次调用。加个布尔锁是最简单有效的防护。3.2 标签判断与组件判断的取舍判断进来的是不是玩家有两种常见方式比较Tag或者尝试获取玩家组件。用Tag更快但依赖项目标签规范用组件更可靠但多一次GetComponent开销。我的建议是两者结合——先用CompareTag做快速过滤再在结算逻辑里通过组件确认关键数据。private void OnTriggerEnter2D(Collider2D other) { if (!other.CompareTag(Player)) return; var player other.GetComponentPlayerController(); if (player null) return; // 记录玩家数据用于结算 lastPlayerHealth player.CurrentHealth; lastPlayerScore player.Score; levelCompleted true; }这样写的好处是即使场景里有其他带Player标签的物体比如玩家的分身技能也不会误触发结算。3.3 触发丢失的三种排查方向如果你确认代码没问题但OnTriggerEnter2D就是不触发按这个顺序排查排查项检查内容常见问题碰撞体配置双方是否都有Collider 2D玩家只有Rigidbody没Collider触发器勾选至少一方勾了Is Trigger两边都是实体碰撞刚体设置至少一方有Rigidbody 2D两个静态碰撞体不触发图层矩阵两层是否允许交互新建图层默认不勾选脚本挂载脚本是否挂在激活物体上物体被禁用导致回调不执行这张表基本覆盖了我遇到过的所有触发失效场景。其中两个静态碰撞体不触发是最隐蔽的——Unity 2D物理要求至少一方有Rigidbody 2D才能产生触发事件。玩家通常有刚体所以问题一般出在终点物体上但终点不需要移动加个Rigidbody 2D设成Static或者Kinematic就行。4. LevelManager的职责边界别让一个脚本什么都管4.1 为什么需要一个独立的关卡管理器很多小项目会把通关逻辑直接写在玩家脚本里检测到终点、加分、切场景全塞在PlayerController里。项目小的时候没问题但一旦关卡变多、结算规则变复杂玩家脚本就会膨胀成一个什么都干的怪物。更麻烦的是场景切换后玩家对象会被销毁如果结算数据存在玩家身上切场景的瞬间数据就丢了。LevelManager的核心价值是把关卡流程从玩家行为里剥离出来。玩家只负责报告我碰到终点了至于怎么结算、什么时候切场景、切到哪个场景全部由LevelManager决定。这样职责清晰也方便做单例访问。public class LevelManager : MonoBehaviour { public static LevelManager Instance { get; private set; } [SerializeField] private float transitionDelay 1.5f; [SerializeField] private string nextSceneName; private LevelResult currentResult; private void Awake() { if (Instance ! null Instance ! this) { Destroy(gameObject); return; } Instance this; DontDestroyOnLoad(gameObject); } public void CompleteLevel(LevelResult result) { currentResult result; StartCoroutine(TransitionRoutine()); } private IEnumerator TransitionRoutine() { // 冻结玩家输入 GameState.SetInputEnabled(false); // 播放结算表现 yield return new WaitForSeconds(transitionDelay); // 保存结算数据 SaveManager.SaveLevelResult(currentResult); // 加载下一场景 SceneManager.LoadScene(nextSceneName); } }4.2 单例的初始化顺序陷阱上面这段代码有个关键点DontDestroyOnLoad必须在Awake里调用而且单例赋值要在销毁重复实例之前完成。我见过有人把Instance this写在Start里结果场景切换时新场景的LevelManager先执行了Awake发现Instance还是旧的把自己销毁了然后旧的那个在切场景时也被销毁最后Instance变成空引用。正确的顺序永远是检查重复 → 赋值单例 → 标记不销毁。如果项目里每个场景都有一个LevelManager那就要确保重复的那个在Awake阶段就被清理掉而不是等到Start。4.3 结算数据的承载方式结算数据用什么结构承载取决于项目复杂度。最简单的做法是定义一个LevelResult结构体[System.Serializable] public struct LevelResult { public int levelIndex; public int score; public float completionTime; public int starsEarned; public bool isPerfect; }这个结构体在触发终点时填充传给LevelManager再由LevelManager决定是存本地、发网络请求还是直接展示。把数据结构和流程控制分开后续加字段、改规则都不会牵一发动全身。注意如果结算数据需要跨场景传递不要用static变量硬存。static在编辑器里停止播放时不会自动重置容易造成上一局的数据带到下一局的诡异现象。用ScriptableObject或者序列化到本地文件更稳妥。5. SceneManager的场景切换策略与过渡处理5.1 同步加载与异步加载的选择SceneManager.LoadScene是同步加载会阻塞主线程直到场景加载完成。对于小场景这点卡顿可能只有几十毫秒肉眼几乎察觉不到。但如果下一关资源量大同步加载会造成明显的卡顿甚至假死。这时候应该用LoadSceneAsyncprivate IEnumerator LoadNextSceneAsync(string sceneName) { var op SceneManager.LoadSceneAsync(sceneName); op.allowSceneActivation false; while (op.progress 0.9f) { float progress Mathf.Clamp01(op.progress / 0.9f); LoadingUI.SetProgress(progress); yield return null; } // 加载完成等待玩家确认或直接激活 yield return new WaitForSeconds(0.5f); op.allowSceneActivation true; }这里有个反直觉的点LoadSceneAsync的progress在到达0.9之后就不再增长剩下的0.1要等allowSceneActivation设为true才会完成。所以进度条最多只能显示到90%最后那段要自己补一个过渡动画或者等待时间否则玩家会觉得进度条卡住了。5.2 场景切换时的对象清理切场景时当前场景的所有物体默认会被销毁。但有几类东西需要特别处理DontDestroyOnLoad的对象比如LevelManager、音频管理器、存档管理器。这些对象要确保在切换时状态正确不会带着上一关的临时数据进入下一关。事件订阅如果玩家脚本在OnEnable里订阅了事件切场景时OnDisable会取消订阅但如果是静态事件或者跨场景的单例事件容易造成重复订阅。我的习惯是在LevelManager切场景前手动清理一遍事件监听。对象池如果项目用了对象池切场景时池子里的对象要么跟着销毁重建要么手动重置状态。带着上一关的池子进下一关很容易出现子弹还在飞的诡异画面。5.3 过渡动画的插入位置场景切换的过渡动画淡入淡出、遮罩推进等应该由LevelManager统一控制而不是散落在各个场景里。我的做法是在LevelManager下挂一个全屏Canvas里面放一个Image做遮罩通过调整alpha实现淡入淡出。这个Canvas的sortingOrder设成最高确保盖住所有内容。private IEnumerator FadeOut(float duration) { float elapsed 0f; Color c fadeImage.color; while (elapsed duration) { elapsed Time.unscaledDeltaTime; c.a Mathf.Clamp01(elapsed / duration); fadeImage.color c; yield return null; } }注意这里用的是Time.unscaledDeltaTime而不是Time.deltaTime。因为结算时我们通常会暂停游戏Time.timeScale 0如果用deltaTime过渡动画会直接卡住不动。这个细节不注意的话表现就是点了通关画面黑了一半就不动了。6. 通关流程中的状态冻结与输入屏蔽6.1 为什么必须冻结玩家输入玩家碰到终点后如果还能继续操作角色会出现各种奇怪的情况角色在结算动画播放期间继续移动、跳跃甚至掉出地图触发死亡逻辑和通关逻辑打架。所以触发终点的第一件事应该是立即屏蔽玩家输入。屏蔽输入有两种粒度一种是只禁用移动和跳跃保留UI交互另一种是全局禁用连暂停菜单都打不开。通关结算期间通常用后者因为这时候玩家不应该做任何操作只需要看结算表现。public static class GameState { private static bool inputEnabled true; public static void SetInputEnabled(bool enabled) { inputEnabled enabled; OnInputStateChanged?.Invoke(enabled); } public static bool IsInputEnabled inputEnabled; public static event System.Actionbool OnInputStateChanged; }玩家脚本在读取输入前先检查GameState.IsInputEnabled这样屏蔽逻辑集中在一处不用去每个脚本里改。6.2 物理状态的收尾处理冻结输入之后还要处理角色的物理状态。如果角色在触发终点时正处于跳跃或下落状态直接切场景会让角色停在半空视觉上很突兀。我的做法是在结算开始时把角色的Rigidbody2D速度归零并切换到Kinematic模式private void FreezePlayer(PlayerController player) { var rb player.GetComponentRigidbody2D(); rb.velocity Vector2.zero; rb.bodyType RigidbodyType2D.Kinematic; player.enabled false; }把bodyType改成Kinematic而不是直接禁用刚体是因为禁用刚体会导致触发器回调中断如果结算逻辑还依赖物理检测就会出问题。Kinematic模式下刚体不受重力影响但触发器仍然工作是更安全的选择。6.3 计时器与分数的最终结算如果关卡有计时触发终点的瞬间要停止计时。这里有个精度问题计时器如果是在Update里累加Time.deltaTime那么从触发到实际停止之间可能多算了几帧。对于追求精确的项目应该在触发回调里记录Time.time作为结束时间戳而不是依赖计时器脚本的当前值。分数结算同理所有加分项应该在触发终点时一次性汇总而不是分散在各个脚本里各自加。我一般会在LevelManager里维护一个ScoreAccumulator各个系统通过接口往里提交分数最后统一结算。7. 从终点回到起点重玩与关卡循环的处理7.1 重玩时的状态重置清单通关后玩家选择重玩或者从主菜单重新进入关卡需要确保所有状态回到初始值。这个清单我建议在项目早期就列出来每加一个系统就补一项玩家位置、速度、朝向生命值、能量值、分数关卡内所有可交互物体的状态开关、门、收集品计时器归零对象池清空事件监听重置相机位置复位漏掉任何一项都会造成重玩后某个东西不对劲的bug。最稳妥的做法是让每个系统自己实现一个ResetState接口LevelManager在关卡开始时统一调用。7.2 关卡索引与进度保存如果项目是多关卡结构LevelManager需要知道当前是第几关、下一关是什么。我通常用一个LevelConfig的ScriptableObject来配置关卡列表[CreateAssetMenu(fileName LevelConfig, menuName Game/LevelConfig)] public class LevelConfig : ScriptableObject { public string[] sceneNames; public int[] starThresholds; }这样关卡顺序和星级门槛都在资源文件里配置改关卡不用动代码。LevelManager根据当前关卡索引查表得到下一关场景名通关时递增索引并保存。7.3 通关后的循环设计游戏终点这个标题其实暗示了一个更深的问题通关之后呢是回到主菜单、进入下一关还是展示制作人员名单这取决于游戏类型。平台跳跃类通常是进入下一关解谜类可能回到选关界面叙事类可能播放结局。不管哪种LevelManager都应该提供一个统一的OnLevelCompleted事件让UI层去决定展示什么。流程控制归LevelManager表现归UI这个边界要守住。我见过把UI跳转逻辑写进LevelManager的项目后期改个按钮位置都要翻管理器代码非常痛苦。8. 几个实际项目中反复出现的坑8.1 场景切换后单例重复前面提过DontDestroyOnLoad的单例问题这里再强调一个变体如果LevelManager挂在场景里的物体上同时又是DontDestroyOnLoad那么每次加载新场景都会创建一个新的LevelManager旧的还在。如果Awake里的重复检查写得不严谨就会出现两个管理器同时响应通关事件场景被加载两次。我的做法是LevelManager不放在场景里而是通过一个Bootstrapper场景在游戏启动时创建之后一直存在。这样从根源上避免了重复创建。8.2 触发器在场景加载时的误触发新场景加载完成后如果玩家出生点恰好和某个触发器重叠OnTriggerEnter2D会在场景加载后的第一帧触发。如果这个触发器是终点玩家一出生就通关了。避免这个问题的方法是在关卡开始后加一个短暂的保护期比如0.5秒内忽略所有触发private float levelStartTime; private void Start() { levelStartTime Time.time; } private void OnTriggerEnter2D(Collider2D other) { if (Time.time - levelStartTime 0.5f) return; // 正常处理 }这个保护期还能顺便解决玩家出生时和地面触发器重叠导致误判落地的问题一举两得。8.3 异步加载时的输入穿透用LoadSceneAsync时如果allowSceneActivation设为true的瞬间玩家还在按跳跃键新场景加载后角色可能会立刻跳一下。解决办法是在加载开始时就屏蔽输入加载完成后延迟几帧再恢复。这个延迟不用太长两三帧就够但必须有。8.4 结算UI和场景切换的时序竞争结算UI的显示和场景切换如果都用协程控制要注意它们的执行顺序。我遇到过结算面板还没完全显示出来场景就切走了的情况。原因是两个协程的等待时间没对齐。我的做法是把结算UI的显示也纳入LevelManager的过渡协程里按顺序执行冻结输入 → 显示结算 → 等待玩家确认 → 淡出 → 加载场景。所有步骤串在一个协程里时序就不会乱。9. 关于这套流程的扩展思路这套触发检测 → 结算处理 → 场景过渡的结构其实不只能用在游戏终点。检查点、传送门、关卡入口本质上都是同一类问题检测到特定条件后执行一系列流程操作。把这套逻辑抽象成一个通用的TriggerFlow组件配置不同的条件和动作能覆盖项目里大部分场景交互需求。我在最近一个项目里就是这么做的TriggerFlow接受一个条件列表标签匹配、组件存在、变量比较和一个动作列表播放动画、修改状态、加载场景通过ScriptableObject配置。终点只是其中一种配置。这样加新交互不用写新脚本策划自己就能配。当然这是项目规模上来之后的优化小项目直接写LevelManager完全够用。另外如果项目要做多平台发布场景切换的加载时间在不同平台上差异很大。移动端加载大场景可能要好幾秒PC端可能一瞬间。过渡动画的时长最好根据实际加载进度动态调整而不是写死一个固定值。这个细节在PC上测试时很容易被忽略等到打包到移动端才发现过渡动画早就播完了场景还没加载好。