新项目优先选 laravel 8.x（当前lts），已有项目升级须先验证依赖包是否兼容9.x或10.x；11.x刚于2026年3月发布，生态适配几乎为零，php 8.2+强制要求且大量常用包尚未支持。
直接说结论：新项目优先选 Laravel 8.x（当前 LTS），已有项目升级前先查清依赖包是否兼容 Laravel 9.x 或 10.x；别碰 11.x —— 它刚在 2026 年 3 月发布，生态适配几乎为零。
怎么看自己该用哪个 Laravel 版本
核心就两条线：项目生命周期 + 第三方包支持度。LTS 版本（如 8.x）官方提供安全更新直到 2025 年底，实际社区维护往往延续到次年中；而 9.x 已结束常规支持，10.x 是当前“活跃非 LTS”版本，但大量常用包（比如 spatie/laravel-permission 的某些旧 tag、laravel/scout 的 Algolia 驱动）还没完成适配。
常见错误现象：
- 执行
composer create-project laravel/laravel myapp拉下来的却是11.x，结果装不上laravel/nova（报laravel/framework ^11.0 requires php ^8.2但 Nova 当前只支持到^10.0） -
php artisan migrate报错Call to undefined method Illuminate\Database\Schema\Blueprint::id()—— 这是用了11.x的新语法，但本地 PHP 是 8.1，且迁移文件混写了旧版写法
实操建议：
- 新项目起步：显式指定版本，运行
composer create-project laravel/laravel myapp "8.*" - 想尝鲜新功能又不敢上生产：用
10.x，但必须逐个验证你依赖的包是否有10.x兼容标签（看包的composer.json里"require": {"laravel/framework": "^10.0"}） - 别信 “最新即最好” ——
11.x强制要求 PHP 8.2+，移除了Arr::fetch()等函数，且artisan serve默认启用 HTTPS 重定向，本地开发反而多一层调试成本
怎么确认当前项目用的是哪个版本
最准的方式不是看 composer.json 里的 "laravel/framework" 行，而是运行：
php artisan --version
或者在代码里调用：
<?php use Illuminate\Support\Facades\App; echo App::version(); // 输出类似 "8.83.27" ?>
注意：App::version() 返回的是运行时加载的实际框架版本，它可能和 composer.lock 记录的不一致（比如你手动改过 vendor 里的源码，或用了 symlink 覆盖）。
容易踩的坑：
- CI/CD 流水线里没固化 PHP 版本，导致
composer install在 PHP 8.3 下拉了11.x，但测试环境是 PHP 8.1，直接报Attribute class Illuminate\Attributes\Deprecated does not exist - 用
laravel/installer创建项目时没加版本约束，新版 installer 默认拉11.x，但你的 Dockerfile 还锁着php:8.1-apache
LTS 和非 LTS 版本的实际差异在哪
不只是“多修两年 bug”。LTS 版本的变更策略更保守：8.x 的所有小版本（8.75.0 → 8.83.27）不会破坏 Eloquent 关系加载顺序、不会改动 Auth::user() 的返回类型、也不会调整中间件注册时机 —— 这些恰恰是非 LTS 版本升级时最常出问题的地方。
性能与兼容性影响：
-
9.x开始默认启用opcache.preload配置，但很多共享主机不支持，导致artisan config:cache失败 -
10.x的队列监听器默认使用redis://协议，若你用的是tcp://写法（旧配置），会静默降级为同步处理 -
8.x的phpunit.xml模板仍兼容 PHPUnit 9.x，而10.x强制要求 PHPUnit 10+，升级后一堆assertDatabaseHas()调用报错
真正关键的点在于：版本选择不是技术参数比对，而是对团队响应能力的预判。当你发现一个包的 maintainer 在 GitHub issues 里回复 “won’t support 11.x until Q4”，那就意味着你得自己 fork、patch、维护那个分支 —— 这种事，LTS 版本能帮你挡掉 80%。
