简介：面向希望使用 Cocos Creator 开发并导出微信小游戏的开发者，压缩包内包含一款“小鸟”主题小游戏的完整项目源码。全部文件共 592 个，整体体积仅 1.67 MB；其中 json 配置负责场景与资源索引，png 图片提供游戏美术素材，meta 文件保存导入设置，js/ts 脚本承载玩法逻辑，bin 文件存放二进制数据，另有 fire 场景、plist 图集、fnt 字体等辅助文件，覆盖从界面布局、动画表现到资源加载的常见环节。项目目录结构清晰，可直接导入 Cocos Creator 打开场景与脚本，查看层级关系、动画状态机与核心逻辑，并参考其中的微信小游戏打包配置、发布设置及整体目录组织方式，便于对照学习、模仿改造或二次开发。该资源已有 3301 人学习下载，适合刚接触 Cocos Creator 微信小游戏打包流程，或希望快速获得完整项目样例的开发者使用。

1. Cocos Creator 打包微信小游戏：一套能把小鸟跑起来的源码包

做小鸟这类轻量休闲游戏，最划算的路线不是先做原生壳，而是直接用 Cocos Creator 打包微信小游戏。同一个工程，在构建面板里把平台切成微信小游戏，就能产出能在微信开发者工具里直接跑起来的代码包。这套源码包正是按这条闭环路线准备的：小鸟的动画、管道生成、碰撞结算和计分逻辑都写在里面，拿到手先不改代码，按第 3 章的参数走一遍构建，基本十分钟内能在模拟器里看到小鸟飞起来。适合第一次接触小游戏打包的人，也适合想验证创意但不想从零搭环境的老手。下文会把版本选型、屏幕适配、构建参数和三类高频翻车点一次讲完。

2. 打包前先搭底子：版本选型、项目结构与屏幕适配

在动手点构建按钮之前，先把这套源码包的运行链路拆开看一遍。Cocos Creator 构建微信小游戏，本质上是一个“编译 + 桥接”的过程：TypeScript 源码编译成 JavaScript，引擎运行时一起打包，再通过 jsb-adapter 和微信小游戏的运行时环境对接。很多新人直接点构建，报错后到处找答案，就是因为不清楚这中间隔了几层。这一章先把版本、产物目录、屏幕适配三个底子问题讲透，后续构建才会顺利。

2.1 Creator 2.x 还是 3.x：小游戏构建链路不一样

收到这类 2D 竖屏小游戏工程，我一般优先选 Creator 2.x，而不是 3.x。原因是 2.x 的微信小游戏适配路线已经被踩得很熟，引擎裁剪后首包更小；3.x 在复杂 3D 渲染和跨端一致性上有优势，但对于小鸟这种纯 2D 场景，3.x 的构建产物和运行时加载机制反而更重，启动耗时和首包体积都容易吃亏。

具体来说，2.x 的构建链路是把引擎核心代码打进一个 game.js，项目脚本编译后放在 src 目录，jsb-adapter 在启动时负责把 Cocos 的 API 映射到微信小游戏环境。微信开发者工具加载 game.js 后，再去拉取 src 和 assets 里的资源，整个链路是线性的，排错也直观。3.x 则引入了更精细的模块分包和管线渲染，虽然现代，但构建配置项多，低端安卓机上引擎初始化时间也更长。

还有一个现实问题：2.x 和 3.x 的工程文件不互通。2.x 工程的 .meta 文件记录资源 UUID，用 3.x 打开会触发大量重新生成，碰撞体、物理材料、预制体引用可能全部错乱。所以源码包是哪个版本，就用那个版本的 Creator 去构建，不要指望跨版本硬拉。如果你拿到的是 2.x 工程，就老老实实用 2.x 编辑器；反之亦然。

2.2 构建产物目录：game.js、game.json 与分包的关系

一次成功的代码包构建产物，默认落在 build/wechatgame 目录。这是微信开发者工具唯一需要认识的目录，也是对新手最容易产生误导的地方。我整理了一份文件清单，标出哪些能碰、哪些别碰。

第一次构建后，我建议你打开 game.json 看一眼。里面除了 window 配置，还可能有 subpackages 字段。微信小游戏平台对主包大小卡得很死，4M 是一个硬上限，超过就上传失败。资源多了以后，就得靠分包把一些非首屏资源拆出去。Cocos Creator 的 Asset Bundle 和微信分包是映射关系，你在编辑器里把一个目录设为 Bundle，构建时 Creator 会在 game.json 里自动生成对应的分包声明。这个机制后面第 4.5 节再展开。

