企业官网建设流程全解析

1. 一个人做微信小游戏，为什么我选了这条技术路线

去年年底我给自己定了个目标：用业余时间独立完成一款微信小游戏，从立项到上线全流程一个人扛。不是那种“三天做个demo”的玩票，而是真正能跑通审核、有留存、能看后台数据的完整产品。当时身边朋友第一反应都是“你一个人？美术、策划、程序、运营全包？”说实话，一开始我心里也没底，但做完之后发现，一人工作室在微信小游戏这个生态里，反而是效率最高的组合方式。

先说说为什么盯上了微信小游戏这个方向。最直接的原因是流量入口足够短——用户点开就能玩，不用下载安装包，不用跳转应用商店，分享到群里就是一条卡片。对于独立开发者来说，获客成本几乎为零，这是任何App都比不了的优势。另一个原因是技术栈相对收敛，微信小游戏运行在类Canvas的渲染环境里，底层是JavaScript/TypeScript的运行时，不需要考虑iOS和Android两套原生代码的适配问题，一个人维护一套逻辑就够了。

那为什么标题里提到了Cocos Creator、TypeScript、Phaser、Canvas这么多东西？因为实际开发中，这些技术点不是二选一的关系，而是根据项目阶段和需求层次组合使用的。我最终的技术选型是：Cocos Creator作为主引擎，TypeScript作为开发语言，Canvas API作为底层补充，Phaser作为原型验证阶段的快速工具。这套组合不是拍脑袋定的，下面我把每个选择的理由拆开讲。

先说引擎选型。市面上做微信小游戏的引擎主要有三个方向：Cocos Creator、LayaBox、Egret，还有直接用原生Canvas手搓的。我试过用原生Canvas从零写一个游戏循环，大概写了三天就放弃了——不是写不出来，而是重复造轮子的成本太高。场景管理、资源加载、动画系统、碰撞检测、粒子效果，这些东西如果全部手写，一个人根本扛不住。Cocos Creator把这些都封装好了，而且对微信小游戏的支持是一线的，官方文档里直接有“发布到微信小游戏”的按钮，点一下就能生成完整的项目结构。

那Phaser呢？Phaser是我在原型阶段用的。当时游戏核心玩法还没定，我需要快速验证“这个玩法好不好玩”。Phaser的优势是轻量、上手快、社区示例多，一个HTML文件引入CDN就能跑起来，改几行代码就能看到效果。我用Phaser大概花了两天时间做了一个可玩的原型，发给几个朋友试玩，收集了一轮反馈之后，才决定用Cocos Creator做正式版本。这个流程我强烈建议一人工作室都走一遍——原型阶段用最轻的工具验证玩法，正式开发再用工程化引擎，不要一上来就搭重型框架，很容易在还没验证玩法的时候就耗尽热情。

TypeScript的选择就更直接了。微信小游戏的底层是JavaScript，但JS的弱类型在项目稍微大一点之后就是灾难。我试过用纯JS写一个超过2000行的游戏逻辑，改一个变量名要全局搜索替换，生怕漏掉哪个地方。TypeScript的静态类型检查能在编译阶段就发现大部分低级错误，而且Cocos Creator对TypeScript的支持是原生的，创建项目时直接选TypeScript模板就行。另外TypeScript的interface和类型声明文件（.d.ts）在对接微信API的时候特别有用，微信官方的类型定义包安装之后，调用wx.login、wx.createUserInfoButton这些接口都有完整的类型提示，不用一边翻文档一边猜参数。

Canvas API虽然被引擎封装了大部分，但有些场景还是得直接调。比如我要做一个文字3D效果的标题动画，Cocos Creator的Label组件不支持这种效果，我就直接用Canvas的2D上下文手动绘制，通过逐帧改变文字的缩放和透明度来模拟3D旋转。还有游戏里的小人形象，我用Canvas的路径绘制API画了一个简单的火柴人，配合骨骼动画的思路，用代码控制每个关节的位置，比用序列帧动画省资源得多。这些底层操作在引擎里都有对应的接口暴露出来，关键是要知道什么时候该用引擎封装好的组件，什么时候该直接操作Canvas。

