Composer Runtime API 并非官方接口，读取配置唯一可靠方式是解析根目录 composer.json；vendor/composer/installed.json 仅适合查询已安装包信息，不可替代项目自身配置读取。
Composer Runtime API 不是官方定义的接口或 SDK，它只是开发者对 composer.json 和运行时环境（如 vendor/autoload.php 加载后可用的类与常量）的一种泛称。你无法通过某个叫 ComposerRuntimeAPI 的类去调用它——真正能读取 Composer 配置的方式，只有一种：解析 composer.json 文件本身。
为什么不能用 Composer 类直接读取配置？
Composer 是一个命令行工具，它的核心类（如 Composer\Composer 或 Composer\Package\Package）在项目运行时默认不可用。这些类只在 composer install 或 composer update 执行期间由 Composer 进程加载，不会自动暴露给你的应用代码。
- 试图
new \Composer\Composer()会抛出Class not found -
composer dump-autoload --classmap-authoritative不会把 Composer 自身类加进自动加载 - 即使手动 require
vendor/composer/autoload_classmap.php，也解决不了依赖缺失问题
如何安全读取 composer.json 中的字段？
最可靠的方式是直接读取项目根目录下的 composer.json，并用 json_decode() 解析。但要注意路径定位和错误处理：
- 不要硬编码
./composer.json—— 项目可能从子目录运行 - 优先用
getcwd()向上遍历，直到找到composer.json或到达磁盘根目录 - 必须检查
file_exists()和json_last_error()，否则生产环境可能静默失败 - 如果只需要 version 或 name，建议缓存解析结果，避免重复 IO
function readComposerConfig($key = null) {
$dir = getcwd();
while ($dir && !file_exists($dir . '/composer.json')) {
$newDir = dirname($dir);
if ($newDir === $dir) break;
$dir = $newDir;
}
if (!$dir || !file_exists($dir . '/composer.json')) {
return null;
}
$json = file_get_contents($dir . '/composer.json');
$data = json_decode($json, true);
if (json_last_error() !== JSON_ERROR_NONE) {
return null;
}
return $key ? ($data[$key] ?? null) : $data;
}
// 用法
$version = readComposerConfig('version'); // "1.2.3"
$name = readComposerConfig('name'); // "myorg/myapp"
vendor/composer/installed.json 是什么？能用来做什么？
这是 Composer 安装后生成的元数据文件，位于 vendor/composer/installed.json，记录了当前已安装的所有包及其版本、autoload 映射等信息。它比 composer.json 更“运行时”，但不包含你的 root package 的完整配置（比如 scripts 或 config 字段）。
- 适合查询“当前实际装了哪些包”“某个依赖的精确版本号”
- 路径固定（只要 vendor 目录没被重命名），比找
composer.json更稳定 - 注意：该文件格式可能随 Composer 版本变化（v1 vs v2），
composer-plugin-api版本字段可作兼容判断 - 别用它替代
composer.json读取项目自身配置，比如extra.my-setting
真正麻烦的不是怎么读，而是读完之后要不要做逻辑分支——比如根据 extra.env 字段切换日志级别。这种耦合会让部署变脆弱，建议只读取声明性字段（name、version、description），其他行为控制交给环境变量或配置文件。
