企业官网建设流程全解析

简介：面向微信小游戏开发者的 Cocos Creator 完整工程源代码，以经典“小鸟”跳跃玩法为示例，帮助使用者弄清从 Cocos Creator 编辑器到微信小游戏运行环境的打包流程、平台适配与资源组织方式。压缩包含 592 个文件，整体仅 1.67MB，构成相当紧凑；其中 289 个 json 文件承担场景配置与资源配置，180 张 png 提供完整美术贴图，81 个 meta 记录导入参数，17 个 js 脚本实现控制逻辑，另外还有 bin 数据文件、fire 场景文件、ts 脚本、plist 图集、fnt 字体以及 gltf 模型等，覆盖了微信小游戏项目常见的资源类型，目录结构也保持了 Cocos Creator 工程的标准布局，查找定位非常方便。目前已有 3301 人学习下载，适合正在学习 Cocos Creator 发布微信小游戏的开发者直接参考。借助这份源码，可以快速查看小鸟游戏的场景搭建、碰撞检测、计分逻辑，以及微信环境下的屏幕适配与音频调用方案；同时能直接复用美术素材与配置数据，省去从零搭建工程的麻烦，作为入门练习或二次开发的基础工程都很合适。

1. Cocos Creator 小鸟上架前最后一公里：这份源代码把微信小游戏打包踩平了

“Cocos Creator 小鸟”这个搜索词背后通常都是同一个问题：游戏在 Cocos 里做着做着就卡住了，单机预览一切都好，一说到微信小游戏打包就发怵。这份打包成微信小游戏源代码的资源我完整跑过一遍，它不是只丢几个脚本给你，而是从工程结构、场景搭建到微信小游戏构建配置的全流程成品。跑通它，你能看到一个经典小鸟跳跃玩法项目是怎么完成从 Cocos Creator 工程到微信小游戏包体完整迁移的。适合刚学 Cocos、卡在“开发完不知道怎么发出去”这一步的开发者。先说结论：这套源码里最值钱的不是小鸟那几帧动画，而是它替你趟平的构建配置和微信端适配。

2. 工程先拆清楚：哪几个目录和文件决定你能不能顺利打出来

2.1 工程目录：先认清 assets、package.json 和 build 这三块

任何一份 Cocos Creator 工程源码拿回来，第一步不是急着打开编辑器，而是先把目录结构看明白。这份“打包成微信小游戏源代码”的工程，我打开后的第一感受是它连场景命名都留了心思，整个工程分为三个层面：编辑器工程区、构建产物区和微信开发者工具导入区。

编辑器工程区对应的是 assets 目录和 project.json、package.json 这些项目级配置文件。assets 底下一般还能看到 scenes、scripts、textures 这些子目录。scenes 里是放游戏场景的，比如 game.fire 这类；scripts 里是 TypeScript 或 JavaScript 写的控制脚本；textures 里是打包用到的图片资源。这份资源里脚本文件命名很直白，你会看到类似 BirdControl、PipeSpawner、GameManager 这样的命名，看名字就能猜到脚本大致职责，排查问题的时候效率会高很多。

构建产物区是你在 Cocos Creator 编辑器里选择“微信小游戏”平台、点构建后生成的那一坨文件。正常生成后会出现一个 build 目录，里面按平台和时间戳建子目录，比如说 build/wechatgame。微信开发者工具要导入的正是这个 wechatgame 目录，不是整个工程。这里有几个新手看了会懵的细节：wechatgame 里会有 game.js、game.json、project.config.json 这些文件，其中 project.config.json 负责向微信开发者工具描述项目信息，而 game.json 里写的是小游戏的窗口配置和设备方向。还有一个 res/ 子目录，放着资源和脚本编译后的产物，但不适合直接手改。

package.json 则记录着引擎版本、模块声明和构建相关配置。打开它你能看到这个项目用的是什么 Cocos Creator 版本，比如 2.4.x 还是 3.x。如果版本对不上，直接用新版引擎打开老工程会弹升级提示，问题不大，但物理参数和 UI 适配可能产生差异。我一般会先看一眼 package.json 里的 creator 字段，再决定用哪个编辑器版本打开。

提示：打开工程前先备份一份原始压缩包。升级过程中编辑器会改动工程配置，万一升级后表现不对，还能回滚到没动过的原版。

2.2 场景与节点结构：小鸟、管道和游戏管理器怎么挂接

