Creator 商店插件怎么选

5.1 商店里到底有哪些东西

我第一次打开 store.cocos.com，是为了给 Skyline Courier 找个能自动排布 UI 的小工具。首页那个推荐位把我带偏了挺久。推荐位排的绝大多数是 3D 源码工程和整包商业游戏，跟 2D 小游戏开发者真正会掏钱买的东西不在一个频道。后来我改成从分类页一层层点进去，范围才缩到能看完。

商店官方只分六大类：Creator Extensions（含插件、云组件、SDKHub 插件）、Code、Art、Music、Tools、Other。这个分类太粗，我在项目里是按「这东西替我干什么」来分的，下面这张表是我的分法：

有个地方我要特别说明：商店里没有独立命名的「登录」「云存档」「推送」插件。我早期以为能直接搜到，后来发现这些能力在 Cocos SDKHub（Account&IAP、IAP、Advertising、Push 四类）里，华为侧则走 HMS Core 插件。想做账号体系，先去 SDKHub 那边看，不要在商店分类里瞎找。

分类看清楚了，再往下的判断其实很朴素：这个东西如果我自己写要花多少时间，它替我做的事会不会随项目变大而变多。

5.2 我打开一个插件页面前后看的六件事

顺序不能乱。我一般按下面这套流程走，任何一项不过关就直接关页面。

第一件，看它是不是开源。 商品页通常有 GitHub 链接。开源不代表质量一定好，但意味着我能读到全部代码，出问题能自己改，也能确认它有没有在偷偷上报数据。我买过一个批量整理 Prefab 的扩展，仓库里只有一句 README，作者两年没更新，但代码就两百行，我照着改了一版自用，反而用到现在。

第二件，看最近更新时间。 商品页上有个版本标签，那是作者声明测试过的 Creator 版本，不等于代码最近一次改动的时间。我会再点进仓库看 commit 记录。两边差得远，就说明作者改了版本号但没动代码，这种插件问题通常不少。

这里补一条实测出来的：商店的版本标签变动很快。我核对过 Google AdMob 那个商品页，标的是 v3.7.3；抖音 SDK 接入范例标的还是 2.4.7。标签只说明作者当年测过哪个版本，不代表现在能用。所以别在书里写死某个插件的版本要求，要写就写「截至我核对时的标注」，读者点进去看到的不一致是正常的。

第三件，看有没有写清依赖。 一个好插件会写明需要哪个第三方 SDK、需要哪个 npm 包、要手动改哪些引擎源码。什么都不写的，多半是没想清楚要别人怎么用。

第四件，看作者是否还在这个生态里。 我会搜作者的论坛 ID。Cocos 论坛 forum.cocos.org 上，作者一般会开一个跟插件同名的帖子。帖子里有人回帖说作者回得多，说明人还在；作者半年不回但插件也没更新，那基本就是弃坑了。

第五件，看它影响的是编辑器还是运行时。 编辑器扩展只在你自己的机器上跑，出问题最多是卡一下编辑器。运行时 SDK 会进到你的包体里，进到微信小游戏的代码里，涉及隐私、审核、包体，评估标准要严一档。

第六件，看价格和它替你省下的活成不成比例。 商店里有标价三位数的工具，也有免费的。一个成熟团队用一年的时间成本去比，比拿标价去比靠谱得多。

5.3 社区评价怎么翻

商店页面的评论区信息量通常不高，作者回复的内容也常常是「已修复，重启编辑器试试」这种没有信息量的话。我翻评价有几个固定动作。

先搜论坛而不是先搜商店。Cocos 论坛按插件名搜，能找到作者发的说明帖和别人的使用反馈。帖子比评论有价值，因为里面有完整的上下文：什么版本、什么项目、什么现象、怎么解决的。

翻评价的时候我盯两件事。一是专门翻差评，看有没有人跟帖。我关心的不是差评本身，是差评下面有没有其他用户给出替代方案，或者作者给出真实原因。有一条评论提到「在 3.8.4 上 Widget 组件的 align 行为变了导致错位，作者说是 3.8.5 才修」，这种信息比商品页上的版本标签有用得多，因为它精确到了小版本。

二是看反馈里有没有出现「我干脆自己写了一个」。这种评价往往价值最高，它说明这个需求确实存在，但现有方案不合适。那你就该考虑自己写，而不是继续找下一个插件。

还有一条经验：看插件有没有被用在小游戏上。同样是插屏广告 SDK，原生端和微信小游戏端的实现难度差一个数量级，如果评论区全是「安卓正常，小游戏上报没数据」，那这个 SDK 对我的项目就是无效的。

5.4 什么该自己写，什么该买

我给自己划的三条线。

通用且一次性的东西，自己写。 比如把 30 个 Prefab 按名字规则重命名、把图集里某几张图换掉、导出一张配置表。这些事写一次脚本半小时，之后再不复用，买插件反而要适配它的输入输出格式。

长期要维护的东西，买或者抄成熟方案。 对象池、事件总线、对象状态机、存档序列化、网络协议框架，这些东西你项目里会一直用，而且用得越久越需要稳定。自己写第一版不难，难的是两年后回头看还认得出。

平台能力相关的，买。 广告、支付、登录、推送、分享，这些涉及平台 SDK 细节、审核规则、版本差异。你的价值不在于重新实现一遍微信小游戏的激励视频 API，而在于把广告位设计得合理。这类东西免费的多、付费的少，先找官方或大厂出的。

还有一条判断标准我常用来：这个东西如果换个人接手维护，会不会很难？如果答案是「会」，那它就不该在你的项目里。

5.5 免费插件的坑，和引入前的评估清单

免费插件不等于低质量，但免费插件的坑有固定的几种。

第一种是配置文档不全。作者觉得「装上就懂」，没写要改哪个设置、哪个平台要额外操作。你按文档配完跑不起来，只能自己去翻作者的源码。

第二种是示例跑不起来。示例工程用的是老版本 Creator，序列化格式和 3.8 差着几代，打开一堆黄色警告，或者直接报序列化错误。插件本身可能没问题，是示例老了。

第三种是作者弃坑。插件两年前就停止更新，你遇到问题去发帖没人回，源码也读不懂（作者用了大量简写和缩写）。这种插件一旦出 bug，你只能自己修。

第四种是免费版阉割。功能在，但导出有水印、有数量限制、只能处理十来个对象，或者每次运行要联网授权。

引入一个插件之前，我把检查项固定成这张表：

我把这张表做成了一张小清单存在项目里，每次引入新插件就过一遍。听起来啰嗦，但真出过事之后就不觉得啰嗦了：我曾装过一个改 Prefab 的扩展，它往工程里写了自己的配置目录，卸载时我删不干净，后来换了项目结构才发现那堆文件一直在影响资源扫描。

插件装得越多，工程越难维护。Skyline Courier 现在常驻的第三方扩展只有两个，一个做批量资源整理，一个做热更打包。剩下的需求，能自己写就自己写。

5.6 相关阅读

• Cocos Creator 3.8 用户手册
• Cocos Creator 3.7 手册（中文）：插件版本差异对照
• Oops Framework