改了 composer.json 但未更新 composer.lock，应使用 composer update --lock-only（Composer 2.2+）；执行前务必加 --dry-run 验证，仅重写 content-hash、排序和元数据，不改动 vendor/。
想更新 composer.lock 文件，先明确你到底要什么：是同步修改后的 composer.json、修复格式/哈希、重建丢失的锁文件，还是只升级某个包？用错命令会导致依赖漂移、CI 失败甚至线上行为不一致。
改了 composer.json 但 composer.lock 没变，该用哪个命令？
这是最常见也最容易误操作的场景。比如你新增了一个 require、调整了 PHP platform 版本，或改了 config 字段——这些改动不会被 composer install 感知，它只认 lock 文件。
-
composer update --lock-only是唯一安全方式（Composer 2.2+）：它读取当前composer.json全部内容，验证已安装包是否仍满足所有约束，仅重写content-hash、排序和元数据，不动vendor/一丁点 - 执行前务必加
--dry-run：运行composer update --dry-run --lock-only，如果输出里只有哈希变更或格式调整，说明没问题；若出现大量包版本变动，说明你的json和已装包已不兼容 - 旧版 Composer（--lock-only，要么升级工具，要么改用
composer update（但会连带升级包，风险更高）
composer.lock 被删了或损坏，怎么安全重建？
别急着 composer install，它会直接报错退出。也别盲目 composer update，它可能升级一堆你不想要的包。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先确认
vendor/是否完整：如果刚删锁文件、没动过vendor/，且composer.json也没改，就用composer update --lock—— 它会基于当前vendor/和composer.json重新生成语义等价的锁文件，输出应为0 installs, 0 updates, 0 removals - 如果
vendor/已不完整（比如部分包被手动删过），--lock会失败；此时只能composer update --dry-run预检，看依赖树是否已漂移；若漂移严重，就得接受版本变化，或回退到上一个干净的git checkout composer.lock - CI 脚本中建议加一层检查：检测
composer.lock是否存在，缺失时自动跑composer update --lock（需确保vendor/可信），否则整个构建卡死
只想升级一个包并同步 composer.lock，不是全量更新
composer update 默认是全量重算，极易引发意外升级。精准控制才是生产环境的常态。
- 用
composer update vendor/package：例如composer update guzzlehttp/guzzle，它会保留其他所有包的精确版本，只按composer.json约束升级目标包及其必要子依赖 - 加
--with-dependencies要谨慎：它会主动升级目标包的全部直接依赖，容易触发连锁反应；不加则只升必须调整的部分 - 如果包不在
composer.json的require或require-dev中（比如只是间接依赖），直接update会报错Package "xxx" listed for update is not required；此时要么先在json中显式添加，要么用--with-all-dependencies（风险更高）
composer update --lock 和 composer update --lock-only 到底差在哪？
这两个参数名字像，行为却完全不同，混用是很多团队 CI 失败的根源。
-
composer update --lock：完全不读composer.json的任何改动，只对当前vendor/目录做快照，重新计算 dist hash、源地址、依赖结构并标准化写回lock；哪怕你在json里新加了一个包，它也当没看见 -
composer update --lock-only：严格基于当前composer.json内容（包括新增/修改的require字段），验证已安装包是否仍满足约束，然后仅刷新lock的元数据和哈希 - 关键区别在于输入源：
--lock以vendor/为准，--lock-only以composer.json为准；前者适合锁文件损坏后“原样重建”，后者适合“同步配置变更”
真正容易被忽略的点是 Composer 版本兼容性：composer.lock 格式随大版本演进（如 1.x → 2.x），不同版本生成的文件可能互不识别。团队协作时，所有人应统一使用相同大版本（推荐 2.x），CI 脚本里别用 composer self-update 无脑升级，而是锁定具体版本，比如 composer self-update 2.5.8。
