利用Composer中文实现针对大型PHP项目的组件化热插拔架构-composer-PHP中文网

composer 不支持运行时热插拔，因其是构建时依赖管理器，autoload 映射静态固化且无类卸载机制；可行方案是基于插件目录+psr-4动态注册+容器生命周期管理+opcache适配。

利用composer中文实现针对大型php项目的组件化热插拔架构

Composer 本身不支持运行时热插拔，所谓“组件化热插拔”必须靠设计约束 + 自动加载机制 + 运行时模块开关来模拟，不是开箱即用的功能。

Composer 是构建时（build-time）依赖管理器，所有 autoload 规则在 vendor/autoload.php 中静态生成，一旦加载完成，类映射就固化了。没有 reload 机制，也没有运行时卸载类的能力。

试图在运行中删改 vendor/ 或修改 composer.json 后调用 composer dump-autoload，会导致已加载类与新映射冲突，引发 Class not found 或 Cannot declare class
require_once 手动加载新组件会绕过 Composer 自动加载，但无法解决命名空间冲突、依赖版本错配、服务容器注册缺失等问题
PHP 的 opcode 缓存（如 OPcache）还会缓存已加载的类定义，即使文件更新也不会自动刷新

核心是把“组件”从 vendor/ 移出，放在独立可读写的插件目录（如 plugins/），并用自定义自动加载器按需注册 —— 不依赖 Composer 的生成逻辑。

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

每个插件目录含自己的 composer.json，但只用于声明元信息（name、version、extra.plugin.enabled），不执行 composer install
主应用启动时扫描 plugins/*/composer.json，过滤出 "extra": {"plugin": {"enabled": true}} 的项
对启用的插件，用 ClassLoader::addPsr4() 动态注册其 src/ 目录，例如：$loader->addPsr4('PluginFoo\', 'plugins/foo/src/');
插件内不得直接 require vendor/autoload.php，所有依赖须由主应用统一提供（通过 composer.json 的 require 声明或 replace 协调）

插件启用/禁用时，不能只改自动加载，还需同步调整 DI 容器绑定 —— 否则 App::make(PluginService::class) 仍会返回旧实例或报错。

约定每个插件实现 PluginInterface，含 register(Container $app) 和 unregister(Container $app) 方法
启用插件时调用 $app->register(new FooPlugin())，内部完成服务绑定、事件监听器注册、中间件追加等
禁用前必须调用 unregister() 清理绑定、移除监听器、关闭连接池等资源；否则内存泄漏或行为残留
避免在 register() 中做耗时操作（如数据库迁移），应拆到单独命令（php artisan plugin:migrate foo）

动态加载的类在 OPcache 启用时不会自动失效，导致改了插件代码却看不到效果，这是最常被忽略的环节。

开发环境务必关闭 OPcache：opcache.enable=0，或使用 opcache_invalidate() 手动清理，但注意它只清文件级缓存，不重载类定义
更稳妥的做法是：插件启用/禁用后，强制重启 PHP-FPM 进程（sudo systemctl reload php*-fpm）或 CLI 脚本重新启动
若用 Swoole / RoadRunner 等常驻进程，必须在插件变更后 reload worker，且确保 ClassLoader 实例被重建（不能复用旧 loader）
别依赖 filemtime() 判断插件是否更新 —— 类文件可能被 OPcache 缓存，而 composer.json 时间戳已变，造成判断失准

真正的难点不在加载机制，而在插件间的依赖隔离和状态清理。一个插件的 unregister() 没写好，可能让整个应用后续请求卡在某个未释放的 PDO 连接或 EventDispatcher 闭包里。