composer update 默认按 composer.json 约束更新并尊重 composer.lock 锁定版本，非强制升级；强制更新需删锁文件或指定包加 --with-all-dependencies；升级 Composer 自身用 composer self-update；依赖冲突报错应使用 composer why-not 和 show --tree 定位。
composer update 会跳过锁文件，但不是“强制更新”
很多人以为 composer update 就是强制升级所有包，其实它只按 composer.json 的版本约束更新，并尊重 composer.lock 已锁定的精确版本。真正想“强制更新”，得先理解它到底在更新什么。
-
composer update默认只更新composer.lock中已存在、且满足composer.json版本范围的包——哪怕远程有更高小版本，只要不越界，就不会动 - 如果某个包在
composer.lock里是"monolog/monolog": "2.8.0"，而composer.json写的是"^2.7"，那composer update不会升到2.9.0，除非你删锁文件或加参数 - 真正“强制”的做法是删掉
composer.lock再跑composer install，但这会重算全部依赖，风险高，一般不推荐
升级指定包到最新稳定版（推荐做法）
想把某个包升到当前稳定分支的最新版（比如 laravel/framework 升到 11.x 最新版），别用模糊命令，直接指名道姓：
composer update laravel/framework --with-all-dependencies
这个命令的关键点：
-
--with-all-dependencies是必须的：否则 Composer 可能因依赖冲突卡住，或只升主包不升其子依赖 - 不加版本号，默认按
composer.json里写的约束走；如果想跳到下一个主版本（如从10.45升11.0），得先改composer.json里的版本字符串，比如把"^10.0"改成"^11.0" - 执行前建议先
git status确认没未提交改动，升级失败时容易卡在半中间状态
升级 Composer 自身到最新稳定版
Composer 工具本身也要更新，否则可能不识别新语法、不支持新 PHP 版本或解析错误。升级命令很简单，但有两个关键路径：
- 全局安装的 Composer（推荐）：
composer self-update
—— 默认只升到最新稳定版，不带--snapshot就不会上开发版 - 项目内局部安装（
composer.phar在项目根目录）：php composer.phar self-update
- 如果提示权限错误（Linux/macOS），别直接
sudo，而是检查~/.composer目录归属，或用curl -sS https://getcomposer.org/installer | php重装 - 升级后运行
composer --version确认输出里没有snapshot字样，否则说明误装了预发布版
常见报错：“Your requirements could not be resolved” 怎么办
这是 Composer 依赖解析失败最典型的提示，不是网络问题，也不是权限问题，而是语义版本冲突。典型诱因：
- 多个包要求同一依赖的不同主版本，比如
package-a要guzzlehttp/guzzle:^7.0，package-b要^8.0，Composer 就没法选 - PHP 版本不匹配：你的
composer.json声明了"php": "^8.1"，但实际环境是8.0，Composer 会直接拒绝解析 - 临时解决可加
-W（--with-dependencies）或--ignore-platform-reqs，但后者只是绕过检查，上线前必须撤掉 - 真要定位冲突，用
composer why-not vendor/package:version查哪个包在拦路，比硬试快得多
依赖树越深，手动调越容易漏掉间接依赖。与其反复试错，不如先看 composer show --tree 拉出全图，再聚焦冲突节点。
