Composer的运行时（runtime）API有什么用？（composer-runtime-api）

composer-runtime-api 是声明 Composer 运行时版本依赖的标识符，非可调用 API；用于确保包在特定 Composer 版本下行为可靠，仅插件或深度集成场景需声明，其版本与 Composer 主版本一致。

Composer 的 composer-runtime-api 并不是一个供开发者直接调用的“运行时 API”，而是一个特殊的 PHP 扩展依赖标识符，用于声明包对 Composer 自身运行时能力的最低版本要求。

它本质是版本约束标记，不是函数或类接口

这个字符串出现在 composer.json 的 require 或 require-dev 字段中（例如 "composer-runtime-api": "^2.0"），作用是告诉 Composer：“本包依赖于 Composer 2.0+ 的某些内部行为（如自动加载机制、插件钩子、脚本执行流程等）”。它不提供任何可调用的方法，也不暴露 PHP 类或函数。

• Composer 在安装 / 更新时会检查自身版本是否满足该约束，不满足则报错退出
• 它不参与自动加载，也不会被 vendor/autoload.php 加载
• 它和 ext-xxx（如 ext-json）类似，属于“环境能力声明”，而非代码接口

主要用途：保障包在特定 Composer 版本下行为可靠

某些包（尤其是插件、脚本 工具、或深度集成 Composer 流程的库）需要依赖 Composer 某个版本引入的关键变更。比如：

• Composer 2.0 重构了自动加载器生成逻辑，旧版插件可能无法正确生成 autoload_files.php
• Composer 2.2+ 增强了脚本事件参数传递方式，依赖新参数的自定义脚本需声明 ^2.2
• 某些安全敏感操作（如 install --no-plugins 的行为差异）在不同大版本间有语义变化

普通项目通常不需要手动添加

绝大多数应用或库无需声明 composer-runtime-api：

• 只使用 require 引入依赖？完全不用管它
• 写了一个 Composer 插件（composer-plugin-api）？应优先声明插件 API 版本，而非 runtime
• 仅在 scripts 中调用 php 或 npm 命令？也不需要
• 只有当你主动读取 ComposerAutoloadClassLoader 内部状态，或 hook EventDispatcher 底层事件时，才可能需约束 runtime 版本

如何查看当前 Composer 的 runtime 版本号？

Composer 不单独发布 runtime 版本号，其版本与 Composer 主程序一致：

• 运行 composer --version，输出如 Composer version 2.7.7，即表示 runtime API 兼容 ^2.0 及其子版本
• 各主版本对应的最小 runtime 标识：1.x → ^1.0，2.x → ^2.0，3.x（未来）→ ^3.0