2.3 设计分辨率与安全区：750×1334 和刘海屏适配

小鸟这类竖屏游戏，我给的默认设计分辨率是 750×1334。这个分辨率的比例接近主流手机屏幕，Canvas 组件设成 Fit Height 加 Fit Width 后，适配压力最小。但选好设计分辨率只是一半，另一半是安全区。

微信小游戏运行在带刘海的机型上时，顶部状态栏区域和底部 home 指示条会遮挡 UI。编辑器里看起来正常的按钮，真机上可能被刘海吃掉，或者底部露出黑边。常见的做法是挂一个安全区适配脚本来整体偏移主 UI。下面这段代码就是读取微信系统信息里的 safeArea，把背景节点往上推，底部按钮往下让出空间：

// SafeAreaAdapter.ts — 2.x 工程写法 // 把这段脚本挂到 Canvas 下的主 UI 节点上 const { ccclass } = cc._decorator; @ccclass export default class SafeAreaAdapter extends cc.Component { onLoad() { // 非微信环境直接跳过，保证编辑器预览正常 if (typeof wx === 'undefined') return; const info = wx.getSystemInfoSync(); const safe = info.safeArea; if (!safe) return; // 计算顶部刘海和底部黑条在可见区域里的比例 const winSize = cc.view.getVisibleSize(); const topRatio = safe.top / info.screenHeight; const bottomRatio = (info.screenHeight - safe.bottom) / info.screenHeight; // 按比例平移整个 UI，让内容避开两个非安全区 const offsetY = winSize.height / 2 * (topRatio - bottomRatio); this.node.y = offsetY; } }

这段代码的逻辑核心是：把 safeArea 的 top 和 bottom 差值折算到设计分辨率坐标系里，再平移主节点。注意 cc.view.getVisibleSize() 返回的是经过 fit 后的逻辑尺寸，单位是设计分辨率的像素，所以可以直接相乘。参数上，topRatio 和 bottomRatio 分别代表刘海高度和底部条高度占屏幕的比例，偏移方向由两者的差决定。竖屏游戏只用处理垂直方向即可。

3. 打包实操：构建面板参数、命令行构建与真机预览

这一章直接进入操作。源码包拿到手，改完 AppID 和路径就开始构建。核心动作只有三个：配置构建面板、执行构建、用微信开发者工具导入产物。每一步都有几个关键参数值得停下来看一眼，否则后续排查时会多花不少时间。

3.1 构建面板参数：包名、引擎裁剪与 MD5 缓存

打开 Creator 编辑器后，从菜单栏进入“项目 -> 构建发布”，平台选择“微信小游戏”。第一次构建前，关注这几个参数。

AppID 可以先填测试号，不要一开始就填正式小游戏 AppID，避免还没测试完就把真机预览名额占掉。初始场景选主场景，一般就是层级管理器里那个包含 Canvas、背景、小鸟、水管管理器的场景。设备方向选“竖屏”，和设计分辨率保持一致。

MD5 缓存建议打开。这个选项会给每个资源文件名追加哈希后缀，微信开发者工具和小游戏运行时能正确识别资源更新，避免改了一版图片还读旧缓存。资源路径里不要带中文，微信开发者工具对中文路径的兼容性很差，构建产物放在纯英文路径下能少很多报错。

引擎模块裁剪是首包体积的关键。在“项目设置 -> 功能裁剪”里，3D 物理、3D 粒子、Spine、DragonBones 这类用不到的模块可以全部取消勾选。小鸟游戏只需要 2D 渲染、2D 物理、UI、音频这几个核心模块。裁剪完再看构建日志，首包体积通常会从 800KB 掉到 400KB 上下，真机启动速度提升明显。

3.2 命令行构建：一次配置、长期复用

手动点构建没问题，但如果要频繁出包，或者想接入持续集成，命令行构建是更靠谱的选择。Cocos Creator 自带命令行工具，把构建参数一次性写在命令里，以后直接复用。下面是我常用的构建命令模板：

