centos 8 官方 appstream 仅提供已 eol 的 php 7.2，部署 php 8.1 必须启用 remi 仓库；因其提供完整签名 rpm 包、systemd 集成及持续更新，而默认 dnf install php 会强制安装过时且无安全支持的 7.2 版本。
CentOS 8 官方 AppStream 只提供 PHP 7.2（EOL 已超期），要部署 PHP 8.1 生产环境，必须用 Remi 存储库 —— 这是目前最稳定、更新及时、且被广泛验证的方案。
为什么不能直接 dnf install php
CentOS 8 的默认 php 模块锁定在 php:7.2，该版本已于 2020 年 11 月停止安全更新。运行 dnf install php 或不指定流（stream）会默认装上这个已废弃版本。即使你手动下载源码编译，也会缺失与系统服务（如 httpd、systemd）深度集成的模块和 SELinux 策略支持，运维成本陡增。
- AppStream 中没有
php:8.1模块（RHEL 8.6 才开始提供，而 CentOS 8 Stream 已于 2024 年底停止维护） -
dnf module list php输出里只有7.2和已弃用的7.3/7.4（若启用过旧 Remi） - 强行编译安装会导致
php-fpm无法被systemctl正确管理，日志、socket 权限、开机启动都容易出错
启用 Remi 并安装 PHP 8.1 的最小必要步骤
Remi 提供了完整、签名、与 CentOS 8 兼容的 PHP 8.1 RPM 包，包含 php-fpm、libphp、常用扩展及 systemd 单元文件。操作只需四步，全部使用 dnf，无需编译：
- 先装 EPEL：
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - 再装 Remi 发行包：
sudo dnf install https://rpms.remirepo.net/enterprise/remi-release-8.rpm - 启用 PHP 8.1 模块：
sudo dnf module enable php:remi-8.1 - 安装核心包：
sudo dnf install php php-cli php-common php-fpm php-mysqlnd php-opcache php-gd php-curl php-mbstring php-xml php-zip
注意：php:remi-8.1 是模块名，不是软件包名；执行 dnf module enable 后，后续 dnf install php 就会自动拉取 Remi 的 8.1 版本，而非系统默认的 7.2。
php-fpm 配置与 Web 服务器集成要点
PHP 8.1 + Remi 默认启用 php-fpm（推荐用于生产），而不是 Apache 的 libphp 模块。这意味着你必须让 Web 服务器（Nginx 或 Apache）通过 FastCGI 与之通信，不能靠 LoadModule php_module 直接加载。
- Nginx：确保
location ~ \.php$块中配置了fastcgi_pass 127.0.0.1:9000或unix:/run/php-fpm/www.sock，并检查/etc/php-fpm.d/www.conf中listen和listen.owner设置是否匹配 Nginx 用户（通常是nginx或apache） - Apache：需启用
proxy_fcgi和setenvif模块，用ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:9000/var/www/html/转发，而非传统AddHandler - SELinux：Remi 包已内置策略，但若自定义 socket 路径（如
/var/run/php-fpm/app.sock），需手动加规则：sudo semanage fcontext -a -t httpd_var_run_t "/var/run/php-fpm(/.*)?"，然后restorecon -Rv /var/run/php-fpm
容易忽略的三个硬性检查点
部署后常因以下三点导致 502/503 或白页，但错误日志里往往不直接提示：
-
php-fpm未启动或监听失败：运行sudo systemctl status php-fpm，确认 Active 是running；再用sudo ss -tlnp | grep ':9000\|php-fpm'查端口或 socket 是否就绪 -
opcache.enable_cli=0在php.ini中被误设为1：这会导致 CLI 模式下 opcache 强制开启，而某些部署脚本（如 Composer install）会因此报错；生产环境应保持默认0 - 时区未设：Remi 的
php.ini默认注释掉date.timezone，PHP 会警告“Unknown timezone”，影响date()、Carbon等行为；务必取消注释并设为真实值，例如date.timezone = "Asia/Shanghai"
这些不是“装完就能跑”的环节，而是上线前必须逐项核对的边界条件。尤其 php-fpm 的用户/组权限、socket 文件上下文、以及 opcache 的 CLI 行为，线上故障里近六成源于此三处之一。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