2. 从零搭建项目：环境准备与工程结构设计

2.1 开发环境搭建的完整清单

正式开发之前，我花了大半天时间把环境搭好。这里列一下我实际用到的工具和版本，避免大家踩版本兼容的坑。

安装顺序有讲究：先装Node.js，再装Cocos Creator，最后装微信开发者工具。Cocos Creator安装时会自动检测Node环境，如果顺序反了，Creator可能找不到Node路径，构建的时候会报错。微信开发者工具安装后要在设置里开启“服务端口”，否则Creator无法自动唤起它进行预览。

注意：Cocos Creator 3.8的微信小游戏构建模板默认使用WebGL渲染，但部分低端安卓机对WebGL支持不完整，需要在构建配置里勾选“兼容WebGL 1.0”选项。这个坑我踩过，测试机上一半的安卓设备黑屏，排查了一天才发现是渲染后端的问题。

2.2 工程目录结构的设计逻辑

一人工作室最容易犯的错误就是目录结构随意，想到哪写到哪。我第一个版本就是这么干的，结果做到第三周的时候，找一个脚本要翻五分钟。后来我重新设计了目录结构，核心原则是按功能模块划分，而不是按文件类型划分。

assets/ scripts/ core/ # 核心框架：事件系统、状态机、对象池 gameplay/ # 玩法逻辑：关卡、角色、敌人、道具 ui/ # 界面相关：弹窗、HUD、按钮 utils/ # 工具函数：数学、字符串、时间 config/ # 配置数据：关卡配置、数值表 prefabs/ # 预制体 textures/ # 图片资源 audio/ # 音效 scenes/ # 场景文件

为什么按功能分而不是按类型分？因为一人开发的时候，你经常需要同时修改一个功能的多个文件。比如改“跳跃”这个功能，可能要动gameplay里的角色脚本、ui里的按钮响应、config里的跳跃力度参数。如果按类型分，这三个文件散落在三个目录里，来回切换很烦。按功能分之后，相关文件都在同一个目录下，改起来顺手得多。

另外我单独建了一个core目录放框架级代码，比如事件总线、对象池、状态机。这些代码在整个项目生命周期里基本不会大改，和业务逻辑隔离之后，重构的时候不会互相影响。对象池这个东西在小游戏里特别重要，微信小游戏的垃圾回收机制和浏览器不太一样，频繁创建销毁对象容易导致卡顿，用对象池复用子弹、敌人、特效这些高频对象，帧率能稳定不少。

2.3 TypeScript类型声明文件的实战用法

TypeScript的.d.ts声明文件在一人工作室的项目里有两个核心用途：对接微信API和扩展引擎类型。

对接微信API这块，微信官方提供了@types/wechat-minigame包，安装之后在tsconfig.json里配置types字段就能自动加载。但实际用的时候发现，官方类型定义有些接口的参数类型不够精确，比如wx.createRewardedVideoAd的返回值类型是any，调用show()方法的时候没有类型提示。我的做法是在types目录下建一个wechat-extend.d.ts文件，手动补充类型声明：

declare namespace WechatMinigame { interface RewardedVideoAd { show(): Promise<void>; load(): Promise<void>; onClose(callback: (res: { isEnded: boolean }) => void): void; offClose(callback: (res: { isEnded: boolean }) => void): void; } }

这样在业务代码里调用ad.show()的时候就有完整的类型提示了，参数写错编译阶段就会报错。扩展引擎类型也是类似的思路，比如我给节点加了一个自定义属性node.userData，就在.d.ts里声明一下，避免到处写as any。

实操心得：.d.ts文件不需要手动import，只要放在tsconfig.json的include路径下，TypeScript编译器会自动加载。但要注意不要和已有的类型定义冲突，如果扩展的接口名和官方定义重名，编译器会报“重复定义”错误。解决办法是用declare module语法扩展，而不是重新声明整个接口。

3. 核心玩法实现：从原型到正式版本的完整过程

3.1 用Phaser快速验证玩法原型

