Composer 不自动锁定版本，真正锁定靠 composer.lock 文件与精确版本约束；若写 "2.9.1" 被解析为 ^2.9.1 就会升级，应改用无符号纯版本+提交 lock 文件+统一用 install。
Composer 不会自动锁定包版本，所谓“锁定”靠的是 composer.lock 文件 + 精确版本约束，不是靠某个命令“按住不让动”。
为什么 composer update 还是升级了我指定的包？
常见错误现象：composer update 后，明明 composer.json 里写的是 "monolog/monolog": "2.9.1"，结果装上了 2.9.2 —— 因为双引号里的 2.9.1 默认被解析为 ^2.9.1（即允许补丁和次要版本更新）。
- 使用场景：你想确保 CI、测试环境、生产部署始终用完全一致的
monolog/monolog版本 - 根本原因：Composer 的版本约束默认启用“波浪号”或“插入符”语义，除非你显式禁用
- 解决办法：改用精确版本（
"2.9.1"）+ 确保composer.lock提交到代码库 + 所有环境都运行composer install而非composer update - 注意：
composer require monolog/monolog:2.9.1会自动加^，得手动编辑composer.json改成不带符号的纯数字
composer update --lock 和 composer install 的区别在哪？
很多人以为 --lock 是“锁定某包”，其实它只是跳过依赖解析、只重写 composer.lock —— 它不会阻止更新，反而可能让锁文件“过期同步”出问题。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer install：严格按composer.lock安装，不读composer.json的版本字段，这才是真正“固定”的操作 -
composer update --lock：重新生成composer.lock，但不更新 vendor；它会把composer.json里当前写的约束（比如^2.9）重新解析一遍，可能拉进新版本 - 性能影响：后者比
composer update快，但依然有网络请求和依赖图计算，不是“无害操作” - 兼容性风险：如果你本地
composer.json已改但没提交composer.lock，CI 上跑composer install就会失败（因为 lock 文件里没有那个版本）
想彻底禁止某个包更新，有哪些可靠手段？
没有“全局禁止更新某包”的开关，但有三个实际可用的组合策略：
- 在
composer.json中用精确版本：写"phpunit/phpunit": "9.6.15"（不带^或~），这是最直接的方式 - 配合
composer update --with-dependencies避免误触：更新主包时，只更新它的直接依赖，不碰phpunit这类顶层开发依赖 - 用
replace声明替代包（慎用）：在composer.json加"replace": {"some/package": "*"}，可阻止安装，但会破坏依赖图，仅适用于明确要移除的废弃包 - 别信
composer prohibit：这不是 Composer 内置命令，是某些第三方插件，维护成本高、兼容性差，不推荐
真正起作用的永远是 composer.lock + 精确版本字符串 + 全流程用 install。只要有人手动改了 composer.json 又忘了删 lock 文件再 commit，或者 CI 脚本里写了 update，版本就守不住——这点比语法细节更关键。
