老项目用Laravel 5/6硬切PHP 8.3必报错，因5/6仅适配PHP 7.1–7.4，不支持联合类型、严格错误模式及废弃函数移除；Laravel 7+才逐步兼容PHP 8.0+。
老项目还在用 Laravel 5/6，硬切 PHP 8.3 会直接报错
PHP 7.4 和 Laravel 5.x–6.x 是“原配”，而 Laravel 7+ 才开始逐步适配 PHP 8.0+。如果你的项目是 Laravel 5.8 或 6.20（常见于老政企系统、外包交付项目），php artisan serve 启动时就会卡在 ParseError: syntax error, unexpected '|'——因为 Laravel 6 的核心代码里没用联合类型，但一旦你装了某个依赖包（比如新版 symfony/console 或 monolog），它内部用了 string|int，PHP 8.3 就直接拒解码。
- PHP 7.4 允许
mysql_connect()、each()等废弃函数，Laravel 5/6 的部分辅助类或第三方插件仍悄悄调用它们 - PHP 8.3 默认开启严格错误模式，
strlen(null)在 7.4 是 warning，在 8.3 是TypeError，而老 Laravel 中间件或验证逻辑里常有这类松散传参 - 宝塔面板里切换 PHP 版本后，
php -v显示的是 CLI 版本，但网站实际走的是 FPM，必须单独确认phpinfo()页面里的版本是否一致
Laravel 9–10 跑 PHP 8.3 没问题，但得关掉 opcache.enable_cli
Laravel 9 要求 PHP >= 8.0，10 要求 >= 8.1，所以 PHP 8.3 对它们属于“向后兼容范围”。但实操中常踩一个坑：opcache.enable_cli=1 在 php.ini 里开着会导致 php artisan config:clear 失败，报 Class not found——因为 CLI 加载了旧 opcode 缓存，而 FPM 进程又没同步。
- 务必检查
php --ini输出的配置路径，编辑对应 php.ini，把opcache.enable_cli设为0 - Laravel 10 的
Route::middleware()在 PHP 8.3 下对闭包参数类型更敏感，如果中间件里写了function ($request, $next) { ... }却没声明类型，某些扩展（如spatie/laravel-permission）会触发TypeError - 宝塔安装 PHP 8.3 后，默认不带
redis.so或swoole.so，要用命令行手动编译：先cd /www/server/php/83/src/ext/redis，再phpize && ./configure && make && make install
Laravel 13 强制要求 PHP 8.3，但老扩展可能还没跟上
Laravel 13 发布于 2026 年 3 月，明确要求 PHP 8.3+，并移除了所有兼容 PHP 8.2 的 polyfill。这意味着它能用 #[Attribute] 声明模型字段、支持类型化类常量、依赖 json_validate() 的增强校验——但这些特性需要底层扩展配合。
-
ext-imagick的 3.7.x 分支才完全支持 PHP 8.3，旧版（如 3.6.0）在处理 WebP 图片时会 segfault - 某些国产 SDK（如微信支付 v3 的
wechatpay-php）在 PHP 8.3 下需升级到 2.0+，否则array_key_exists()对null键的行为变更会导致签名失败 - 宝塔截至 2026 年 9 月仍无法自动识别 PHP 8.3 的
pdo_sqlsrv扩展（Windows 环境下），得手动下载 DLL 并改extension_dir路径
别只看框架文档写的“最低版本”，要看你实际装的包
Composer 解析依赖时，不会因为你本地是 Laravel 10 就阻止你装一个只支持 PHP 8.3 的包。比如你运行 composer require laravel/pint，它当前最新版要求 PHP 8.3，但你的项目是 Laravel 9 + PHP 8.1 —— Composer 会装成功，等你跑 php artisan pint 时才爆 ParseError。
立即学习“PHP免费学习笔记（深入）”；
- 用
composer show --platform查看当前环境真实支持的 PHP 版本和扩展 - 在
composer.json里显式锁死平台版本："config": {"platform": {"php": "8.1.25"}}，避免 CI 环境误升 - PHP 8.3 的 DNF 类型（如
(A|B)&(C|D)）目前只有 Psalm 能完整分析，PHPStan 对它的支持仍不稳定，静态检查容易漏掉运行时崩溃点
isset($arr['key']) 后面紧跟 $arr['key']->method() 的写法，在 7.4 是静默 null，到 8.3 就是 Call to a member function on null——这种错不会在部署时暴露，而是在村民提交低保申请的第 3 步才弹出来。 
