简介：这是一份基于 Cocos Creator 开发的微信小游戏完整源代码，面向使用 Cocos Creator 进行微信小游戏开发与打包的开发者，尤其适合以“小鸟”类休闲游戏为切入点学习引擎构建与发布流程的读者。资源包共 592 个文件，压缩包大小约 1.67MB，包含 289 个 json 配置数据文件、180 个 png 图形素材、81 个 meta 资源元数据、17 个 js 与 2 个 ts 脚本文件，另有 plist 图集、fire 场景文件、fnt 位图字体以及 gltf 模型文件，覆盖场景搭建、素材管理、逻辑控制与资源配置等核心环节。目前已有 3301 人学习下载，具备较高的参考热度。通过这份源码，读者可以直观了解 Cocos Creator 工程中各类资源文件的分工与组织形式，理解 json 配置如何驱动场景、png/plist 如何组织图片、js/ts 脚本如何挂接节点逻辑，也能掌握将游戏发布为微信小游戏所需的目录结构与基础配置要点。基于现有“小鸟”游戏逻辑，还可进行玩法扩展、UI 调整或素材替换，是一份兼顾入门学习与二次开发的实用素材。1. 拿到 Cocos Creator 小鸟源码先别双击工程：版本决定你能不能跑起来如果你手里也有一份Cocos Creator 打包成微信小游戏的小鸟游戏源代码，最忌讳的第一件事就是双击工程文件直接打开。类似「Cocos Creator 小鸟」这种流传较广的练手项目，很多是在 2.x 时代写的，而你电脑上装的可能是 3.x，绝大多数情况下工程直接打不开——脚本编译报错、场景资源丢失、构建按钮灰掉，每一步都在消耗耐心。正确的顺序是：先看引擎版本，再决定是直接打开还是先做工程迁移。这份资源本质上是一个完整可运行的小游戏工程，包含场景、预制体、游戏脚本、构建配置，核心玩法就是点击起跳、穿过管道、计分、碰撞结束。它解决的问题很具体：不用从零搭框架，拿到手改一改素材和参数，就能构建出在微信里跑的竖屏小游戏。适合两类人：一类是第一次接微信小游戏、想知道整套发布链路怎么走的开发者；另一类是想要一个干净模板、快速验证玩法原型的熟手。我的做法是，先把它当成「可运行的参考实现」，再逐步替换成自己的东西。2. 微信小游戏不是网页：运行环境、屏幕适配与资源策略2.1 没有 DOM 的渲染环境：引擎是怎么塞进微信的微信小游戏运行在一个阉割过的浏览器内核里，没有document、没有window、没有 DOM 树，只提供 Canvas 和 WebGL 渲染接口。Cocos Creator 之所以能把游戏打包进去，靠的是一层适配层——把引擎内部对 DOM、Audio、本地存储的调用，全部转接到微信小游戏提供的wx.*接口上。Cocos Creator 2.x 和 3.x 在这层的处理方式不同：2.x 更像是在原有网页渲染体系外面包一层 polyfill，不少浏览器 API 被强行模拟出来；3.x 从架构上就把渲染层直接对接 WebGL，适配更干净。你可以通过构建产物来验证这一点。# 构建完成后进入微信小游戏产物目录 cd build/wechatgame # 查看顶层结构 ls -la # 查找引擎适配层相关文件 find . -name "*adapter*" -o -name "sys*" | head -20构建产物里会有src/、assets/、engine/之类的目录，engine/下就是被编译过的引擎适配代码。如果你看到大量wx.createCanvas、wx.getSystemInfoSync这类调用，说明适配层工作正常。拿到任何一份 Cocos 小游戏源码，建议先执行这一步，确认构建产物完整，再回过去看源码工程。这里有个容易忽略的点：微信开发者工具模拟器能跑，不代表所有接口在真机上可用。适配层代码在模拟器和真机上走的是同一套逻辑，但真机上 Canvas 的创建时机、触摸事件的坐标换算、音频的加载策略都有差异，后面第 5 章会专门讲。2.2 屏幕适配：设计分辨率、适配策略与安全区小鸟游戏是竖屏玩法，画面宽高比在不同手机上差异很大——iPhone 的全面屏比例接近 19.5:9，老款安卓机是 16:9，老 iPhone 是 16:9 左右。如果不做适配，会出现两种情况：要么画面被拉伸变形，要么两侧被裁掉内容。Cocos Creator 的适配核心是cc.view.setDesignResolutionSize()加上 Canvas 组件的适配策略。设计分辨率就是你制作场景时用的逻辑尺寸，比如720x1280，真机渲染时引擎按策略换算成实际像素。适配策略行为适用场景风险SHOW_ALL完整显示设计分辨率内容，留黑边拼图、棋牌类两侧或上下留边，不美观FIXED_WIDTH宽度铺满，高度方向可超出裁剪竖屏跑酷、射击、小鸟顶部或底部可能被裁掉FIXED_HEIGHT高度铺满，宽度方向可超出裁剪横屏游戏左右可能被裁掉NO_BORDER按比例放大到铺满全屏，四周裁剪全屏沉浸式裁剪最多，UI 位置要小心小鸟这类竖屏游戏，我一般用 FIXED_WIDTH。玩法核心是角色左右移动范围固定，宽度保持一致能保证管道间距在每台设备上视觉一致，高度方向多一些少一些影响不大。// 在 game.js 或首场景的启动脚本里设置 view.setDesignResolutionSize(720, 1280, ResolutionPolicy.FIXED_WIDTH);需要注意一个坑：Cocos Creator 3.x 里，designResolution的设置在构建面板的「适配屏幕」选项里也能配，而且构建面板的配置会覆盖代码。所以如果你在脚本里改了分辨率但真机上没生效，先检查构建面板的「适配屏幕宽度/高度」是不是被勾成了另一个策略。安全区问题同样不能漏。全面屏手机的底部有横条，顶部有刘海，如果你把分数 UI 放在屏幕最顶部或操作按钮放在最底部，真机上很可能被遮挡。微信小游戏提供了wx.getSystemInfoSync().safeArea，在 Cocos 里可以通过sys.getSafeAreaRect()拿到逻辑坐标下的安全区。拿到后，把关键 UI 强制约束在该矩形内。2.3 资源打包策略：主包 4MB 与 Bundle 拆分微信小游戏主包有 4MB 的体积限制，超过就上传失败。小鸟游戏的资源其实很小：几张鸟的序列帧、几张管道图片、一个背景、两三个音效，加起来通常不到 1MB，完全可以内嵌在主包里。但如果你替换了高清素材，或者加了一堆 UI 贴图、粒子特效，体积很快就会顶到上限。Cocos Creator 3.x 提供了 Bundle 机制，可以把资源拆成多个子包，主包只保留首屏必需内容，其余资源在需要时动态加载。判断当前构建产物体积是否超限，命令很简单：# 在构建产物目录下查看体积 du -sh build/wechatgame # 如果只关心首包（子包会单独列目录） du -sh build/wechatgame/assets我拿到这份小鸟源码后，先看 assets 目录，如果里面资源文件不多，默认就是单包模式，不需要额外拆分。真正要拆的场景是：你打算把鸟的动画帧、背景音效全部替换成高质量素材。我遇到过一次，替换了一套 2K 背景图，主包直接到 5.2MB，上传被拒，后来把背景图和音效挪到子包，启动时先显示 Loading 再动态下载，问题才解决。拆 Bundle 的操作在编辑器里就能做：选中资源文件夹，在属性检查器里把「Bundle 名称」填上，资源就归到对应子包。加载时用assetManager.loadBundle()配合bundle.load()。不要把所有东西都塞进首包，也不要为了拆而拆——Bundle 的下载有延迟，首屏需要的东西留在主包，次要内容拆出去。3. 拆解小鸟游戏核心代码：场景结构、状态机与碰撞判定3.1 拿到源码先看目录与场景结构一份标准的 Cocos Creator 工程，最核心的目录是assets/，里面按常规会分成scenes/、scripts/、prefabs/、resources/。拿到源码后，我习惯先把assets/的目录树打出来，快速建立全局认知。# 在工程根目录执行 tree assets -L 2正常会看到类似结构：scenes/下放.scene文件（本质是 JSON 格式的场景描述），scripts/下放.ts或.js脚本，prefabs/下放可复用的预制体。小鸟游戏一般会有一个主场景，场景的 Canvas 节点上挂着游戏管理器脚本，鸟角色节点上挂着角色控制脚本。识别入口场景有一个技巧：打开assets/下的场景文件，搜索GameManager或类似命名的脚本类，那个场景大概率就是主入口。.scene文件很长，不要全文读，用编辑器打开后直接看节点树和组件列表，比看 JSON 直观得多。3.2 游戏状态机与鸟的物理模型小鸟游戏看起来简单，代码组织却需要一个清晰的状态机。原因很实际：鸟在「待开始」「飞行中」「游戏结束」三种状态下，响应完全不同——待开始时不掉下来，飞行中点击会起跳，结束后点击要重新开始。如果不做状态区分，逻辑会乱成一团。// GameManager.ts - 状态机核心 enum GameState { Ready, Playing, Over } // 单例管理节点状态 export class GameManager extends Component { public state: GameState = GameState.Ready; startGame() { this.state = GameState.Playing; // 鸟开始受重力影响 bird.enableGravity(true); // 管道开始生成与移动 pipeManager.startSpawning(); } gameOver() { this.state = GameState.Over; // 停止管道生成，播放碰撞动画 pipeManager.stopSpawning(); audioManager.playHit(); } onTouched() { if (this.state === GameState.Ready) { this.startGame(); } else if (this.state === GameState.Playing) { bird.jump(); } else if (this.state === GameState.Over) { this.restartGame(); } } }这段代码里，onTouched被全局触摸事件调用，通过判断state决定行为。这是小鸟游戏最核心的控制流——所有交互都收敛到这一个方法里，状态切换的入口非常清楚。鸟的物理模型是伪重力和伪速度，不需要引入完整的物理引擎。每一帧做两件事：速度累加重力增量，位置累加速度增量。// Bird.ts - 鸟的运动逻辑 public gravity: number = -1200; // 重力加速度，像素/秒²，负值向下 public jumpSpeed: number = 420; // 起跳瞬间的速度，像素/秒，正值向上 public rotationSpeed: number = 180; private _velocity: number = 0; update(dt: number) { // 未开始或已结束时不更新物理 if (gameManager.state !== GameState.Playing) return; // 重力改变速度，速度改变位置 this._velocity += this.gravity * dt; this.node.setPosition( this.node.position.x, this.node.position.y + this._velocity * dt ); } jump() { // 每次点击把速度重置为起跳速度，实现「拍打」效果 this._velocity = this.jumpSpeed; }gravity和jumpSpeed是影响手感的第一优先级参数。重力越大下落越快，跳跃速度越大单次抬升越高。我测试时习惯先把重力设到-1000、跳跃速度400，跑几轮之后按「跳一下上升大概 80~100 像素」的手感目标去微调。这份源码里这两个值一定写在脚本顶部或 Inspector 暴露面板上，改完保存就能在模拟器里直接感受差异，不用重新编译。3.3 管道生成、移动与得分检测管道是另一个核心模块。它的工作模式不是每帧新建实例，而是对象池复用——生成一组管道对，移动到屏幕左侧边界后回收，再放在右侧新的位置。这样做主要为了性能：小鸟游戏场景里通常同时存在 4~5 组管道，如果反复创建销毁节点，会造成频繁的 GC 暂停。// PipeManager.ts - 管道生成与回收 public spawnInterval: number = 1.4; // 每 1.4 秒生成一组管道 public gapHeight: number = 200; // 上下管道之间的缝隙高度 public moveSpeed: number = -160; // 管道左移速度，像素/秒 private _pipes: Node[] = []; update(dt: number) { for (let pipe of this._pipes) { pipe.position.x += this.moveSpeed * dt; // 移出屏幕左侧后回收 if (pipe.position.x < -900) this.recycle(pipe); } } generatePipe() { // 随机缝隙中心点：保证缝隙在上下管道之间，不会出界 const minY = -400; const maxY = 200; const gapCenter = Math.random() * (maxY - minY) + minY; // 上面管道底部 = 缝隙中心 - gapHeight/2 // 下面管道顶部 = 缝隙中心 + gapHeight/2 // 分别设置两组管道的 y 坐标后加入 _pipes }gapHeight是难度核心。缝越大越容易过，越小越劝退。spawnInterval决定了管道密集度，越短越紧张。我见过很多游戏的难度曲线就是在spawnInterval上做文章——每过 10 分减少 0.05 秒，配合gapHeight逐步缩小，玩家很难察觉难度在爬升。碰撞判定是这份源码里最值得看的部分。小鸟游戏不需要引擎级物理碰撞，用 AABB 包围盒相交检测就够了，代码量少、性能好、调试直观。// Collision.ts - 轴对齐包围盒碰撞检测 function checkAABB(bird: Rect, pipeRect: Rect): boolean { // 两个矩形相交的条件：X 方向与 Y 方向都重叠 return bird.x < pipeRect.x + pipeRect.width && bird.x + bird.width > pipeRect.x && bird.y < pipeRect.y + pipeRect.height && bird.y + bird.height > pipeRect.y; }它的原理简单说：把鸟和管道各看成一个矩形，检查它们在 X 轴和 Y 轴上的投影是否同时重叠。如果只用管道组的中心点做检测，会出现「鸟明明被碰到却被判定得分」的错觉——因为管道上下两根的矩形是分离的，中间缝隙不算碰撞，中心点检测会把缝隙和管道壁混为一谈。正确做法是对每根管道单独取矩形做检测。得分检测更简单——不用碰碰撞体，只比较位置坐标：当管道的 x 坐标第一次小于鸟的 x 坐标时，得分加一。这时候管道和鸟还没发生碰撞，玩家会有「刚好擦过去」的爽感。但要注意，一定要加一个「已得分」标记，否则同一组管道会在多帧内连续触发加分。4. 从 Cocos Creator 构建到微信开发者工具：完整发布流程4.1 构建面板参数配置Cocos Creator 的构建面板是所有平台发布的统一入口，选错参数会在后面浪费大量时间。构建平台的选项里选「微信小游戏」，然后逐个确认参数。参数推荐值说明AppID填写小游戏 AppID 或用测试号正式发布必须真实 AppID，测试号无法上传初始场景主场景（含 GameManager 的场景）启动后加载的第一个场景设备方向竖屏（Portrait）小鸟游戏必须是竖屏，设错会横着运行适配屏幕勾选配合 FIXED_WIDTH 策略生效MD5 Cache勾选资源文件名加 MD5 哈希，防止微信缓存旧资源调试模式开发时勾选，发布前取消勾选后保留调试日志，取消后体积更小主包压缩类型默认保持默认即可，不需要手动改有一个参数容易被忽略：初始场景。如果你做了一堆测试场景，忘了把入口场景指定为正式主场景，构建出来的包可能打开就是一个空白场景，甚至直接报错。4.2 导出构建产物并导入微信开发者工具构建完成后，产物默认在工程目录下的build/wechatgame。打开微信开发者工具，导入项目时选择build/wechatgame目录而不是工程根目录——这是新手最容易搞混的地方。# 构建完成后，先看一眼产物是否完整 cd build/wechatgame ls -la # 期待看到 game.json、project.config.json、src/、assets/ 等 # 如果没有 project.config.json，说明构建不完整，回到编辑器重新构建微信开发者工具导入后，还需要检查两件事：右上角详情里的「本地设置」要勾选「不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书」。这不是为了绕过什么审核，而是因为本地调试时使用的是局域网 IP 和临时资源路径，不校验才能正常加载。正式上传前要取消勾选，否则线上环境资源加载策略不同，可能出现本地能跑线上白屏的诡异现象。这步里最玄学的点在于：微信开发者工具的模拟器有时和真机表现不一致。触摸事件的模拟、帧率的差异、音频的时序，都可能不同。所以我在模拟器里能跑通后，不会急着收工，而是用开发者工具右上角的「预览」按钮生成二维码，用手机微信扫码真机跑一遍。4.3 构建产物快速排错：看日志与查进程真机预览报错时，第一反应不应该是改代码重新构建。先打开微信开发者工具的「调试器」面板，切换到 Console 标签页，把报错信息里的文件名和行号记下来。最常见的情况是资源路径错误或脚本空引用，日志会直接告诉你。还有一种情况是点了「预览」二维码但手机打开后长时间黑屏。不要急着删包，先确认是否首次加载子包资源——如果你把资源放进了 Bundle，首次进入会有一个下载过程，在弱网下可能要等好几秒，黑屏其实是资源下载中。这时候在工程代码里加一个 Loading 转圈提示，比优化加载速度更重要——玩家不知道卡了还是挂了，体验差别很大。5. 打包微信小游戏常见问题复盘：五条现象、原因与处理5.1 构建后导入工具直接白屏，报 Cannot read property of undefined现象：构建产物导入微信开发者工具，模拟器一片白，Console 里报错指向引擎源码里的某一行。原因：90% 的情况是 Cocos Creator 编辑器版本和构建产物引擎版本不一致。比如你前几天用 3.x 构建过一版，今天换了 2.x 工程直接构建，旧的构建缓存没清理，产物理的引擎适配层被旧代码污染。解决：在构建面板点右下角的「清除」按钮，删掉整个build/wechatgame目录，重新构建。这一步能解决绝大多数构建产物异常。如果还是白屏，把微信开发者工具的「缓存目录」也清一遍——工具本身会缓存编译中间文件，会导致代码更新不生效。5.2 真机上角色乱飞、位置偏移，模拟器却一切正常现象：模拟器里鸟的位置和点击响应完全正常，换成真机后鸟飞到屏幕外、点击位置偏了半个屏幕。原因：模拟器默认使用工具的窗口尺寸，真机的屏幕物理尺寸、像素密度都不同。如果适配策略是 SHOW_ALL，不同宽高比会产生黑边，节点坐标和触摸坐标的换算就会被拉伸扭曲。解决：确认竖屏游戏的适配策略统一为 FIXED_WIDTH 或 FIXED_HEIGHT，不要混用。检查 Canvas 组件里的适配设置和代码里setDesignResolutionSize是否冲突，以代码为准，构建面板的「适配屏幕」保持勾选即可。另外真机调试时先执行wx.getSystemInfoSync()，确认拿到的屏幕宽高比和设计分辨率是否是同一方向。5.3 音频真机无声，模拟器正常播放现象：点击起跳的音效、碰撞的音效在模拟器里都正常，真机上完全无声。原因：微信小游戏对音频有明确的自动播放限制——不允许在没有任何用户交互前播放音频。如果你的play()调用发生在场景启动、碰撞检测等没有用户手势触发的时机，微信会直接丢弃这次播放请求。解决：把音频初始化放在第一次用户触摸的回调里。比如在主场景的onTouched里先执行audioManager.resume()或audioSource.play()，之后再播放任何音效都没问题。我通常会监听里一次触摸事件，在触摸回调里调用wx.setInnerAudioOption({ obeyMuteSwitch: false })并预热音频实例。5.4 主包超过 4MB，上传被拒现象：构建成功，但上传到微信公众平台时提示主包超限。原因：资源文件体积过大，主要是图片。PNG 原图动不动几 MB，序列帧动画更是重量级。小鸟游戏的动画帧如果做成 512x512 的高清图，很容易爆掉。解决：图片用 TinyPNG 或 Cocos Creator 内置压缩工具压到 1024 以内；音频如果是 WAV 转成 m4a 或 mp3，码率控制在 128kbps。还放不下就把背景图和音效拆进 Bundle，主包只留玩法必须的场景和脚本。判断主包体积的准确方式不是看整个build/wechatgame目录，而是看assets子目录和src子目录的总和。5.5 每次改代码，真机预览看到的还是旧版本现象：代码改了一轮，真机预览跑起来发现功能没变，或者画面卡在最旧的资源版本。原因：微信开发者工具和手机端都有资源缓存。工具缓存的是编译中间文件，手机缓存的是已经下载的资源包。Cocos Creator 构建产物里的文件不带 hash 时，同名文件会命中旧的微信缓存。解决：开发阶段每次预览前，在微信开发者工具菜单里执行「清除缓存 -> 全部清除」，再重新编译。正式发布时一定把 MD5 Cache 勾选上，这样资源文件名带哈希值，旧文件在微信服务器上无法命中，玩家自动加载新版本——这是最稳妥的线上更新机制。6. 发布前用「真机三连」验证一次：比跑十遍模拟器都管用有过一次深刻的翻车教训。某次我把一个改好的版本在模拟器里跑了几十遍，感觉万无一失，直接上传提审。结果审核人员在真机上打开，发现游戏结束界面弹出的分数数字偏到屏幕外面，整个 UI 被安全区挤压变形。问题本身不大，但整套提审流程重走一遍的时间成本很高。从那以后，我养成了一个强制习惯：每次准备上传前，都执行一遍「真机三连」验证。第一连，微信开发者工具的「真机调试」模式打开，手机扫码后在手机屏幕上操作，桌面上同步看 Console 日志。重点观察有没有资源加载失败、空指针、警告信息。第二连，在真机调试面板里打开性能监控，盯两点：帧率是否稳定在 30fps 以上，Draw Call 是否在一个合理区间。小鸟这类 2D 轻量游戏，Draw Call 超过 50 就说明有节点没有合批，图片资源该做合图了。第三连，关闭「不校验合法域名」，用正式域名配置重新跑一遍真机预览——这一步模拟的是线上环境，能提前发现资源域名校验问题。一套走完大约十分钟，换来的是一份「这个包上传后大概率不会被退回」的信心。特别是经历过真机翻车之后，我越来越认同一个观点：模拟器跑通的只是黑匣子里的逻辑，真机跑通的才是玩家实际体验。这期间也有后悔药可吃——微信开发者工具的「版本管理」功能可以回退到上一个上传的版本，但回退会中断审核流程，影响上线的时效。与其事后补救，不如发布前把这三连当成固定的验收流程。希望帮到你。本文还有配套的精品资源，点击获取
简介：这是一份基于 Cocos Creator 开发的微信小游戏完整源代码，面向使用 Cocos Creator 进行微信小游戏开发与打包的开发者，尤其适合以“小鸟”类休闲游戏为切入点学习引擎构建与发布流程的读者。资源包共 592 个文件，压缩包大小约 1.67MB，包含 289 个 json 配置数据文件、180 个 png 图形素材、81 个 meta 资源元数据、17 个 js 与 2 个 ts 脚本文件，另有 plist 图集、fire 场景文件、fnt 位图字体以及 gltf 模型文件，覆盖场景搭建、素材管理、逻辑控制与资源配置等核心环节。目前已有 3301 人学习下载，具备较高的参考热度。通过这份源码，读者可以直观了解 Cocos Creator 工程中各类资源文件的分工与组织形式，理解 json 配置如何驱动场景、png/plist 如何组织图片、js/ts 脚本如何挂接节点逻辑，也能掌握将游戏发布为微信小游戏所需的目录结构与基础配置要点。基于现有“小鸟”游戏逻辑，还可进行玩法扩展、UI 调整或素材替换，是一份兼顾入门学习与二次开发的实用素材。1. 拿到 Cocos Creator 小鸟源码先别双击工程：版本决定你能不能跑起来如果你手里也有一份Cocos Creator 打包成微信小游戏的小鸟游戏源代码，最忌讳的第一件事就是双击工程文件直接打开。类似「Cocos Creator 小鸟」这种流传较广的练手项目，很多是在 2.x 时代写的，而你电脑上装的可能是 3.x，绝大多数情况下工程直接打不开——脚本编译报错、场景资源丢失、构建按钮灰掉，每一步都在消耗耐心。正确的顺序是：先看引擎版本，再决定是直接打开还是先做工程迁移。这份资源本质上是一个完整可运行的小游戏工程，包含场景、预制体、游戏脚本、构建配置，核心玩法就是点击起跳、穿过管道、计分、碰撞结束。它解决的问题很具体：不用从零搭框架，拿到手改一改素材和参数，就能构建出在微信里跑的竖屏小游戏。适合两类人：一类是第一次接微信小游戏、想知道整套发布链路怎么走的开发者；另一类是想要一个干净模板、快速验证玩法原型的熟手。我的做法是，先把它当成「可运行的参考实现」，再逐步替换成自己的东西。2. 微信小游戏不是网页：运行环境、屏幕适配与资源策略2.1 没有 DOM 的渲染环境：引擎是怎么塞进微信的微信小游戏运行在一个阉割过的浏览器内核里，没有document、没有window、没有 DOM 树，只提供 Canvas 和 WebGL 渲染接口。Cocos Creator 之所以能把游戏打包进去，靠的是一层适配层——把引擎内部对 DOM、Audio、本地存储的调用，全部转接到微信小游戏提供的wx.*接口上。Cocos Creator 2.x 和 3.x 在这层的处理方式不同：2.x 更像是在原有网页渲染体系外面包一层 polyfill，不少浏览器 API 被强行模拟出来；3.x 从架构上就把渲染层直接对接 WebGL，适配更干净。你可以通过构建产物来验证这一点。# 构建完成后进入微信小游戏产物目录 cd build/wechatgame # 查看顶层结构 ls -la # 查找引擎适配层相关文件 find . -name "*adapter*" -o -name "sys*" | head -20构建产物里会有src/、assets/、engine/之类的目录，engine/下就是被编译过的引擎适配代码。如果你看到大量wx.createCanvas、wx.getSystemInfoSync这类调用，说明适配层工作正常。拿到任何一份 Cocos 小游戏源码，建议先执行这一步，确认构建产物完整，再回过去看源码工程。这里有个容易忽略的点：微信开发者工具模拟器能跑，不代表所有接口在真机上可用。适配层代码在模拟器和真机上走的是同一套逻辑，但真机上 Canvas 的创建时机、触摸事件的坐标换算、音频的加载策略都有差异，后面第 5 章会专门讲。2.2 屏幕适配：设计分辨率、适配策略与安全区小鸟游戏是竖屏玩法，画面宽高比在不同手机上差异很大——iPhone 的全面屏比例接近 19.5:9，老款安卓机是 16:9，老 iPhone 是 16:9 左右。如果不做适配，会出现两种情况：要么画面被拉伸变形，要么两侧被裁掉内容。Cocos Creator 的适配核心是cc.view.setDesignResolutionSize()加上 Canvas 组件的适配策略。设计分辨率就是你制作场景时用的逻辑尺寸，比如720x1280，真机渲染时引擎按策略换算成实际像素。适配策略行为适用场景风险SHOW_ALL完整显示设计分辨率内容，留黑边拼图、棋牌类两侧或上下留边，不美观FIXED_WIDTH宽度铺满，高度方向可超出裁剪竖屏跑酷、射击、小鸟顶部或底部可能被裁掉FIXED_HEIGHT高度铺满，宽度方向可超出裁剪横屏游戏左右可能被裁掉NO_BORDER按比例放大到铺满全屏，四周裁剪全屏沉浸式裁剪最多，UI 位置要小心小鸟这类竖屏游戏，我一般用 FIXED_WIDTH。玩法核心是角色左右移动范围固定，宽度保持一致能保证管道间距在每台设备上视觉一致，高度方向多一些少一些影响不大。// 在 game.js 或首场景的启动脚本里设置 view.setDesignResolutionSize(720, 1280, ResolutionPolicy.FIXED_WIDTH);需要注意一个坑：Cocos Creator 3.x 里，designResolution的设置在构建面板的「适配屏幕」选项里也能配，而且构建面板的配置会覆盖代码。所以如果你在脚本里改了分辨率但真机上没生效，先检查构建面板的「适配屏幕宽度/高度」是不是被勾成了另一个策略。安全区问题同样不能漏。全面屏手机的底部有横条，顶部有刘海，如果你把分数 UI 放在屏幕最顶部或操作按钮放在最底部，真机上很可能被遮挡。微信小游戏提供了wx.getSystemInfoSync().safeArea，在 Cocos 里可以通过sys.getSafeAreaRect()拿到逻辑坐标下的安全区。拿到后，把关键 UI 强制约束在该矩形内。2.3 资源打包策略：主包 4MB 与 Bundle 拆分微信小游戏主包有 4MB 的体积限制，超过就上传失败。小鸟游戏的资源其实很小：几张鸟的序列帧、几张管道图片、一个背景、两三个音效，加起来通常不到 1MB，完全可以内嵌在主包里。但如果你替换了高清素材，或者加了一堆 UI 贴图、粒子特效，体积很快就会顶到上限。Cocos Creator 3.x 提供了 Bundle 机制，可以把资源拆成多个子包，主包只保留首屏必需内容，其余资源在需要时动态加载。判断当前构建产物体积是否超限，命令很简单：# 在构建产物目录下查看体积 du -sh build/wechatgame # 如果只关心首包（子包会单独列目录） du -sh build/wechatgame/assets我拿到这份小鸟源码后，先看 assets 目录，如果里面资源文件不多，默认就是单包模式，不需要额外拆分。真正要拆的场景是：你打算把鸟的动画帧、背景音效全部替换成高质量素材。我遇到过一次，替换了一套 2K 背景图，主包直接到 5.2MB，上传被拒，后来把背景图和音效挪到子包，启动时先显示 Loading 再动态下载，问题才解决。拆 Bundle 的操作在编辑器里就能做：选中资源文件夹，在属性检查器里把「Bundle 名称」填上，资源就归到对应子包。加载时用assetManager.loadBundle()配合bundle.load()。不要把所有东西都塞进首包，也不要为了拆而拆——Bundle 的下载有延迟，首屏需要的东西留在主包，次要内容拆出去。3. 拆解小鸟游戏核心代码：场景结构、状态机与碰撞判定3.1 拿到源码先看目录与场景结构一份标准的 Cocos Creator 工程，最核心的目录是assets/，里面按常规会分成scenes/、scripts/、prefabs/、resources/。拿到源码后，我习惯先把assets/的目录树打出来，快速建立全局认知。# 在工程根目录执行 tree assets -L 2正常会看到类似结构：scenes/下放.scene文件（本质是 JSON 格式的场景描述），scripts/下放.ts或.js脚本，prefabs/下放可复用的预制体。小鸟游戏一般会有一个主场景，场景的 Canvas 节点上挂着游戏管理器脚本，鸟角色节点上挂着角色控制脚本。识别入口场景有一个技巧：打开assets/下的场景文件，搜索GameManager或类似命名的脚本类，那个场景大概率就是主入口。.scene文件很长，不要全文读，用编辑器打开后直接看节点树和组件列表，比看 JSON 直观得多。3.2 游戏状态机与鸟的物理模型小鸟游戏看起来简单，代码组织却需要一个清晰的状态机。原因很实际：鸟在「待开始」「飞行中」「游戏结束」三种状态下，响应完全不同——待开始时不掉下来，飞行中点击会起跳，结束后点击要重新开始。如果不做状态区分，逻辑会乱成一团。// GameManager.ts - 状态机核心 enum GameState { Ready, Playing, Over } // 单例管理节点状态 export class GameManager extends Component { public state: GameState = GameState.Ready; startGame() { this.state = GameState.Playing; // 鸟开始受重力影响 bird.enableGravity(true); // 管道开始生成与移动 pipeManager.startSpawning(); } gameOver() { this.state = GameState.Over; // 停止管道生成，播放碰撞动画 pipeManager.stopSpawning(); audioManager.playHit(); } onTouched() { if (this.state === GameState.Ready) { this.startGame(); } else if (this.state === GameState.Playing) { bird.jump(); } else if (this.state === GameState.Over) { this.restartGame(); } } }这段代码里，onTouched被全局触摸事件调用，通过判断state决定行为。这是小鸟游戏最核心的控制流——所有交互都收敛到这一个方法里，状态切换的入口非常清楚。鸟的物理模型是伪重力和伪速度，不需要引入完整的物理引擎。每一帧做两件事：速度累加重力增量，位置累加速度增量。// Bird.ts - 鸟的运动逻辑 public gravity: number = -1200; // 重力加速度，像素/秒²，负值向下 public jumpSpeed: number = 420; // 起跳瞬间的速度，像素/秒，正值向上 public rotationSpeed: number = 180; private _velocity: number = 0; update(dt: number) { // 未开始或已结束时不更新物理 if (gameManager.state !== GameState.Playing) return; // 重力改变速度，速度改变位置 this._velocity += this.gravity * dt; this.node.setPosition( this.node.position.x, this.node.position.y + this._velocity * dt ); } jump() { // 每次点击把速度重置为起跳速度，实现「拍打」效果 this._velocity = this.jumpSpeed; }gravity和jumpSpeed是影响手感的第一优先级参数。重力越大下落越快，跳跃速度越大单次抬升越高。我测试时习惯先把重力设到-1000、跳跃速度400，跑几轮之后按「跳一下上升大概 80~100 像素」的手感目标去微调。这份源码里这两个值一定写在脚本顶部或 Inspector 暴露面板上，改完保存就能在模拟器里直接感受差异，不用重新编译。3.3 管道生成、移动与得分检测管道是另一个核心模块。它的工作模式不是每帧新建实例，而是对象池复用——生成一组管道对，移动到屏幕左侧边界后回收，再放在右侧新的位置。这样做主要为了性能：小鸟游戏场景里通常同时存在 4~5 组管道，如果反复创建销毁节点，会造成频繁的 GC 暂停。// PipeManager.ts - 管道生成与回收 public spawnInterval: number = 1.4; // 每 1.4 秒生成一组管道 public gapHeight: number = 200; // 上下管道之间的缝隙高度 public moveSpeed: number = -160; // 管道左移速度，像素/秒 private _pipes: Node[] = []; update(dt: number) { for (let pipe of this._pipes) { pipe.position.x += this.moveSpeed * dt; // 移出屏幕左侧后回收 if (pipe.position.x < -900) this.recycle(pipe); } } generatePipe() { // 随机缝隙中心点：保证缝隙在上下管道之间，不会出界 const minY = -400; const maxY = 200; const gapCenter = Math.random() * (maxY - minY) + minY; // 上面管道底部 = 缝隙中心 - gapHeight/2 // 下面管道顶部 = 缝隙中心 + gapHeight/2 // 分别设置两组管道的 y 坐标后加入 _pipes }gapHeight是难度核心。缝越大越容易过，越小越劝退。spawnInterval决定了管道密集度，越短越紧张。我见过很多游戏的难度曲线就是在spawnInterval上做文章——每过 10 分减少 0.05 秒，配合gapHeight逐步缩小，玩家很难察觉难度在爬升。碰撞判定是这份源码里最值得看的部分。小鸟游戏不需要引擎级物理碰撞，用 AABB 包围盒相交检测就够了，代码量少、性能好、调试直观。// Collision.ts - 轴对齐包围盒碰撞检测 function checkAABB(bird: Rect, pipeRect: Rect): boolean { // 两个矩形相交的条件：X 方向与 Y 方向都重叠 return bird.x < pipeRect.x + pipeRect.width && bird.x + bird.width > pipeRect.x && bird.y < pipeRect.y + pipeRect.height && bird.y + bird.height > pipeRect.y; }它的原理简单说：把鸟和管道各看成一个矩形，检查它们在 X 轴和 Y 轴上的投影是否同时重叠。如果只用管道组的中心点做检测，会出现「鸟明明被碰到却被判定得分」的错觉——因为管道上下两根的矩形是分离的，中间缝隙不算碰撞，中心点检测会把缝隙和管道壁混为一谈。正确做法是对每根管道单独取矩形做检测。得分检测更简单——不用碰碰撞体，只比较位置坐标：当管道的 x 坐标第一次小于鸟的 x 坐标时，得分加一。这时候管道和鸟还没发生碰撞，玩家会有「刚好擦过去」的爽感。但要注意，一定要加一个「已得分」标记，否则同一组管道会在多帧内连续触发加分。4. 从 Cocos Creator 构建到微信开发者工具：完整发布流程4.1 构建面板参数配置Cocos Creator 的构建面板是所有平台发布的统一入口，选错参数会在后面浪费大量时间。构建平台的选项里选「微信小游戏」，然后逐个确认参数。参数推荐值说明AppID填写小游戏 AppID 或用测试号正式发布必须真实 AppID，测试号无法上传初始场景主场景（含 GameManager 的场景）启动后加载的第一个场景设备方向竖屏（Portrait）小鸟游戏必须是竖屏，设错会横着运行适配屏幕勾选配合 FIXED_WIDTH 策略生效MD5 Cache勾选资源文件名加 MD5 哈希，防止微信缓存旧资源调试模式开发时勾选，发布前取消勾选后保留调试日志，取消后体积更小主包压缩类型默认保持默认即可，不需要手动改有一个参数容易被忽略：初始场景。如果你做了一堆测试场景，忘了把入口场景指定为正式主场景，构建出来的包可能打开就是一个空白场景，甚至直接报错。4.2 导出构建产物并导入微信开发者工具构建完成后，产物默认在工程目录下的build/wechatgame。打开微信开发者工具，导入项目时选择build/wechatgame目录而不是工程根目录——这是新手最容易搞混的地方。# 构建完成后，先看一眼产物是否完整 cd build/wechatgame ls -la # 期待看到 game.json、project.config.json、src/、assets/ 等 # 如果没有 project.config.json，说明构建不完整，回到编辑器重新构建微信开发者工具导入后，还需要检查两件事：右上角详情里的「本地设置」要勾选「不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书」。这不是为了绕过什么审核，而是因为本地调试时使用的是局域网 IP 和临时资源路径，不校验才能正常加载。正式上传前要取消勾选，否则线上环境资源加载策略不同，可能出现本地能跑线上白屏的诡异现象。这步里最玄学的点在于：微信开发者工具的模拟器有时和真机表现不一致。触摸事件的模拟、帧率的差异、音频的时序，都可能不同。所以我在模拟器里能跑通后，不会急着收工，而是用开发者工具右上角的「预览」按钮生成二维码，用手机微信扫码真机跑一遍。4.3 构建产物快速排错：看日志与查进程真机预览报错时，第一反应不应该是改代码重新构建。先打开微信开发者工具的「调试器」面板，切换到 Console 标签页，把报错信息里的文件名和行号记下来。最常见的情况是资源路径错误或脚本空引用，日志会直接告诉你。还有一种情况是点了「预览」二维码但手机打开后长时间黑屏。不要急着删包，先确认是否首次加载子包资源——如果你把资源放进了 Bundle，首次进入会有一个下载过程，在弱网下可能要等好几秒，黑屏其实是资源下载中。这时候在工程代码里加一个 Loading 转圈提示，比优化加载速度更重要——玩家不知道卡了还是挂了，体验差别很大。5. 打包微信小游戏常见问题复盘：五条现象、原因与处理5.1 构建后导入工具直接白屏，报 Cannot read property of undefined现象：构建产物导入微信开发者工具，模拟器一片白，Console 里报错指向引擎源码里的某一行。原因：90% 的情况是 Cocos Creator 编辑器版本和构建产物引擎版本不一致。比如你前几天用 3.x 构建过一版，今天换了 2.x 工程直接构建，旧的构建缓存没清理，产物理的引擎适配层被旧代码污染。解决：在构建面板点右下角的「清除」按钮，删掉整个build/wechatgame目录，重新构建。这一步能解决绝大多数构建产物异常。如果还是白屏，把微信开发者工具的「缓存目录」也清一遍——工具本身会缓存编译中间文件，会导致代码更新不生效。5.2 真机上角色乱飞、位置偏移，模拟器却一切正常现象：模拟器里鸟的位置和点击响应完全正常，换成真机后鸟飞到屏幕外、点击位置偏了半个屏幕。原因：模拟器默认使用工具的窗口尺寸，真机的屏幕物理尺寸、像素密度都不同。如果适配策略是 SHOW_ALL，不同宽高比会产生黑边，节点坐标和触摸坐标的换算就会被拉伸扭曲。解决：确认竖屏游戏的适配策略统一为 FIXED_WIDTH 或 FIXED_HEIGHT，不要混用。检查 Canvas 组件里的适配设置和代码里setDesignResolutionSize是否冲突，以代码为准，构建面板的「适配屏幕」保持勾选即可。另外真机调试时先执行wx.getSystemInfoSync()，确认拿到的屏幕宽高比和设计分辨率是否是同一方向。5.3 音频真机无声，模拟器正常播放现象：点击起跳的音效、碰撞的音效在模拟器里都正常，真机上完全无声。原因：微信小游戏对音频有明确的自动播放限制——不允许在没有任何用户交互前播放音频。如果你的play()调用发生在场景启动、碰撞检测等没有用户手势触发的时机，微信会直接丢弃这次播放请求。解决：把音频初始化放在第一次用户触摸的回调里。比如在主场景的onTouched里先执行audioManager.resume()或audioSource.play()，之后再播放任何音效都没问题。我通常会监听里一次触摸事件，在触摸回调里调用wx.setInnerAudioOption({ obeyMuteSwitch: false })并预热音频实例。5.4 主包超过 4MB，上传被拒现象：构建成功，但上传到微信公众平台时提示主包超限。原因：资源文件体积过大，主要是图片。PNG 原图动不动几 MB，序列帧动画更是重量级。小鸟游戏的动画帧如果做成 512x512 的高清图，很容易爆掉。解决：图片用 TinyPNG 或 Cocos Creator 内置压缩工具压到 1024 以内；音频如果是 WAV 转成 m4a 或 mp3，码率控制在 128kbps。还放不下就把背景图和音效拆进 Bundle，主包只留玩法必须的场景和脚本。判断主包体积的准确方式不是看整个build/wechatgame目录，而是看assets子目录和src子目录的总和。5.5 每次改代码，真机预览看到的还是旧版本现象：代码改了一轮，真机预览跑起来发现功能没变，或者画面卡在最旧的资源版本。原因：微信开发者工具和手机端都有资源缓存。工具缓存的是编译中间文件，手机缓存的是已经下载的资源包。Cocos Creator 构建产物里的文件不带 hash 时，同名文件会命中旧的微信缓存。解决：开发阶段每次预览前，在微信开发者工具菜单里执行「清除缓存 -> 全部清除」，再重新编译。正式发布时一定把 MD5 Cache 勾选上，这样资源文件名带哈希值，旧文件在微信服务器上无法命中，玩家自动加载新版本——这是最稳妥的线上更新机制。6. 发布前用「真机三连」验证一次：比跑十遍模拟器都管用有过一次深刻的翻车教训。某次我把一个改好的版本在模拟器里跑了几十遍，感觉万无一失，直接上传提审。结果审核人员在真机上打开，发现游戏结束界面弹出的分数数字偏到屏幕外面，整个 UI 被安全区挤压变形。问题本身不大，但整套提审流程重走一遍的时间成本很高。从那以后，我养成了一个强制习惯：每次准备上传前，都执行一遍「真机三连」验证。第一连，微信开发者工具的「真机调试」模式打开，手机扫码后在手机屏幕上操作，桌面上同步看 Console 日志。重点观察有没有资源加载失败、空指针、警告信息。第二连，在真机调试面板里打开性能监控，盯两点：帧率是否稳定在 30fps 以上，Draw Call 是否在一个合理区间。小鸟这类 2D 轻量游戏，Draw Call 超过 50 就说明有节点没有合批，图片资源该做合图了。第三连，关闭「不校验合法域名」，用正式域名配置重新跑一遍真机预览——这一步模拟的是线上环境，能提前发现资源域名校验问题。一套走完大约十分钟，换来的是一份「这个包上传后大概率不会被退回」的信心。特别是经历过真机翻车之后，我越来越认同一个观点：模拟器跑通的只是黑匣子里的逻辑，真机跑通的才是玩家实际体验。这期间也有后悔药可吃——微信开发者工具的「版本管理」功能可以回退到上一个上传的版本，但回退会中断审核流程，影响上线的时效。与其事后补救，不如发布前把这三连当成固定的验收流程。希望帮到你。本文还有配套的精品资源，点击获取