composer update --lock 重新生成整个 composer.lock 文件，包括包版本、依赖树、URL 和哈希，前提是 vendor 满足 composer.json 约束；它不升级 vendor，但允许合法版本变更，非依赖字段修改应使用 --lock-only，哈希不匹配时可重算哈希。
composer update --lock 到底改什么？
它不只刷新哈希，而是重新生成整个 composer.lock 文件：包括所有包的版本号、依赖树、dist URL 和 dist.sha256。前提是当前 vendor/ 中已安装的包仍满足 composer.json 的约束。如果约束没变（比如 "monolog/monolog": "^2.0"），它可能保留 2.9.1；但如果 2.10.0 已发布且兼容，--lock 就可能把 lock 里写成 2.10.0 —— 它不是“不动版本”，而是“不动 vendor”，版本变更只要合法就允许。
什么时候它真能只刷哈希？
只有两种情况会真正只改哈希、不碰版本：
- 你只改了
composer.json的非依赖字段（如description、license、空格或换行），此时应改用composer update --lock-only（Composer 2.2+） - 你没改
composer.json，但源站重推了 dist 包（比如私有镜像同步延迟），导致本地vendor/文件和 lock 中的dist.sha256不一致 —— 此时composer update --lock会重算并写入新哈希，其他字段不变
注意：--lock 不校验 vendor 文件内容是否真匹配 lock 中的哈希，它只读 lock、重算、再写回 lock。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
常见误用和报错原因
composer update --lock 很容易静默失败或产出语义错误的 lock 文件：
- 加了非法 platform 配置（比如
"php": ">=8.1 "多了个空格），命令直接退出，不写 lock -
composer.json里 require 版本变了（如"phpunit/phpunit": "^10.0"→"^11.0"），--lock完全忽略，lock 还是旧版 —— 你以为同步了，其实没生效 - 本地
vendor/缺包、或多出未声明的包，它不会报错，也不会清理，只照常重写 lock - 跨环境执行前没核对
composer config platform，PHP 版本或扩展差异会导致哈希计算结果不同
替代方案怎么选？
想安全刷新 lock，优先按场景选命令：
- 只改了注释/空格/非依赖字段 → 用
composer update --lock-only（加--dry-run预检） - 确认没动 require，但 CI 报哈希不匹配 → 先跑
composer install --no-scripts --no-plugins，它会按 lock 校验并重写正确哈希 - 想预览
composer.json修改后 lock 会怎么变 → 用composer update --no-install，不是--dry-run（后者根本不存在） - 旧版 Composer（--lock-only → 升级工具，别用删 lock + install 凑合
真正“只更新哈希”不是默认行为，而是特定前提下的副作用；一旦 composer.json 和 vendor/ 出现隐性不一致，--lock 就会输出一个看似正常、实则不可靠的 lock 文件。