游戏的核心玩法是“闪避+收集”：玩家控制一个小人在不断滚动的场景里左右移动，躲避障碍物，收集金币。这个玩法听起来简单，但手感调优的空间很大——移动速度、加速度、障碍物生成频率、金币吸引力，每个参数都会影响体验。

我用Phaser花了两天做了个原型。Phaser的API设计很直观，创建一个场景、加载资源、写update循环，基本就是照着文档抄。原型阶段我甚至没用图片资源，所有东西都是用graphics对象画的矩形和圆形，因为原型阶段验证的是玩法，不是美术。这一点很多新手容易搞反，花大量时间画素材，结果玩法不好玩，素材全白费。

Phaser原型跑起来之后，我找了五个朋友试玩，收集到的反馈集中在两点：一是“移动太滑了，停不下来”，二是“障碍物来得太突然，来不及反应”。这两个问题都是手感参数的问题，不是玩法本身的问题。我调整了移动的阻尼系数，从0.9调到0.75，让角色松手后更快停下；障碍物的生成间隔从固定值改成随距离动态变化，前期给玩家更多反应时间。调整之后反馈明显好转，这才决定用Cocos Creator做正式版本。

3.2 Cocos Creator中的角色控制与物理系统

正式版本的角色控制我没有用Cocos Creator自带的物理引擎，而是手写了移动逻辑。原因有两个：一是微信小游戏的性能预算有限，物理引擎的碰撞检测开销不小；二是这个游戏的碰撞逻辑很简单，就是矩形和矩形的相交判断，没必要上物理引擎。

手写移动逻辑的核心是一个update函数，每帧根据输入更新角色的位置：

update(dt: number) { const input = this.getInputDirection(); const targetSpeed = input * this.maxSpeed; this.currentSpeed = this.lerp(this.currentSpeed, targetSpeed, this.acceleration * dt); const pos = this.node.position; this.node.setPosition(pos.x + this.currentSpeed * dt, pos.y, pos.z); this.clampPosition(); }

这里的lerp是线性插值，用来实现平滑的加速和减速。acceleration参数控制加速的快慢，值越大响应越灵敏，但太大就会显得“滑”。我实测下来，acceleration在8到12之间手感最好，具体值要根据maxSpeed来调。clampPosition是边界限制，防止角色跑出屏幕。

障碍物的碰撞检测我用的是AABB包围盒，每个障碍物和角色都有一个矩形包围盒，每帧检测两个矩形是否相交。这个算法的复杂度是O(n)，n是障碍物数量。因为同屏障碍物最多十几个，性能完全没问题。如果障碍物数量上百，就需要用空间分割或者四叉树优化，但这个游戏用不上。

3.3 Canvas绘图实现小人形象与文字3D效果

游戏里的小人形象我没有用美术素材，而是用Canvas的路径绘制API代码画出来的。为什么这么做？一是省资源，一个火柴人的绘制代码不到100行，比一张序列帧图省内存；二是灵活，可以通过代码控制每个关节的角度，实现简单的骨骼动画效果。

绘制逻辑大概是这样的：先画头（圆形），再画身体（线段），再画四肢（线段），每个部位的位置由关节角度决定。跑步动画就是让四肢的角度随时间做正弦变化：

const legAngle = Math.sin(this.runTime * this.runSpeed) * this.legSwing;

legSwing控制摆腿的幅度，runSpeed控制摆腿的频率。这两个参数配合角色的移动速度来调，速度越快，摆腿频率越高，看起来就越自然。

文字3D效果是用Canvas的transform实现的。Cocos Creator的Label组件不支持3D变换，我就把文字渲染到一个离屏Canvas上，然后通过ctx.setTransform设置透视矩阵，逐帧改变旋转角度，最后把离屏Canvas的内容绘制到主Canvas上。这个方案的好处是完全可控，想要什么效果就调什么参数；坏处是性能开销比普通Label大，所以只用在标题界面，游戏内不用。

注意：Canvas的setTransform参数顺序是(a, b, c, d, e, f)，分别对应缩放、旋转、平移的矩阵元素。如果搞不清楚矩阵怎么算，可以用ctx.rotate()、ctx.scale()、ctx.translate()这三个方法组合，虽然性能略差但可读性好得多。

