composer.lock并非真正锁定版本，它仅记录当前安装状态；真正锁定需靠composer.json中的精确版本约束或replace/conflict机制。
composer.lock 文件不是锁，composer require 时没加 --no-update 就会动它
很多人以为只要生成了 composer.lock，包就“锁死”了——错。它只记录当前安装状态，下次运行 composer update 或没加约束的 composer require，照样会升级。
- 真正锁定版本，得靠
composer.json里的版本约束写死，比如"monolog/monolog": "2.9.1"（精确版本）或"^2.9.1"（看似宽松，但实际受 lock 文件影响） - 如果只想锁一个包，别碰整个项目，用
composer require vendor/package:1.2.3 --no-update，再手动删掉vendor/下对应目录，最后composer install - 执行
composer update vendor/package时，即使composer.json写死了版本，Composer 仍会尝试解析依赖图——若其他包要求更高版本，它可能报冲突而不是跳过
用 composer prohibit？不，那是假命令，真解法是 replace + conflict
没有 composer prohibit 这个命令，搜到的都是误导。想彻底阻止某个包升级或被其他包带入，得在 composer.json 里动手脚。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
"replace": { "vendor/package": "*" }：告诉 Composer “这个包我已自行提供”，它就不会再去装或更新原包（适合你 fork 了并打补丁） -
"conflict": { "vendor/package": ">=2.0.0" }：明确禁止某范围版本被安装，比写死 require 更强硬 - 注意顺序：
conflict不会阻止已安装的包，只影响后续install/update；而replace若没配好 autoload，会导致类找不到
composer update --lock 不更新代码，但可能悄悄改 composer.lock
这个命令常被误解为“安全锁版本”，其实它只是跳过下载和安装，但仍会重写 composer.lock —— 比如调整平台配置、PHP 版本变化、或依赖树解析结果不同都会触发变更。
- 想确保 lock 文件完全不变，就别跑任何
composer update类命令，连--lock都别碰 - CI/CD 中验证 lock 是否被意外修改？用
git status composer.lock+git diff --exit-code composer.lock - 某些插件（如
hirak/prestissimo）或新版 Composer（2.5+）会在--lock时校验 hash 并修正字段格式，导致 diff 出现无关变更
PHP 版本或平台配置变，composer install 也可能失败，哪怕版本没动
很多人锁了包版本，却在换服务器后 composer install 报错，原因不在包本身，而在 composer.json 的 platform 或 PHP 实际版本与 lock 文件记录不一致。
- 检查
composer.json里有没有"config": { "platform": { "php": "8.1.10" } }—— 如果写死了，而目标环境是 8.1.12，Composer 可能拒绝安装（尤其启用了platform-check） - lock 文件里记录的是“当时解析出的满足条件的版本”，不是“绝对不可变的二进制”；换平台后依赖解析路径可能不同，导致选中另一个小版本
- 最稳做法：CI 中用
composer install --no-interaction --no-progress --ignore-platform-reqs绕过检查，但要清楚代价——可能漏掉真实不兼容问题
require 没用，得查 composer show -t vendor/package 看谁在引用它。
