Cocos Creator入门攻略：从编辑器安装到APK打包完整实践

Cocos Creator 入门到底该怎么入？我从装编辑器到打包APK的完整记录

我身边隔三差五就有人问我同一个问题：我想学做游戏，到底该选哪个引擎？市面上的选择确实多，Unity、Unreal、Godot，各有各的道理。但如果你的目标不是做一款大型3D作品，而是做一款能在手机上流畅跑起来、能发到微信小游戏平台、最好一个人就能快速把原型做出来的2D游戏，那 Cocos Creator 几乎是我最愿意推荐的选择。它全称叫 Cocos Creator，但不只是个"引擎"，更是一套从场景编辑、脚本编写、资源管理到构建发布全流程覆盖的内容生产工作台。

这篇文章不是官网文档的复述，而是我实际从零开始用 Cocos Creator 之后的系统梳理。内容会覆盖：这个引擎到底适合做什么、开发环境怎么搭、节点和组件以及脚本这三大核心概念到底怎么理解、如何做一个能玩的小Demo、以及很多新手最关心的——怎么把项目打包成 APK 装进手机。整条链路跑通过一次，你对 Cocos Creator 的认知就不再是一堆零散知识，而是一个完整的开发闭环。如果你第一次接触游戏引擎，或者以前只写过前端后端、想转游戏开发，这篇内容应该能帮你少走不少弯路。

1. Cocos Creator到底是什么：一个编辑器优先的2D游戏工作台

先说结论：Cocos Creator 是一个编辑器优先的游戏开发工具，尤其擅长2D游戏和微信小游戏这类轻量级项目。所谓"编辑器优先"，是说它把早期 Cocos2d-x 那种纯代码拼场景的方式，变成了可视化操作。这个变化对独立开发者和新手来说，影响是颠覆性的。

1.1 它跟传统纯代码游戏开发的区别

在 Cocos2d-x 那个年代，做游戏基本靠代码流。场景里放一个按钮，要手写精灵、手写坐标、手写触摸响应；换一张图，要重新打包资源，跑起来才知道效果。而 Cocos Creator 打开编辑器就能直接操作：把节点拖进场景，在属性检查器里改坐标、颜色、尺寸，再给节点挂一个脚本组件，保存后马上就能预览。这种"所见即所得"的体验，做前端的朋友应该很熟悉——就像以前用纯文本写网页，后来有了带实时预览的可视化编辑器一样。

如果拿一个更生活化的比喻来解释：纯代码开发像是买来一堆木板和钉子，从零开始手工做家具，尺寸错了要拆了重来；Cocos Creator 则像给了一个带图纸和半成品模组的木工工作台，你只需要拖拽零件、拧紧螺丝、涂上颜色，成品立刻呈现。剩下需要你动手的，是装什么零件、零件之间怎么配合，也就是游戏逻辑本身。

1.2 它真正擅长做的几类项目

作为一个从业者，我见过不少人把 Cocos Creator 和 Unity 放在一个维度上硬比，然后得出"它不如Unity"的结论。这种比较其实没有意义，因为它俩的定位就不一样。Cocos Creator 的强项很明确，我总结为四类：

• 2D休闲游戏：消除、跑酷、棋牌、超休闲，这是它的基本盘，市面上大量爆款都是这个类型。
• 微信小游戏、抖音小游戏：这是 Cocos 最具竞争力的领域，它对小游戏平台有非常完善的原生适配，很多现象级小游戏都用它开发。
• H5互动页面和营销小游戏：需求方往往要得很急，Cocos 出包快、预览方便，特别适合这类"快速上线、快速迭代"的项目。
• 学习游戏开发原理：因为逻辑全在 TypeScript 里，结构清晰简单，比一上来就学大而全的引擎更容易理解游戏运行的核心机制。

技术底层方面，Cocos Creator 3.x 基于自研的3D渲染器，同时完整支持2D渲染，2D和3D可以在同一个场景里混排。虽然它的3D能力跟 Unity 这种全平台大引擎相比确实有差距，但做中轻度3D项目、或者在2D游戏里穿插一点3D效果，已经完全够用。选引擎这件事，先看项目类型再选工具，而不是选个"最强引擎"硬套所有需求。

2. 环境准备：装好编辑器，跑通第一个场景

