Laravel升级必须逐主版本进行，先确认当前与目标版本及PHP兼容性（如11.x需PHP≥8.2），再同步更新composer.json中framework及配套包版本，运行composer update --with-all-dependencies，最后用php artisan upgrade迁移结构并清理缓存。
想升级项目内核（比如 Laravel、Symfony、WordPress 插件等），别直接跑 composer update —— 它大概率什么都不会升，除非你先改 composer.json 里的版本约束，再配合 --with-all-dependencies。
为什么 composer update 不升级内核包？
因为 Composer 默认只在 composer.json 当前声明的版本范围内找“兼容最新版”，不是找“远程最新稳定版”。比如你写的是 "laravel/framework": "^10.0"，它就永远不会升到 11.x，哪怕 11.2.0 已发布。
- 执行
composer show laravel/framework看versions行，确认当前允许的范围 - 执行
composer show laravel/framework --all查看所有可用版本（需网络） - 如果
installed版本低于你期望的主版本（如装着10.48.0却想要11.0.0），说明约束没放开
升级内核包必须改 composer.json 再更新
内核包升级本质是跨主版本变更，不能靠参数绕过，必须显式调整约束。否则 composer update laravel/framework --with-all-dependencies 仍卡在 10.x。
- 把
"laravel/framework": "^10.0"改成"laravel/framework": "^11.0"（或更宽泛的"^11"） - 保存后运行
composer update laravel/framework --with-all-dependencies - 加
-v观察是否触发了整棵树重解析（输出里有Resolving dependencies和大量Downloading） - 若失败，先用
composer why-not laravel/framework:11.0.0查哪个依赖在锁死旧分支
--with-all-dependencies 是关键，但不是万能
它让 Composer 重新协商整个依赖图，确保子依赖（如 symfony/console、nesbot/carbon）也适配新内核。不加这个，可能只升了主包，子依赖还是旧的，运行时报错。
- 只写
composer update laravel/framework：仅更新该包本身，子依赖不动 - 加
--with-dependencies：升该包 + 其直系子依赖，但其他分支仍可能滞留旧版 - 加
--with-all-dependencies：全链路重算，最接近“强制对齐新内核”的安全做法 - 注意：它仍受
config.platform.php和require中其他包约束影响，冲突时会报错，不是硬覆盖
升级后 vendor/autoload.php 失效？别漏掉 autoload 重建
Composer 更新依赖后不会自动重建自动加载映射，尤其当类路径、命名空间或 PSR-4 配置有变更时，vendor/autoload.php 可能引用旧映射，导致 Class not found。
- 手动触发重建：
composer dump-autoload -o（优化模式）或composer dump-autoload（开发模式） - 某些框架（如 Laravel）要求额外运行
php artisan package:discover刷新服务提供者 - CI/CD 中记得把
dump-autoload加进构建步骤，否则本地正常、线上报错
真正容易被忽略的是：内核升级后，composer.lock 的 content-hash 和平台字段（如 php、ext-json）会随新依赖变化，而旧版 Composer 可能无法正确读取——团队成员和 CI 必须统一使用 Composer 2.5+，否则 install 会静默失败或降级回退。
