composer依赖锁定需同时满足：composer.json写三位完整版本号（如"2.9.1"）、composer.lock提交至git、部署时运行composer install；缺一不可，否则仍会升级版本。
Composer 依赖锁定不是靠命令开关，而是靠 composer.json 写死版本 + composer.lock 提交 Git + 部署时用 composer install —— 三者缺一不可。
为什么 composer install 还是升了版本？
根本原因只有两个：锁文件缺失或被绕过。常见现象包括：
-
composer.lock没提交到 Git，或被.gitignore忽略 - 有人改了
composer.json但没运行composer update vendor/package同步锁文件，就直接 push - CI 脚本里写了
composer update（无参数），等于全量刷新，lock彻底失效 - 本地执行
composer require some/pkg，它依赖更高版的monolog/monolog，Composer 强制升级并重写lock
验证方式：composer show monolog/monolog 看当前装的是不是你想要的；再跑一次 composer update monolog/monolog，如果提示 Nothing to install or update，才算真正锁住。
composer.json 里怎么写才算真锁定？
必须用三位完整数字，不带任何符号：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- ✅ 正确：
"monolog/monolog": "2.9.1"、"symfony/console": "==5.4.38" - ❌ 错误：
"^2.9"、"~2.9"、"2.9.*"、甚至"2.9"（缺补丁号，解析行为在不同 Composer 版本中不一致）
注意：== 是显式等号约束，比纯字符串更防手误；而 ^0.2.3 在 0.x 阶段实际等价于 ~0.2.3，语义不稳定，慎用。
团队协作中怎么防止 composer.lock 失效？
composer.lock 不是缓存，是部署一致性契约。关键动作必须做：
- 检查
.gitignore是否意外包含composer.lock—— 它不该在那里 - 每次改完
composer.json，立刻运行composer update vendor/package（指定包）或composer update（全量），然后git add composer.lock - 上线前加保险：
composer install --locked，它会校验lock里每个版本是否仍满足composer.json的约束，不满足直接报错退出 - CI 流水线第一步加
ls -la composer.lock，确认拉取的是最新可信版本，而非缓存旧文件
最常被忽略的点：锁文件的 Git 状态比所有命令都重要。盯住它有没有被修改、有没有被跳过、有没有格式错误 —— 这些问题不会报“版本错”，只会报 Class not found 或 content-hash mismatch，排查成本远高于预防。
