composer.lock是依赖的权威快照，必须提交至git；删后执行composer install会报错，因install仅按lock精确还原，无lock则失去依据；应通过composer update升级或git恢复lock。
composer.lock 锁定旧版本不是“问题”，而是它本该做的事；真要改，得用 composer update，不是删文件或硬覆盖。
为什么删了 composer.lock 再 composer install 会失败
因为 composer install 的前提就是 composer.lock 存在且结构合法。删掉它再执行 install，Composer 直接报错：Lock file does not contain required package "xxx" 或直接拒绝运行——它没图可索，根本不知道装什么。
-
composer install是“按图还原”，只认composer.lock里写的精确版本、hash、dist URL -
composer update才是“重画地图”，根据composer.json重新解析依赖树并生成新 lock - 误删 lock 后想恢复？先
git checkout composer.lock，再composer install，别手写或复制别人 lock
想升级某个包到新版本，但 lock 死锁着旧版怎么办
不能绕过 lock 直接改 vendor，也不能手动编辑 lock 文件——它是完整依赖图的序列化快照，改一行就可能让整个安装失败。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 升级单个包：运行
composer update monolog/monolog --with-all-dependencies，避免子依赖卡在旧版 - 只更新 lock 文件结构（比如适配新 Composer 版本）：用
composer update --lock，不改动任何包版本 - CI 脚本里禁止无参数
composer update，必须明确指定包名或加--dry-run验证
老项目被 lock 锁在 PHP 7.4 兼容版，现在要升到 PHP 8.2 怎么办
不是 lock “锁错了”，而是它忠实地记录了旧环境下的解。升级 PHP 后，旧 lock 往往无法复现——因为新平台约束（如 "php": "^8.2"）和旧依赖不兼容。
- 先确认本地 PHP 版本：
php -v，再检查composer.json里的platform配置是否匹配 - 运行
composer why-not php:8.2，快速定位哪个包拦路（比如laravel/framework还卡在 v8） - 升级主框架后，再
composer update --with-all-dependencies让所有关联依赖同步协商 - 切忌加
--ignore-platform-reqs上线，这只是临时调试手段
同事的 vendor 和你的不一样，但都没动 composer.json
大概率是 composer.lock 没提交、被忽略、或 Git 冲突后手动乱合并了。lock 文件一旦不一致，composer install 就会退化成隐式 update，结果不可控。
- 不要手动合并 lock 文件，哪怕只改了一行
content-hash - 冲突时，先
git checkout --ours composer.lock（或--theirs），删掉vendor/，再composer install - 如果提示
Your lock file does not contain a compatible set of packages，说明composer.json已被他人修改，先git pull，再composer install
lock 文件不是障碍，是锚点。真正容易被忽略的是：它不校验运行时行为，只保证安装过程可重现；所以测试必须跑在 composer install 构建出的 vendor 上，而不是靠 composer update 临时凑出来的环境。