说实话，游戏引擎入门的第一道坎不是写代码，而是把开发环境搭好。我见过太多人卡在这一步就放弃了，其实整个过程没多难，但有几个知识必须先理清。

2.1 版本怎么选：2.x还是3.x

在开始装编辑器之前，必须先面对一个很现实的问题：Cocos Creator 有2.x和3.x两个大版本，网上教程很多是2.x时代的，代码长得完全不一样。2.x早期的写法是cc.Class，到了3.x全变成现代 TypeScript 的装饰器写法。你要是混着看，很容易被绕晕。

2.x最后的稳定大版本是2.4.x，官方把它作为长期维护版本。它的插件生态相对丰富，老教程多，很多已上线项目还是2.x。但2.x的架构比较老，3D支持不完整，官方已经不再增加新功能。3.x是从底层重构过的版本，接口统一，脚本语言强制 TypeScript，3.8.x 是我个人比较推荐的一个稳定版本。

如果你现在才开始学，别犹豫，直接上3.8.x。原因很简单：官方文档、新示例、新插件都围绕3.x更新，你学完立刻能用上；反过来跟着2.x老教程学，报错的时候搜到的解决方案很可能完全不适用，想死的心都有。

有个好消息是，Cocos 官方通过 Dashboard 这个工具管理编辑器版本，一个 Dashboard 里可以同时装2.x和3.x的多个版本，项目之间切换也很方便。所以不存在"装错版本全盘重来"的问题，放心尝试。

2.2 项目目录里这些文件夹都是干嘛的

第一次创建 Cocos Creator 项目的人，很容易被项目文件夹里那一堆英文目录吓到。其实你真正需要手动维护的只有一个：assets目录。其他的基本都是自动生成的，不用管。

• assets：你的所有游戏资源都在这里，场景、脚本、图片、音频、预制体，全部必须放进这个目录。
• library：编辑器导入资源后自动生成的缓存数据库，可以理解成图片、音频经过处理的中间格式。不要手动改，删了会自动重建。
• temp：临时文件，编辑器运行时产生的，不用管。
• local、profiles、settings：编辑器本地配置和项目设置，不需要手动操作。
• build：构建发布产物所在目录，你打的 APK、Web 包都会在这里出现。

这里有一个非常关键的机制：Cocos Creator 内部通过 UUID 管理资源，而不是通过文件路径。你在场景里引用了一张图片，之后在资源管理器里移动它的位置，场景里的引用不会断。这对项目重构特别友好，但同时也意味着：尽量不要在代码里用硬编码路径去加载资源。这个问题我在后面会专门展开讲。

2.3 创建第一个场景：从新建项目到点击预览

环境装好之后，我们来跑通第一个场景。

第一步：打开 Dashboard，在项目页点"新建"，模板选择 Empty(2D)。填项目名，确认路径，等编辑器加载完成。

第二步：新建2D模板后，assets里通常已经有一个默认场景文件，双击打开它。如果因为某些原因没有场景文件，就在资源管理器里右键 -> 创建 -> 场景，然后双击打开。新建出来的默认场景是空的，你需要在层级管理器里右键 -> 创建2D对象 -> Canvas，画布节点就出现了。Canvas 是2D游戏的根节点，所有 UI 元素都挂在它下面。

第三步：选中 Canvas 节点，右键 -> 创建2D对象 -> Label，场景里会出现一个文本。选中这个 Label，在右边的属性检查器里找到 String 属性，把它改成 "Hello Cocos Creator"。

第四步：点击编辑器顶部工具栏最左边那个三角形预览按钮。编辑器会在默认浏览器里打开一个页面，页面里就是你游戏的真实运行画面，上面显示着刚输入的这行文字。

第五步：按 F12 打开浏览器开发者工具，切到 Console 面板，能看到 Cocos 引擎的启动日志。

到这一步，你的 Cocos Creator 环境就算真正跑通了。很多人卡在"不知道从哪开始"，其实先把这条最基础的操作走一遍，你对"编辑器里的一切操作，最终会映射为游戏运行时的画面"这个抽象概念，就会有非常直观的认识。

3. 节点、组件和你写的第一行脚本

在 Cocos Creator 里，所有游戏内容都建立在三个核心概念之上：节点、组件、脚本。我见过不少人一开始就急着抠 API，结果越学越乱。其实只要把这三个概念之间的关系彻底搞清楚，编辑器里90%的操作你都能一眼看懂。

