唯一安全、语义明确的命令是 composer update --lock-only（composer 2.2+），它仅刷新 lock 文件元数据（content-hash、格式、platform 等），不下载包、不改 vendor/、不重算依赖树，严格校验当前 vendor 是否仍满足 composer.json 约束。
想只更新 composer.lock 而不动 vendor/，唯一安全、语义明确的命令是 composer update --lock-only（Composer 2.2+）。 其他常见写法如 composer update --no-install 或 composer update --lock 都不满足“仅同步元数据、不触发依赖解析”的核心诉求，容易导致锁文件与实际状态错位。
为什么 composer update --no-install 不行
它仍会完整执行依赖求解：下载所有包的 composer.json 元数据、运行 SAT 求解器、生成新依赖图，只是跳过写入 vendor/ 和 autoloader。网络 I/O 和 CPU 开销几乎没减少，且产出的 composer.lock 可能含意料外的版本变更。
-
--no-install不校验本地vendor/是否满足新约束，只管“算出来就写” - 若你只改了
description或空格，它却把monolog/monolog从2.10.0升到2.11.0，就违背初衷 - 它不保证
dist.sha256与当前vendor/中文件一致，后续install可能失败
composer update --lock-only 真正干了什么
它读取当前 composer.json 全部内容（包括非依赖字段），验证已安装包是否仍满足所有约束，然后仅刷新 composer.lock 中的元数据：
- 重算
content-hash（匹配新 JSON 的哈希） - 标准化 JSON 格式（缩进、字段顺序、换行符）
- 更新
platform、config等元数据字段（如config.platform.php改动） - 不下载任何包、不修改
vendor/、不联网、不重排依赖树
典型场景：Git 合并后 composer.json 多了个空格，composer install 报 “Lock file is not up to date”——这时就该跑 composer update --lock-only。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer update --lock 是另一回事
它完全忽略 composer.json 的任何改动，只对当前 vendor/ 目录做快照：
- 重新计算每个包的
dist.sha256、源地址、autoload 映射 - 标准化写回
composer.lock，但不校验这些包是否还满足composer.json的约束 - 若你手动删过某个包，它不会报错；若
vendor/已损坏，它可能直接失败 - 适用场景：修复 Git 自动换行导致的 JSON 格式损坏，或统一团队 lock 文件格式
注意：--lock 不处理 composer.json 中新增的 require 条目，也不会响应 platform 版本变更——它只信 vendor/，不信 json。
实操前必须检查的三件事
运行 composer update --lock-only 前，务必确认：
- 你的 Composer 版本 ≥ 2.2（
composer --version查看），旧版本不支持该参数 - 先加
--dry-run预览：composer update --dry-run --lock-only，观察输出是否只列元数据变更，而非一堆包版本更新 - 确保
vendor/目录完整且未被手动篡改，否则验证会失败或产生错误哈希
真正“只更新锁文件”的动作，本质是在赌当前 vendor/ 和 composer.json 仍兼容；--lock-only 是唯一把这赌注控制在元数据层的官方机制。其他路径，要么动包，要么绕过校验，都不够干净。
