必须在composer.json中写死无符号三位版本号如"monolog/monolog": "2.9.0"，并提交composer.lock到Git、部署时运行composer install——三者缺一不可。
直接改 composer.json 里的版本号再跑 composer update，不是“强制同步”，而是触发一次受控的依赖重解析——真正能锁死版本、规避冲突的，只有精确版本声明 + composer.lock 提交这一条路。
怎么让 Composer 死死装某个具体版本（比如 monolog/monolog 2.9.0）
必须在 composer.json 的 require 里写死不带符号的版本号：
-
"monolog/monolog": "2.9.0"—— 这才是锁定，Composer 不会升到 2.9.1 或 2.10.0 - 别写
"^2.9.0"或"~2.9.0"，它们都允许小版本浮动，一跑composer update就可能漂移 - 写完立刻执行
composer update monolog/monolog --with-dependencies，否则旧composer.lock仍记录着老版本 - 改完后
git diff composer.lock确认只变了预期包及其直系依赖，没牵连phpunit或symfony/console等无关项
composer require 报 “Conclusion: don’t install xxx v2.1.0” 怎么办
这不是包有问题，是当前依赖图里某处卡死了版本下限。关键动作不是硬上，而是查阻塞链：
- 先跑
composer why-not vendor/package:v2.1.0（例如composer why-not guzzlehttp/guzzle:^7.5），它会输出谁在阻止安装，比如laravel/framework v10.32.0 requires guzzlehttp/guzzle ^7.2但你本地锁的是^6.5 - 检查
composer.json里是否手动写死了冲突包的旧版本（如"guzzlehttp/guzzle": "6.5.8"），删掉或改成兼容范围 - 别直接删
composer.lock—— 这会让所有包重新计算，可能把线上稳了半年的ramsey/uuid从 4.7.5 升到 5.0.0，引发 BC break - 如果只是验证可行性，加
--dry-run：composer require vendor/package:v2.1.0 --dry-run
想升级一个包却提示 “Package xxx is not required in your composer.json”
说明这个包没被显式声明在 require 或 require-dev 里，而是作为子依赖被拉进来的。此时 composer update vendor/package 会直接报错：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先确认它是不是真需要单独升级：运行
composer show vendor/package，看versions行是否包含你要的版本，installed行是否落后 - 如果是间接依赖，有两种选择：① 找出哪个主包依赖它（用
composer depends vendor/package），然后升级那个主包；② 在composer.json里显式加上该包（如"vendor/package": "^3.0"），再跑composer update vendor/package - 加了之后务必补
--with-dependencies，否则 Composer 可能拒绝执行，报 “无法满足要求” - 升级后立刻检查
composer.lock是否只动了目标包和它的必要依赖，避免意外带偏整个生态
为什么改了 PHP 版本后 composer install 失败，但 composer update 却能过
因为 composer.lock 顶部的 platform 字段锁定了 PHP 版本声明（如 "php": ">=8.1.0"），而 composer install 会严格校验本地 PHP 是否匹配；composer update 则默认跳过这个检查，强行重算依赖树：
- 运行
composer show --platform查当前环境声明，对比composer.lock里的platform块 - 若本地 PHP 是 8.3，但 lock 里写的是
"php": ">=8.1.0 ，就得先改 <code>composer.json的config.platform.php，再跑composer update --lock - CI 环境尤其要注意：不能靠
--ignore-platform-reqs硬扛，那会让生产环境装上不兼容的包，等上线才崩 - 最稳妥的做法是：PHP 升级后，所有人先同步改
composer.json的 platform 配置，再统一composer update --lock，提交新composer.lock
真正容易被忽略的是：所有“强制”操作（删 lock、加 --ignore-platform-reqs、手动改 lock 文件）都在绕开 Composer 的一致性保障机制。一旦这么干，就等于放弃 composer.lock 存在的意义——它不再是一份可验证的依赖快照，而是一份随时可能失效的手工记录。