3.1 场景是一棵树，节点是空壳，组件是灵魂

一个游戏场景，本质是一棵节点树。根节点下挂着 Canvas，Canvas 下挂着各种 UI 节点，每个 UI 节点下面还可以继续挂子节点。节点（Node）本身能表达的只有空间属性：位置、旋转、缩放、透明度。它就像一张白纸，自身是空的，你要往上面贴东西，它才有实际内容。

贴在节点上的东西，就叫组件（Component）。一个节点可以同时挂很多个组件，各组件各司其职：

• Sprite 组件：让节点显示一张图片。
• Label 组件：让节点显示一行文字。
• AudioSource 组件：让节点能播放声音。
• 你写的脚本组件：让节点具备自定义逻辑。

同时，场景里的节点是有层级关系的：子节点会跟着父节点一起移动、旋转、缩放。这就是为什么所有 UI 都要挂在 Canvas 下面——Canvas 决定了一套屏幕适配策略，挂进去的 UI 全部跟随这个策略，不用你一个个手动处理缩放。

可以这样记：节点是空壳，组件是能力，层级决定归属。理解这三句话，Cocos Creator 的编辑器操作你就懂了一半。

3.2 生命周期：onLoad、start、update

写脚本的本质，是自定义一个组件。在 assets 里右键 -> 创建 -> TypeScript，生成一个脚本文件，双击打开就是一段模板代码。脚本组件的核心是生命周期函数，它们的调用顺序非常固定：

• onLoad：节点被激活到场景中时调用，且只调用一次。适合做初始化变量、注册事件这类工作。
• start：在第一帧 update 之前调用，也只执行一次。适合做依赖其他节点初始化结束之后的逻辑。
• update(deltaTime)：每一帧都会被调用。deltaTime是这一帧与上一帧之间的时间差，单位是秒，通常稳定在 1/60 左右。
• lateUpdate(deltaTime)：在 update 之后调用，适合做摄像机跟随这类需要等所有逻辑更新完再执行的事情。
• onDestroy：节点销毁时调用，适合做解绑事件、释放资源。

新手最容易犯的一个错误，是把 update 当成"每秒执行一次"。它其实是"每帧执行一次"，60帧设备上一秒跑约60次。所以只要涉及计时、移动、数值累积，必须把deltaTime乘进去，否则游戏在不同帧率的设备上速度会完全不一样。这个道理跟前端 requestAnimationFrame 里计算时间差是一样的逻辑。

3.3 通过一个倒计时Label把概念串起来

概念光看容易晕，来做一个最简单的倒计时文本，把上面这些串起来。

在 Canvas 下创建一个 Label，改名叫 TimeLabel。再创建一个 TypeScript 脚本，命名为 Countdown.ts，写入：

import { _decorator, Component, Label } from 'cc'; const { ccclass, property } = _decorator; @ccclass('Countdown') export class Countdown extends Component { @property(Label) label: Label | null = null; private totalTime = 0; private lastSecond = -1; update(deltaTime: number) { this.totalTime += deltaTime; const currentSecond = Math.floor(this.totalTime); if (currentSecond !== this.lastSecond) { this.lastSecond = currentSecond; if (this.label) { this.label.string = `运行时间：${currentSecond} 秒`; } } } }

然后把 Countdown 脚本拖到 TimeLabel 节点上。选中 TimeLabel 节点，在属性检查器里能看到脚本组件暴露出的 Label 属性槽，把场景里的 TimeLabel 节点拖进去。点击预览，屏幕上就会每秒更新一次时间。

这里有两个必须理解的点。

第一，@property(Label)装饰器的作用是让脚本暴露一个属性到编辑器面板上。你可以在编辑器里直接拖拽引用，而不需要在代码里写一长串查找节点的逻辑。这是 Cocos Creator 开发里极其重要的一种工作方式——能用编辑器关联的，就尽量少用代码查找。

第二，为什么用Math.floor(this.totalTime)判断秒数变化？因为 update 每秒执行几十次，如果每次都去设置 label.string，会出现无意义的字符串赋值和文本重排。只在秒数真正变化时才更新文本，这是一个很实用的小优化。

4. 动手做一个可玩的小Demo：点击方块计分

到这一步，刚需要的技能点基本都点亮了，是时候做一个真正可以玩的小游戏。我选的玩法最简单：点击屏幕上的方块加1分，同时方块随机跳到另一个位置。麻雀虽小，但覆盖了场景搭建、脚本编写、触摸事件、UI更新这几个核心能力，而且做完能真的玩起来。

