Composer 2 的 runtime 提供运行时环境支撑（如 InstalledVersions 查询、平台检查），composer-plugin-api 则定义插件开发接口与生命周期钩子，二者协同实现插件在合规环境中精准介入执行。
Composer 2 的 runtime 和 composer-plugin-api 是两个不同层级但紧密协作的机制：前者是运行时环境的基础支撑，后者是插件开发者与 Composer 交互的契约接口。
runtime 提供运行时能力支持
Composer 2 引入了更明确的 runtime 概念，主要体现为：
- Composer/InstalledVersions 类自动加载，可在 PHP 运行时直接查询已安装包名、版本、是否是 root 包等信息，无需解析 vendor/composer/installed.json
- 平台检查在
vendor/autoload.php初始化时自动触发，验证当前 PHP 版本、扩展是否满足依赖声明，失败即报错，避免运行时隐性崩溃 - 所有 runtime 功能默认启用，若你的库依赖这些能力（比如动态判断某包是否存在），需在
composer.json中声明"require": {"composer-runtime-api": "^2"}，强制要求用户使用 Composer 2
composer-plugin-api 是插件开发的标准契约
它是一组虚拟包（如 composer-plugin-api:2.0.0），定义插件可实现的接口和生命周期钩子，确保插件与 Composer 主程序兼容：
- 插件必须实现
Composer\Plugin\PluginInterface，并在activate()中注册事件监听器（如InstallerEvent、PostUpdateEvent） - Composer 2 扩展了插件 API，支持更细粒度的钩子（如
PreFileDownloadEvent）、并行操作上下文、以及对部分更新（composer update foo/bar:1.2.*）的完整支持 - 插件不再需要手动读取
composer.lock或扫描vendor/，而是通过Composer\Script\Event和Composer\Package\CompletePackage等 runtime 对象安全获取上下文数据
两者如何协同工作
一个典型场景是编写自动清理缓存的插件：
- 插件通过
composer-plugin-api声明兼容版本，并在activate()中监听PostInstallEvent - 事件触发后，插件调用
Composer/InstalledVersions::getVersion('my-org/my-cache-tool')判断工具是否就绪 - 再借助 runtime 提供的
Composer\IO\IOInterface和Composer\Util\Filesystem安全执行清理逻辑
基本上就这些。runtime 是你代码能“知道什么已装、当前环境是否合规”的基础；plugin-api 是你“能什么时候介入、怎么合法挂钩”的规则手册。不复杂但容易忽略。
