composer 通过吸收 npm、cargo、bundler 的成熟模式，在 php 约束下做取舍：composer.lock 必须提交以保障可重现构建；require-dev 影响依赖解析范围；conflict/replace 是应对 php 无模块系统的补丁；依赖解析含静态约束与运行时 autoload 两阶段。
Composer 没有直接“学习”其他包管理器，而是通过实际工程反馈，逐步吸收已被验证的模式——比如 npm 的语义化版本解析、Cargo 的锁定文件精度、Bundler 的依赖分组逻辑。它不是照搬，而是在 PHP 生态约束下做取舍。
为什么 composer.lock 必须提交到 Git
这借鉴了 npm 和 Cargo 的经验：锁定文件是可重现构建的唯一可靠依据。PHP 没有像 Rust 那样强制编译时校验，所以靠人工维护 composer.json 的 "version" 字段极易出错。
-
composer install读composer.lock，保证所有环境拉取完全一致的依赖树 -
composer update才会重算依赖并更新composer.lock，此时才可能引入不兼容变更 - 如果只提交
composer.json，CI 或新成员执行composer install会触发隐式update行为（取决于 Composer 版本和配置），结果不可控
require-dev 不只是“开发时用”，它影响依赖解析范围
这个设计明显参考了 npm 的 devDependencies 和 Bundler 的 group :development，但 PHP 的自动加载机制让它的影响更底层。
- 运行
composer install --no-dev时，Composer 不仅跳过安装require-dev下的包，还会在解析主依赖时**排除那些仅被 dev 包引用的版本约束** - 例如：A 包在
require-dev中依赖"monolog/monolog": "^2.0"，而你的主项目require的 B 包只兼容monolog:^1.0；若没加--no-dev，Composer 可能因 A 的约束强行升级 monolog，导致 B 崩溃 - 生产部署必须用
--no-dev，否则可能意外装入带phpunit或symfony/debug的完整依赖图，增大攻击面
conflict 和 replace 是应对 PHP 缺乏模块系统的关键补丁
Java 有模块版本隔离，Rust 有 crate scope，而 PHP 全局 autoloader + 单一 vendor 目录导致冲突无法绕过。Composer 的 conflict 和 replace 是向 Cargo 的 [replace] 和 npm 的 resolutions 学来的“止血方案”，但更粗暴。
-
"conflict": {"laravel/framework": "9.0.*"}不会阻止安装，只在composer update解析失败时抛出明确错误，提示你手动干预 -
"replace": {"symfony/polyfill-php80": "*"}告诉 Composer：“这个包已由我内置提供”，避免重复安装——常用于框架集成版或私有 SDK 封装 - 误用
replace会导致 autoloader 找不到类，因为 Composer 不检查你是否真提供了对应代码
真正难的是理解 Composer 的“依赖解析”发生在两个阶段：先是静态分析 composer.json 约束，再是运行时通过 autoload 规则注入类路径。其他语言的包管理器大多只管第一阶段，而 PHP 这个第二阶段一旦出错，报错信息往往指向类未找到，而不是依赖冲突本身。
