CentOS 上的 PHP 环境，常见问题通常不是“会不会装”，而是“该选哪个版本、哪些参数必须先调、上线后怎么避免性能和兼容性问题”。这篇文章按实际部署顺序拆开讲：先确定版本，再完成 Remi 仓库安装和基础配置，最后补上 OPcache、PHP-FPM 与 Web 服务器联动优化。读完你可以据此判断，自己的项目更适合 PHP 7.4 还是 PHP 8.x，以及哪些配置项需要优先检查。
先确定版本：CentOS 上 PHP 到底怎么选
在 CentOS 上选择 PHP 版本，建议先看四个维度：应用兼容性、性能收益、安全支持周期，以及与现有技术栈的配合情况。版本选错了，后面的安装和调优往往都是在补救。
先看应用兼容性
如果服务器承载的是老项目，尤其是 WordPress 5.8 及以下、Drupal 8 及以下这类旧版应用，就应优先匹配它们的推荐版本，通常至少是 PHP 7.2+ 或 7.4+。这类项目对升级的容错空间有限，盲目切到 PHP 8.x，容易在插件、主题或旧扩展上出现兼容性问题。
如果是较新的应用栈，比如 Laravel 10、Symfony 6，那么 PHP 8.0 及以上基本是前提条件。版本不够，新特性无法使用，框架本身也可能直接报错或出现功能异常。
再看性能和安全窗口
性能方面，PHP 7.x 尤其是 7.4，相比 5.x 通常有大约 2-3 倍提升，对大多数中小型业务已经足够。PHP 8.x 系列，例如 8.1、8.2，引入 JIT 编译器后，整体性能通常还能比 7.x 再高 10% 到 30%。
但性能提升的代价是兼容性门槛更高。比如旧代码在升级到 PHP 8.x 时，可能需要调整 __toString() 魔术方法的返回值类型。只要项目里有历史包袱，升级前都应该先做完整测试。
安全性上，优先选择仍在支持周期内的版本更稳妥。原文给出的参考节点是：
- PHP 7.4 LTS 支持到 2024 年 11 月
- PHP 8.0 LTS 支持到 2025 年 11 月
- PHP 8.1 LTS 支持到 2026 年 11 月
这些版本能持续收到安全补丁，适合作为生产环境的优先候选。
最后确认技术栈是否配套
PHP 版本不能脱离 Web 服务器和数据库单独决定。部署前至少要确认 Apache/Nginx、MySQL/MariaDB 是否能稳定配合。
- Apache 2.4 通常需要搭配 PHP 7.0+ 的
mod_proxy_fcgi模块 - Nginx 则通过 PHP-FPM 与 PHP 通信
如果这些组件之间的连接方式、模块或 socket 配置没有对齐，环境即使安装成功，后续也会频繁出问题。
CentOS 上安装 PHP 与基础配置
CentOS 默认 YUM 仓库里的 PHP 版本通常偏旧，因此实际部署时一般会启用 EPEL 和 Remi 仓库。EPEL 提供额外软件包，Remi 提供更新的 PHP 版本。
先启用 EPEL 和 Remi 仓库
sudo yum install epel-release -y
sudo yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm -y
# CentOS 7
# sudo yum install http://rpms.remirepo.net/enterprise/remi-release-8.rpm -y
# CentOS 8这里需要根据系统版本选择对应的 Remi 源，CentOS 7 和 CentOS 8 的安装包地址不同。
安装 PHP 7.4 与常用扩展
下面以 PHP 7.4 为例，先启用 Remi 中对应的软件流，再安装 PHP 核心和常用扩展：
sudo yum-config-manager --enable remi-php74
sudo yum install php php-cli php-fpm php-mysqlnd php-gd php-mbstring php-xml php-opcache -y这组扩展覆盖了命令行、FPM、MySQL、图像处理、字符串处理、XML 和 OPcache 等常见场景，适合作为通用基础环境。
配置 /etc/php.ini 的核心参数
安装完成后，先调整 /etc/php.ini。这一步主要解决资源限制、上传大小和时区等基础问题。
memory_limit = 256M：按应用需求设置，避免过大导致整体内存压力失控max_execution_time = 300：适合上传文件或处理大批量数据的场景upload_max_filesize = 50Mpost_max_size = 50M：两者需要与前端表单的enctype="multipart/form-data"配合date.timezone = Asia/Shanghai：避免时间函数报错或时区偏差
配置 PHP-FPM 进程池
接着编辑 /etc/php-fpm.d/www.conf，这里影响并发能力和资源占用。对大多数业务，动态进程池是更常见的选择。
pm = dynamic：动态调整进程数，适合通用场景pm.max_children = 50：可按公式(可用内存 - 1G) / 单个进程内存估算，文中示例提到 1GB 内存可设为 30-40pm.min_spare_servers = 5pm.max_spare_servers = 35：保留适量空闲进程，减少频繁创建和销毁request_terminate_timeout = 30s：避免单个脚本长期占用资源
重启服务并验证版本
修改完成后，重启 PHP-FPM 和对应的 Web 服务器：
sudo systemctl restart php-fpm
sudo systemctl restart httpd # Apache
# sudo systemctl restart nginx # Nginx最后用下面的命令确认 PHP 是否已经正确安装：
php -v性能优化：把可用配置真正用起来
PHP 环境能跑起来之后，接下来就该处理解析开销、并发承载和 Web 服务器集成效率。实际优化里，OPcache 和 PHP-FPM 往往是最先见效的两项。
启用 OPcache
OPcache 会缓存编译后的 PHP 脚本，减少重复解析和编译的开销，是生产环境里最基础也最有效的优化手段之一。可在 /etc/php.ini 中加入：
[opcache]
zend_extension=opcache.so
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60其中：
opcache.memory_consumption表示缓存大小，单位 MB，需要按服务器内存调整opcache.revalidate_freq表示脚本重新验证时间，单位秒，数值过小会增加文件检查频率
按负载微调 PHP-FPM
如果业务已经有实际访问量，就不要只停留在默认值。文中给出的一个参考是：服务器内存为 2GB 时，pm.max_children 可以设为 50-60，pm.start_servers 设为 10，以避免子进程过多把机器拖垮。
这类参数没有放之四海而皆准的固定答案，核心是结合内存占用和并发峰值去算，而不是只看网上的模板配置。
Nginx 和 Apache 应该怎样接入 PHP
PHP 本身调优之后，还要确认 Web 服务器和 PHP-FPM 的连接路径正确。Nginx 与 Apache 的接入方式不同，配置也不能混用。
Nginx 的 PHP 处理配置
如果使用 Nginx，可在 server 块中加入以下配置，让请求通过 fastcgi_pass 转到 PHP-FPM 的 socket 或端口：
location ~ .php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php-fpm/www.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}这里最关键的是 fastcgi_pass 指向要和 PHP-FPM 实际监听方式一致，否则 PHP 请求会直接返回错误。
Apache 的 mod_proxy_fcgi 配置
如果使用 Apache，则通常依赖 mod_proxy_fcgi，可在 VirtualHost 中加入：
SetHandler "proxy:fcgi://unix:/run/php-fpm/www.sock|fcgi://localhost"
只要 Apache、PHP-FPM 和 socket 路径保持一致，这种方式可以较稳定地把 PHP 请求转交给 FPM 处理。
缓存与监控：优化不是一次性工作
除了 OPcache，还可以继续引入 Redis 或 Memcached 来缓存数据库查询结果，例如给 WordPress 做对象缓存。这类缓存能直接减少数据库压力，对页面响应时间改善通常很明显。
同时，线上配置需要持续监控。可使用 top、htop、vmstat 等工具观察 CPU、内存和磁盘 IO，再据此回头调整 pm.max_children、pm.start_servers、opcache.memory_consumption 等参数。
CentOS 上的 PHP 优化没有一组永远正确的万能配置。更实际的做法是：先根据项目选对版本，完成基础参数设置，再结合访问特征和资源使用情况逐步修正。
