composer update 本就是强制更新，但受限于 composer.json 中的版本约束；若需跨主版本升级，必须手动修改约束并执行 update。
composer update 不会“强制更新”——它本来就是强制的，所谓“强制”其实是你没理解它默认行为背后的依赖约束逻辑。
为什么 composer update 看起来没更新？
不是命令不执行，而是 Composer 尊重 composer.json 里的版本约束（比如 "monolog/monolog": "^2.0"），只在允许范围内找最新兼容版本。如果你本地已装 2.9.1，而仓库最新是 2.10.0，它会更新；但如果最新是 3.0.0，它就跳过——因为 ^2.0 不包含 3.x。
- 检查当前锁文件：运行
composer show monolog/monolog看实际安装版本和约束范围 - 确认远程包状态：用
composer show -a monolog/monolog查看所有可用版本 - 别直接删
vendor/或composer.lock——这不叫强制，叫自毁式重装
想升到某个大版本（比如 3.x）？改 composer.json 再 update
Composer 不会违背你的声明。要跨主版本，必须显式放宽或修改约束。
- 把
"monolog/monolog": "^2.0"改成"monolog/monolog": "^3.0"，再跑composer update monolog/monolog - 如果只想临时绕过约束试装，可用
--with-all-dependencies（但慎用，可能破坏依赖图） - 注意：改完
composer.json后，composer update默认只更新该包及其必要依赖，不会全量刷新整个 lock 文件
真要无视锁文件、全量重算依赖？用 --lock 不行，得删锁再 update
composer update --lock 是个误导性参数——它不“强制”，只是校验锁文件一致性；真正重算依赖图，必须让 Composer 忽略现有 composer.lock。
- 安全做法：先备份
composer.lock，再执行rm composer.lock && composer update - 等效但更明确的写法：
composer update --ignore-platform-reqs --no-install+ 手动composer install，适合 CI 场景 - 警告：删除
composer.lock后，所有包都会按composer.json重新解析，可能引入意外的次版本升级（如从phpunit/phpunit: ^9.5升到9.6），务必测试
最常被忽略的一点：你以为的“强制”，其实是在对抗自己写的约束；真正的控制权不在命令选项里，而在 composer.json 的每个版本号背后。
