实体组件系统（Entity-Component-System，简称ECS）是我在游戏开发领域中非常推崇的一种架构模式。它通过将数据与行为彻底分离，旨在解决传统面向对象设计中我曾遇到的继承复杂性、耦合度过高以及扩展性不足等问题。在这篇文章中，我将分享我对ECS架构优劣的看法、它适用的游戏项目类型，以及结合我的项目经验和kunpo-ecs框架，深入探讨ECS架构在游戏开发中的具体应用。
数据与逻辑的彻底分离（解耦）: 在我的理解中，ECS最核心的优势就是将数据（组件）和逻辑（系统）彻底分开。实体本身只是一个ID，它没有任何数据或行为，只是组件的容器。这种纯粹的解耦让我的代码变得异常清晰，每个组件都只关注数据，每个系统都只关注处理特定类型组件的逻辑。
强大的扩展性: 由于实体是通过组合不同的组件来获得行为的，我可以在不修改现有代码的情况下，通过添加或移除组件来轻松改变实体的功能。这种高度模块化的设计让我能够非常灵活地扩展游戏功能，比如给敌人添加一个新的行为，只需要给它添加对应的组件和处理该组件的系统即可，无需修改复杂的继承关系。
高可维护性: 因为逻辑与数据分离，并且每个系统都只关注拥有特定组件组合的实体，我的代码结构变得非常清晰。每个系统职责单一，这不仅方便我个人理解和修改代码，也极大地提升了团队协作的效率和项目的长期可维护性。
高复用性: 我发现ECS架构的组件和系统具有极高的复用潜力。由于组件是纯粹的数据结构，而系统是针对特定数据组合的纯逻辑处理，这意味着在我的下一个项目中，大部分通用的组件（如位置、生命值、速度等）和系统（如移动系统、渲染系统、碰撞检测系统等）都可以被直接拿来使用，大大减少了重复开发的工作量，提升了开发效率。
数据驱动: 游戏中的各种行为和状态主要通过系统对数据（组件）的操作来体现，而非通过对象方法调用。这种数据驱动的模式让游戏配置化内容提供了天然的支持。
初期学习曲线和适应成本: 对于我这样习惯了传统面向对象设计的开发者而言，ECS的思维模式确实需要一些时间来适应。如何合理地拆分组件、设计系统、以及有效地管理实体生命周期，这些都需要通过实践来积累经验。
初期开发复杂性: 在项目初期，ECS架构的基础设施搭建和完善可能需要我投入更多的时间。组件和系统的设计需要我进行前瞻性思考，以避免后期频繁重构。
过度设计风险: 我也清楚，对于一些小型、逻辑相对简单的游戏，如果盲目引入ECS架构，可能会导致不必要的复杂性，反而增加了我的开发成本和维护难度。
根据我的经验，ECS架构在以下类型的游戏项目中能发挥巨大优势：
需要管理大量动态实体的游戏: 例如策略游戏（RTS）、模拟经营类游戏、MMORPG等，这些游戏往往需要同时管理成千上万个实体，并且这些实体可能拥有复杂的行为和交互。ECS的解耦和模块化特性让我能够更有效地组织和管理这些海量的游戏对象。
物理模拟和复杂AI: 涉及到大量碰撞检测、路径寻路、行为树等复杂计算的游戏，ECS架构清晰的职责划分让我能够更好地设计和优化这些复杂的系统。
数据驱动和高度可配置的游戏: 如果游戏内容需要高度可配置、易于迭代和修改，ECS的数据驱动特性将极大地帮助我。我可以让游戏策划通过简单的配置数据来调整游戏行为，而无需频繁修改代码。
尽管我认为ECS优势显著，但它并非我的万金油：
实体数量少、逻辑简单的小游戏: 对于这类游戏，我可能会选择更传统、更快速高效的面向对象或脚本式开发，引入ECS反而会增加不必要的开销。
强调美术表现和动画、逻辑相对固定的游戏: 例如一些剧情驱动的单机游戏，其核心在于高质量的视听体验和预设的剧情流程。这类游戏对逻辑的动态扩展性要求不高，ECS带来的额外设计成本可能不划算。
开发周期短，资源有限的项目: 在这种情况下，我可能会优先选择自己最熟悉、上手最快的架构，以确保项目能够按时交付。学习和实践ECS可能需要额外的投入。
我个人非常热衷于在游戏开发中采用ECS架构，这在我的项目实践中，特别是像《宫爆老奶奶》《比特小队》这样的游戏中得到了充分验证。
《宫爆老奶奶》是一款Roguelike割草游戏，它的核心特点是：
大量敌人同屏: 玩家需要面对源源不断的敌人，数量可达数百甚至上千。
丰富的技能和道具: 玩家可以通过多种技能和道具组合，产生各种华丽的攻击效果。
复杂的碰撞和伤害计算: 技能与敌人之间、敌人与敌人之间都需要进行实时的碰撞检测和伤害计算。
在传统面向对象架构下，管理如此庞大的对象数量和复杂的交互逻辑，我很容易遭遇维护困难，例如对象间复杂的引用关系、继承链的膨胀以及难以预测的副作用。
而ECS架构完美契合了《宫爆老奶奶》的需求，让我在开发过程中受益匪浅：
清晰的职责分离，轻松管理海量实体: 每个敌人、每个子弹、每个掉落物对我来说都是一个实体。我将它们的位置、生命值、攻击力等纯数据存储在组件中，并通过系统集中处理它们的移动、攻击、销毁等逻辑。这种职责分离让我在面对大量同屏单位时，依然能够保持代码的清晰和逻辑的独立性，从而轻松地管理复杂的游戏状态。
灵活的技能和道具系统，强大的扩展性: 技能和道具对我来说可以被设计为独立的组件。当实体拥有某个技能组件时，相应的系统就会处理其技能逻辑。这种设计让技能的组合和扩展变得异常容易，我可以在不修改核心逻辑的情况下，快速迭代和增加新的技能，且不会导致复杂的继承链。
高内聚低耦合的系统设计: 移动系统只处理带有位置和速度组件的实体；碰撞系统只关注带有碰撞体组件的实体。这种职责单一的设计，让每个系统的实现都非常简洁明了，易于我调试和优化，极大地降低了模块间的耦合。
kunpo-ecs是一个我用 TypeScript 实现的实体组件系统 (ECS) 框架，它是我在游戏开发中实践ECS架构的一个具体案例。它很好地展示了我是如何将ECS架构的核心思想应用到实际项目中的。
kunpo-ecs核心概念的理解与实现实体 (Entity): 在 kunpo-ecs 中，实体对我来说就是游戏对象的唯一标识符，本质上是一个纯数字 ID。它们本身不包含任何数据或逻辑，只作为组件的容器，这符合我追求的“纯粹”实体概念。
组件 (Component): 我强调组件是纯数据结构。在 kunpo-ecs 中，我使用 @ecsclass 和 @ecsprop 装饰器来定义组件及其属性。例如，一个 PositionComponent 可能包含 x 和 y 坐标，一个 HealthComponent 包含 currentHealth 和 maxHealth。我要求组件实现 reset 方法，以便在对象池回收时重置数据，这有助于提高内存效率并减少GC，尤其是在TypeScript环境中。
系统 (System): 系统是我放置游戏逻辑的地方。在 kunpo-ecs 中，我使用 @ecsystem 装饰器定义系统，并通过 matcher 配置查询规则。例如，一个 MovementSystem 可能匹配拥有 PositionComponent 和 VelocityComponent 的实体，并在其 update 方法中更新实体的位置。kunpo-ecs 的查询系统非常灵活，支持 allOf (必须包含所有组件), anyOf (包含任意一个组件), excludeOf (排除特定组件) 或 optionalOf (可选包含组件) 等多种匹配模式，这让我能精确地定义系统作用的范围。
世界 (World): World 是管理所有实体、组件和系统的容器。我需要创建 World 实例，注册系统和系统组，并调用 world.initialize() 初始化。在游戏循环中，我通过调用 world.update(dt) 来驱动所有系统的逻辑，让它们协同工作。
kunpo-ecs的特性及其我的应用数据编辑器: kunpo-ecs 提供了一个基于 Cocos Creator 3.8.6 开发的数据编辑器。这对我来说非常重要，因为它使得游戏策划和开发者可以直观地配置 ECS 数据，例如定义不同类型的实体、为实体预设组件及其初始值，从而实现真正的数据驱动开发，极大地降低了代码修改的频率，提升了迭代效率。
内存高效: 尽管TypeScript环境对缓存命中率的直接提升有限，但kunpo-ecs通过优化的数据结构和算法，如稀疏集合 + 密集数组的数据布局方式，以及对象池的使用，显著减少了内存开销和垃圾回收（GC）压力。这对我处理大量实体时非常有帮助。
简洁API与完整类型支持: TypeScript 的强类型特性为 kunpo-ecs 提供了全面的类型安全，这帮助我减少了运行时错误。简洁直观的API设计也降低了我的学习成本，使得我可以快速上手并投入开发。
灵活的查询系统: 强大的实体查询功能是ECS的核心。kunpo-ecs 的查询器在条件相同时会复用，并且提供了 iterate 和 iterate1/2/3/4 等迭代器，实现零GC或少量GC的组件遍历，这对于我构建性能敏感的游戏逻辑至关重要。
命令缓冲区: kunpo-ecs 采用了命令缓冲区模式来管理实体和组件的变更。这意味着像删除实体、添加/删除组件等操作不会立即执行，而是延迟到下一帧的 update 之前处理。这种设计避免了在系统迭代过程中修改数据结构可能导致的错误，保证了数据的一致性和系统的稳定性，这在多系统交互时尤其重要。
掩码高效匹配: 我利用掩码机制实现高效的组件匹配，这是ECS框架中常见的优化手段，可以极大地提升系统筛选实体的速度，即使在JavaScript/TypeScript环境中，这也是一个有效的优化。
在我看来，ECS架构作为一种强大的游戏开发模式，通过其数据与行为分离的核心思想，为我带来了极高的模块化、强大的扩展性、优异的可维护性和显著的高复用性。我发现它特别适用于那些需要处理大量实体、复杂逻辑和高度可扩展性的游戏项目。虽然其学习曲线和初期投入可能相对较高，但一旦我掌握了它，它能极大地提升我的游戏开发效率和质量。
通过我开发的kunpo-ecs这样的开源项目，我希望能够更深入地理解ECS架构在实际游戏开发中的落地方式，从组件的定义、系统的编写、到世界的管理和内存优化，都能找到清晰的实践路径。展望未来，随着游戏复杂度的不断提升，我相信ECS架构无疑将在游戏开发领域扮演越来越重要的角色，它将是我未来项目中的首选架构之一。
kunpo-ecsgithub:https://github.com/gongxh0901/kunpo-ecs
说实话，写这个工具纯粹是被逼的。
发版那天晚上，对着10+个渠道的打包列表，我一遍遍地重复着：打开 Creator → 选平台 → 构建 → 等 → 开 Android Studio → 编译 → 签名 → 上传 → 发通知…
到第三个渠道我就开始怀疑人生了，到第七个渠道我开始思考为什么要做游戏开发。
那天晚上我就下定决心：这种重复劳动必须自动化。
一条命令，所有渠道自动打包、自动上传、自动通知。我该干嘛干嘛去，等着收结束消息就行。
在动手之前，我先梳理了一下痛点：
渠道太多：Android 官方包、TapTap、抖音APP、微信小游戏、抖音小游戏、支付宝小游戏、华为快游戏、OPPO快游戏、小米快游戏、鸿蒙…
流程重复：每个渠道的打包流程大同小异，但手动操作每次都要从头来
容易出错：手动切换配置、手动签名，稍不注意就搞错
耗时太长：一个渠道打完要好几分钟，10个渠道就是半天起步
所以我的目标很明确：一条命令搞定所有事情。
最开始我也想过用一个大函数把所有逻辑写进去，但很快就发现不行。
不同平台的打包流程差异很大：
如果用一个大函数，代码里全是 if (platform === 'android') {...}，维护起来简直是噩梦。
于是我想到了 Pipeline 模式：把构建流程拆解为独立的步骤（Step），通过 Pipeline 串联执行。
说白了就是把打包流程拆成一个个小步骤，然后按顺序执行：
// Android 打包流程
class BuilderAndroid {
buildPipeline() {
return [
new ModifyVersionJsonStep(), // 修改版本号
new BuildCreatorStep(), // Creator 构建
new ModifyMainJsStep(), // 修改 main.js（热更新用）
new GenerateManifestStep(), // 生成 manifest
new ModifyNativeConfigAndroid(), // 修改 Android 原生配置
new CompileAndroid(), // Gradle 编译
new CopyArtifactStep('apk'), // 拷贝 APK
new SignApkStep(), // 签名
new UploadArtifactStep() // 上传 CDN
];
}
}
// 微信小游戏打包流程
class BuilderWechat {
buildPipeline() {
return [
new ModifyVersionJsonStep(), // 修改版本号
new BuildCreatorStep(), // Creator 构建
new UploadRemoteResStep(), // 上传远程资源到 CDN
new CompileWechat() // 调用微信CI上传到后台
];
}
}
看到没？两个平台共用了 ModifyVersionJsonStep 和 BuildCreatorStep，但后面的步骤完全不同。
这种设计的好处就是：
这是我从 Linus 那句话学来的：数据结构比代码重要。
Context 就是一个数据容器，所有步骤共享同一个 Context，通过它传递数据：
class Context {
#data = new Map(); // 用 Map 存储，性能更好
constructor(params) {
// 存储构建参数
this.set('channel', params.channel); // 渠道
this.set('platform', params.platform); // 平台
this.set('version', params.version); // 版本号
this.set('mode', params.mode); // debug/release
this.set('build', params.build); // 构建号
// ...
}
// 基础操作
get(key) { return this.#data.get(key); }
set(key, value) { this.#data.set(key, value); }
// 步骤结果管理
setStepResult(stepName, result) { ... }
getStepResult(stepName) { ... }
}
为啥要这么设计？
举个例子，CompileAndroid 步骤编译完 APK 后，把产物路径写入 Context：
context.set('OUTPUT_NAME', 'app-release.apk');
后面的 SignApkStep 直接从 Context 读取：
const apkPath = context.get('OUTPUT_NAME');
Step 之间完全解耦，互不依赖。
每个 Step 只做一件事，保持简单。我用了模板方法模式：
class Step {
// 步骤名称（子类必须实现）
get name() {
throw new Error('子类必须实现 name');
}
// 判断是否可跳过（子类可选实现）
canSkip(context) {
return context.isStepExecuted(this.name); // 默认：已执行过则跳过
}
// 执行步骤（模板方法，统一处理日志和错误）
async execute(context) {
if (this.canSkip(context)) {
Logger.log(`⊳ 跳过步骤: ${this.name}`);
return context.getStepResult(this.name);
}
try {
Logger.log(`▶ 开始执行: ${this.name}`);
const startTime = Date.now();
const result = await this.run(context); // 调用子类实现
const duration = ((Date.now() - startTime) / 1000).toFixed(2);
Logger.success(`✓ 完成: ${this.name} (耗时: ${duration}s)`);
context.setStepResult(this.name, result);
context.markStepExecuted(this.name);
return result;
} catch (error) {
Logger.error(`✗ 失败: ${this.name}`);
throw error;
}
}
// 实际执行逻辑（子类必须实现）
async run(context) {
throw new Error('子类必须实现 run()');
}
}
基类帮你处理了日志、计时、错误处理、结果缓存，子类只需要专注于业务逻辑。
Pipeline 的实现超级简单，就是按顺序执行 Step 数组：
class Pipeline {
#steps = [];
constructor(steps = []) {
this.#steps = steps;
}
async execute(context) {
Logger.blue('==================== Pipeline 开始执行 ====================');
Logger.log(`总步骤数: ${this.#steps.length}`);
const startTime = Date.now();
for (let i = 0; i < this.#steps.length; i++) {
const step = this.#steps[i];
Logger.log(`\n[${i + 1}/${this.#steps.length}] ${step.name}`);
await step.execute(context); // 每个步骤共享同一个 context
}
const totalDuration = ((Date.now() - startTime) / 1000).toFixed(2);
Logger.success(`✓ 总耗时: ${totalDuration}s`);
}
}
这里我用了数据驱动的方式，消除了一堆 if/else：
class BuilderFactory {
// 平台 → Builder 映射表
static #builderMap = {
'android': BuilderAndroid,
'ios': BuilderIOS,
'harmonyos-next': BuilderHarmony,
'wechatgame': BuilderWechat,
'alipay-mini-game': BuilderAlipay,
'bytedance-mini-game': BuilderBytedance,
'huawei-quick-game': BuilderHuaweiQuick,
'oppo-mini-game': BuilderOppoQuick,
'xiaomi-quick-game': BuilderXiaomiQuick,
'vivo-mini-game': BuilderVivoQuick
};
static createByPlatform(platform, params) {
const BuilderClass = this.#builderMap[platform];
if (!BuilderClass) {
throw new Error(`不支持的平台: ${platform}`);
}
return new BuilderClass(params);
}
}
新增平台只需要往 Map 里加一行，不改逻辑。
这个优化真的让我省了不少时间。
Android 平台有多个渠道：官方包、TapTap、抖音APP…
它们都要先执行 Creator 构建，而 Creator 构建是最耗时的（5分钟起步）。
如果打3个 Android 渠道，就要执行3次 Creator 构建，15分钟就没了。
但实际上，同平台的渠道可以共享 Creator 构建产物！
在配置文件里，给同平台的渠道设置相同的 group：
[
{ "channel": "official", "platform": "android", "group": "android" },
{ "channel": "taptap", "platform": "android", "group": "android" },
{ "channel": "douyin", "platform": "android", "group": "android" }
]
然后在 BuildCreatorStep 里实现跳过逻辑：
class BuildCreatorStep extends Step {
canSkip(context) {
const channel = context.get('channel');
const buildGroup = DataHelper.channels.getBuildGroup(channel);
// 检查该 buildGroup 是否已经构建过
if (buildGroup && BuildCache.isGroupBuilt(buildGroup)) {
Logger.log(`跳过 Creator 构建：buildGroup [${buildGroup}] 已构建（共享产物）`);
return true;
}
return false;
}
async run(context) {
// 执行 Creator 构建
await runCreatorBuild(...);
// 标记 buildGroup 已构建
const buildGroup = DataHelper.channels.getBuildGroup(channel);
if (buildGroup) {
BuildCache.markGroupBuilt(buildGroup, channel);
}
}
}
效果：
official 渠道：执行 Creator 构建，标记 android 组已构建taptap 渠道：检测到 android 组已构建，跳过 Creator 构建douyin 渠道：检测到 android 组已构建，跳过 Creator 构建3个渠道只需要1次 Creator 构建，从15分钟优化到5分钟！
class BuildCache {
static #builtGroups = new Map(); // 已构建的 buildGroup
static isGroupBuilt(buildGroup) {
return this.#builtGroups.has(buildGroup);
}
static markGroupBuilt(buildGroup, channel) {
if (!this.#builtGroups.has(buildGroup)) {
this.#builtGroups.set(buildGroup, {
builtBy: channel, // 首次构建的渠道
sharedBy: [] // 共享的渠道列表
});
} else {
const info = this.#builtGroups.get(buildGroup);
info.sharedBy.push(channel);
}
}
static clear() {
this.#builtGroups.clear(); // 每次批量构建开始时清空
}
}
批量打包结束后，还会打印共享汇总：
==================== Creator 构建共享 ====================
[android]
构建者: official
共享者: taptap, douyin (节省 2 次 Creator 构建)
我设计了两种使用方式：
运行 npm run build，会弹出交互式界面：
? 请选择渠道类型: (Use arrow keys)
━━━━━━━━ 渠道分组 ━━━━━━━━
🌍 全部渠道 (all)
🎮 小游戏 (minigame)
⚡ 快游戏 (quickgame)
📱 原生平台 (native)
━━━━━━━━ 单个渠道 ━━━━━━━━
❯ 官方android (official)
TapTap (taptap)
微信小游戏 (wechatgame)
...
按上下键切换选中渠道，回车确认，继续输入版本号、构建号、选择模式等。
这种方式适合开发时用，直观方便。
npm run build:jenkins -- \
-p official,taptap \
-v 1.0.0 \
-b 100 \
-d false \
-r 15 \
-m "修复bug" \
-n true
参数都通过命令行传入，适合 Jenkins 等 CI 系统调用。
为了方便批量打包，我还设计了渠道分组：
-p all # 所有渠道
-p minigame # 小游戏渠道（微信、抖音、支付宝）
-p quickgame # 快游戏（华为、oppo、vivo、小米）
-p native # 原生平台（Android、iOS、鸿蒙）
-p official,taptap # 指定多个渠道
实现也很简单：
class ChannelParser {
static parseChannels(channelInput) {
const inputs = channelInput.split(/[,\s]+/);
const channelSet = new Set();
for (const input of inputs) {
// getChannelsByGroupKey 会根据关键字返回对应的渠道列表
const channels = DataHelper.channels.getChannelsByGroupKey(input);
channels.forEach(ch => channelSet.add(ch));
}
return Array.from(channelSet); // 去重后返回
}
}
打包完成后，自动发送飞书通知。
每个渠道打包完成（成功或失败），都会把结果收集到 MessageHelper：
// BuilderBase.start()
async start() {
try {
await pipeline.execute(this.context);
// 成功，收集消息
const message = this.context.getBuildMessage();
message.succeed = true;
MessageHelper.addMessage(message);
} catch (error) {
// 失败，也收集消息
const message = this.context.getBuildMessage();
message.succeed = false;
message.message = error.message;
MessageHelper.addMessage(message);
}
}
批量打包时，所有渠道都打完后，统一发送一条飞书卡片消息：
// build-core.js
async function startBatchBuild(params) {
// 初始化
MessageHelper.initBaseInfo('build', version, mode, '', buildCode);
// 逐个打包
for (const channel of channels) {
try {
await startBuild({ ...params, channel }, true); // true = 跳过单独通知
} catch (error) {
// 继续打包下一个
}
}
// 统一发送通知
await MessageHelper.send();
}
这样打包10个渠道，只会收到1条汇总消息，不会被通知轰炸。
针对不同平台，飞书卡片的展示也不一样：
代码里用不同的方法处理：
#parseBuildMessageElement(messageType, info) {
if (!info.succeed) {
return this.#buildFailMessage(info);
}
if (DataHelper.platforms.isQRCode(info.platform)) {
return this.#buildMessageQrcode(info);
}
if (info.platform === "harmonyos-next") {
return this.#buildMessageHarmony(info);
}
return this.#buildMessageDefault(info);
}
除了完整打包，我还支持了热更新流程。
热更新的 Pipeline 更简单：
class BuilderHotUpdate extends BuilderBase {
buildPipeline() {
return [
new ModifyVersionJsonStep(), // 修改 version.json
new BuildCreatorStep(), // 构建 Creator 项目
new ModifyMainJsStep(), // 修改 main.js
new GenerateManifestStep(), // 生成热更新 manifest
new UploadHotUpdateResStep() // 上传热更新资源到 CDN
];
}
}
复用了 Creator 构建相关的 Step，只是后面的步骤不一样。
所有配置都放在 config/ 目录下，模版在 template/ 目录：
config/
├── base.json # 基础配置（Creator 路径、项目路径）
├── channels.json # 渠道配置（渠道列表、分组）
├── platforms.json # 平台配置（构建路径、打包配置文件）
├── certificates.json # 证书配置（Android/鸿蒙签名证书）
├── oss.json # OSS 配置（上传地址）
├── hotupdate.json # 热更新配置
└── notification.json # 通知配置（飞书 webhook）
配置和代码分离，不同项目只需要改配置文件，不用改代码。
最后放一下项目的目录结构：
src/
├── core/ # 核心框架
│ ├── Context.js # 数据容器
│ ├── Step.js # 步骤基类
│ ├── Pipeline.js # 执行器
│ └── BuildCache.js # 构建缓存（buildGroup 共享）
├── builders/ # 构建器
│ ├── BuilderBase.js # 构建器基类
│ ├── BuilderFactory.js # 工厂类
│ ├── BuilderAndroid.js # Android
│ ├── BuilderWechat.js # 微信小游戏
│ ├── BuilderHarmony.js # 鸿蒙
│ └── ...
├── steps/ # 步骤
│ ├── creator/ # Creator 相关
│ │ ├── BuildCreatorStep.js
│ │ ├── ModifyVersionJsonStep.js
│ │ ├── ModifyMainJsStep.js
│ │ └── GenerateManifestStep.js
│ ├── compile/ # 编译相关
│ │ ├── CompileAndroid.js
│ │ ├── CompileWechat.js
│ │ └── ...
│ ├── sign/ # 签名相关
│ └── upload/ # 上传相关
├── config/ # 配置加载器
├── notification/ # 通知系统
├── oss/ # OSS 上传
├── utils/ # 工具类
└── bin/ # 入口脚本
├── build.js # 交互式打包
├── build-jenkins.js # CI/CD 打包
├── hotupdate.js # 交互式热更新
└── hotupdate-jenkins.js # CI/CD 热更新
说实话，这个工具我写了大概一周，后面又断断续续优化了几天。
核心就这几个东西：
其实架构不复杂，关键是想清楚要解决什么问题。
之后每次发版，我就运行一条命令，然后去喝杯咖啡。等收到飞书通知，所有渠道都打完了。
后来我把它集成到Jenkins后，每次发版，策划直接在网页上点击几下就可以完成打包了。
任务顺利交出去了，反正我再也不用发版当天加班到凌晨了。
如果你也在做游戏开发，也被多渠道打包折磨过，希望这篇文章能给你一些启发。
当然也有Store版本，不想自己动手的可以购买使用：
]]>热更新的本质很简单，说白了就是把游戏资源放到远程服务器，然后客户端在需要时下载远程资源，使用远程资源替换本地文件。
Creator官方提供了热更新方案，详细信息请参考文档热更新。 这里简单介绍一下:
很多年前第一次做热更新功能时，我们把资源按照游戏版本号放到CDN上 最初的方案是这样的
cdn.example.com/game/1.0.0/ # 游戏版本 1.0.0
├── project.manifest
├── version.manifest
└── remote-assets/
├── assets/
├── src/
└── jsb-adapter/
每次发布热更新,直接在 1.0.0/ 目录下覆盖资源再覆盖 manifest 文件和 version.manifest 文件。看起来没问题,但实际上有个时间窗口问题:
2，需要更新 100 个文件从CDN下载的远程资源会保存到本地，开始就直接在可写目录下新建了一个hotupdate文件夹，并没有其他区分机制，导致不同包版本的热更新资源全部放到同一个目录下，跨包版本更新时旧文件没清理干净，运行的是四不像版本，各种诡异 bug。
后来才找到靠谱的方案。这篇文章说说我是怎么踩坑、怎么填坑的。
先明确两个概念:
举个例子:游戏版本 1.0.0 可能有多个资源版本(1、2、3…),每次热更新都会递增资源版本号。
按照下面这样分布热更新资源，还有另外一个好处 可以提前准备热更新资源，并上传到CDN，但是不上传version.manifest文件 等时间到发布的时间节点，再替换掉远程的version.manifest文件，指向最新版本的资源
上文中2.1中提到的问题，是因为我们直接操作了已经发布了的热更新资源，我们不能保证瞬间上传完成，所以就需要已经发布的资源保证不再修改。
所以我们改成了下面这样的CDN文件布局:
cdn.example.com/game/
└── 1.0.0/ # 游戏版本 1.0.0
├── version.manifest # 固定地址,内容指向最新的资源版本
├── 1/ # 资源版本 1
│ ├── project.manifest
│ └── remote-assets/
├── 2/ # 资源版本 2
│ ├── project.manifest
│ └── remote-assets/
└── 3/ # 资源版本 3
├── project.manifest
└── remote-assets/
每次发布热更新,直接在1.0.0/目录下根据资源版本号新建一个目录，然后上传 project.manifest 和 远程资源 文件。
由于每次都会重新下载version.manifest文件，所以我们把变更后的新地址保存到version.manifest中
{
"packageUrl":"https://cdn.example.com/game/1.0.0/3", // 指向新的资源地址
"remoteManifestUrl":"https://cdn.example.com/game/1.0.0/3/project.manifest", // 指向新的 project.manifest 地址
"remoteVersionUrl":"https://cdn.example.com/game/1.0.0/version.manifest", // 这个地址保持不变
"version":"3" // 新的资源版本号
}
当所有文件上传完成之后，最后替换远程的1.0.0/version.manifest 文件
这样就保证了已经发布的资源不会被修改，也不会被覆盖。
玩家热更新时，下载远程的version.manifest文件和project.manifest文件使用的都是本地的project.manifest文件中的地址。
这些地址是不会变化的，指向的远程资源还是老的文件，当然远程version.manifest文件中的地址已经发生变化了。
但是version.manifest目前有用的信息只用到了version字段，也就是资源版本号。
通过查看官方AssetsManager的源码，发现AssetsManager中其实是提供了动态修改远程地址的问题 下载远程version.manifest文件后，把其中的地址相关的信息，覆盖到本地的project.manifest文件中
// 参数1: 本地project.manifest文件路径，可以传空字符串，或者加载后的资源Asset的nativeUrl属性
// 参数2: 本地存储目录
// 参数3: 版本号比对函数，这里我用的是数字，比较大小就行了
this._am = new native.AssetsManager("", writablePath, (v1, v2) => {
return v1 > v2;
});
// 之后下载远程的version.manifest文件，替换本地project.manifest文件中的地址后，再重新加载LocalManifest
this._am.getLocalManifest().parseJSONString(JSON.stringify(content), manifestRoot);
这个就很简单了，可以根据游戏版本号组织本地资源的缓存目录，或者跨游戏版本后，清理之前存的本地资源。
// 之前的资源存储路径
let storagePath = `${jsb.fileUtils.getWritablePath()}hotupdate/`;
// 新的资源存储路径
let gameVersion = '1.0.0'; // 游戏版本号
let storagePath = `${jsb.fileUtils.getWritablePath()}hotupdate/${gameVerison}/`;
main.js文件，添加热更代码project.manifest文件project.manifest 和 version.manifest 文件project.manifest 文件到CDNversion.manifest 文件到CDNversion.manifest文件，比对资源版本号，不需要更新跳过，需要更新继续下一步project.manifest文件，使用3下载的version.manifest文件中的地址，替换本地project.manifest文件中的地址LocalManifestAssetsManager的update方法，开始更新跨游戏版本更新，只需要更新对应版本文件夹下的version.manifest文件，指向最新版本的资源即可。
- 不要修改已发布热更新资源
- 动态修改manifest是关键
- 热更的资源按游戏版本隔离
- 使用脚本自动化构建、热更流程，防止人为操作失误
这篇文章分享的方案不一定是最优的,但起码是我在实际项目中验证过的,基本能覆盖常见场景。如果你也在做热更新,希望能帮你少踩点坑。
有问题随时交流,大家一起进步。
用 Cocos Creator 开发也有段时间了，说实话资源加载这块一直让我挺头疼的。
每次写加载代码都是这样，或者先加载bundle再这样：
resources.load("prefab/player", Prefab, (err, prefab) => {
if (err) {
console.error(err);
return;
}
// 终于可以用了
});
加载个资源要写这么一坨，关键是项目里到处都是这种代码。
更麻烦的是批量加载。比如进入战斗场景，我要加载：
这时候就得自己写循环、计算进度、处理异常…每个项目都要封装一遍，烦死了。
还有资源释放的问题。退出战斗场景时，怎么把刚才加载的资源都释放掉？一个个记录路径？太蠢了。引用计数？自己管理容易出错。
反正就是觉得官方的 API 不太够用，每次都要自己折腾。
既然每个项目都要写，不如封装成库，以后直接用。于是就有了 bit-assets。
核心思路很简单：
import { AssetLoader, IAssetConfig } from "kunpocc-assets";
// 把要加载的资源配置好
let configs: IAssetConfig[] = [
{ path: "config" },
{ path: "icon", type: SpriteFrame },
{ path: "prefab", type: Prefab },
{ path: "texture/avatar", type: SpriteFrame, isFile: true }, // 单个文件
{ path: "pet", type: SpriteFrame, bundle: "battle" }, // 其他 bundle
];
// 创建加载器
let loader = new AssetLoader("battle"); // 给个名字，后面释放用得上
loader.parallel = 10; // 并行的任务数量
loader.retry = 3; // 失败了重试 3 次
loader.setCallbacks({
complete: () => {
console.log("加载完了");
},
fail: (code, msg) => {
console.error("加载失败:", msg);
},
progress: (percent) => {
console.log("进度:", Math.floor(percent * 100) + "%");
}
});
loader.start(configs);
import { AssetPool } from "kunpocc-assets";
let prefab = AssetPool.get<Prefab>("prefab/player");
let icon = AssetPool.get<SpriteFrame>("icon/gold", "bundleName");
// 也可以用 UUID 获取
let asset = AssetPool.getByUUID<SpriteFrame>("xxxxx-xxxx-xxxx");
import { AssetPool } from "kunpocc-assets";
// 释放单个资源
AssetPool.releasePath("prefab/player");
// 释放整个文件夹下的 SpriteFrame 类型资源
AssetPool.releaseDir("icon", "resources", SpriteFrame);
// 重点：按批次释放
AssetPool.releaseBatchAssets("battle"); // 把刚才加载的战斗资源全释放掉
// 释放所有资源
AssetPool.releaseAll();
这个批次释放真的很好用。比如我做了个战斗场景和商城场景：
// 进战斗
let battleLoader = new AssetLoader("battle");
battleLoader.start(battleConfigs);
// 进商城
let shopLoader = new AssetLoader("shop");
shopLoader.start(shopConfigs);
// 退出战斗，一行代码释放所有战斗资源
AssetPool.releaseBatchAssets("battle");
// 退出商城，一行代码释放所有商城资源
AssetPool.releaseBatchAssets("shop");
场景切换的时候再也不用担心资源释放的问题了。
用Creator加载的资源也可以加入到管理中，最后统一释放
resources.load("prefab/player", Prefab, (err, prefab) => {
if (err) {
console.error(err);
return;
}
// 参数1: 资源
// 参数2: 资源所在的bundle 默认: resources
// 参数3: 资源加载批次名 可以不传 默认 ""
AssetPool.add(prefab, resources, "batchName");
});
代码放 GitHub 上了，ISC 协议，随便用：
也有商城版本，同样免费
有 bug 或者建议欢迎提 issue，我看到会回复。
这个库主要是我自己项目在用，觉得还挺顺手的，就分享出来了。
如果你也觉得 Creator 的资源加载 API 不太好用，可以试试这个。代码不多，看源码也很快。
有问题随时交流。
]]>这是我在游戏开发中积累的一系列常用工具，主要基于 Cocos Creator 开发。这些工具涵盖了ECS、行为树、界面属性绑定、EXCEL转JSON、调试工具、内存查看等多种可视化工具。
一个即插即用的 Cocos Creator 调试与性能分析工具，实时编辑属性、定位节点、分析资源内存占用。
商店地址: Cocos Store - 调试与内存分析插件
支持版本: Cocos Creator 2.4.0+
演示视频: Cocos Creator 调试与内存分析插件演示
Cocos官方推荐: 微信公众号。
一个专为 Cocos Creator 3.7+ 设计的实体配置管理插件，通过可视化编辑和数据驱动方案，彻底简化游戏实体配置流程，提升开发效率。
商店地址: Cocos Store - 实体配置插件
支持版本: Cocos Creator 3.7+
一个专为 Cocos Creator 3.7+ 设计的可视化行为树编辑器，通过可视化编辑和数据驱动方案，彻底简化游戏行为树配置流程，提升开发效率。
商店地址: Cocos Store - 行为树插件
支持版本: Cocos Creator 3.7+
一个为 Cocos Creator 3.7+ 和 FairyGUI 设计的界面属性绑定插件，通过可视化编辑绑定代码和UI组件。
商店地址: Cocos Store - 界面属性绑定插件
支持版本: Cocos Creator 3.7+
一个 Cocos Creator 3.7+ 的Excel转JSON插件。
商店地址: Cocos Store - Excel转JSON插件
支持版本: Cocos Creator 3.6+
这套工具集合致力于为 Cocos Creator 开发者提供高效、易用的游戏开发解决方案。无论是独立开发者还是团队项目，都能为您的游戏开发之旅提供强有力的支持。
项目持续优化中，敬请期待更多功能和改进！
]]>《比特小队》是一款由KunpoGames旗下bit工作室倾力打造的Roguelike+TPS（第三人称射击）独立游戏。它将玩家带入一个充满未知与挑战的随机宇宙，你需要探索各个星球，获取强力的道具和装备，战胜不同类型的敌人，最终拯救危在旦夕的星系。
拯救星系是一项艰难的任务。游戏融合了高随机性的Roguelike元素和硬核的第三人称射击玩法。每一次冒险，你面对的关卡、敌人、道具都是全新的。你需要做好充分的准备，并拥有足够的耐心，才能在一次次的挑战中不断变强，收获游戏丰富有趣的核心内容。
除了紧张刺激的战斗，星系中还隐藏着无数的秘密。那些细小的线索就散落在各个角落，每个角色、每个NPC都有着自己的背景故事。游戏拥有海量的武器、道具、成就等待你去收集和解锁。这不仅仅是一场战斗，更是一场发现之旅。
自发布以来，《比特小队》在玩家社区中收获了大量积极的评价。更是获得了9.4分的高分评价，玩家们普遍称赞其为“国产良心之作”，对其“不逼氪金”的付费模式大加赞赏。丰富的游戏内容和极高的可玩性，让许多玩家沉迷其中，并乐于将其与《以撒的结合》等经典独立游戏进行比较。
《比特小队》的诞生并非一蹴而就，它凝聚了团队数年的心血与坚持。
这段漫长而详细的研发历程，不仅记录了游戏的成长，也见证了开发团队与玩家社区之间的紧密互动。正是这种不断的打磨和优化，才最终铸就了《比特小队》这款深受玩家喜爱的优秀作品。
]]>如果你在开发小游戏，特别是需要同时支持微信、支付宝、字节跳动等多个平台，你会发现一个头疼的问题：每个平台的网络API都不完全一样。
微信小游戏用wx.request和wx.connectSocket，支付宝用my.request和my.connectSocket，字节跳动又是另一套API。写一次代码要适配多个平台，需要大量的if-else判断。
kunpocc-net就是为了解决这个问题——用统一的API，让你的网络代码在所有平台上都能跑。
npm install kunpocc-net
import { HttpManager, IHttpEvent } from 'kunpocc-net';
// 定义请求回调
const loginEvent: IHttpEvent = {
name: "login",
onComplete: (response) => {
console.log('登录成功:', response.data);
},
onError: (response) => {
console.log('登录失败:', response.error);
}
};
// 发送POST请求
HttpManager.post(
"https://api.example.com/login",
{ username: "test", password: "123456" },
"json",
loginEvent
);
// 发送GET请求
HttpManager.get(
"https://api.example.com/userinfo",
{ userId: 123 },
"json",
loginEvent
);
import { Socket } from "kunpocc-net";
// 创建连接
const socket = new Socket("wss://game-server.com/ws", {
binaryType: "arraybuffer",
timeout: 5000
});
// 监听连接事件
socket.onopen = () => {
console.log("连接成功");
};
socket.onmessage = (data) => {
console.log("收到消息:", data);
};
socket.onclose = (code, reason) => {
console.log("连接断开:", code, reason);
};
// 发送消息
socket.send("Hello Server");
// 发送二进制数据
socket.sendBuffer(buffer);
// 主动断开
socket.close(1000, "正常关闭");
简单实用：API设计简洁，上手快。一个HttpManager.post()就能发请求，一个new Socket()就能建连接。
跨平台兼容：自动识别运行平台，无需手动适配。在微信、支付宝、字节跳动小游戏，以及普通Web环境都能正常工作。
类型安全：完整的TypeScript类型定义，IDE有完整的代码提示和类型检查。
零依赖：不依赖任何第三方库，打包后体积小。
生产可用：已在多个游戏项目中使用，稳定可靠。
如果你在小游戏开发中遇到网络API兼容问题，或者想简化HTTP请求代码，kunpocc-net应该能帮到你。
]]>✅ 运行时自动展示完整节点树（展开/收起） ✅ 点击节点 → 游戏画面高亮定位 ✅ 属性实时编辑（立即生效，无需编译）
支持的属性包括：
active：激活状态name：节点名称x, y：位置坐标width, height：尺寸大小anchorX, anchorY：锚点设置scaleX, scaleY：缩放比例rotation：旋转角度opacity：透明度(0-255)color.r/g/b：RGB颜色值✅ 按 Bundle / 资源类型 / 路径分组 ✅ 支持按大小与类型筛选（B/KB/MB/GB） ✅ 默认按占用降序，快速定位“大户”资源
直接点击节点高亮定位，现场改位置/尺寸/透明度，省去反复编译验证。
项目运行时感觉卡顿，怀疑是资源加载过多导致的内存压力。传统方式下，你只能靠经验猜测或者写复杂的统计代码。
打开内存面板，按 Bundle/类型/路径盘点占用，优先处理 Top 资源包与贴图集。
新人看节点树结构，逐个点击即见高亮，十分钟熟悉主界面结构。
1) 下载 kunpo-inspector.min.js
2) 放入项目目录
3) 在编辑器设置为插件
1) 推荐下载 kunpo-inspector.min.mjs（或 kunpo-inspector.min.ts）
2) 直接放入 assets/ 目录，无需插件配置
如有建议与问题，欢迎在商店评论区留言，我会优先处理高频诉求并持续打磨体验。
]]>kunpocc（简称kunpocc）是我开发的一个基于Cocos Creator的游戏开发框架。在用Cocos Creator做游戏项目时，经常会遇到一些重复性的开发工作，比如UI窗口管理、资源加载、平台API差异处理等。为了提高开发效率，我把这些常用功能封装成了一个框架。
这个框架已经在几个商业项目中使用。
这是框架的核心功能，基于FairyGUI构建，提供完整的窗口管理功能：
主要特性：
使用示例：
import { Window, _uidecorator } from 'kunpocc';
const { uiclass, uiprop, uiclick } = _uidecorator;
@uiclass("Window", "Home", "MainWindow")
export class MainWindow extends Window {
@uiprop private btnStart: GButton;
@uiprop private txtTitle: GTextField;
@uiclick
private onBtnStart(): void {
console.log('开始游戏');
}
}
提供平台检测和小游戏API封装，支持：
平台检测示例：
import { Platform } from 'kunpocc';
if (Platform.isWX) {
console.log('当前是微信小游戏');
} else if (Platform.isAndroid) {
console.log('当前是Android平台');
}
小游戏API使用：
import { MiniHelper } from 'kunpocc';
// 获取小游戏基础信息
const common = MiniHelper.common();
// 播放广告
const ad = MiniHelper.ad();
// 支付功能
const pay = MiniHelper.pay();
提供统一的计时器管理功能：
import { GlobalTimer } from 'kunpocc';
// 启动定时器 (回调函数, 时间间隔秒, 重复次数: 0=执行一次, -1=无限重复)
const timerId = GlobalTimer.startTimer(() => {
console.log('定时器执行');
}, 1, -1); // 每秒执行一次，无限重复
// 停止定时器
GlobalTimer.stopTimer(timerId);
// 暂停和恢复
GlobalTimer.pauseTimer(timerId);
GlobalTimer.resumeTimer(timerId);
提供屏幕尺寸相关的静态属性：
import { Screen } from 'kunpocc';
// 获取屏幕信息
console.log('屏幕宽度:', Screen.ScreenWidth);
console.log('屏幕高度:', Screen.ScreenHeight);
console.log('设计分辨率:', Screen.DesignWidth, Screen.DesignHeight);
console.log('安全区域:', Screen.SafeWidth, Screen.SafeHeight);
提供热更新的基础功能：
import { HotUpdateManager } from 'kunpocc';
// 需要先获取实例并初始化
const hotUpdate = HotUpdateManager.getInstance();
// 检查更新
hotUpdate.checkUpdate().then(result => {
if (result.code === HotUpdateCode.CHECK_FOUND_UPDATE) {
console.log('发现新版本');
// 可以开始更新流程
}
});
用于UI红点等条件显示功能，需要配合装饰器使用：
import { _conditionDecorator, ConditionManager } from 'kunpocc';
// 条件系统需要先初始化
ConditionManager.initCondition();
// 条件系统主要通过装饰器和条件类来管理UI节点的显示状态
// 具体使用方式需要定义条件类并配合UI节点
src/
├── cocos/ # Cocos Creator适配层
├── condition/ # 条件显示模块
├── fgui/ # FairyGUI相关
├── global/ # 全局工具
├── hotupdate/ # 热更新
├── minigame/ # 小游戏平台
├── tool/ # 工具函数
└── ui/ # UI管理核心
npm install kunpocc
详细的使用文档和示例代码可以在项目的docs目录中找到。
框架还提供了一些配套的开发工具：
kunpo-fgui插件: Cocos Creator插件，可以一键导出FairyGUI界面配置，减少手写代码量。
独立模块：
这个框架的设计原则是实用性优先。每个功能都是在实际项目中遇到问题后，总结出来的解决方案。代码结构清晰，文档相对完整，适合中小型游戏项目使用。
框架还在持续优化中，会根据实际使用中遇到的问题不断改进。如果你也在使用Cocos Creator开发游戏，欢迎试试这个框架，也欢迎提出改进建议。
这个项目主要是为了解决我在游戏开发中遇到的实际问题。如果对其他Cocos Creator开发者也有帮助，那就更好了。
]]>如果你用Cocos Creator开发游戏，要发布到多个平台，你就知道有多痛苦了。
每次更新版本，需要：
一个游戏6个平台，每个平台5-8步操作，手动操作一遍要1-2小时，而且容易出错。
这个工具就是为了把这些重复劳动自动化，一个命令搞定所有平台的打包发布。
原生平台打包:
Creator构建 → 生成热更新manifest → 修改版本号/build号 → 平台打包 → 上传CDN → 飞书通知
小游戏打包:
Creator构建 → 上传远程资源到CDN → 上传小游戏后台 → 设置体验版 → 飞书通知+二维码
热更新发布:
Creator构建 → 生成新manifest文件 → 上传更新资源到CDN → 飞书通知
cd BuildTools
npm install
修改config.json，主要配置：
{
"creator": "/Applications/Cocos/Creator/3.8.6/CocosCreator.app/Contents/MacOS/CocosCreator",
"project": "/Users/your-name/YourGame",
"channels": [
{
"channel": "wechatgame",
"name": "微信小游戏",
"platform": "wechatgame",
"config": "./local/buildConfig_wechatgame.json"
}
],
"platforms": [
{
"platform": "android",
"native": "./native/engine/android/app",
"build": "./build/android/proj"
}
]
}
# 阿里云OSS（用于CDN上传）
export OSS_ACCESS_KEY_ID="your-key-id"
export OSS_ACCESS_KEY_SECRET="your-key-secret"
export OSS_URL="your-oss-url"
export OSS_REGION="oss-cn-hangzhou"
export OSS_BUCKET="your-bucket"
# 飞书通知机器人
export FEISHU_ROBOT_WEBHOOK="your-webhook-url"
# Android打包工具
export APKSIGNER="/path/to/sdk/build-tools/30.0.3/apksigner"
交互式打包:
node BuildCommand.js
# 选择平台、输入版本号、选择debug/release
命令行打包:
# 打包微信小游戏 v1.2.0 release版
node BuildJenkins.js -p wechatgame -v 1.2.0 -b 1 -d false -n true
# 热更新 Android v1.2.1
node HotUpdateJenkins.js -p android -v 1.2.1 -hot 1001 -d false -n true
集成Jenkins:
// Jenkins Pipeline 示例
pipeline {
agent any
parameters {
choice(name: 'PLATFORM', choices: ['wechatgame', 'android', 'harmonyos-next'], description: '选择平台')
string(name: 'VERSION', defaultValue: '1.0.0', description: '版本号')
booleanParam(name: 'IS_DEBUG', defaultValue: false, description: '是否Debug版本')
}
stages {
stage('Build Game') {
steps {
script {
sh """
cd BuildTools
node BuildJenkins.js -p ${params.PLATFORM} -v ${params.VERSION} -b ${env.BUILD_NUMBER} -d ${params.IS_DEBUG} -n true
"""
}
}
}
}
post {
success {
echo "构建成功: ${params.PLATFORM} v${params.VERSION}"
}
failure {
echo "构建失败"
}
}
}
配置化驱动: 通过JSON配置文件管理所有平台参数，不需要改代码。
模块化设计: 每个平台一个独立模块，添加新平台只需实现对应接口。
完整的构建链: 从Creator构建到最终发布的完整自动化。
错误处理: 每步操作都有结果检查，构建失败会及时停止并通知。
通知集成: 自动发送飞书通知，包含版本信息、下载链接、二维码。
// platforms/YourPlatform.js
class BuildYourPlatform {
static async build(config, channel, version, buildCode, isDebug) {
// 实现平台特定的构建逻辑
return Result.success();
}
}
// AutoBuild.js
this._platformFlowBindFuncs = {
['your-platform']: this.buildYourPlatformFlow,
// ... 其他平台
}
{
"channels": [
{
"channel": "your-channel",
"name": "Your Platform",
"platform": "your-platform",
"config": "./local/buildConfig_your-platform.json"
}
]
}
继承基础构建类，重写需要的方法：
class CustomAndroidBuild extends BuildAndroid {
static async beforeBuild() {
// 构建前的自定义操作
await super.beforeBuild();
// 你的自定义逻辑
}
static async afterBuild() {
// 构建后的自定义操作
await super.afterBuild();
// 你的自定义逻辑
}
}
添加新的通知渠道：
// notifications/YourNotification.js
class YourNotification {
static async send(title, content, isDebug) {
// 实现通知逻辑
}
}
AutoBuild.js: 主控制器，协调各模块BuildCreator3.8.js: Creator构建封装platforms/: 各平台构建实现utils/: 通用工具类（命令执行、文件操作、结果处理）oss/: CDN上传模块NotificationFeishu/: 飞书通知模块遵循现有模式: 每个平台模块都返回Result对象，统一错误处理。
配置优先: 尽量通过配置文件控制行为，减少硬编码。
详细日志: 使用Colors.js输出带颜色的日志，方便调试。
异常处理: 每个异步操作都要try-catch，构建失败要有明确提示。
如果你也被多平台打包折磨，不妨试试。
]]>