Yii2 Advanced：能否将vendor中的mdmsoft(rbac)文件夹完整迁移至backend？

当然可行，但这绝对不是官方推荐的做法——毕竟Composer管理的包放在vendor目录里是有它的设计逻辑的。不过如果你有特殊需求（比如要深度定制这个RBAC扩展，不想依赖Composer更新覆盖你的修改），完全可以手动迁移，但得把这些关键事项都考虑清楚：

1. 命名空间与自动加载要适配 #

mdmsoft/rbac的默认命名空间是mdm\rbac，迁移到backend目录后，必须确保Yii的自动加载器能正确找到这些类：

• 快速方案：在backend/config/main.php的初始化代码里添加类映射：

  Yii::$classMap['mdm\rbac\*'] = '@backend/mdm/rbac/*.php';
  

• 规范方案：修改项目根目录的composer.json，在autoload的psr-4节点新增一行：

  "mdm\\rbac\\": "backend/mdm/rbac/"
  

  然后执行composer dump-autoload更新自动加载映射。

2. 修正所有路径别名与硬编码路径 #

原扩展会大量使用@mdm/rbac这类别名来引用视图、配置、资源文件，迁移后必须调整：

• 最简单的方式是在backend/config/main.php里重新定义别名：

  Yii::$aliases['@mdm/rbac'] = '@backend/mdm/rbac';
  

• 也可以逐个检查扩展代码里的硬编码路径（比如视图文件引用、配置文件路径），替换为新的相对路径或backend下的别名。

3. 确认依赖关系不受影响 #

检查mdmsoft/rbac是否依赖其他vendor中的包（比如它依赖Yii2核心组件，这个没问题，但如果有其他第三方依赖），迁移后要确保这些依赖仍在vendor目录中正常加载。迁移完成后，务必测试所有核心功能：角色分配、权限验证、规则执行、RBAC管理界面等，避免出现类找不到的错误。

4. 考虑后续维护成本 #

一旦迁移，你就无法再通过Composer更新这个扩展了——所有官方更新都需要手动合并到backend下的文件夹中，这会大大增加维护成本。如果只是需要定制扩展，更推荐的做法是：

• Fork原扩展到自己的代码仓库
• 修改composer.json指向你的fork版本
• 通过Composer安装，这样既可以保留定制能力，又能通过Composer管理更新。

5. 处理数据库迁移文件 #

如果之前已经执行过扩展自带的数据库迁移（位于migrations目录），迁移后不需要重新执行，但如果后续你修改了扩展内的迁移逻辑，建议将迁移文件移到backend的migrations目录下，并修改迁移类的命名空间，避免与原vendor中的迁移冲突。

6. 静态资源与视图文件适配 #

如果扩展包含CSS/JS等静态资源，原先是通过AssetBundle发布到web/assets的，迁移后要检查AssetBundle类中的sourcePath是否需要修改为新的路径。如果有自定义视图文件，也要确保视图引用的路径正确。

总的来说，迁移是完全可行的，但一定要做好充分的测试，并且想清楚后续的维护成本。如果不是必须深度定制，还是建议保留在vendor目录中，通过Composer管理更省心。

内容的提问来源于stack exchange，提问作者Sergio Sabido