PHP 8.3部署必须分别验证CLI与Web（FPM）配置，因二者完全隔离；仅php -v显示8.3.x不代表Web环境就绪，需用php --ini、php-fpm -t、phpinfo()等确认各自php.ini路径、扩展加载及error_log等关键项。
php -v 显示 8.3.x 不代表配置就绪
很多团队看到 php -v 输出 8.3.x 就以为万事大吉，结果上线后白屏或报 500。根本原因是 CLI 和 Web SAPI（如 PHP-FPM）用的是两套独立配置，php -v 只反映 CLI 的版本和 php.ini 路径，完全不涉及 Nginx/Apache 实际加载的配置。
必须分别验证：
-
php --ini查 CLI 加载的php.ini路径； -
php-fpm -t+sudo systemctl status php8.3-fpm确认 FPM 进程正在运行； - 在 Web 根目录放
test.php：，访问它看“Loaded Configuration File”是否指向/etc/php/8.3/fpm/php.ini（Ubuntu/Debian）或对应路径； - 对比 CLI 和 Web 页面里 “PHP Version”、“Loaded Extensions” 是否一致——尤其
mbstring、pdo_mysql、opcache这三个必须都出现。
display_errors=Off 是硬性红线，不是可选项
哪怕框架设了 APP_DEBUG=false，只要 php.ini 里 display_errors = On，错误堆栈、绝对路径、数据库连接参数就会直接吐到浏览器里。攻击者不用登录就能拿到你服务器结构。
生产环境唯一安全做法是：
立即学习“PHP免费学习笔记（深入）”；
- 全局关闭：
display_errors = Off； - 显式指定日志路径：
error_log = /var/log/php8.3/error.log（确保目录存在且www-data可写）； - 禁用
expose_php = Off，避免响应头泄露X-Powered-By: PHP/8.3.12； - 别信
error_reporting = 0——它会让error_log()也失效，应设为E_ALL & ~E_NOTICE & ~E_DEPRECATED。
OPcache 必须开，但 validate_timestamps=0 有前提
opcache.enable = 1 是性能刚需，但 opcache.validate_timestamps = 0 只适用于代码不热更的场景。如果你用 Git 钩子自动部署，改完代码却没清缓存，用户会看到旧逻辑。
两种安全做法：
- 纯手动发布（上传 zip 后重启 FPM）→ 设
opcache.validate_timestamps = 0； - 自动化部署（Git hook +
git pull）→ 必须设opcache.validate_timestamps = 1，并配opcache.revalidate_freq = 2（每 2 秒检查一次文件变更）； - 无论哪种，都要确认
opcache.memory_consumption≥ 128M，否则小项目都可能缓存溢出。
$_SERVER 变量异常？Nginx fastcgi_param 漏了关键项
PHP 8.3 对 $_SERVER 注入更严格，Nginx 默认 fastcgi_params 文件缺失两个映射，导致 $_SERVER['HTTPS'] 始终为空、$_SERVER['REQUEST_URI'] 多带查询参数。
必须在 location ~ \.php$ 块内显式补上：
-
fastcgi_param HTTPS $https if_not_empty;（识别反向代理后的 HTTPS）； -
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;（替代老旧的$document_root，否则软链项目如 Laravel public 目录会触发 open_basedir 拒绝）； - 别忘了
fastcgi_param PATH_INFO $fastcgi_path_info;，否则 Laravel 的路由参数解析会失败。
改完必须 sudo systemctl reload nginx，且 phpinfo() 页面里检查 $_SERVER 字段是否符合预期——这是最容易被忽略的调试盲区。
