Composer锁定版本的本质是依靠composer.lock文件并提交至版本控制，而非在composer.json中硬写死版本号；硬写"1.2.3"会绕过语义化版本机制，导致协作不一致，真正可靠的方式是提交lock文件并始终用composer install。
Composer 锁定版本号，本质不是“写法问题”，而是理解 composer.json 中 version 字段和 composer.lock 文件的分工——直接写死版本号（如 "monolog/monolog": "2.9.1"）能锁，但多数情况下不该这么干。
为什么 "package": "1.2.3" 不等于“真正锁定”
这种写法确实会让 Composer 安装指定版本，但它绕过了语义化版本约束机制，且在团队协作中极易引发不一致：
- 如果别人运行
composer update monolog/monolog，它会无视你写的"1.2.3"，转而按^1.2或~1.2.0解析（取决于你是否启用了prefer-stable和平台配置） -
composer install时，Composer 优先信任composer.lock，而不是composer.json里的字符串；如果你没提交 lock 文件，别人拉下来就是全新解析 - 硬写
"1.2.3"会导致后续无法用composer update --with-dependencies安全升级子依赖
真正可靠的锁定：靠 composer.lock + 提交它
Composer 的设计哲学是：版本范围定义在 composer.json，精确版本记录在 composer.lock。所谓“锁定”，是指让所有环境都使用同一个 lock 文件。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 首次安装后，立刻
git add composer.lock并提交——这是最常被跳过的一步 - CI/CD 流程中必须用
composer install（不是update），否则 lock 文件失效 - 想升级某个包？运行
composer update vendor/package，它会更新该包及其兼容子依赖，并重写composer.lock - 检查是否生效：删掉
vendor和composer.lock，再跑composer install，看是否装回同一套哈希和版本
需要强制固定某包（比如等补丁）？用 require + minimum-stability 组合
某些场景下（如临时规避 bug），你确实需要阻止 Composer 升级某个包，哪怕有新 patch 版本。这时不能只靠字符串写死，得配合稳定性控制：
- 在
composer.json中写："monolog/monolog": "2.9.1 as 2.9.0"—— 这种as语法可欺骗依赖解析器，但仅限特殊情况 - 更稳妥的做法是设
"minimum-stability": "stable"，并确保该包没有发布stable新版；若它发布了2.9.2，你仍需手动update并重新 commit lock - 避免用
"dev-master"或"@dev"，它们天然不可锁定；改用"dev-main#abc123"（带 commit hash）才具备确定性
常见错误现象：composer install 装出不同版本
这几乎全是 lock 文件没管好导致的，不是写法问题：
- Git 忽略了
composer.lock（检查 .gitignore 是否含该行） - 本地执行过
composer update但没提交新的composer.lock - CI 环境误用
composer update --no-interaction替代install - PHP 版本不一致，导致 Composer 自动降级兼容包（例如 PHP 8.2 下
symfony/console可能选6.4.*，而 PHP 8.0 下选5.4.*）
真正要盯住的只有两件事：lock 文件是否在版本控制里、是否每次变更都重新提交它。其余“写法技巧”都是在绕开这个事实，反而增加维护成本。
