composer update 默认更新 composer.json 中所有满足约束的包及间接依赖，导致非目标包版本变动；应使用 --with-dependencies、--dry-run 或 --no-update-with-dependencies 精准控制。
更新单个包时 composer update 为什么连其他包也变了？
因为 composer update 默认不带参数时会更新 composer.json 中所有满足版本约束的包，不是“只更新你心里想的那个”。它读的是整个依赖图，顺手把间接依赖也按新规则重解一遍。
常见错误现象：composer update monolog/monolog 后，guzzlehttp/guzzle 版本也跳了，甚至 CI 突然挂了——这说明你没锁住间接依赖的兼容边界。
- 正确做法：加
--with-dependencies或明确排除无关包，例如：composer update monolog/monolog --with-dependencies - 更安全的做法是先用
--dry-run预览：composer update monolog/monolog --dry-run - 如果只想升
monolog/monolog本身、完全不动其依赖，用--no-update-with-dependencies（Composer 2.5+）
composer require 能不能用来“升级”已有包？
可以，但本质是“重新声明需求”，不是“升级命令”。它会修改 composer.json 并执行安装逻辑，效果接近更新，但行为更可控。
使用场景：你想把 symfony/console 升到 ^6.4，而它当前是 ^5.4，且项目里没有硬编码调用 v6 独有 API。
- 执行：
composer require symfony/console:^6.4 - 它会自动删掉旧版本、写入新约束、重装，并触发
autoload-dump - 注意：如果新版本和现有其他包冲突（比如
doctrine/dbal还卡在 v2），Composer 会报错，而不是降级或跳过 - 此时别硬加
--ignore-platform-reqs，先看composer why-not symfony/console:^6.4定位阻塞项
更新失败时看到 Your requirements could not be resolved 怎么办？
这不是网络问题，是版本约束矛盾。Composer 已穷尽所有可能组合，仍找不到一组同时满足所有包 require 字段的版本。
典型诱因：某个包升级后要求 PHP >= 8.1，但你的 config.platform.php 还设成 "7.4"；或两个包各自要求对方的不同主版本。
- 第一步查平台配置：
composer config platform.php，确认和实际运行环境一致 - 第二步看谁在挡路：
composer prohibits vendor/package:version（例如composer prohibits laravel/framework:10.0） - 第三步临时放宽约束：编辑
composer.json，把冲突包的版本号改成更宽泛的范围（如从"^2.3"改成"^2.0 || ^3.0"），再试composer update - 切忌直接删
composer.lock——那等于放弃可重现性
更新后功能异常，但 composer show 显示版本是对的
版本对 ≠ 代码对。可能原因：类加载缓存没刷新、APCu 缓存了旧的 autoloader 映射、或包内有未声明的运行时条件分支。
最容易被忽略的是 Composer 的 autoloader 生成机制——它默认只在 install/update 时重生成，但如果你手动改过 vendor/autoload.php 或用了自定义 classmap，它不会自动感知。
- 强制重生成 autoload：
composer dump-autoload -o（-o表示优化，生成静态映射） - 清 APCu 缓存（如果启用）：
apcu_clear_cache('user')或重启 PHP-FPM - 检查是否启用了
config.autoload-suffix，不同环境 suffix 不一致会导致加载错文件 - 某些包（如
nette/utils）会在vendor/bin放辅助脚本，更新后记得确认脚本是否同步更新
复杂点在于：很多问题表面是“更新失败”，实际是“缓存没清干净”或“平台配置和本地环境错位”。动手前先 composer show package/name 和 composer why package/name 多敲两遍，比重装 Composer 有用得多。
