Composer不支持直接定义新type，因type路由由硬编码的InstallationManager控制，仅识别内置或插件显式注册的类型；实现需编写composer-plugin，实现PluginInterface并在activate()中向InstallationManager注册支持该type的InstallerInterface实例。
Composer 不支持直接定义新的 composer-installable 类型（比如 my-custom-type），也没有“安装器类型扩展方法”这个官方概念。所谓“自定义安装器”，实际是通过实现 Composer\Installer\InstallerInterface 并注册为 installer 插件来接管某类 type 的安装逻辑。
为什么不能直接在 composer.json 里声明新 type 的安装行为
Composer 的 type 映射由硬编码的 Composer\Installer\InstallationManager 控制，type 字段仅用于路由到内置安装器（如 library→LibraryInstaller、wordpress-plugin→WordPressPluginInstaller）。它不会动态解析你写的任意字符串并加载对应逻辑。
-
type值必须是 Composer 已知的类型，或已被第三方插件显式注册支持的类型 - 未注册的
type会被当作library处理（即解压到vendor/下，不执行特殊逻辑） - 试图在
composer.json中写"type": "my-custom-type"而不配套插件，等于没写
如何真正实现一个自定义 type 的安装逻辑
核心是编写一个 Composer 插件，实现 Composer\Plugin\PluginInterface，并在 activate() 中向 InstallationManager 注册一个自定义安装器实例，该实例能处理指定 type。
- 插件需声明
type: "composer-plugin"，且extra.composer-plugin.class指向主类 - 安装器类必须实现
Composer\Installer\InstallerInterface，重点实现supports()（返回是否处理该type）和install()/update() - 注册时调用
$installationManager->addInstaller($installer)，顺序影响优先级 - 项目中需在
require-dev或require中引入该插件包，否则不会加载
use Composer\Composer;
use Composer\IO\IOInterface;
use Composer\Plugin\PluginInterface;
use Composer\Installer\InstallationManager;
use MyVendor\MyCustomInstaller;
class MyCustomPlugin implements PluginInterface
{
public function activate(Composer $composer, IOInterface $io)
{
$installationManager = $composer->getInstallationManager();
$installationManager->addInstaller(new MyCustomInstaller($io, $composer));
}
}
常见踩坑点：type 名字、autoload 和插件加载时机
很多失败不是因为逻辑错，而是环境没对上：
-
type值区分大小写，且不能含空格或特殊字符；推荐全小写+短横线，如my-custom-bundle - 插件包自身的
autoload必须正确（通常用"psr-4"），否则class not found错误会静默吞掉激活过程 - 插件必须被
composer install安装进vendor/后才能生效；如果插件本身依赖其他插件，注意加载顺序 - 运行
composer show --plugins可确认插件是否已激活；若没列出，说明未被载入（检查 require、autoload、Composer 版本兼容性） - Composer 2.x 对插件签名和稳定性要求更严，
minimum-stability为stable时，插件版本也需打 stable tag
真正难的不是写几行 PHP，而是让 Composer 在正确的时间、以正确的顺序、加载正确的类——所有环节断一环，type 就只是个字符串。
