3.7 升级了扩展管理器，采用了全新的 UI 并且支持一键安装和更新扩展插件，还支持记录和安装项目所依赖的扩展，让项目的分发更加方便。
为了实现更好的版本管理，提高扩展稳定性，新版扩展管理器也调整了一些管理机制：
1. 3.7 开始编辑器将不再读取全局目录下的扩展，老项目升级到 3.7 时将会自动复制全局插件到项目中。此功能通过配套的 Dashboard 1.2.4 实现，请先确保本地 Dashboard 已自动更新至 1.2.4 版本。
2. 从扩展管理器中安装的扩展将记录依赖关系，通过 Dashbord 1.2.4 以上版本打开项目时会自动检查并安装依赖的扩展。此功能目前还不支持 Store 中的插件，我们将在之后的版本中继续完善。
3. 开发中的插件可以通过点开扩展管理器上方的导入按钮小箭头，选择开发者导入（Developer Import），此功能将为外部插件创建软链接到项目中，避免了插件同步问题。
4. Store 中的插件如需共用，在 3.7.0 仍与之前一致，需要在各台电脑上分别手动安装，或者将插件内容上传到 Git 版本库。
其中最重要的就是第一点，不再支持全局插件。这个决策确实很难让人理解，本帖尝试进行一次集中说明。这不是为了争辩或者打压社区，而是希望能够让信息流动更加高效、更加公开透明。如果有新的反馈建议仍然欢迎在本帖继续交流，我们仍然愿意做出改变。
起因
此决策始于 21 年底，新版扩展管理器筹备阶段。由于新版扩展管理器牵涉到原有插件系统、Dashboard、Store 等众多模块，要解决各种兼容性、体验性问题，因此遇到了很多困难。经过大量调研和讨论，我们决定废弃全局插件功能。
与全局插件相关的问题
- 多个插件位置导致的逻辑混乱
1.1 这样就会导致插件的配置可能存在多个地方，编辑器、全局、项目（本地配置）、项目（git 同步配置），这些配置会互相影响，可能 A 插件会有部分配置从 B 加载，部分配置从 C 加载，开发者和使用者都很可能会搞晕。
1.2 除了配置，插件本身也会相互覆盖，编辑器插件有 3 个层级，内置插件（实际上内置插件还分成两种来源）、全局插件、项目插件。一个插件在多个地方存在不同版本的话，使用者可能就无法意识到自己使用了错误的版本。
- 多个插件版本导致的配置混乱
2.1 若全局共存有相同插件的 N 个版本，这些版本之间的全局配置就会产生冲突。
例如 Creator 2.4.11 禁用编辑器自动刷新资源后，导致 2.4.10 的项目也禁用了…… 因为这个配置其实 2.4.10 本来就有，但是 2.4.11 才开放了这个设置界面。用户本意是只让 2.4.11 禁用的，没想到配置文件串了。这类型的错误还有很多衍生版本，这里不再展开。
- 选择困难
3.1 所有涉及到插件的操作，都要让用户指定是安装到全局或者项目。当全局并存多个版本时，还需要让用户选择要使用哪个版本的插件。这不仅仅是在插件安装环节出现，在项目版本升级时，也需要让用户重新选择全局插件要使用哪个插件版本，否则编辑器可能不兼容。
想象一下，当用户安装的插件多了以后，每次建项目，都得从一大摞插件里面挑出要加载的全局插件…… 这个挑选过程要把体验做得好又要费一番功夫，体验不好肯定会被吐槽建个项目都得纠结哪些插件要加载。如果某个插件本地安装的版本与特定编辑器不兼容，用户还得挑选完插件后记得切换版本才行……
- 项目分发困难
4.1 很多插件是开发者自研的，并没有注册到扩展管理器中。这时分发项目给其它人的时候很容易漏发全局插件，导致对方无法运行。我们在跟开发者或者内部团队要 demo 的时候，经常就因为少了插件导致编译失败，增加了问题排查和沟通的成本。
4.2 即便目标设备上有指定插件，由于版本很可能不匹配，也可能会出现奇怪的问题。增加了排查成本。
4.1 和 4.2 可以通过在扩展管理器锁死插件版本来解决，不过这样又会导致问题 3.1，只要已安装的插件版本不匹配，开发者就又需要强制切换版本，切换后重新锁死版本，再分发给别人又会引起别人的版本不匹配。
- 插件版本碎片化严重
扩展管理器支持热更后，插件的升级会比现在方便很多，如果用户逐版本升级，就会在全局留下很多老版本，这些老版本无法被清理。因为扩展管理器在升级时无法判断老版本是否还会被其他项目暗中使用，让用户自己清理的话同样会出现误删除的风险。
想象一下，当开发者看到全局目录下一溜的老版本，是不是又会吐槽 Creator 竟然不会自动清理？用户自己又怎么知道哪些版本能删？
总结
以上只是我尝试总结的一部分原因。由于相关的调研比较杂乱（最近几年我们至少建立了 10 个扩展相关的 GitHub Issue 和 Discussion 来讨论和调研，文字量不亚于 10 篇这样的帖子），我这里的总结可能还并不全面。
Creator 的扩展机制遇到了很多挑战，各种 Store 的插件、项目、Dashboard 的配合、多项目多编辑器多插件这三者如何组织和共存、已安装的插件何配置如何处理…… 还有我们之后规划的一些新的更新机制，都在干扰我们的实现。全局插件只是其中混乱的一个源头。
上面这些问题每一点单独拎出来当然都是可以通过产品或者技术层面去解决的，只不过我们觉得选择比努力更重要。秉持着 KISS 原则，我们宁愿把扩展机制先做得笨一些，也要让他能够尽可能的简单和可靠，特别是对新手而言。稳定和可靠对 Creator 来说是最重要的，其次才是性能和易用。因此只要全局插件会在 5% 的使用场景中带来潜在的可用性问题，特别是只要全局插件容易对新手造成困扰，我们就有必要从机制上彻底解决。
我们也会在这个机制上继续优化，优化一些体验问题，例如新版的扩展管理器支持开发者导入一个本地插件。不排除后续我们也会用类似的机制来解决一些便捷性问题，我们也欢迎诸君在本帖提出改进建议。
Q&A
Q：可以设置插件更新不再覆盖，以目录区分， PackageName/v1.1.1/ ，由用户在项目中选择开启哪个版本，如果旧版本确实不需要，交由用户是否卸载
Q：应该将插件安装到全局，然后在项目配置文件中配置是否开启。而且dashboard来管理插件的话，全局更方便管理
A：项目的创建是很高频的操作，偶尔一两次让用户在项目配置或者 Dashboard 里精挑细选其实还行，长久以往其实还挺繁琐的。会出现 3.1 的问题。持续优化这个选择过程的话，最终就会变成创建项目时默认什么插件都不安装，有需要的话再选择安装。那其实已经跟现有的扩展机制非常像了，只不过现在是通过“导入”或者“自动下载安装”。唯一的区别可能是“找插件”可能没那么方便，这个我们后面会持续优化，比如推出收藏夹之类的功能。实际上只要涉及到“让用户选择”，那是否安装在全局已经不重要了。从体验的角度来看浪费的那点硬盘空间不值一提，实在不行还可以用软链接绕过。
Q：如果用户的插件过多，是否采用项目独有，应该交由用户来选择
A：无法解决上述 5 个问题，还多出了新的 实现成本、理解成本、排查问题的成本…… 我们不希望把 Creator 做得过于复杂，到最后我们自己都 hold 不住，稍微改点东西都可能因为考虑不周引发新的 bug。
Q：我想不出全局插件，还有其它所谓的项目独有就没问题，全局就无法保证正确运行的问题
A：上面这些问题每一点单独拎出来当然都是可以通过产品或者技术层面去解决的，只不过我们觉得选择比努力更重要。一个根源上容易出错的机制，打再多补丁也是徒劳。
Q：我们N个项目都要拷贝1份要疯了。
A：3.7 正式发布时会配套升级 Dashboard 到 1.2.4，1.2.4 加入了老项目升级到 3.7 时自动复制全局插件到项目中的功能。抱歉公测期间 Dashboard 暂时还没来得及升级，所以导致开发者要手动拷贝。
Q：自动拷贝到本地没用啊。我们几十个项目，不能指望着他们后续会主动同步这个。用全局插件开发时我们做自动更新。
A：使用“开发者导入”，选择插件在本机的共享目录。此功能会帮助开发者在项目里创建一个软连接，这样插件就能从本机任意目录自动同步了。
Q：你说的这些困扰基本无关痛痒，论坛里基本也没有什么反馈；反馈的一些核心问题没怎么动，改这些帧没必要，而且改的还不好
A：Creator 今天的用户量十分庞大，产品需要能尽可能 100% 解决问题。哪怕只会造成 1% 的用户或者 1% 新手困扰，都必须从产品或者技术层面解决。我们是没有人力去逐个进行技术支持或者解释要如何用对产品的。
Q：像我这有十多个插件的，每个项目都导入一边，就会有几十乘以十几份。这考虑的太少了啊。这处理的太过分了！！！！
A：我们后续会优化插件批量导入功能。开发者本地的插件现在也已经支持单独加载，不需要放到项目内。
Q：我在商店出售的商品，如果用到本人自己的插件了的，价格决定不会低。如果用到了他人的插件，我不会在商店出售。
A：要分享项目时剔除私有插件，目前最推荐的办法是使用 git archive -o xxx.zip <分支名> 命令，此命令会把当前项目打包为 zip，并且剔除掉 .gitignore 文件中的资源，这样就不会包含 library、temp、local 等本地目录，只需要在 .gitignore 里面排除不希望共享的插件路径即可。后续我们会考虑在 Dashboard、扩展管理器中集成类似的管理功能。
Q：上传 git 时，ignore 掉另外人或另一台设备拉取就没有各个使用的插件，不 ignore 掉，仓库会多一堆，且大家都能处理这个插件，一个人没弄好，插件这块难维护了。
A：项目组要用同一个插件时，如果是私有插件就别 ignore，这样也能避免版本不匹配带来的问题；如果是公开插件，3.7.0 加入了注册机制，将来会扩大到 Store 的所有插件，到时候别人就会自动安装，不需要放到 git。