90%的Cocos开发者不知道，插件还能这么玩！

引言

哈喽大家好，我是亿元程序员，一位有着8年游戏行业经验的主程。

很多Cocos开发者 平时都会用插件，但真正自己写过全局插件的小伙伴，可能并不多。

普通插件一般跟着项目走，只服务当前项目。

全局插件 就不一样了，它安装在Cocos Creator的全局扩展目录中，只要你打开编辑器，不管切换到哪个项目，都可以使用同一套工具。

这就非常适合沉淀一些通用能力。

比如打开项目目录、启动本地工具、资源检查、Prefab批处理、构建辅助、小游戏包体分析等等。

举个例子，像下面这种发布辅助能力，就非常适合放到全局插件里：

为什么这个例子适合做成全局插件？

因为它不是某个游戏玩法里的业务逻辑，而是很多项目都可能用到的发布流程能力。

今天 项目A要上传到服务器，明天项目B也要上传到服务器。

如果每个项目都单独写一套上传按钮、分支前缀、预览地址配置，后面维护起来就会很麻烦。

但如果 把它做成全局插件，就可以在所有Cocos项目中复用同一套上传逻辑。

这就是全局插件最有价值的地方：把重复流程做成编辑器能力。

言归正传 ，本期我们手把手看下一个Cocos全局插件是怎么跑起来的，估计90%的小伙伴都不知道~。

全局插件放在哪里？

这里非常重要。

如果是项目插件，一般放在当前项目的：

text 复制代码

项目目录/extensions

但如果是全局插件 ，就不能只放在某个项目里，而是要放到Cocos Creator的全局扩展目录。

以当前实战为例，它所在的位置是：

这是 Cocos Creator的全局扩展目录之一。

放在这里的插件 ，不绑定某一个游戏项目，而是跟着当前Cocos Creator编辑器环境走。

也就是说 ，只要这个全局插件启用了，你打开任意Cocos项目，都可以在编辑器里看到它。

如何让全局插件生效？

放对目录后 ，插件没问题的话，自动就会生效。

如果插件加载成功，就可以在顶部菜单的扩展菜单里看到对应入口（本实战工程）。

甚至可以在扩展管理器的内置扩展找到我们的自定义全局插件：

如果修改了TypeScript代码，还需要重新编译：

bash 复制代码

npm run build

最后回到Cocos Creator里重新加载插件，我们可以在Load中加入输出，如果启动项目有输出，说明插件加载成功：

很多小伙伴插件没生效，不是代码写错了，而是放错目录，或者改完忘记重新编译。

实战工程结构

实战工程 是一个Cocos Creator 3.8.7的全局扩展示例，主要结构如下：

text 复制代码

globalext
├─ package.json
├─ tsconfig.json
├─ src
│  └─ main.ts
├─ panels
│  └─ default
│     └─ index.ts
└─ dist

这几个文件分别负责不同事情：

package.json：声明插件信息、菜单、面板和消息。
src/main.ts：插件主入口，真正执行功能逻辑。
panels/default/index.ts：编辑器面板代码。
dist：TypeScript编译后的运行代码。

第一步：声明这是一个插件

首先看 package.json。

实战工程里有几个关键配置：

这里重点看两个字段：

name：插件名，这里叫 globalext。
main：插件入口，指向编译后的 ./dist/src/main.js。

因为这是TypeScript工程，所以我们平时写的是src/main.ts，真正被Cocos Creator 加载的是编译后的JS文件。

执行构建命令：

bash 复制代码

npm install
npm run build

编译完成后 ，dist 目录里就会生成编辑器实际加载的代码。

第二步：给全局插件加菜单

插件通常用起来，最直接的方式就是加菜单。

实战工程 在 package.json 里通过 contributions.menu 注册了多个菜单项：

这段配置的意思是：

在 Cocos Creator顶部菜单的扩展菜单下，放一个 Happy Tools 分组。
菜单显示文字是"打开面板"。
点击菜单后 ，发送一条 open-panel 消息。

注意，菜单本身不负责执行逻辑，只发送消息，小伙伴们，这是什么模式？

第三步：把菜单消息绑定到方法

同样在 package.json 中，可以看到消息映射：

这里的意思是：

收到 open-panel 消息，就调用 openPanel 方法。
收到 open-assets 消息，就调用 openAssets 方法。
收到 print-project-path 消息，就调用 printProjectPath 方法。

这就是 Cocos 插件里非常核心的一条链路：

菜单点击 -> 发送 message -> 调用 main.ts 里的 methods 方法

理解这条链路后，大部分编辑器插件功能都能写出来。

第四步：编写插件主入口

接下来看 src/main.ts。

当前工程 里导出了一个 methods 对象：

就是具体的方法实现，举例几个方法：

openPanel：打开插件面板。
openAssets：打开当前项目的 assets 目录。
printProjectPath：打印当前Cocos项目的路径。

第五步：做一个自定义面板

只有菜单还不够直观，所以实战工程还做了一个自定义面板。

面板声明在 package.json 里：

这里说明插件有一个默认面板：

标题是 Happy Tools。
类型是 dockable，可以停靠在编辑器里。
入口是 ./dist/panels/default。

然后在 panels/default/index.ts 里定义界面：

第六步：面板按钮调用主入口

和菜单一样，面板本身也不直接处理复杂逻辑。

它通过 Editor.Message.request 去调用主入口里的方法：

这里的 globalext 就是插件名。

完整调用链路是：

点击面板按钮
Editor.Message.request("globalext", "open-assets")
package.json 找到 open-assets
调用 main.ts 里的 openAssets
打开当前项目 assets 目录

到这里，一个完整的全局插件功能就跑通了。

第七步：常用功能

其实我们用全局插件的目的，就是为了把经常用到的功能更加容易使用。

例如：

一键启动 Cocos MCP Server(前提是要先安装Cocos Mcp)。
用 Codex打开当前项目。
构建完成后上传到服务器。
自动生成线上预览地址等等。

全局插件 + 外部命令 ，其实就能把很多零散工具都收进Cocos编辑器。

更进一步

基于这个工程，后续可以继续扩展很多功能。

比如：

扫描所有Prefab ，检查Label字体是否正确。
扫描assets目录，统计图片、音频、字体大小。
打包前检查主包资源是否超标。
一键打开项目的配置表目录。
一键压缩资源。
一键精简字库。

这些功能如果写在单个项目里，只能服务一个项目。

但如果 写在全局插件里，就可以服务你所有的符合版本的Cocos项目。

这就是全局插件最大的价值：

把一次经验，变成长期工具。

结语

本文最主要的目的不是带大家回归古法编程，而是分享给大家经验。

毕竟在AI时代，经验可能比技术更重要。

小伙伴们觉得对吗？可在评论区分享你的看法~

本文实例工程 可通过私信发送"全局插件"获取。

我是"亿元程序员"，一位有着8年游戏行业经验的主程。在游戏开发中，希望能给到您帮助，也希望通过您能帮助到大家。

实不相瞒，想要个赞和爱心！请把该文章分享给你觉得有需要的其他小伙伴。谢谢！