场景文件在 assets/scenes 下，双击打开后你会看到典型的 Cocos Creator 层级面板结构。按照常见的横版跳跃游戏设计，场景里至少有 Canvas、GameManager 和 UI 层这三个主要框架。Canvas 下面挂场景背景、地面、小鸟、管道生成器；GameManager 是空的挂载节点，控制游戏状态机，比如 READY、PLAYING、OVER 三种状态；UI 层则放分数、开始按钮、结束面板。

这份源码里的节点命名没有用“node1、node2”这种含糊的名字，这也是我更愿意推荐它做入门资源的原因。你点开一个叫 Bird 的节点，它的组件列表里会挂着 Sprite 渲染组件和一个自定义脚本 BirdControl。再往下看，小鸟的子节点通常还会有一个 CircleCollider 或 BoxCollider 碰撞体，具体取决于项目用的是 2D 物理还是直接坐标判定。这里的选型很讲究：如果碰撞逻辑是自己在脚本里算距离，那就没必要开物理引擎，还能省下不少包体体积。后面构建章节我会专门讲模块裁剪，这里先埋一点：模块勾选直接影响微信小游戏首包大小，很多问“为什么我的包这么大”的人，先看这个。

管道生成器会挂在一个 PipeSpawner 脚本上，负责定时生成上下一对管道并推进它们向左移动。游戏管理器则挂 GameManager 脚本，负责监听小鸟碰撞事件、计分、切换游戏状态。搞清楚这些挂接关系，你后面改玩法才有方向。比如想把只鸟从 Flappy Bird 改成钢琴块，本质就是换掉卡片生成逻辑和判定逻辑，骨架并不需要动。

2.3 核心玩法脚本逐个拆：控制、生成、碰撞三条线

核心脚本通常拆成三块。第一块是小鸟控制，典型实现是每帧给刚体施加一个向上的冲量或者直接改 y 坐标，并配合一个重力常量往下拉。我给这里的代码补一个简化版，方便你把脚本和场景对应着读：

