Composer怎么执行更新依赖包命令-composer-PHP中文网

composer update 不加参数会丢弃 composer.lock 并重新解析所有依赖，导致不可重现构建；应优先用 --dry-run 预览、git checkout composer.lock && composer install 快速回滚，单包更新须用 vendor/name 格式且不加引号。

composer怎么执行更新依赖包命令

composer update 不加参数就是在改 lock 文件

裸跑 composer update 会丢弃当前 composer.lock，重新解析 composer.json 中所有版本约束，从 Packagist 拉取每个包在约束范围内“最新兼容”的版本——哪怕只是小版本号变动，也可能带入行为变更（比如 Guzzle 默认超时从 5 秒缩到 3 秒）。CI/CD 流水线里这么写，等于放弃构建可重现性。

常见错误现象：Your requirements could not be resolved，大概率不是依赖冲突，而是本地 PHP 版本或扩展缺失（如 missing ext-curl）；卡在 metadata 获取阶段不报错、不超时，只能干等。

想预览影响范围？先跑 composer update --dry-run，再 git diff composer.lock 看 SHA 变更
升级后出问题？立刻 git checkout composer.lock && composer install，比查 changelog 快十倍
永远在运行前提交或备份 composer.lock：cp composer.lock composer.lock.bak

只更新一个包：必须写全 vendor/name 格式

composer update monolog/monolog 是唯一安全的“单包更新”方式。它只按 composer.json 中该包的约束（如 "monolog/monolog": "^2.8"）拉取最新兼容版（如 2.10.0），并仅顺带更新其直系依赖中未被其他顶层包锁死的部分（比如 psr/log 若需升到 ^2.0 才能装 monolog 2.10，就会升）。

常见错误现象：输成 composer update（漏参数）、或用引号包裹包名（composer update "monolog/monolog"），导致 shell 忽略参数，实际执行了全量更新。

包名必须完整、准确，格式为 vendor/name，例如 laravel/framework、guzzlehttp/guzzle
如果包没出现在你的 composer.json 的 require 或 require-dev 里，命令会静默成功但不执行任何操作
--with-dependencies 在 Composer 2.2+ 已被移除，执行会报错 Unrecognized option

连带更新指定直系依赖：用 --with 参数

默认情况下，composer update guzzlehttp/guzzle 不动它的子依赖，比如 psr/http-message 还卡在 1.0.1。这不是 bug，是设计使然。要让它连带更新某些直系依赖，用 --with：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

composer update guzzlehttp/guzzle --with psr/http-message

注意：--with 后跟的是包名，多个包用空格分隔，不是逗号；它只影响该包声明的直系依赖，不会递归扫整个依赖图。

若目标包的新版本 require 字段收紧了对某个子依赖的约束（如从 ^1.0 改为 ^2.0），且当前锁的是 1.1.4，则该子依赖会被一并升级
若只是小版本更新（如 7.2.1 → 7.2.3），且依赖约束没变，子依赖通常不动
不要用 --with-all-dependencies 来“保险”，它会递归更新整个依赖图中所有可匹配的包，极易引发意外兼容问题

升级前必须看 composer outdated --direct

composer outdated --direct 不改任何文件，只告诉你哪些显式声明的依赖有新版可升，并暴露三类关键风险：

安全更新：标有 [security] 的行，如 guzzlehttp/guzzle 7.8.1 → 7.8.2 [security]
主版本跳变：如 symfony/console 5.4.39 → 6.4.0，说明约束已允许升 6.x，但你未必准备好
约束失效：某包在 composer.json 里写了 "^2.0"，但 outdated 不显示它——大概率被 replace 或 require-dev 干扰了依赖图

如果 outdated 输出为空，先检查是否启用了 "minimum-stability": "stable" 和 "prefer-stable": true，它们会过滤掉所有预发布版本，导致“有新包也看不见”。

真正容易被忽略的是：升级后 vendor/autoload.php 失效，90% 不是包没装对，是自动加载映射没重建。执行 composer dump-autoload -o 即可生成优化后的静态映射；如果项目用了自定义 PSR-4 命名空间，顺手检查下 composer.json 的 autoload 段是否被意外覆盖或缩进错乱——升级过程不会动它，但手动编辑时容易手抖。