# macOS 下 Creator 2.x 命令行构建微信小游戏 /Applications/CocosCreator.app/Contents/MacOS/CocosCreator \ --project /Users/you/work/flappy_bird \ --build "platform=wechatgame;debug=false;md5Cache=true" \ --force # Windows 下路径类似，指向安装目录里的 CocosCreator.exe # 注意 --build 参数里没有指定 buildPath 时，默认输出到工程目录下的 build/

参数说明：platform 固定填 wechatgame；debug=false 表示构建发布版本，此时会做代码压缩，体积更小；md5Cache=true 对应面板里的 MD5 缓存开关。--force 表示强制全量构建，不加的话会复用增量缓存，如果改了脚本而没改资源，可能构建出旧代码。我在持续集成节点上还习惯先执行一次rm -rf build/wechatgame temp，清掉旧产物再构建，避免微信开发者工具读到残留文件。

3.3 微信开发者工具导入与预览：目录千万别指错

构建完成后，打开微信开发者工具，新建小游戏项目。这一步最容易翻车：目录选择必须指向 build/wechatgame，而不是 Creator 工程根目录。很多人在这里选错了，打开后看到一堆 source 目录和 project.json，项目类型直接识别失败，报错不断。

导入后先看 game.json 是否能正常解析，再点“编译”。如果模拟器里小鸟直接飞起来，说明构建链路已经通了。此时做三件事：一是打开“详情 -> 本地设置”，勾选“不校验合法域名”，否则资源请求会被拦；二是把调试器切到 Console 面板，确认没有红色报错；三是点“预览”，生成二维码，用手机微信扫码真机跑一遍，重点听第一个音效、看碰撞判定和底部按钮位置。

真机预览时，如果手机和开发工具不在同一局域网，预览二维码可能刷新不出来，这时改用“自动预览”或让工具自动推送即可。

4. 打包避坑：五条实测翻车记录，从白屏到包体超限

打包这件事，顺利的时候一次过，不顺利的时候能卡你一整天。这一章我把实际踩过的五类高频问题整理出来，每一条都按现象、原因、解决三个步骤写，方便你对照排查。

4.1 白屏问题：jsb-adapter 加载失败

现象：微信开发者工具编译后模拟器一片白，Console 第一行报错，提示无法加载 jsb-adapter/jsb-adapter.js。

原因：多数情况是 build 目录残留。比如在一次构建后切换了 Git 分支，或者把旧版构建产物和新版混在一起，导致 jsb-adapter 文件缺失或路径错位。还有一种是工程目录被压缩软件解压时丢了符号链接，jsb-adapter 目录变成空壳。

解决：先删掉构建目录和临时缓存，再重新构建。命令行里执行：

rm -rf build/wechatgame temp

然后回到 Creator 重新走一遍构建。如果还报同样的错，检查工程目录下有没有一个和 jsb-adapter 同名的文件夹被误放到了根目录，若有，移走后重建。从那以后我每次构建都会顺手清一次 build 和 temp，宁可多花十秒全量构建，也不赌增量缓存。

4.2 小鸟穿水管：物理步长与碰撞体尺寸

现象：在编辑器里测试好好的，真机上小鸟高速下落时会从水管缝隙里径直穿过去，没有任何碰撞反馈。

原因：Cocos 2.x 物理引擎默认按固定时间步长模拟，也就是 1/60 秒一帧。真机帧率不稳定时，渲染帧率掉到 30 帧，物理模拟仍然按固定步长跑，但两次模拟之间的位移会变大；加上小鸟这种高速移动物，碰撞体的面积很小，一帧内可能直接跳过碰撞检测。

解决：这一步核心是让物理判定更保守。把小鸟刚体组件的 Allow Sleep 取消勾选，防止它在物理世界静止时进入休眠；给小鸟碰撞体稍微放大一圈，比如从 60×50 改成 62×52，视觉上看不出来，但物理判定更稳健。如果你用的碰撞体是圆形，建议改成长方形，和管道矩形边界的贴合度更高。编译后真机重测，穿模问题基本消失。

4.3 花屏与紫边：纹理压缩与合图的兼容坑

现象：编辑器模拟器里画面正常，真机上某些精灵图的边缘出现紫边或花斑，尤其在小鸟翅膀扇动动画里最明显。

原因：这是纹理合图后子图尺寸没有对齐 4 像素导致的。微信小游戏运行在 GPU 上，纹理采样需要满足压缩格式的对齐要求，非 4 倍数宽高的图片在部分机型上采样会越界，边缘出现杂色。