const { ccclass, property } = cc._decorator; @ccclass export default class BirdControl extends cc.Component { @property jumpSpeed: number = 350; // 是否允许玩家操作 private canControl: boolean = false; start() { // 初始时等待 GameManager 发开始信号 cc.systemEvent.on('game-start', this.enableControl, this); } enableControl() { this.canControl = true; } update(dt: number) { if (!this.canControl) return; // 点击或触摸时给小鸟一个向上的速度 if (cc.isValid(this.node)) { this.node.y += this.jumpSpeed * dt; } } }

这段代码的主干是 update 里每帧向上叠加位移，jumpSpeed 控制跳跃强度。如果原始工程用的是刚体，那这里的做法会替换成调用 rigidBody.linearVelocity。两种做法的差别在于：遇到管道碰撞时刚体写法自带物理反弹效果，而直接改坐标写法则需要自己写碰撞检测，但控制感更直接，不容易出现弹飞这种“玄学”现象。参数 jumpSpeed 可以先用 350，如果你发现小鸟跳得发飘就降到 300，手感太肉就提到 400。

第二块是管道生成与移动。常见做法是节点池回收，不反复 instantiate/destroy，而是用 cc.NodePool 把移出屏幕的管道重新放回池里复用，这样不会因为生成销毁导致微信小游戏内存抖动：

const { ccclass, property } = cc._decorator; @ccclass export default class PipeSpawner extends cc.Component { @property(cc.Prefab) pipePrefab: cc.Prefab = null; @property spawnInterval: number = 1.5; @property moveSpeed: number = -120; private pool: cc.NodePool = new cc.NodePool(); spawnPipe() { let pipe = this.pool.get(); if (!pipe) { pipe = cc.instantiate(this.pipePrefab); } pipe.parent = this.node; pipe.y = Math.random() * 200 - 100; pipe.getComponent(PipeItem).init(this.moveSpeed, () => { this.pool.put(pipe); }); } }

spawnInterval 是生成间隔，数值越小难度越大。moveSpeed 是管道向左移动速度，负值表示向左。把管道放进 NodePool 这个操作在这类小游戏中是常规且必要的优化，否则场景里同时存在几十个节点，微信小游戏的绘制调优和内存表现都会变差。如果你看到源码里的实现不是 NodePool 而是直接销毁重新创建，那也不用急着否定，游戏规模小并且目标真机性能好的情况下也能跑，但建议你还是改成池子方案更稳妥。

第三块是碰撞与计分。碰撞判定的写法分为两种：一种是小鸟节点挂 cc.Collider2D，靠物理系统回调 onBeginContact；另一种是脚本里每帧检查小鸟矩形和管道矩形是否相交。后者更轻量，不用引入物理模块，实现起来只有几行 AABB 判断。你看到源码里用哪一种，就直接沿用，不要把两个方案混在一起改，我见过有人为了让碰撞更准同时开了物理引擎又手写判定，结果竹篮打水一场空，包还大了两兆。

3. 微信小游戏打包：构建面板参数、模块裁剪与首包体积控制

3.1 构建面板从零到一：平台选择与包名配置

Cocos Creator 打包微信小游戏的整体流程不长，但每一步配置错了排查成本都不低。我拆这份源码时重点看了它的构建配置，因为工程代码写得再花哨，构建面板配错了照样出不来。从编辑器菜单打开“项目 -> 构建发布”，你会看到一个构建面板。首先要做的是在“发布平台”这个下拉框里选择“微信小游戏”，选完 Cocos 会自动把构建输出目录调整到 build/wechatgame。

接下来功能勾选呈现：在 2.4.x 版本中，构建面板一般会有“初始场景”、“MD5 Cache”、“调试模式”、“分离引擎”这些选项充值。3.x 版本的变化会更大一点，但核心的“是否拆包”和“资源服务器地址”这两个依然在。普通项目建议开启 MD5 Cache，这样文件内容变化时会自然带着指纹更新，避免微信小游戏里的缓存一直加载旧文件。你看这份源码的构建产物里，文件名带了一长串哈希，就是 MD5 Cache 的结果。

游戏方向这一块别忘。经典小鸟是小竖屏游戏，需要在“屏幕方向”里选“竖屏”，对应到 game.json 里的 deviceOrientation 为 portrait。如果你不改，微信小游戏会按照默认的横屏去展示你的竖屏画面，两个大黑边瞬间让你怀疑人生。另外 AppID 在你没有真正注册微信小游戏之前可以先填测试号，构建和预览调试都不受影响，只是真机分享时受限制。

注意：真机预览时微信开发者工具需要保持登录同一个微信账号。用测试号只要扫码就能真机预览，不影响开发调试，但发布上线必须换成正式 AppID。

3.2 模块裁剪：首包小一兆它说了算

Cocos Creator 构建时各种内置模块是默认全部勾选的。但对一个小鸟游戏来说，2D 物理、3D 渲染、粒子系统、骨骼动画这些模块可能完全无用。模块裁剪就是把不需要的能力从引擎包里剔除，直接改变最终的包体大小。构建面板里“包含模块”这一项里，看着勾选清单你会看到 3D Physics、Particle System、Video Player、WebView 等选项。这份源码的工程配置里已经把很多不相关模块取消了勾选，保留的通常是 cc.Node、Sprite、UI、Audio、2D 系统这些。

以我的习惯，模块裁剪遵循“按需加回”原则：先把默认全选改成最小集，再根据运行时报错逐个把用到的模块加回来。模块少了之后，引擎代码体积会明显缩水，首包压缩前从 3MB 掉到 1.5MB 都不稀奇。需要提醒的是，裁剪模块后清缓存重跑一次完整流程，否则微信开发者工具和 Cocos 编辑器各自的缓存会掩盖掉缺模块的错误。你可以在构建后把“调试模式”打开，然后在微信开发者工具里跑一遍核心流程——从点击开始到撞击结算，确保没有弹出“xx module is not defined”这类报错。

3.3 分包与远程资源：大包体下的两条后路

如果包体在 4MB 限制内，直接整包发布最省心。遇到资源多、包体超限的情况，两条后路分别是代码分包和远程资源加载。代码分包是微信小游戏的标准能力，把 game.js 拆成主包和分包，用户先加载主包玩第一关，后面内容走分包。Cocos Creator 3.x 里支持构建时按照 bundle 配置自动拆包，2.4.x 则要手动配置构建发布里的“起始场景”和“Bundle”组织方式。远程资源则是把图片、音频放到你的服务器或 CDN，然后小游戏启动时从网络加载。远程加载需要在小游戏后台配置好合法域名，开发阶段可以在开发者工具里勾选“不校验合法域名”来临时绕过。

这套源码的场景相对简单，资源量不会触及 4MB，所以你看它工程里并没有做很复杂的分包配置。但你把技术栈迁移到自己更复杂的项目时，记得回到这两条路来重新规划。

4. 真机调试与上线前检查：帧率、内存和域名缺一不可

4.1 从模拟器走向真机：预览调试的正确姿势

微信开发者工具里模拟器的一切表现都只能算参考，真正的考核发生在真机预览。调试这份源码时，我建议的路径是先用微信开发者工具打开构建产物目录，跑“预览”生成二维码，再用手机微信扫码。进入游戏后，打开微信开发者工具的“调试面板”，你能在手机上看到 console 日志和网络请求。厨房里听不到的声音用耳朵判断不了，工具的日志能逼出音频加载失败这类隐蔽问题。

真机预览时你需要关注几个重点：第一是首屏加载时间，从扫完码到见第一个画面超过 5 秒就要回头查包体大小和资源网络请求；第二是帧率，小鸟跳跃和管道移动都是持续运动的，掉帧很容易察觉，60 FPS 的项目掉到 40 FPS 会明显卡顿；第三是触摸响应延迟，模拟器里点击和小鸟跳跃之间几乎是同帧的，真机如果感觉慢了半拍，多半是触摸事件监听和物理更新在帧调度上打架。

4.2 用 Profiler 看性能：一帧里到底谁在拖时间

Cocos Creator 编辑器里自带 Profiler，微信开发者工具里也有性能面板。我会把两个一起开，一个看引擎内部耗时，一个看渲染和内存。小鸟游戏的性能瓶颈通常集中在两个地方：节点数量和 draw call。节点数量来自管道池复用不彻底或场景残留未清空的对象池，draw call 则来自图片资源无法合批。观察帧率掉帧时，切到Profiler 的“UI”和“JS”分类，如果看到逻辑脚本耗时占了 40% 以上，就是脚本写得太重了。比如每帧动态创建对象、频繁遍历节点这些写法都会把 JS 耗时顶上去。

遇到这种场景，我的习惯是把 update 里的高频计算拆成定时轮询或加阈值判断。比如小鸟 y 坐标每帧都更新，碰撞检测只需要在管道节点进入活动区域时才做；分数累加只需要在碰撞体接触瞬间触发，不必每帧轮询。

微信开发者工具性能面板里还有内存走势图。如果内存用一会就只涨不跌，极大概率是节点池或事件监听泄漏。泄漏在手机上是慢慢温吞地卡死，难受程度比瞬时崩溃更真实——玩着玩着越来越卡，最后无响应，只能强杀进程。排查泄漏比较直接的手段是连续玩十局，每局结束后观察内存是否回落，不回落的那个对象清单就是嫌疑目标。

4.3 合法域名与远程资源：上线前网络这关

如果你的资源里有任何远程加载——不管是音频、图片还是排行榜接口——上线前必须在小游戏管理后台配置 request 和 downloadFile 的合法域名，且必须是 HTTPS 并有有效证书。开发阶段可以靠工具里的不校验域名选项绕过，但正式版本这条绕不过去。这一关容易翻车：域名配了但没带端口号，或者证书只支持了 PC 端浏览器，到了微信里就请求失败。最省事的检查方式是先在开发者工具里关闭“不校验合法域名”重新预览一遍，所有网络请求都通了再提审。

5. 避坑：打包微信小游戏我踩过的 5 个坑

5.1 现象：预览正常，微信开发者工具白屏

第一次在微信开发者工具中导入构建产物时，最常碰见的就是一片白屏，console 栏没有任何明显报错，或者只有一句“game.js 加载失败”。原因多半不是代码问题，而是构建产物目录选错了。有人把整个整个 Cocos 工程目录导进了微信开发者工具，而微信小游戏要求导入的是构建生成的 wechatgame 这个子目录。解决方法是重新导入，项目目录字段指向 build/wechatgame，同时检查 project.config.json 存在且完整。从那次之后，我每次构建完都会先看一眼 wechatgame 里有没有 game.js，再导入开发者工具。

5.2 现象：触摸事件时灵时不灵，鼠标点击正常

在 Cocos 编辑器预览时点哪都能触发跳跃，到了微信小游戏真机预览，发现有时候手指点了没反应。原因在于监听事件类型选错了。Cocos 在浏览器预览模式下鼠标事件能跑，但在微信小游戏环境里必须注册触摸事件。解决方法是把事件监听换成 cc.Node.EventType.TOUCH_START，不要把 TOUCH_END 当点击用，因为玩家可能在按下瞬间就移动手指。修复之后，跳跃响应会明显变得更干脆，这个坑在几乎所有手机小游戏上都会遇到。

5.3 现象：构建成功但首包超过 4MB 限制

发布时微信要求首包不能超过 4MB，构建产物明明不大，一压缩却总超限。原因通常是“分离引擎”、“调试模式”或多余模块还开着。调试模式下引擎不压缩，包体会明显膨胀。解决方法是发布前打开构建面板，关掉“调试模式”，再执行一次模块裁剪，把不用的物理、粒子、视频模块全都去掉。裁剪后如果还超，再走远程资源和分包的路。值得注意的是，4MB 是“首包加载时下载量”的限制，不是压缩包总大小，所以远程资源这种“首包不下载”的方案才有用。

5.4 现象：真机声音不出来，模拟器里好好的

音频只在模拟器里能响，真机却鸦雀无声。常见原因是 Cocos Creator 的 AudioSource 组件在手机上默认走了不符合小游戏音频上下文的通道，微信小游戏需要在用户第一次触摸屏幕后初始化音频，浏览器自动播放政策也有类似限制。解决方式是确保音频管理器在触摸事件回调里调用一次播放函数，并处理 audioEngine 的 resume 逻辑。也可以把音频资源通过微信小游戏的 Audio 接口单独加载，避开引擎层的默认行为。这个坑的隐蔽性在于 console 不会报错，只能说全靠耳朵。

5.5 现象：屏幕两边黑边或全部拉伸变形

不同手机的比例差异很大，直接按设计分辨率全屏显示时，有的手机上下露白边，有的横向拉伸得不像样子。原因是没有正确设置 Canvas 的适配策略。解决方式是 Cocos Creator 中 Canvas 组件选择“适配屏幕宽度”和“适配屏幕高度”组合策略，设计分辨率按 750x1334 来配，同时背景图或者地面做成可拉伸的九宫格。如果你在主场景里固定了某个 Node 的大小，换到细长屏幕上就会出现摆放错位。给地面和背景做的每一张图，都要想到它在宽高比 19.5:9 和 16:9 上默认撑满。

6. 复用与改造：给组件加个调试热区，任何玩法都能装进这套壳

严格来说，元导入这份源码后你拿到的不只是小鸟跳跃这一个玩法，而是一套通用的“单键反应游戏”框架：一个可控制对象、一组障碍生成、一个碰撞反馈。想把它改造成别的小游戏，我习惯从两个点入手。第一是为主角控制脚本加一个调试热区，让未在编辑器中选中对象时也能在真机上手动拉起跳跃事件。第二是抽出计分与存档逻辑，本地缓存最高分，避免每局都清零。这类改造不复杂但特别省事：换游戏内容时，我们不用动心跳逻辑，只换预制体资源和参数。

具体做法是：在 GameManager 脚本里加一个 debugTouchEnabled 属性，默认在场景里打开。伪代码如下：

if (this.debugTouchEnabled) { this.node.on(cc.Node.EventType.TOUCH_START, () => { this.emit('game-start'); this.currentScore++; }); }

跑通的流程是：准备新玩法的几张图片和音效，替换原工程场景里的资源；调整 jumpSpeed、spawnInterval 和 moveSpeed 三个参数，让手感匹配新的视觉表现；在构建面板里重新确认平台为微信小游戏，再走一遍构建、导入、预览。这套流程我走了很多次，每次做完都更确信：从复用到上线，中间最值得投入的是练好那套构建检查和性能排查。真机预览不是验证结束，而是要持续开着性能面板玩几局，留意内存和掉帧。

有一次我图省事，改完碰撞体尺寸后没有点保存场景就去构建，结果微信开发者工具里一切正常，一到真机就出现小鸟穿管子的离奇表现。查找半天才发现碰撞体改好了但场景没存，构建产物带的还是旧数据。从那以后我每次在场景编辑器里动过任何组件参数，都强制定死思路：先在编辑器跑一次预览、保存场景、再构建、最后微信开发者工具里重新加载。这四步顺序打死不变。真心的，这套源码最能让新手受益的不是代码多精妙，而是一个聪明的前人把那些坑替你试过了。希望帮到你，顺着构建流程走一遍，你会对 Cocos 里“打包小游戏”这件事彻底脱敏。

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