PHP 8.0 启动失败主因是配置文件缺失或扩展ABI不兼容：status=78表明php-fpm.conf丢失；扩展如redis.so需匹配ABI 20200930，否则静默失效；解析错误（如assert变更、类型语法）会中断加载且无日志。
PHP 8.0 无法启动，90% 的情况不是“没装好”，而是错误被静默吞掉——你根本看不到报错，只看到服务起不来、页面空白、systemctl status php8.0-fpm 显示 status=78 或直接 exit。必须绕过显示层，直奔日志源头。
确认 PHP 8.0 错误日志是否真正启用
很多人以为改了 php.ini 就完事，其实 log_errors = On 只是开关，后面三件事缺一不可：
-
error_log路径必须存在且 Web 服务用户（如www-data或nginx）有写权限；否则日志文件创建失败，错误就彻底消失 -
log_errors_max_len不能为 0？错——设为 0 才表示不限长度，避免长错误被截断；设成 1024 反而可能丢掉关键堆栈 - PHP-FPM 场景下，
php.ini的error_log仅影响脚本运行时错误；FPM 自身启动失败（如配置缺失、扩展 ABI 不匹配）会写入/var/log/php8.0-fpm.log，而不是php.ini指定的路径
快速定位 FPM 启动失败的真实原因（status=78）
status=78 是 PHP-FPM 内部错误码，专指“无法加载主配置”。它和端口、权限、扩展都没关系，就是 /etc/php/8.0/fpm/php-fpm.conf 文件丢失或为空。
- 执行
ls -l /etc/php/8.0/fpm/php-fpm.conf，若提示 “No such file or directory”，就是它 - 别用
cp从 PHP 7.4 复制同名文件——ABI 不兼容，FPM 进程会静默崩溃 - 安全补全方式：用
wget下载社区验证过的最小可用配置（如 gist 上php-fpm.conf），mv过去后必须systemctl restart php8.0-fpm
检查扩展是否真加载，而非“名字在列表里”
php -m | grep redis 看到 redis 并不等于 new Redis() 能用。PHP 8.0 的 ABI ID 是 20200930，旧版 redis.so 二进制不兼容，类注册会失败。
立即学习“PHP免费学习笔记（深入）”；
- 运行
php --ri redis，如果输出里没有Redis => enabled和类列表（如Redis, RedisArray...），说明扩展没真正初始化 - 检查真实 so 文件路径：
/www/server/php/80/lib/php/extensions/no-debug-non-zts-20200930/redis.so（宝塔）或/usr/lib/php/20200930/redis.so（Ubuntu） - 用
file redis.so确认架构匹配；用ldd redis.so | grep "not found"查依赖缺失
解析阶段错误（Parse error）为什么没行号？
PHP 8.0 解析器更严格，遇到语法硬伤（如命名参数位置错、联合类型写在 7.4 环境、尾逗号缺失）会直接中断，连 error_log 都来不及写完整信息。
- 用
find /var/www -name "*.php" -exec php -l {} \; 2>&1 | grep "Parse error"扫描全部文件，定位具体出错文件 - 重点盯
function定义里的默认值顺序、match表达式括号闭合、以及任何含|符号的类型声明（如string|int）——这些在 7.4 是非法，在 8.0 是合法但需确保上下文支持 - 临时在疑似文件顶部加
error_log("HERE", 0)，看日志是否写入；没写入，说明卡在解析阶段，不是执行阶段
最常被忽略的一点：PHP 8.0 的 assert() 默认行为变更不是警告，是解析期致命错误。哪怕一行 assert('is_array($x)'); 都会让整个文件加载失败，且不报具体位置——必须用 php -l 逐个扫。
