直接写死版本号即可锁定，如"monolog/monolog": "1.2.3"；composer.lock才是实际执行安装的契约，必须提交至Git并确保CI使用composer install而非update。

直接写死版本号就能锁定，不需要额外命令

Composer 默认安装时如果只写 ^1.2.3 或 ~1.2.0，它会按语义化规则自动升级小版本或补丁版本。要彻底锁死到某个具体版本（比如 1.2.3），最简单的方式就是把版本约束写成不含运算符的纯数字字符串。

• 在 composer.json 的 require 里写："monolog/monolog": "1.2.3" —— 这表示「只接受 1.2.3，不接受任何其他版本」
• 执行 composer install 或 composer update monolog/monolog 后，composer.lock 里就会固定记录该 SHA 和 ZIP URL
• 后续所有机器运行 composer install 都会严格还原这个版本，哪怕远程包已发布 1.2.4

用 composer require 时怎么指定精确版

命令行添加依赖时，如果不加任何符号，默认就是精确匹配；但很多人误加了 ^ 或 ~ 却没意识到。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 正确写法：composer require guzzlehttp/guzzle:7.5.0 → 锁定 7.5.0
• 错误写法：composer require guzzlehttp/guzzle:^7.5.0 → 实际允许 7.5.x 全系列
• 如果已经装了带范围的版本，先删掉 vendor/ 和 composer.lock 中对应项，再重装精确版更稳妥

为什么 composer.lock 比 composer.json 更关键

composer.json 是“意向”，composer.lock 才是“契约”。即使你写了精确版本号，若 lock 文件里存的是旧的哈希或不同版本，composer install 仍会按 lock 来装。

• 团队协作中，必须提交 composer.lock 到 Git —— 否则别人 install 时可能拉到不同版本
• CI 环境务必用 composer install（不是 update），否则会忽略 lock 文件重新解析依赖树
• 检查是否真锁死了：打开 composer.lock，搜索包名，看 "version" 字段是不是你想要的完整版本字符串，且 "source" 下的 "reference" 是确定的 commit hash

锁定后更新怎么办？别用 update 直接覆盖

想升到另一个固定版本（比如从 2.1.0 改成 2.1.5），不能只改 composer.json 再跑 composer update —— 它可能顺手把其他依赖也带升级了。

• 推荐做法：composer require vendor/package:2.1.5 --no-update 先改 JSON，再 composer update vendor/package 单独更新这一个
• 更安全的做法：删掉 vendor/vendor/package 和 composer.lock 中该包条目，然后 composer install
• 注意：某些包（如 Laravel）主版本升级可能破坏 autoload 或配置结构，光锁版本不够，还得同步检查文档兼容性

实际项目里，最常被忽略的是 lock 文件的提交和 CI 中 install/update 的混用。只要 lock 文件存在且未被绕过，版本就不可能漂移——但前提是它真被用了。