如何在Composer中实现模块化的依赖管理
搞模块化依赖管理，有个常见的“坑”得先避开：千万别指望在composer.json的require字段里动态写入租户包名——比如“vendor/{$tenant}/module-a”这种写法，Composer会直接报Invalid package name错误，根本行不通。正确的思路，得拆成「静态主干 + 运行时加载」两层机制。
为什么 composer.json 里不能写变量或租户占位符？
原因很简单：Composer在解析composer.json时，处于纯文本处理阶段，它不执行任何PHP代码。所以，像“vendor/{$tenant}/module-a”: “^1.0”这种带变量的包名，连最基本的语法校验都过不了，更别提后续的下载和安装了。实际开发中，经常遇到这样的场景：开发者在本地手动改了composer.json并提交，结果上线后，CI/CD流水线一跑composer install就直接失败，错误信息里明确写着“包名非法”。
这里有个基本原则：只有所有租户都共用的基础能力（比如lara vel/framework、spatie/multitenancy），才应该放进根目录的composer.json里。至于各个租户私有的模块，必须脱离require字段来管理。
如何让租户模块类被自动加载到？
核心思路是绕过require，利用Composer自带的ClassLoader::addPsr4()方法，在运行时动态注册命名空间映射。具体操作，可以按下面几步来：
- 首先，确保你的模块目录结构符合PSR-4规范。举个例子，文件路径是
modules/tenant-a/src/FeatureX/Handler.php，那么它对应的命名空间就应该是AppTenantModulesAFeatureX。 - 接着，在初始化租户上下文的地方（比如Lara vel的中间件或服务提供者里），调用注册方法：
$loader->addPsr4('AppTenantModulesA\', base_path('modules/tenant-a/src/')) - 这里有个细节必须注意：注册前最好先检查一下，避免重复注册污染autoload缓存。可以用
in_array('AppTenantModulesA\', $loader->getPrefixesPsr4())来判断。 - 最后，注册时机也很关键。建议放在
app()->booted()回调里控制，这样能确保只执行一次，而不是每个HTTP请求都去调用，避免不必要的性能开销。
为什么 dump-autoload 不扫描我新加的模块路径？
这个问题困扰过不少人。其实原因在于，composer dump-autoload命令只处理composer.json里autoload和autoload-dev字段声明的路径。对于你通过运行时addPsr4()动态注册的路径，它完全感知不到。
这意味着什么呢？很可能出现这种情况：你模块文件放好了，addPsr4()也调用了，但请求进来还是抛出Class not found异常。这时候别急着怀疑代码，大概率是因为PHP-FPM的worker进程没有重启，旧的ClassLoader实例还“活着”，它根本不知道有新路径被注册进来。
所以，这不仅仅是“缓存没清”那么简单，而是ClassLoader生命周期的问题——PHP进程本身不重载，你新注册的路径就不会生效。
要不要用 nwidart/lara vel-modules 这类包？
这是个好问题。nwidart/lara vel-modules这类包，更适合用来“统一管理项目内部的多个功能模块”。比如，把一个后台CMS拆分成user-module、order-module等，每个模块可以独立启用或禁用，并且包含自己的数据迁移和路由。但是，它默认的处理方式，依然是把模块当作“项目内的子目录”，所有模块代码最终都会进入主项目的vendor自动加载链。这对于要求代码隔离的多租户场景来说，就不太合适了。
那么，分界线在哪里？关键在于：你的模块是否需要跨环境、跨租户进行独立的版本控制和发布？如果需要，比如每个租户的模块版本可能不同，甚至需要通过私有Packagist仓库来分发，那就别把它硬塞进项目的Modules/目录下，再用merge-plugin去合并autoload。那样做只是把多个composer.json在逻辑上合成一个，本质上还是静态依赖管理，解决不了租户级别的动态加载需求。
总结一下：如果你的模块需要按租户隔离、独立发布，那就坚持“私有仓库 + 运行时addPsr4()”这条路；如果只是项目内功能拆分，用lara vel-modules会更省事。搞清楚这个核心区别，技术选型就不会迷路了。