4. 微信小游戏打包与性能优化的实战记录

4.1 从Cocos Creator到微信开发者工具的完整打包流程

打包流程看起来简单，但实际操作的坑不少。Cocos Creator的构建面板里选择“微信小游戏”平台，填好AppID，点构建，等几分钟就能生成一个完整的项目目录。然后用微信开发者工具打开这个目录，就能预览和上传了。

但有几个细节要注意。第一，构建时的“资源服务器地址”要填对，如果填了本地地址，上传之后线上用户加载不到资源。我一开始填的是http://localhost:8080，本地预览没问题，上传之后白屏，排查了半天才发现是这个问题。第二，分包加载要提前规划，微信小游戏的主包限制是4MB，超过之后必须分包。我的做法是把首屏需要的资源放主包，关卡资源、音效、大图放分包，通过wx.loadSubpackage按需加载。

第三，首屏渲染时间要控制。微信小游戏的启动流程是：下载代码包→初始化引擎→加载首屏资源→渲染。每个环节都会影响用户的等待时间。我的优化手段是：代码包开启压缩，引擎初始化时只加载必要的模块，首屏资源用雪碧图合并减少请求数。实测下来，首屏渲染时间从最初的4.2秒降到了1.8秒，这个提升对留存率的影响非常明显。

4.2 性能优化的五个关键手段

微信小游戏的性能瓶颈主要在渲染和内存两个方面。我踩过的坑和对应的优化手段整理如下：

DrawCall是渲染优化的核心指标。每次切换纹理、切换材质都会产生一次DrawCall，DrawCall越多，CPU在渲染准备上的开销就越大。Cocos Creator的自动图集功能可以把多张小图合并成一张大图，运行时只需要一次DrawCall就能渲染所有小图。我把游戏里所有UI元素和角色动画帧都打进了图集，DrawCall从最初的80多降到了20左右。

对象池的使用也有讲究。不是所有对象都适合放进对象池，只有创建销毁频繁、初始化开销大的对象才值得池化。比如子弹、金币、飘字这些，创建频率高，每次都要分配内存和初始化属性，用对象池复用能显著减少GC压力。但像场景、UI面板这种创建一次就长期存在的对象，放对象池反而增加管理复杂度，没必要。

4.3 微信小游戏审核的避坑指南

审核这块我被打回过两次，第一次是因为诱导分享，第二次是因为类目选择错误。这两个问题在独立开发者里非常常见，我详细说一下。

诱导分享的判定标准比想象中严格。我在游戏结束界面加了一个“分享给好友复活”的按钮，被判定为诱导分享。后来改成“分享给好友获得金币奖励”，还是被打回。最后改成分享按钮不附带任何奖励，只是单纯提供一个分享入口，才通过审核。微信的规则是：分享必须是用户主动行为，不能和游戏内的利益挂钩。

类目选择也很关键。微信小游戏的类目分为很多种，选错了会被打回。我的游戏是休闲益智类，第一次选了“动作”类目，被打回要求改选“休闲益智”。类目选择的原则是看游戏的核心玩法，而不是看游戏的题材。比如一个跑酷游戏，虽然角色在“跑”，但核心是休闲玩法，应该选休闲类目而不是体育类目。

实操心得：提交审核之前，一定要用微信开发者工具的“体验版”功能自己完整走一遍流程，包括登录、支付、分享、广告观看。很多问题在开发环境里不会暴露，只有真机体验版才能发现。另外审核时间一般是1到3个工作日，节假日会延长，上线计划要留出缓冲。

5. 一人工作室的效率工具与工作流

5.1 用Playwright做自动化回归测试

一人工作室没有测试团队，但游戏上线之后每次更新都可能引入新bug。我的解决方案是用Playwright做自动化回归测试。Playwright可以模拟浏览器操作，我用它来跑游戏的核心流程：启动→进入主界面→开始游戏→操作角色→游戏结束→查看结算。每次更新之后跑一遍，几分钟就能确认核心流程没有被破坏。

