必须先核对环境兼容性：检查php版本是否满足旧版最低要求、确认composer.lock未被修改、验证数据库迁移可逆性、比对config目录配置是否被新版本删除或重命名，否则恢复旧版将导致覆盖数据、启动失败或权限错乱。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要让Laper团队在恢复旧版本前避免覆盖数据、启动失败或权限错乱，必须先核对当前环境与目标旧版的匹配关系，检查PHP版本是否低于旧版最低要求、确认composer.lock是否被修改过、验证数据库迁移状态是否可逆、比对config目录下自定义配置是否已在新版本中被删除或重命名。
确认当前运行环境与目标旧版的兼容性
执行php -v查看实际PHP版本；若目标旧版是Laravel 9.1，则要求PHP ≥ 8.0，而当前若为8.2，虽能运行但可能触发未声明返回类型的Strict Warning，需提前补全void声明。
运行php artisan --version确认当前框架版本；若显示Laravel Framework 11.3.0，说明已升级至11.x，此时不能直接切回9.1——中间缺失的10.x版本会导致Illuminate\Foundation\Application构造函数签名不兼容，artisan命令会抛出ArgumentCountError。
检查composer.json中"laravel/framework"字段值，若仍为"^11.0"，说明未手动降级约束，直接git checkout旧分支后运行composer install会因依赖冲突失败。
验证关键文件是否已被新版本覆盖或删除
方法一：对比config/目录差异
进入config/目录，运行git status config/；若输出包含modified: app.php或deleted: cache.php，说明Laravel 11默认移除的配置项已被改动，恢复旧版前必须从Git历史中还原原始cache.php，否则php artisan config:clear会报Class not found。
方法二：检查app/Providers/RouteServiceProvider.php是否被升级助手修改
Laravel 11官方升级助手会重写该文件，将mapApiRoutes()和mapWebRoutes()合并进boot()；若目标旧版是9.1，其路由注册逻辑依赖独立方法，不还原将导致所有API路由404。
【必须还原】执行git checkout v9.1.0 -- app/Providers/RouteServiceProvider.php，否则路由系统无法加载。
检查数据库迁移状态是否支持回退
第一步：列出已执行迁移
运行php artisan migrate:status，确认最新迁移时间戳是否早于目标旧版本的最后一个发布日期（如Laravel 9.1最后发布于2022年10月，对应迁移文件名应不晚于2022_10_15_000000_add_soft_deletes_to_users_table.php）。
第二步：确认是否存在不可逆操作
若列表中出现2023_05_20_100000_drop_old_columns_from_posts_table.php这类含DROP COLUMN的迁移，且该文件在9.1分支中不存在，则说明此迁移由11.x新增，恢复旧版前必须手动导出被删字段数据，否则回退后业务字段永久丢失。
第三步：验证down()方法完整性
打开任意一条新迁移文件，检查down()方法是否为空或仅含Schema::dropIfExists；若存在DB::statement('ALTER TABLE ... DROP COLUMN')且无对应重建逻辑，该迁移不可安全回退。
确认第三方包是否已升级到不兼容旧版的版本
运行composer show | grep -E "(spatie|nunomaduro|laravel/sanctum)"，重点看版本号：
若spatie/laravel-permission显示v6.0.0，而目标旧版9.1仅支持^4.0，则composer install会因约束冲突中止，必须先在composer.json中锁定为"spatie/laravel-permission": "^4.6"再执行安装。
若laravel/sanctum显示v4.0.2，它强制要求Laravel 11的illuminate/auth v11，与9.1完全不兼容；此时需同步降级为"laravel/sanctum": "^2.14"，否则启动时抛出Target class [Laravel\Sanctum\Sanctum] does not exist。
