composer update 不加参数会丢弃 composer.lock 并重新解析所有依赖，导致不可重现构建；应优先用 --dry-run 预览、git checkout composer.lock && composer install 快速回滚，单包更新须用 vendor/name 格式且不加引号。
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：
工作流任务拆解与模型编排技能。使用场景：(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 段是否被意外覆盖或缩进错乱——升级过程不会动它，但手动编辑时容易手抖。
