1. 场景不是"界面"，先理顺 Cocos Creator 中的场景概念与构建配置
先说个很多新手都会踩的坑：把"场景"理解成游戏里的一个"页面"。这个概念一旦偏了，后面做场景切换时就会绕很多弯路，尤其是当你想做"主菜单→游戏关卡→结算页"这种最基础的游戏流程时，你会发现网上教程各写各的，有的讲cc.director.loadScene，有的讲编辑器里拖拽绑定，看完还是不知道到底怎么用。我先把场景这个概念掰开揉碎讲清楚，后面对代码和事件绑定的理解就顺了。
在 Cocos Creator 里，场景（Scene）是一个完整的、独立运行时环境。它包含了一整套节点树、组件、灯光、相机、UI 画布、音频，甚至逻辑脚本。可以理解为：场景就是游戏世界的一个"状态快照"，一个关卡、一个主菜单、一个结算界面，都可以各自做成一个场景。编辑器里每个.scene文件对应一个场景，双击就能打开编辑。
很多人误以为场景就是"UI 界面"，所以把主菜单、设置、排行榜全塞进同一个场景里，用隐藏/显示节点的方式切来切去。这种做法不是不行，但对于中大型项目，后续维护就是灾难：节点层级几千个，查找困难，场景加载速度被拖慢，而且多个 UI 之间的状态管理极其容易出 bug。最合理的做法是：把逻辑独立、加载时机不同的模块拆分成多个场景，用场景切换来组织游戏流程。
1.1 创建多个场景的标准操作
在 Cocos Creator 的assets面板里，右键 → 创建 → Scene，就能新建一个场景文件。建好后给它起个有意义的名字，比如MainMenu、GameLevel、GameOver。注意，文件名就是场景名，也是后续代码里用来加载场景的标识。所以命名一定要规范，别用中文名，也别叫什么new scene 1，不然到了写loadScene的时候，你自己都不知道该填什么。
我习惯的项目结构是这样的：
assets/ scenes/ MainMenu.scene GameLevel.scene GameOver.scene scripts/ MainMenu.ts GameLevel.ts GameOver.ts prefabs/ ...每个场景对应一个同名的入口脚本，挂在场景根节点或者一个专门的GameManager节点上。这样场景之间的职责边界非常清晰：主菜单场景只负责主菜单的 UI 交互，游戏关卡场景只负责玩法逻辑，结算场景只负责展示结果。
创建好场景后，需要在构建发布面板里确认一下场景列表。快捷键 Ctrl+Shift+B 打开构建发布，在"参与构建的场景"里勾选所有需要打包的场景。这一步经常被忽略，结果就是编辑器预览时一切正常，一打包 APK，某些场景进不去，报错说场景找不到。为什么？因为没勾选的场景根本没被打进包里。
1.2 场景切换时的资源加载机制
理解场景切换，必须理解 Cocos Creator 的资源加载机制。每个场景文件会引用一堆资源：图片、音频、预制体、图集、材质等。当调用loadScene切换到新场景时，引擎会做两件事：销毁当前场景的所有节点，然后加载并实例化新场景的所有内容。
这个"销毁"是彻底的。当前场景里所有节点的onDestroy会被调用，所有挂载的组件实例会被回收，场景根部挂的普通全局变量如果被写在组件属性上，也会一并消失。很多新手第一次写出"切场景后数据丢失"的 bug，就死在这一步——组件属性的生命周期是跟着场景走的，不是跟着程序走的。
但也别慌，后面第 4 章会专门讲跨场景数据保存的方案。这里你要先建立起一个核心认知：场景切换 = 销毁重建，所以在切换前，要想清楚哪些数据需要保留、用什么方式保留，而不是在切换后才着急找数据。
2. 代码切换场景：director.loadScene 的前因后果
代码切换场景是 Cocos Creator 里最基础也最核心的场景切换方式，掌握它之后，不管是按钮点击、定时跳转、还是游戏结束自动切结算页，都是同一套逻辑。Cocos Creator 3.x 的 API 是director.loadScene(sceneName)，在 2.x 里是cc.director.loadScene(sceneName)，区别只在有没有cc前缀，使用逻辑完全一致。
为什么用代码切换而不是纯编辑器操作？因为实际项目里，场景切换绝大多数不是"点击按钮"这么简单。比如：玩家通关后，需要先播放一段过场动画，再进入下一关；或者游戏失败后，先弹出结算界面，点击"重新开始"才回到关卡场景。这些带条件的跳转，编辑器拖拽绑定根本做不了，必须在代码里写判断逻辑。
2.1 最基础的代码切换：一个完整示例
先上一个最朴素的示例，在MainMenu场景的某个组件脚本里写：
import { _decorator, Component, director } from 'cc'; const { ccclass } = _decorator; @ccclass('MainMenu') export class MainMenu extends Component { start() { // 5 秒后自动进入游戏关卡 this.scheduleOnce(() => { director.loadScene('GameLevel'); }, 5); } }这段代码的逻辑很简单：场景加载完成后，5 秒后切到GameLevel场景。实际项目里，你只需要把scheduleOnce里的回调换成玩家点击事件触发即可。
拿到这段代码后，新手最容易提出一个疑问："这个GameLevel字符串哪里来的？"答案就是场景文件的名字。你在assets面板里看到GameLevel.scene，代码里就填'GameLevel'。这里有个我踩过的坑：场景重命名后，代码里的字符串不会自动跟着更新。你重构了场景名，但忘了改代码，运行时报Scene 'xxx' not found，排查半天才发现是名字对不上。所以场景命名要尽量一次到位，或者在重命名后全局搜索一遍代码里对应的字符串。
2.2 预加载场景，避免切换白屏
loadScene是"加载并切换"，所以引擎会先加载新场景的全部资源，完成后再跳转。如果新场景资源多、体积大，加载期间屏幕会卡在旧场景最后一帧，体验很差。
解决办法是director.preloadScene(sceneName, onLoaded, onProgress)，也就是预加载。把新场景提前加载到内存里，等真正需要切换时，loadScene的速度就会快很多，因为资源已经就绪了。
// 在进入主菜单时，预加载游戏关卡场景 director.preloadScene('GameLevel', (err) => { if (err) { console.error('预加载失败', err); return; } console.log('GameLevel 预加载完成'); }, (completedCount, totalCount) => { const progress = completedCount / totalCount; console.log(`预加载进度: ${Math.round(progress * 100)}%`); } );预加载的典型使用场景是：玩家在主菜单停留时，后台预加载游戏主关卡；在关卡加载界面时，预加载结算场景。我的经验是，不要预加载用不上的场景，尤其不要一口气预加载全部场景，那样启动内存占用会飙升，低端安卓机上很容易被杀进程。预加载要按游戏流程"下一站要用什么就提前载什么"。
loadScene本身也支持回调：
director.loadScene('GameLevel', (err) => { if (err) { console.error('场景加载失败', err); return; } console.log('场景切换完成'); });如果你在切换后还要做一些初始化、传递参数之类的事，强烈建议把逻辑写在这个回调里，而不是直接放在loadScene下一行。因为loadScene是异步的，下一行的代码会先执行，此时新场景的节点可能还没创建完成。很多人在这里踩坑：调用loadScene后立刻find('Canvas/xxx')去找节点，结果返回 null，报错说节点不存在。
2.3 切换前后的生命周期调用顺序
有一件事，官方文档写得很零散，但实际开发中非常关键——场景切换时各生命周期方法的调用顺序。
我实测下来的调用顺序是这样的，以场景 A 切到场景 B 为例：
排在第一的是场景 A 里所有组件的onDisable和onDestroy，也就是旧场景开始销毁。接着创建场景 B 的节点树，执行场景 B 里所有组件的onLoad，然后是onEnable，最后start，场景 B 正式运行。
这个顺序里最值得注意的点是：先销毁旧场景，再加载新场景。所以如果你在场景 A 的onDestroy里读了某个全局数据，把它传给场景 B，这个操作是安全的。反过来，如果你在场景 A 的onDisable里访问场景 B 的节点，那就会出错——因为此时场景 B 还没创建。
我踩过一次这样的坑：在场景 A 的销毁回调里调用了director.loadScene('GameOver')，结果场景 A 还没销毁完，又触发了一次场景切换，引擎直接报"场景切换中，无法再次切换"。从此我给自己定了个规矩：场景切换的入口统一放在事件回调或定时器里，绝不放在生命周期方法（onLoad、onDestroy）中直接触发。
3. 事件绑定切换场景：从编辑器拖拽到动态监听的完整套路
代码里写死"5 秒后切场景"只是演示，实际游戏里玩家需要自己控制跳转时机，最常见的入口就是一个按钮。按钮的场景切换有两种做法：编辑器拖拽绑定，和代码动态监听。两种方式适用场景不同，我建议都要掌握。
3.1 编辑器里直接拖拽绑定点击事件
最简单的方式：在场景里创建一个 Button 节点，选中它，在Button 组件的Click Events数组里点加号，新增一个条目。然后把挂有脚本的节点拖到Target槽里，组件下拉框选择脚本名，方法名选择你写的跳转函数。
示意流程大致是：Button 节点 → Button 组件 → Click Events → 添加事件 → 拖拽目标节点 → 选择组件 → 选择方法。
配套的脚本长这样：
import { _decorator, Component, director } from 'cc'; const { ccclass } = _decorator; @ccclass('MainMenu') export class MainMenu extends Component { // 这个方法会被 Button 点击事件调用 onStartGame() { director.loadScene('GameLevel'); } }注意：编辑器的事件绑定点的是组件里的方法名，所以方法必须是public（TypeScript 里默认就是 public），而且不能有参数（或者参数能由事件系统自动传入，但新手阶段建议保持无参）。绑定完成后，运行预览，点击按钮，场景就会切换。
3.2 代码动态绑定点击事件的写法
编辑器拖拽绑定虽然直观，但因为事件配置存在.scene文件里，重构脚本时极易失效——比如方法改名了，或者脚本重新挂载了，编辑器里的事件引用就断了，点击没反应，而且没有报错，排查成本很高。
代码绑定则灵活得多。在start生命周期里获取按钮节点，注册监听：
import { _decorator, Component, Button, director } from 'cc'; const { ccclass } = _decorator; @ccclass('MainMenu') export class MainMenu extends Component { start() { // 先从当前节点下找到按钮 const btn = this.node.getComponent(Button); if (btn) { btn.node.on(Button.EventType.CLICK, this.onStartGame, this); } } onStartGame() { director.loadScene('GameLevel'); } onDestroy() { // 反注册，防止内存泄漏 const btn = this.node.getComponent(Button); if (btn) { btn.node.off(Button.EventType.CLICK, this.onStartGame, this); } } }Button.EventType.CLICK在 Cocos Creator 3.x 里可以直接写成'click'，但用枚举是官方推荐做法，因为引擎升级时若枚举值变了，代码会自动适配。这里要注意，组件挂载的节点本身必须是 Button 节点，getComponent(Button)才能拿到组件。如果你的按钮是子节点，需要先this.node.getChildByName('StartBtn').getComponent(Button)找到子节点再取组件。
为什么我强调onDestroy里要off反注册？因为 Cocos Creator 的事件系统是在 Node 上监听的，虽然场景销毁时节点本身会释放，但如果节点被做成常驻节点（后续会讲），或者按钮被复用，不反注册就会导致回调被多次触发。新手阶段可以宽松一点，但养成随手off的习惯，对后面做复杂项目绝对有好处。
3.3 事件绑定最容易踩的三个坑
第一个坑：重复绑定导致点击一次触发两次跳转。典型场景是你在onLoad里写了node.on(...)，然后场景切回来再次加载时，又执行了一次onLoad，同一个按钮被绑了两次监听。点击一次，loadScene被调用两次，第一次成功后场景已经切走了，第二次往往报错或者出现诡异的 bug。对策就是确保绑定逻辑只执行一次，或者在绑定前先off一次。
第二个坑：按钮事件回调里场景名拼写不一致。编辑器里看场景文件名是GameLevel，但代码里写成了gameLevel，或者多了个空格。场景名是区分大小写的，这种错误在运行时表现为点击按钮没反应，控制台报Failed to load scene。排查方法很简单：在回调第一行打印场景名，确认传入的值正确。
第三个坑：隐藏节点上的按钮仍然可以被点击。有些新手把 UI 面板切走时只是node.active = false，但忘记把按钮的interactable设成 false，导致玩家疯狂点击屏幕时触发了一连串场景切换。建议在切换场景前，先禁用所有 UI 的交互，或者直接销毁入口按钮节点。
4. 场景切换中的数据保存：不留神就会丢的全局变量
先说一个很多新手都会犯迷糊的认知误区。很多人以为，我在场景 A 的某个组件里写了一个static count = 0，或者声明了一个全局变量window.gameData = {}，切换场景后这个数据应该还在。事实上，静态属性和挂载在window上的全局数据在场景切换后确实还在，因为它们不属于任何一个场景节点。真正会被销毁的，是挂在节点组件上的普通实例属性。
比如你写了这么一个组件：
@ccclass('PlayerData') export class PlayerData extends Component { score: number = 0; }然后把它挂在了场景 A 的某个节点上，玩家玩了一会儿，score变成了 500。一切换场景，这个节点连同组件一起被销毁，score就没了。数据跟着组件走，组件跟着节点走，节点跟着场景走——这是理解场景数据保存最核心的一句话。
4.1 最实用的跨场景数据方案：全局单例
跨场景保存数据的办法有很多，最实用也最推荐新手使用的是全局单例。原理很简单：把数据挂在模块级别，而不是场景节点上，这样场景销毁重建不影响它。
// GameData.ts export class GameData { private static _instance: GameData | null = null; static get instance(): GameData { if (!this._instance) { this._instance = new GameData(); } return this._instance; } score: number = 0; level: number = 1; }在任意场景的组件里读写：
import { GameData } from './GameData'; // 写入 GameData.instance.score += 100; // 读取 const score = GameData.instance.score;这个单例不依赖任何场景节点，纯粹是一个 JavaScript 对象，只要游戏进程不退出，数据就一直在。配合loadScene的回调使用，就能实现"结算页读取关卡数据"这种常见需求：
// 在关卡场景里，玩家死亡时 GameData.instance.score = this.score; GameData.instance.level = this.currentLevel; director.loadScene('GameOver', () => { console.log('结算场景已加载，当前分数', GameData.instance.score); });注意，全局单例在场景切换后不会被销毁，所以要注意数据重置时机。比如玩家点击"重新开始"时，需要手动把score清零。否则会出现上一局的分数带到下一局这种 bug。
4.2 常驻节点：跨场景存活的另一种思路
全局单例适合存数据，但如果你要跨场景保留的是一整个节点（比如背景音乐播放器、全局消息提示 UI、玩家角色模型），那更合适的是常驻节点。
Cocos Creator 提供了game.addPersistRootNode(node)接口，把一个节点标记为常驻。被标记后，这个节点在场景切换时不会被销毁，而是原封不动地保留到下一个场景。比如：
import { _decorator, Component, game } from 'cc'; const { ccclass } = _decorator; @ccclass('BackgroundMusic') export class BackgroundMusic extends Component { onLoad() { // 把这个节点设为常驻节点 game.addPersistRootNode(this.node); } }这个BackgroundMusic组件挂在场景根节点下的一个空节点上，节点上挂了一个 AudioSource 组件。只要这个场景加载过一次，音乐节点就会跨场景存活，后续切换场景音乐都不会断。
用常驻节点要注意一个问题：不能重复挂载。如果主菜单场景加载时生成了一个常驻节点，进入游戏关卡后，关卡场景里又有一个同名节点调用了addPersistRootNode，内存里就会有两个音乐播放器，声音重叠。稳妥的做法是先检查是否已存在：
onLoad() { // 避免重复常驻 if (!game.isPersistRootNode(this.node)) { game.addPersistRootNode(this.node); } }实际项目中我的习惯是：数据用全局单例，UI/音频/玩家角色等需要存活的节点用常驻节点，两者配合使用。全局单例灵活、轻量，但要自己管理生命周期；常驻节点直观、天然支持组件，但要防重复挂载。新手从全局单例入手就好，等遇到"场景切换后背景音乐中断"这类问题时，再引入常驻节点。
5. 真机调试与场景加载优化：实测中容易忽略的细节
场景切换在不同环境下表现差异很大，我见过不少人在浏览器预览里一切正常，一打包到真机就各种问题。这里的坑，值得专门写一节。
5.1 编辑器预览和真机的差别
在浏览器里调场景切换，资源加载用的是本地文件服务，速度快，基本看不到白屏。但打包成 APK 后，资源需要从本地包体或者远程服务器加载，速度会慢很多。低端安卓机上，一个大场景从loadScene到显示，耗时可能超过两秒。
所以我建议所有做场景切换的教程项目，从一开始就要养成用真机预览的习惯。Cocos Creator 支持浏览器预览的同时，也支持直接连接安卓设备进行真机调试。真机测试能暴露出一堆开发模式下发现不了的问题：加载慢、内存不足闪退、音频资源没打包进去等。
5.2 场景加载性能优化的三个方向
场景加载慢的根本原因是资源量太大。优化的方向有三个：
第一，资源裁剪。同一个场景里尽量不要塞入另一套场景的专属资源。比如主菜单场景的背景图，不应该引用关卡场景里才用到的模型、贴图。Cocos Creator 在构建时会做资源合并，但如果你在多个场景里引用了同一张大图，它会被打入多个场景包，造成重复下载和重复内存。
第二，图集合并。UI 图片尽量打图集，而不是散图。散图数量一多，加载时间会指数级上升。创建图集的方式是在assets面板选中多张图片，右键 → 创建图集。合并后，原本几百张小图变成了一张大图加一个配置文件，加载效率极大提升。
第三，场景分包与远程加载（进阶）。Cocos Creator 支持把某些资源放到 Bundle 里，按需加载。比如你的游戏有 10 个关卡，每个关卡 100MB 资源，全部打进安装包显然不行。这时候可以把每个关卡单独做成一个 Bundle，玩家玩到第 3 关时，才动态下载第 3 关的 Bundle，加载完再进场景。这个方案对新手来说偏复杂，但至少要知道有这种玩法，等项目体量上去了再回来看这篇文章，你会发现方向还是对的。
5.3 常见报错和排查思路
最后整理几个我遇到过的、跟场景切换直接相关的报错，方便你遇到问题时快速定位。
场景名找不到的报错，控制台会提示Scene 'xxx' not loaded。先检查构建发布面板里有没有勾选该场景，再看代码里的字符串大小写和拼写。如果两个都确认无误，就把xxx.scene文件从 assets 里删掉重新导入一次，偶尔会有缓存的坏文件。
切换后卡在加载界面，常见原因是新场景的某个脚本在onLoad里抛了异常。此时新场景没有正常渲染，但引擎又已经销毁了旧场景，看起来就像卡死。排查方法是看控制台是否有红色报错，或者在onLoad里加日志，看看节点创建到哪一步停下来了。
内存溢出的报错表现为运行一段时间后游戏被系统杀掉。这时候去检查有没有频繁切换大场景而没有释放资源。Cocos Creator 3.x 有资源管理器，但默认不会立刻释放旧场景的资源。如果你遇到明显的内存增长，可以在切换场景前手动调用资源释放接口，把旧场景不再使用的资源释放掉。
有个细节值得一提，切换场景时的加载动画，我建议做成独立的加载场景，而不是在当前场景上叠一个加载 UI。因为director.loadScene在加载过程中，旧场景的节点还在，但主循环可能处于阻塞状态，UI 动画不一定能流畅播放。独立加载场景的思路是：主菜单点击"开始"后，先切到一个非常简单的Loading场景，在Loading场景里做预加载，加载完成后再切到真正的游戏场景。这个方案虽然多了一次切换，但体验更好，也是商业游戏里最常见的做法。
如果你现在手头正好卡在场景切换上，我的建议是：先做最小的例子，一个小场景 A 一个场景 B，一个按钮一次切换，跑通之后再逐步增加资源量、添加数据传递、做预加载。把这篇文章提到的每个环节都亲手验证一遍，你对 Cocos Creator 场景机制的理解，会比看十遍文档都扎实。
