必须先筛查第三方包兼容性：spatie/laravel-backup v8、laravel/sanctum v3等不支持Laravel 11，会导致Class not found或中间件静默失效；需通过composer show、GitHub Releases及composer.json约束逐项验证，并生成兼容性报告锁定高危项。
你需要在升级 Laravel 11 前快速识别哪些第三方包会直接导致应用启动失败或功能静默失效，而不是等 composer update 后才在日志里翻找 Class not found 或 Target class does not exist。
确认当前项目中所有已安装的第三方包
运行 composer show --installed，将输出保存为 packages-before.txt。这一步不能跳过，因为部分包可能未在 composer.json 中显式声明，而是被其他包间接引入。
重点筛查 vendor/ 目录下非官方组织（如 spatie、nunomaduro、laravel）的包，这些往往是兼容性风险高发区。
逐个验证关键包对 Laravel 11 的支持状态
方法一：查 GitHub Release 页面
打开每个待验证包的 GitHub 主页，点击 “Releases”，看最新正式版（not pre-release）的发布说明中是否明确写出 “Supports Laravel 11” 或类似表述。若最新版发布于 2025 年底之前，【基本可判定不兼容】，因为 Laravel 11 正式 LTS 是 2025 年底才确立的。
方法二：读 composer.json 约束
进入该包的 vendor/{vendor}/{package} 目录，打开其 composer.json，查找 "require" 下的 "laravel/framework" 字段。如果值是 "^9.0 || ^10.0" 或 "^10.*"，而没有 "^11.0"，就说明它尚未适配 Laravel 11。
方法三：用 Composer Dry Run 快速探路
临时修改你项目的 composer.json，把 "laravel/framework": "^11.0" 写进去，然后执行：composer update laravel/framework --dry-run --with-all-dependencies
观察终端输出中是否出现 conflict 提示——只要有一行含 "laravel/framework 11.0" 和某个包名的冲突，就立刻记下来。
优先处理高危包清单
第一步：核对 Sanctum 版本
运行 composer show laravel/sanctum，确认输出版本号 ≥ 4.0。若为 2.x 或 3.x，【必须升级，否则认证中间件会静默跳过】。
第二步：检查备份类包
若使用 spatie/laravel-backup，运行 composer show spatie/laravel-backup。v8 支持 Laravel 10，但不兼容 11；v9 才开始支持。v8 会直接导致 php artisan backup:run 报错退出。
第三步：扫描 Scout 驱动兼容性
若项目启用 Algolia 或 Meilisearch 驱动，查看其对应 Scout 扩展包（如 algolia/scout-extended）的 README，确认是否标注支持 Laravel 11。旧版 Scout 驱动在 Laravel 11 中调用 search() 方法时可能返回空数组而不报错。
第四步：过滤国内生态包
重点检查微信 SDK 封装（如 overtrue/wechat）、短信网关（如 yansongda/laravel-pay 的子模块）、阿里云 OSS 封装等。这些包通常滞后 1–2 个主版本，GitHub Issues 里搜 “Laravel 11” 往往能看到用户集中反馈无法实例化服务提供者。
生成兼容性报告并锁定风险项
新建一个 compatibility-report.md 文件，按如下格式填写：
- spatie/laravel-backup → v8.5.0 → ❌ 不兼容 → 替换为 v9.0.0 或等待适配
- laravel/sanctum → v3.2.1 → ❌ 不兼容 → 必须升至 v4.0.1
- overtrue/wechat → v7.3.0 → ⚠️ 未声明支持 → 暂存，需本地测试公众号回调流程
完成此表后，所有 ❌ 项必须在 composer update 前解决，⚠️ 项需安排专项测试用例覆盖核心路径。