解决：把出问题的图片导入 Creator 后，右键选中，在属性检查器里把“平铺”关掉，然后将图片的宽高裁剪成 4 的倍数。如果用了图集合图，还要检查图集配置里的“内边距”，默认 2 像素不够的话改成 4 像素。重新构建后真机上看边缘，紫边消失。

4.4 音效时有时无：异步加载和播放时机

现象：第一次点击屏幕触发小鸟扇翅音效时没有声音，后面再点几次又正常了。

原因：音频资源是异步加载的，首次点击时 AudioClip 还没有进入内存，播放指令被忽略。编辑器里因为本地资源加载快，几乎感觉不到这个时序问题，真机上就很明显。处理方式是在游戏启动阶段预加载音频，而不是等用户点击时才加载。下面是预加载代码：

// AudioManager.ts — 预加载核心音效 const AUDIO_WING = 'audio/wing'; export function preloadAudio() { cc.resources.load(AUDIO_WING, cc.AudioClip, (err, clip) => { if (err) { cc.warn('音效加载失败: ' + err.message); return; } // 首次播放时 clip 已可用 cc.audioEngine.play(clip, false, 1); cc.audioEngine.stopAll(); }); }

这段代码在启动场景 onLoad 时调用。cc.resources.load 的第一个参数是 resources 目录下的相对路径，不带扩展名；回调里拿到 AudioClip 资源后再播放，虽然只是触发了一次又立即停掉，但音频文件已经进入内存缓存，后续点击再播放就不会卡时序了。

4.5 主包超限：4M 限制与资源切割

现象：上传代码包时提示“主包大小超过 4M，请使用分包”，构建产物提交失败。

原因：主包塞进了太多资源，尤其是未经压缩的音频文件和大量独立 PNG。小鸟游戏不算复杂，但如果音频是 1MB 以上的 MP3，再加上几张背景图和序列帧，主包很快就涨到 5M 以上。

解决：把非首屏资源挪进 Asset Bundle。在 Creator 的资源管理器里，选中音频目录右键 -> 转换为 Asset Bundle，构建时 Creator 会自动生成微信分包配置。解除分包里的音频和背景图后，主包剩下的就是代码和必要 UI，一般能压到 3M 以内。这里提醒一句：Bundle 资源和首屏场景的资源要分开，启动场景里被引用的内容不要放进 Bundle，否则启动时加载不到。

5. 二次开发技巧：给小鸟加计分、排行与手感优化

包打出来能跑了，接下来才是真正做出差异化的地方。这里给两个立刻能落地的技巧，一是用本地存储做计分和最高分，二是通过几个参数调整手感。

5.1 用本地存储做计分和最高分

微信小游戏环境支持同步存储，Cocos 做了封装，直接用 cc.sys.localStorage 就可以，不需要额外适配：

// ScoreManager.ts — 计分与最高分存取 const BEST_KEY = 'bird_best_score'; export function saveScore(score: number): void { cc.sys.localStorage.setItem(BEST_KEY, score.toString()); } export function loadBestScore(): number { const val = cc.sys.localStorage.getItem(BEST_KEY); return val ? parseInt(val) : 0; }

这段代码的逻辑很简单：得分时调用 saveScore 写入本地缓存，游戏结束展示 loadBestScore 作为最高分。注意微信开发者工具模拟器里的缓存和真机不互通，判断排行是否生效要以真机预览为准。

5.2 手感调参：重力、跳跃力度和水管速度

小鸟游戏“好不好玩”本质是物理参数的手感问题。以下是我调过的几组经验值，可以作为起步参考：

调整重力时，我会先固定水管速度，然后只在 -1300 和 -1800 之间试跳二十局，感受“按下去飞多高、落下去多快”。跳跃速度和水管速度也按同样的节奏调，一次只改一个变量，避免手感玄学化。实践下来，重力 -1400、跳跃速度 580、水管速度 160 的组合兼顾了新手友好和挑战性，适合休闲玩法。

从那以后，我每次发布这类竖屏小游戏都强制走一遍固定流程：清空构建缓存、裁剪引擎模块重新打包、用真机预览至少跑三分钟，重点盯首屏启动速度、第一次点击音频、小鸟碰撞判定和底部按钮位置。这套流程帮我挡掉了不少上线后才会暴露的问题，希望帮到你。

本文还有配套的精品资源，点击获取