新项目应直接用php 8.3，老项目若依赖create_function()、mysql_connect()等则只能选php 7.4；php 8.4目前不成熟，务必避开。
直接上 PHP 8.2 或 8.3，除非你明确知道必须用老版本——新项目没理由卡在 7.4，老项目硬切 8.x 也大概率会挂。
看清楚你跑的是什么程序，不是看“新不新”
WordPress 6.0+、Laravel 10+、ThinkPHP 6.3+ 这些主流框架的最低要求已经锁死在 PHP 8.1 起步。如果项目代码里大量用 create_function()、mysql_connect()、each()，或者依赖 ionCube 加密扩展（未适配 PHP 8），那 PHP 7.4 就是事实上的底线——PHP 8.0+ 会直接报 Fatal error，不是警告。
容易踩的坑：
- 以为宝塔面板里选了“PHP 8.2”就万事大吉，结果
php -v在终端还是 7.4 —— Web 请求走 FPM，CLI 命令走系统软链接，两者完全独立 - 用
composer install时默认调用 CLI 版本，如果它还是 7.4，而composer.json要求"php": "^8.2"，就会报错退出
别信“最新版最好”，PHP 8.4 目前就是个坑
PHP 8.4 已于 2025 年底发布，但它移除了 get_magic_quotes_gpc()、收紧了弱类型比较规则、并强制所有致命错误转为 Error 异常。目前主流工具链还没跟上：Swoole 5.1.3 以下不兼容，laravel/pint 1.15.0 之前无法解析新语法，宝塔 8.0.5 仍无法识别部分 8.4 扩展模块。
所以现在（2026 年 10 月）稳妥的选择是：
- 全新项目：直接上
PHP 8.3，JIT 更稳，enum和readonly支持完整，扩展生态已基本对齐 - 生产迁移过渡：用
PHP 8.2，Swoole/Redis/Imagick 等关键扩展兼容性最成熟，宝塔和 cPanel 识别无误 - 绝对不碰
PHP 8.4，除非你亲自编译过全部扩展并跑通全量测试
FPM 和 CLI 的 php.ini 是两套配置，改错地方等于没改
Web 请求读的是 /etc/php/8.2/fpm/php.ini，命令行执行 php -r "echo opcache_get_status();" 读的是 /etc/php/8.2/cli/php.ini。常见静默故障：
-
opcache.enable = Off在 CLI 配置里没开 → Composer 自动加载变慢，Artisan 命令响应迟钝 -
date.timezone没设 → PHP 8.0+ 会触发Warning，某些日志组件直接拒写 -
mbstring.func_overload在 PHP 8.2+ 已被彻底移除 → 如果旧代码依赖它，无论怎么配 ini 都会报Unknown option
改完必须分别重启服务：sudo systemctl restart php8.2-fpm 和 sudo systemctl restart php8.2-cli（后者实际是重载软链接，但验证时务必执行 php -v 和 php --ini 确认路径）。
多版本共存时，Nginx fastcgi_pass 指向错了就 502
Ubuntu/Debian 下装多个 PHP-FPM 版本后，每个版本监听的 socket 路径不同：
-
PHP 8.2默认 socket：/run/php/php8.2-fpm.sock -
PHP 8.3默认 socket：/run/php/php8.3-fpm.sock
Nginx 配置里 fastcgi_pass 必须严格匹配，写成 fastcgi_pass unix:/run/php/php8.2-fpm.sock; 却运行着 8.3 的服务，必然 502。更隐蔽的问题是：systemd 服务名也按版本区分，sudo systemctl status php8.2-fpm 和 sudo systemctl status php8.3-fpm 得分开查状态，不能只看 php-fpm。
真正麻烦的点不在安装，而在验证——每个版本的 phpinfo()、php -m、php --ini、curl -I http://localhost 都得单独跑一遍，漏掉任意一环，上线后就只能靠错误日志反推。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
