Laravel 14 最低 PHP 抬到 8.4：从 master 分支看到的 2027 Q1 排期
这些内容来自 laravel/framework 的 master 分支，不是正式发布版本。官方文档目前还没有 Laravel 14 这一条，下面的版本号、日期和依赖关系都属于前瞻信息，落地前需自行验证。
Laravel 14 的两处改动
Laravel 14 预计 2027 Q1 发布，最低 PHP 要求从 Laravel 13 的 8.3 抬到 8.4。
这个改动来自 PR #59104，直接把最低 PHP 版本提到 8.4。原因不在 Laravel 自身，而是 Symfony 8 要求 PHP 8.4，而 Laravel 的 HTTP 内核、控制台、路由等组件构建在 Symfony 之上，上游的门槛会顺着依赖链传导下来。
支持周期方面，Laravel 14 预计 bug 修复支持到 2028 Q3，安全支持到 2029 Q1。
支持时间线
按当前可查的信息整理，各版本的支持窗口如下：
| 版本 | PHP 范围 | 发布日期 | Bug 修复至 | 安全支持至 |
|---|---|---|---|---|
| Laravel 11 | PHP 8.2–8.4 | 2024-03-12 | 2025-09-03 | 2026-03-12 |
| Laravel 12 | PHP 8.2–8.5 | 2025-02-24 | 2026-08-13 | 2027-02-24 |
| Laravel 13 | PHP 8.3–8.5 | 2026-03-17 | 2027 Q3 | 2028-03-17 |
| Laravel 14 | PHP 8.4+ | 2027 Q1 | 2028 Q3 | 2029 Q1 |
可以看到几条规律：PHP 下限每个大版本抬一次（8.2 → 8.3 → 8.4），上限跟着 PHP 小版本走；bug 修复窗口大约 18 个月，安全支持再往后延 6 个月左右。
每年 Q1 一个大版本
Laravel 的支持策略大致是每年 Q1 出一个大版本，发布节奏比较固定。上表里 11 是 3 月 12 日、12 是 2 月 24 日、13 是 3 月 17 日、14 落在 2027 Q1，基本符合这个规律。
需要注意的是，Laravel 11 只支持到 PHP 8.4，Laravel 12 才覆盖到 8.5。也就是说如果项目跑在 PHP 8.5 上，能选的版本下限是 Laravel 12。
同一周的 Symfony
同一周 Symfony 发布了 6.4.47、7.4.20、8.1.8，以及 Symfony Reprise 1.3.0，并继续往主干引入 Symfony 8.2 的特性：
- OpenID Connect 登录
- PGP/MIME 签名与加密邮件
- sudo 模式
- 更灵活的序列化分组
- 性能改进
另外，Laravel Cloud 也可以运行 Symfony 应用。
升级排期建议
结合上表，给几条可执行的判断：
Laravel 11 的项目先动。 Bug 修复已经在 2025-09-03 结束，安全支持 2026-03-12 到期。还没升级的，优先级应该排在前面，目标是先到 12 或 13，不必等 14。
Laravel 12 的项目算好时间点。 Bug 修复到 2026-08-13，安全支持到 2027-02-24。如果想直接跳到 Laravel 14，中间跨度是两个大版本，且 PHP 下限要从 8.2 提到 8.4，运行环境得同步升级。Laravel 14 的发布窗口是 2027 Q1，安全支持到期和 14 发布之间只差一个月左右，留给 "12 → 14" 的缓冲不多。
Laravel 13 的项目跨到 14 最省事。 13 的 PHP 范围是 8.3–8.5，14 是 8.4+，下限只抬了一级，如果 13 的生产环境已经跑在 8.4 或 8.5 上，框架侧的改动会比较小。13 的安全支持到 2028-03-17，从周期上看时间充裕。
检查依赖里的 Symfony 版本约束。 如果某个包把 Symfony 锁在 7.x，Laravel 14 升级时会被一起卡住。这类约束在 composer.json 里通常不显眼，升级前值得单独过一遍。具体某个包是否已经支持 Symfony 8，需自行验证。
PHP 版本先于框架版本升级。 从 12 直接跳 14 的场景里，PHP 从 8.2/8.3 到 8.4 是硬门槛，这一步最好在框架升级前独立完成并验证一遍，避免框架和运行时的问题混在一起排查。
参考：