4.1 场景搭建和资源准备

场景准备分两部分。

第一，在 Canvas 下创建一个 Sprite 节点，命名为 Target，这就是你要点击的方块。关于方块图片，最简单的方式是自己准备一张 100x100 的纯色 PNG，用画图工具或者其他图像软件都行，然后直接拖进 assets 目录导入。选中 Target 节点，在 Sprite 组件的 SpriteFrame 属性上赋值这张图片，再把节点尺寸 Content Size 设为 100x100。如果你看到 Sprite 是空白的，优先检查这两点：SpriteFrame 是否正确赋值、节点透明度是否为255。

第二，在 Canvas 下创建一个 Label 节点，命名为 ScoreLabel，字体大小调成40左右，颜色选个和背景有明显反差的，位置放在屏幕上方。这行文字就是分数UI。

场景搭好后，层级管理器里应该长这样：Canvas 下面挂着 Target 和 ScoreLabel 两个子节点。

4.2 核心玩法逻辑怎么写

给 Target 节点挂一个脚本 ClickHandler.ts。逻辑是：注册触摸事件，触摸结束时加分、更新UI、随机移动。

import { _decorator, Component, Node, Label, view } from 'cc'; const { ccclass, property } = _decorator; @ccclass('ClickHandler') export class ClickHandler extends Component { @property(Label) scoreLabel: Label | null = null; private score = 0; onLoad() { this.node.on(Node.EventType.TOUCH_END, this.onTouched, this); } onDestroy() { this.node.off(Node.EventType.TOUCH_END, this.onTouched, this); } private onTouched() { this.score++; if (this.scoreLabel) { this.scoreLabel.string = `分数：${this.score}`; } // 让方块在屏幕可见范围内随机移动 const size = view.getVisibleSize(); const halfW = size.width / 2 - 60; const halfH = size.height / 2 - 60; const newX = Math.random() * halfW * 2 - halfW; const newY = Math.random() * halfH * 2 - halfH; this.node.setPosition(newX, newY); } }

把脚本拖到 Target 节点上，再把 ScoreLabel 节点拖进脚本的 scoreLabel 属性槽，点击预览，去点那个方块。分数会累加，方块会随机乱跳。

这里有几个操作上的关键点。

第一，事件注册放在 onLoad、解绑放在 onDestroy，是绝对要养成的成对习惯。onLoad 保证节点一激活就能响应事件；onDestroy 负责清理，避免节点销毁后事件回调仍然触发，导致报错或内存泄漏。前端开发里 addEventListener 和 removeEventListener 不配对会出什么问题，在这里就一模一样。

第二，随机位置时为什么两端减60？因为节点本身有100x100的尺寸，如果直接用整个屏幕宽度随机，方块中心一旦靠近边缘，一半身子会跑到屏幕外面。减60大于半个边长，才能保证方块完整留在地面可见区域内。这种边界处理，新手往往想不到，但实际做游戏的时候处处都是这种细节。

第三，如果你的场景里还挂了别的 UI 元素，比如一个覆盖全屏的 BlockInputEvents 节点，它会把触摸事件全部吞掉，Target 怎么点都没反应。遇到"明明挂了事件却没反应"的问题，第一件事检查是不是有节点挡在 Target 上层。

4.3 在预览模式下调试

预览模式跑起来之后，调试主要靠浏览器控制台。在脚本里加一行console.log('click', this.score)，点方块时控制台就会输出。如果改了代码之后没有效果，先别急着怀疑编译器，大概率是预览页面没刷新。我的经验是：改变量、改UI属性，早点停掉预览重新启动；只是在已有逻辑里加日志的话，页面刷新一下就能看到最新代码。

另外，浏览器开发者工具的 Sources 面板里可以给脚本打断点。断点命中时，你可以暂停游戏运行，查看当前作用域里所有变量的值，再一步步往下走。这个手段对理解生命周期函数的调用顺序特别有帮助。比如在 onLoad、start、update 里分别打断点，刷新页面后观察它们的触发顺序，比看十遍文档印象都深。

5. 把项目打成APK装进手机

终于到了这个"压轴问题"：怎么把 Cocos Creator 项目打包成 APK。这也是很多新手从"做游戏"走向"游戏能装在手机里跑"的关键一步。我先泼盆冷水：第一次构建大概率不会一次过，但只要环境配好，后面就是流程化的操作。

5.1 打包前必须配好的三样东西

打包 Android 需要准备三样东西：JDK、Android SDK、Android NDK。

• JDK：Java 开发工具包。Cocos Creator 3.8 推荐 JDK 8 到 11 之间，我个人用的是 JDK 8，稳定，兼容问题少。
• Android SDK：包含 platform-tools、build-tools、platforms 等。如果你装过 Android Studio，SDK 已经在机器上了，记住路径就行。
• Android NDK：Cocos 构建原生工程时需要编译 C++ 部分的库，必须单独下载。Cocos Creator 3.8 官方推荐 NDK r21e，别随便换新版，很多诡异编译错误都是 NDK 版本不对引起的。

装好之后，打开编辑器菜单栏的"偏好设置 -> 外部程序"，把 SDK 和 NDK 路径填进去。这里是我踩过最深的一个坑：这几个路径绝对不能包含中文和空格，否则 Gradle 构建阶段会报出各种匪夷所思的错误，光排查就花了我一整个下午。

5.2 构建面板里的关键配置：包名和签名

在菜单栏打开"项目 -> 构建发布"，第一次会提示创建构建任务。新建一个任务，平台选择 Android。

进入配置面板后，大部分选项保持默认即可，但有三个地方一定要自己填：

• 游戏名称：手机桌面上显示的应用名，可以用中文。
• 包名：也就是应用ID，必须使用反向域名格式，比如com.yourname.clickgame。不能以数字开头，不能有中文和特殊符号。包名以后就是应用的身份标识，一旦上线就很难修改，建议一开始就认真想好。
• 签名：Android 应用必须做数字签名。在命令行执行 keytool 生成密钥库文件：

keytool -genkey -v -keystore clickgame.keystore -alias clickgame -keyalg RSA -keysize 2048 -validity 10000

执行过程中会让你设置密钥库密码、确认一些身份信息，一般随便填都行。最后会生成一个 clickgame.keystore 文件，把它放进一个安全目录，然后在构建面板的签名配置里填上 keystore 路径、密码、别名和别名密码。

注意：keystore 文件和密码务必多备份几次。如果应用已经发布，换一个新 keystore 重新签名，系统会认为这是另一个应用，你将无法覆盖升级旧版本，这个代价是很惨痛的。

构建面板里几个关键配置项，我整理成了表格：

5.3 从Gradle构建到生成APK的完整过程

配置完成后点击"构建"按钮，接下来就是漫长的等待。Cocos Creator 3.x 的 Android 构建流程分两段：第一段编辑器把项目资源打成发布包，第二段生成一个完整的原生 Android 工程，再调用 Gradle 编译成 APK。第一次构建尤其慢，因为 Gradle 要下载依赖、NDK 要编译原生代码，整个过程即使机器性能不错，也要十几分钟到半小时。

构建完成后，APK 的默认输出位置在项目目录下：

build/android/proj/build/outputs/apk/debug/（Debug包）或build/android/proj/build/outputs/apk/release/（Release包），里面就是你的 .apk 文件。

安装到手机有两种方式。一种是数据线连接手机，打开手机的 USB 调试，在命令行执行：

adb install -r build/android/proj/build/outputs/apk/debug/demo-debug.apk

另一种更省事：在 Cocos Creator 构建面板里点击"运行"按钮，它会自动安装到已经连接的设备上。我建议新手直接用"运行"按钮，少敲命令，也就少出错的机会。

5.4 首次构建踩过的那些坑

我自己第一次构建 APK，整整折腾了两天，环境占了大部分时间。挑几个高频问题说说。

第一个是 Gradle 下载慢到像卡死。Cocos 生成的 Android 工程默认从国外地址下载 Gradle，国内网络动不动就超时。解决方法是修改生成工程里的gradle-wrapper.properties，把distributionUrl换成国内镜像地址；同时把工程根目录build.gradle里的仓库源加上阿里云 Maven 镜像：

allprojects { repositories { maven { url 'https://maven.aliyun.com/repository/public' } google() mavenCentral() } }

第二个是 SDK 版本对不上，报错信息类似Failed to find target with hash string 'android-31'。这说明本地 SDK 缺少对应版本的 platform，用 SDK Manager 装上就好。不建议新手直接去改构建配置里的 compileSdkVersion，因为可能把其他依赖的编译版本也带偏。

第三个是签名相关报错，比如密钥库密码错误、别名不存在。这种问题通常是大写没区分、粘贴密码时多了空格。记住，密码和别名都区分大小写，粘贴进去之前先敲一遍看看有没有多余字符。

第四个是 NDK 版本不对导致原生代码编译报错。不要用最新的 NDK 去试，Cocos Creator 3.8 对 NDK 版本有明确要求，通常官方文档写的是 r21e，就用 r21e 最省心。

还有一个很容易被忽略的问题：如果手机上已经装了相同包名的应用，再安装新测试包会提示"应用未安装"或安装失败。解决方法是先卸载旧应用，或者在构建配置里换一个新包名。

6. 入门阶段的几个典型坑与我最推荐的练手路线

功能都跑通之后，再分享几个我觉得对新手最有价值的经验。这些坑不是代码逻辑的问题，而是工作习惯的问题，避开它们，后面的学习会顺畅很多。

6.1 资源加载不要用硬编码路径

很多老教程喜欢教resources.load("textures/xxx")动态加载资源。这个写法本身没有错，但它有个前提：资源必须放在assets/resources目录下，而且路径不能带后缀。如果你从网上抄了一段代码，却忘了把资源放进 resources 目录，运行时就会得到 null 引用。

我的建议是：能拖就拖。把资源直接在编辑器中拖到脚本的@property属性槽上，让编辑器替你管理引用。这样有几个好处——资源被误删或移动位置时，编辑器会第一时间报错提醒，而不是等运行时才炸出神秘的 null；代码的可读性也更好，一眼就能看出脚本依赖哪些资源。

等以后真的需要动态加载，比如从服务器下载配置、按关卡读资源，再去认真看resources.load和assetManager的文档。入门阶段，优先掌握"编辑器引用"这条最稳妥的路。

6.2 分辨率适配先理解Canvas组件

换了不同比例的手机，UI 位置全乱了？这几乎是每个新手必经的坎。

Cocos Creator 的 2D UI 适配核心是 Canvas 组件。选中 Canvas 节点，属性检查器里可以看到设计分辨率、适配策略（fitWidth/fitHeight）。设计分辨率是你做 UI 时的基准尺寸，比如 750x1334。适配策略决定不同屏幕上如何缩放：fitHeight 就是保持 UI 高度刚好等于屏幕高度，宽度不够的部分左右裁掉；fitWidth 同理。

所以做 UI 有个通用原则：重要的信息、操作按钮放在屏幕中央区域，边缘部分默认就可能被裁切。想让某个按钮始终固定在屏幕右上角，不要在父节点下手动算坐标，而是给按钮挂一个 Widget 组件，设置为右对齐、上对齐，它会自动根据实际屏幕调整位置。手动量出来的坐标，在开发机上看着没问题，换个手机就露馅。

6.3 我最推荐的练手路线

看完这些经验，如果你决定开始动手，我建议的路径是这样的：先把官方示例项目里的 Demo 从头到尾跟做一两个完整的，注意是每行代码都自己敲，不是复制粘贴。然后挑其中一个 Demo，改规则——把跳跃改成收集，把点击计分改成拖拽跟随。这一步的目的是确认你真正理解了逻辑，而不是单纯照抄。再下一步，找一个你想复刻的小游戏玩法，用纯色方块当素材，重做一遍，然后打包 APK 到自己手机上跑起来，发给朋友玩一圈。

我个人体验最深的结论是：入门阶段最值钱的能力不是背 API，而是把脑子里的想法快速变成一个能运行的东西。只要"场景 -> 代码 -> 预览 -> 构建 -> 手机"这条链路跑通过一次，后面所有的知识点，其实都只是往这条链上继续挂新东西而已。

最后再分享一个小技巧。如果你在社区里提问，说"为什么我的 Cocos 写法和某个教程不一样"，八成是版本差异。一开始学就把版本定死，遇到问题优先用官方文档搜，其次用报错信息原文去搜社区，再看视频教程。报错信息里的关键单词复制准确，能帮你找到真正有用的答案。我后来回想，自己在 Cocos Creator 上浪费得最多的不是代码逻辑，而是环境、版本、依赖这三件事，希望这篇内容能让你少走我走过的这些弯路。