Composer本身不提供运行时配置注入能力，仅负责依赖下载、安装、自动加载与版本锁定；所谓“共享依赖配置注入”，实为在实例化第三方包（如Guzzle、Monolog）时，由开发者通过构造函数、工厂方法或DI容器显式传入配置参数。
共享依赖的配置注入本质是“传递参数给服务构造器”
Composer 本身不提供运行时配置注入能力——它只负责下载、安装、自动加载和版本锁定。所谓“在共享依赖里注入配置”，实际是指：你引入的第三方包（比如 monolog/monolog 或 guzzlehttp/guzzle）是否支持通过构造函数、工厂方法或配置文件接收你的自定义参数。Composer 只管把包拉下来，真正做配置的是你自己的代码或框架（如 Laravel、Symfony）。
常见方式：靠包自身设计的构造入口 + 你在代码中手动传参
绝大多数 Composer 包不会读取 composer.json 里的字段来初始化自己；它们只暴露类、接口和可配置的构造参数。你需要在实例化时显式传入配置。例如：
-
GuzzleHttp\Client支持构造时传['base_uri' => 'https://api.example.com', 'timeout' => 5] -
Monolog\Logger需要先 new 一个 handler（如StreamHandler），再 addHandler，路径、级别都得你自己指定 - 有些包提供静态工厂方法，比如
League\Flysystem\Local\LocalFilesystemAdapter::fromArray($config)
没有统一的“Composer 配置注入语法”。别试图往 composer.json 的 extra 字段里塞数据库密码——那只是元数据，没人自动读它。
想让配置集中管理？用框架或自己封装一层
纯 Composer 项目里，最直接的做法是写个配置数组，然后在创建对象时引用它：
$config = require 'config.php'; $client = new GuzzleHttp\Client($config['guzzle'] ?? []);
更规范的做法是借助 DI 容器（如 PHP-DI、Laravel Container）或框架生命周期，在服务注册阶段完成配置绑定。例如 Laravel 中你可以在 App\Providers\AppServiceProvider::register() 里 bind：
$this->app->bind(GuzzleHttp\Client::class, function ($app) {
return new GuzzleHttp\Client(config('services.guzzle'));
});
这时候配置才真正“注入”了，且可复用、可覆盖、可测试。
容易踩的坑：误以为 composer install 会读取 extra 字段自动初始化
有人会在 composer.json 里加：
"extra": {
"db_host": "localhost",
"log_level": "debug"
}
然后期待某个包自动读取这些值——这不会发生。除非该包明确声明支持并实现了对 extra 的解析（极少见，且需文档说明），否则这些字段只是供插件或脚本消费的元信息。UpdateHelper 插件能读 extra 是因为它监听了 Composer 事件并主动解析；普通库不会。
配置不是靠 Composer “注入”的，是你在代码里主动“送进去”的。漏掉这一步，或者指望自动发生，是旧项目集成失败最常见的原因。
