Composer.json 字段并非全部可在运行时读取，PHP 代码需手动解析文件；autoload 和 config 等字段仅作用于 Composer 工具本身，不暴露给运行时，且 require/require-dev 在安装后无区分。
composer.json 字段不是全都能被运行时读取
这里有个常见的认知误区：很多人以为 Composer 安装完依赖后，会提供一个统一的运行时 API 来读取 composer.json 里的所有配置。比如幻想能调用类似 Composer::getConfig('require') 这样的方法。但现实是，这种接口根本不存在。
Composer 本身只在安装或更新时解析 composer.json。一旦进入 PHP 运行时，想获取这些配置，你就得自己动手加载和解析这个文件。另一个常见的错误思路是试图从 vendor/composer/installed.json 或 composer.lock 里反推原始配置。但这两个文件只保存了解析后的结果，比如包的确切版本，而像 config、scripts、autoload 这些原始字段结构，它们是不会保留的。
- 最可靠的方法：直接用
json_decode(file_get_contents('composer.json'), true)手动读取。不过，这里有个关键点——你得先准确定位到项目根目录。 - 路径陷阱：千万别硬编码
./composer.json。因为执行脚本的位置可能是任意的。稳妥的做法是从getcwd()返回的当前目录开始，逐级向上遍历，直到找到composer.json文件，或者到达磁盘根目录为止。 - 环境变量覆盖：如果项目通过
COMPOSER环境变量指定了配置文件名（例如COMPOSER=composer-dev.json），那么你必须读取这个指定的文件，而不是默认的composer.json。
autoload 和 config 字段最容易被误读
这两个字段的“职责范围”非常明确，但也因此最常被误解。
先说 autoload。里面定义的 PSR-4 映射（比如 "App\": "src/"）是给 Composer 自己生成自动加载器用的。PHP 运行时并不会自动加载这些命名空间——除非你已经执行过 composer dump-autoload，并且在代码入口处引入了 vendor/autoload.php。换句话说，这个配置是 Composer 工具的“内部指令”，不是 PHP 环境的“全局设置”。
再看 config 字段。它下面的所有值，无论是 "sort-packages": true 还是 "cache-dir": "./.cache"，都只影响 Composer 命令本身的行为。这些配置对 PHP 代码是完全不可见的，它们既不会写入环境变量，也不会变成你可以访问的常量。
- 想在代码里获取
sort-packages的值？不行。它仅仅控制composer.json文件格式化时的输出顺序。 "process-timeout": 3600是 Composer 执行命令时的超时设置，跟你代码里的exec()或shell_exec()函数毫无关系。- 如果应用需要感知某些配置，正确做法是手动将它们复制到
.env文件或独立的config/app.php中。别指望 Composer 会自动帮你桥接这些配置。
require 和 require-dev 在运行时不可区分
这可能是另一个反直觉的地方。require 和 require-dev 本质上是 Composer 在安装阶段的指令。一旦所有依赖被安装到 vendor/ 目录，PHP 运行时就不再关心某个类库最初来自哪个字段了——所有的自动加载规则都已经合并进了 vendor/autoload.php。
这意味着什么？举个例子，你把 monolog/monolog 放在 require-dev 里，只要它被 autoload 加载了，生产环境照样能用（前提是 vendor 里没删除它）。反过来，放在 require 里的包，在开发环境也随时可用。
- 真正的隔离开关：唯一能物理隔离开发依赖的命令是
composer install --no-dev。这个命令决定了是否将require-dev下的包安装进vendor/目录。 - 环境判断：想在运行时判断“当前是否是开发环境”，应该依赖
getenv('COMPOSER_DEV_MODE')或自定义的环境变量，而不是去读取composer.json。 - 版本校验：
composer.json里写的"require": {"php": ">=8.1"}只在安装时用于环境校验。PHP 运行时本身不会检查这个条件，也不会因此抛出错误。
repositories 和 plugins 配置无法被代码直接访问
这两个字段的生命周期更靠前，也更“短暂”。
repositories 字段，无论是定义自定义的 VCS 源，还是 path 类型的本地包，都只在依赖解析阶段起作用。解析完成后，这些信息就被丢弃了。plugins 字段同理——它们是 Composer 在生命周期早期读取的输入参数，并非运行时状态。
所以，即便你配置了 "repositories": [{"type": "path", "url": "../my-local-package"}]，在 PHP 代码里也拿不到这个路径信息，更无法据此动态引入本地包。
- 加载本地包的正确姿势：必须走标准的自动加载流程。确保那个本地包自身拥有合法的
composer.json，并且它的autoload配置已经通过composer dump-autoload被注册到主项目中。 - 避免硬编码路径：不要试图在代码里用
file_get_contents('../my-local-package/composer.json')。这种做法路径不可靠，可能受权限限制，也严重违反了封装原则。 - 运行时发现包信息：如果确实需要在运行时获取已安装包的信息，应该查询
vendor/composer/installed.php（PHP数组格式）或vendor/composer/installed.json（JSON格式）。这里面包含了包的名称、版本、安装路径等元数据，但请注意，原始repositories配置并不在其中。
说到底，Composer 的配置可以大致分为三类：安装期指令（如 require）、工具行为开关（如 config.sort-packages）和元数据声明（如 autoload）。它们各自的生命周期和作用域截然不同，因此没有一个统一的入口可以读取全部信息。如果硬要在一个地方获取所有配置，反而容易陷入路径、权限、缓存和环境变量覆盖等各种陷阱之中。理解它们各自的边界，才是高效、准确使用 Composer 的关键所在。