Playwright和TypeScript的配合很顺畅，测试脚本本身就是TypeScript写的，可以直接复用游戏里的类型定义。比如测试“金币收集”功能，我可以import游戏里的金币配置，用相同的数值来验证收集逻辑是否正确。这种测试代码和业务代码共享类型的做法，能避免很多因为类型不一致导致的测试误报。

import { test, expect } from '@playwright/test'; test('核心流程回归', async ({ page }) => { await page.goto('http://localhost:7456'); await page.waitForSelector('#game-canvas'); await page.click('#start-button'); await page.waitForTimeout(2000); const score = await page.textContent('#score-label'); expect(Number(score)).toBeGreaterThan(0); });

这个测试脚本虽然简单，但覆盖了最核心的流程。每次改完代码跑一遍，心里踏实很多。

5.2 版本管理与持续集成的轻量方案

一人工作室不需要复杂的CI/CD流水线，但基本的版本管理和自动构建还是要有的。我用的是Git + GitHub Actions的组合。每次push到main分支，Actions自动执行构建脚本，生成微信小游戏的代码包，然后上传到微信开发者工具的CI接口。

这个流程的搭建成本大概半天，但收益很大。以前每次发版都要手动构建、手动上传，容易漏步骤。现在push代码之后等几分钟，构建结果自动出来，我只需要在微信后台点一下“提交审核”就行。Actions的配置文件也不复杂，核心就是安装依赖、执行构建命令、调用微信的CI接口。

注意：微信开发者工具的CI接口需要先在微信公众平台开启“CI权限”，并生成一个密钥。这个密钥要存在GitHub的Secrets里，不要硬编码在配置文件里。另外CI构建的代码包大小可能和本地构建有差异，因为CI环境的Node版本和依赖版本可能不同，建议在CI配置里锁定版本号。

5.3 时间管理与精力分配的真实体会

一人工作室最大的挑战不是技术，是时间管理和精力分配。我白天有正职工作，只有晚上和周末能做游戏。一开始我试图每天做一点，结果发现碎片化的时间根本做不了需要深度思考的事情，比如架构设计、算法调优。后来我调整了策略：工作日晚上只做机械性工作，比如画UI、调参数、写文档；周末整块时间做核心开发，比如写玩法逻辑、优化性能。

这个策略的效果很明显。机械性工作不需要太多脑力，晚上做一两个小时也不会影响第二天上班；核心开发需要连续思考，放在周末整块时间做效率最高。另外我给自己定了一个规矩：每天至少提交一次代码，哪怕只改了一行。这个习惯保证了项目的持续推进，不会因为某天太忙就断掉节奏。

6. 上线后的数据观察与迭代方向

游戏上线第一个月，日活大概在200左右，留存率次日35%、七日12%。这个数据不算亮眼，但对一人工作室的第一个产品来说，我觉得可以接受。通过后台数据我发现几个有意思的现象：用户平均游戏时长只有3.2分钟，说明单局时间太长或者难度曲线有问题；分享率不到5%，说明分享入口的曝光不够或者分享动机不足。

针对这两个问题，我做了两个调整：一是把单局时间从平均90秒压缩到60秒，降低难度曲线的陡峭程度；二是在结算界面增加了一个“炫耀成绩”的分享按钮，展示用户的最高分和排名。调整之后，平均游戏时长提升到4.5分钟，分享率提升到8%。虽然提升幅度不大，但方向是对的。

后续的迭代方向我还在思考。一个方向是增加社交元素，比如好友排行榜、异步对战；另一个方向是丰富关卡内容，现在只有一种玩法模式，玩久了会腻。但一人工作室的精力有限，不可能同时做多个方向，我倾向于先做社交元素，因为微信小游戏的社交裂变是最大的流量来源，把分享和排行榜做好，获客成本能进一步降低。

这个项目从立项到上线大概用了三个月，代码量一万行左右，美术资源大部分是代码生成的，音效用了免费素材。整体投入的时间大概200个小时，按我自己的时薪折算，开发成本相当于一万多块钱。但收获的经验和成就感是钱买不到的。如果你也是一个人想做微信小游戏，我的建议是先做最小可玩版本，快速上线，用真实数据指导迭代，不要憋大招，不要追求完美，先跑起来再说。