Composer 默认只锁定直接依赖，间接依赖由上游包决定，易导致版本漂移；用 conflict 字段可强制限制间接依赖版本，是当前最可靠方案。
为什么 composer update 总是升级间接依赖，而 require 里根本没写它？
因为 Composer 默认只锁住你直接声明的包版本（require 里的），其余依赖由上游包的 composer.json 中的 require 字段决定，且会随其更新策略浮动。你看到的 vendor/autoload.php 加载的其实是整个依赖树展开后的结果，不是你手动写的那几行。
常见错误现象：composer install 在 CI 或新机器上装出和本地不一致的子依赖，导致行为差异或 Class not found；某天突然报 Method not found，查发现是 monolog/monolog 从 2.x 升到了 3.x，而你依赖的 laravel/framework 还没适配。
- 间接依赖版本由最松的那个上游约束决定（比如 A 要
"psr/log": "^1.0"，B 要"psr/log": "^2.0"，最终可能装 2.x） - 仅靠
composer.lock不能跨项目保证一致性 —— 它只记录当前解析出的版本，一旦有人执行composer update xxx或删了 lock 文件重装，就可能变 -
composer require --no-update不解决这个问题，它只跳过安装，不干预后续解析逻辑
用 require-dev + conflict 硬控间接依赖版本
这不是“优雅方案”，但它是目前最可靠、无副作用、兼容所有 Composer 版本（包括 2.x 和 3.x）的强制锁定方式。原理很简单：让 Composer 在解析阶段就拒绝掉你不想要的版本，而不是等装完再 patch。
使用场景：你想确保 guzzlehttp/guzzle 无论被谁拉进来，都只能是 ^7.5，防止被 aws/aws-sdk-php 或 spatie/laravel-backup 带进 ^8.0。
实操建议：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 在
composer.json的根级加"conflict"字段："conflict": { "guzzlehttp/guzzle": ">=8.0.0" } - 如果要同时锁多个版本范围，写多行：
"conflict": { "phpunit/phpunit": ">=10.0", "symfony/console": ">=7.0" } - 不要用
require-dev“假装”需要它来锁版本 —— 那会引入不必要的 autoloading 和 dev-only 类，反而增加风险 -
conflict不影响已安装的包，只作用于下次composer update或install时的依赖解析
composer require --with-all-dependencies 的真实效果和陷阱
这个命令常被误认为“能锁死整棵树”，其实它只是让 Composer 在升级指定包时，把它的所有传递依赖也一并升级到最新兼容版本 —— 换句话说，它加剧版本漂移，而不是抑制它。
容易踩的坑：
- 执行
composer require foo/bar --with-all-dependencies后，monolog/monolog可能从 2.9.2 升到 3.5.0，哪怕你完全不需要它升级 - 它不会帮你识别冲突，也不会提示“这个升级会导致 X 包不兼容”，只会静默完成
- 在团队协作中，这个命令产生的
composer.lock差异极大，极难 Code Review，容易漏掉关键变更 - 如果你只想更新
foo/bar本身，应该用composer update foo/bar --with-dependencies（注意是update，不是require），且确认上游已声明好conflict
为什么不用 replace 或 provide 来覆盖间接依赖？
这两个字段设计初衷是“声明替代实现”（如用 symfony/polyfill-mbstring 替代原生 mbstring 扩展），不是用来做版本控制的。强行用它们会破坏依赖图完整性。
典型问题：
-
"replace": {"guzzlehttp/guzzle": "7.5.*"}会让 Composer 认为你“已经提供了 guzzle”，从而跳过安装 —— 但你的代码根本没实现它，运行时直接Class not found -
"provide"是软声明，Composer 不校验实现，也不阻止别人装同名包，完全无法达成“强制限定”目标 - 某些插件（如
hirak/prestissimo）或私有仓库配置下，replace还会触发不可预测的解析回退
真正需要稳定间接依赖的项目，conflict 是目前唯一既明确、又安全、还留有清晰错误提示（解析失败时会告诉你哪个包冲突）的方式。别省这三行 JSON，它比你花两小时 debug 一个奇怪的 ArgumentCountError 划算得多。
