Laravel升级需严格按主版本顺序进行，先确认当前与目标版本及PHP兼容性，再同步更新全部依赖及结构，最后彻底清理缓存并排查废弃函数调用。
直接升级 laravel/framework 或 topthink/framework 很容易连带升级不兼容的底层依赖，不是框架没升成，而是 symfony/console、doctrine/dbal 这类包被悄悄拉高了小版本，导致 Class not found 或方法签名错——这是最常被忽略的“静默破坏”。
为什么 composer update laravel/framework 会崩掉 tinker？
它不是只更新 Laravel，而是按 composer.json 中该包的约束（比如 "^10.0"）重新计算整个依赖图。Composer 会顺手把 symfony/console 升到 v7，但 Laravel 10 官方只支持 v6.x。
- 典型报错：
Class "SymfonyComponentConsoleCommand" not found - 验证方式：运行
composer show symfony/console，看实际装的是不是 v6.x - 别信 “
laravel/framework: ^10.0” 就安全——它不拦着 Composer 拉 v7 的 Symfony - 真正保险的做法是在
composer.json的require里显式锁死："symfony/console": "^6.2"
扩展包突然报 Call to undefined method IlluminateSupportStr::slug() 怎么办？
这不是框架升级失败，是扩展包还没适配新 Laravel 版本。Laravel 10 移除了 Str::slug() 的第三个参数，但老版 laravel-lang 还在传。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先查扩展包 GitHub 的 latest release，确认是否标注支持 Laravel 10/11
- 打开它的
composer.json，看"laravel/framework": "^9.0"这种声明还在不在 - 临时降级：用
composer require spatie/laravel-permission:"^5.5"，而不是留空让 Composer 自选 - 绝对别删
vendor重装——这绕过了 Composer 的版本兼容性校验，问题更难定位
composer update topthink/framework 后入口文件报错找不到类？
ThinkPHP 6 → 8 升级后目录结构和自动加载规则全变了，vendor/autoload.php 加载失败往往是因为 PSR-4 映射没同步更新，或手动加的 packages/ 目录没被识别。
立即学习“PHP免费学习笔记（深入）”；
- 检查
composer.json的autoload段，确认"App\": "app/"（不是application/） - 运行
composer dump-autoload -o强制重建优化版自动加载映射 - 如果用了自定义包路径（如
packages/mycompany/core），必须在autoload里显式加 PSR-4 映射 - 升级后别跳过
composer show --tree，一眼就能看出哪些间接依赖被意外拉高了
最危险的不是升级失败，而是升级“看似成功”却埋下隐性不兼容——比如某个中间件在 Laravel 11 下默认返回 Response 对象，而你写的逻辑还假设它是字符串。这种问题不会在 composer update 时报警，只能靠覆盖核心路径的单元测试暴露。
