直接升级PHP 7.4到8.0可行但必须先验证兼容性并改造代码，否则因函数移除（如mysql_*、each）、类型收紧、扩展不兼容等将导致白屏或Fatal error。
直接升级 PHP 7.4 到 PHP 8.0 是可行的，但不能跳过兼容性验证和代码改造直接切换。PHP 8.0 移除了多个函数、收紧了类型检查、改变了错误级别（如未定义数组键从 Notice 升级为 Warning），未经处理的项目大概率会白屏或报致命错误。
先确认扩展与依赖是否支持 PHP 8.0
很多崩溃不是代码问题，而是底层扩展不兼容。PHP 8.0 要求扩展重新编译，旧版扩展加载即失败。
- 运行
php -m列出所有已启用扩展，重点核对：redis（需 ≥5.3.0）、mongodb（≥1.9.0）、gd（≥2.3.0）、opcache（必须启用且配置兼容） - 检查
composer.json中的"php": "^7.4"约束，改为"^8.0"；再执行composer check-platform-reqs，它会明确告诉你哪个包不支持 PHP 8.0 - 常见踩坑点：
laravel/framework需 ≥8.0，doctrine/dbal需 ≥3.0，monolog/monolog需 ≥2.0 —— 低于这些版本会直接拒绝安装
废弃函数必须手动替换，不能靠自动工具兜底
PHP 8.0 彻底移除了 each()、create_function()、mysql_connect() 等函数，调用即 Fatal error。静态分析工具（如 phpstan）能发现一部分，但仍有漏网之鱼。
-
each()：必须改用foreach，尤其注意循环中修改原数组时行为差异 -
create_function()：全部替换为匿名函数，例如$fn = function($x) { return $x * 2; }; -
assert()字符串参数被禁用：把assert('is_int($v)')改成assert(is_int($v))，否则直接报错 - 别忽略自定义函数里嵌套的废弃调用，比如你封装的
db_query()内部若用了mysql_*()，也得一并改掉
字符串和数组访问行为变更最容易漏测
PHP 8.0 把很多“容忍型”操作转为显式报错，本地开发常因错误报告级别低而错过，上线后才暴露。
立即学习“PHP免费学习笔记（深入）”；
-
$str[0]访问字符串首字符：PHP 7.4 允许，PHP 8.0 仍允许，但$str[100]（越界）会触发Warning: String offset cast occurred -
$arr['missing']访问未定义键：PHP 7.4 是Notice，PHP 8.0 升级为Warning，若error_reporting包含E_WARNING就会中断执行 - 修复方式统一：用
??或isset()替代裸访问，例如$val = $arr['key'] ?? null; - 特别注意模板引擎（如 Twig、Smarty）中传入的变量，它们可能在渲染时触发这类访问，需补全默认值逻辑
Web 服务与 CLI 的 PHP 版本必须分别配置
升级后 Apache/Nginx 和终端命令行（php、composer、artisan）很可能还在用旧版本，导致“明明装了 PHP 8.0，但 php -v 还是 7.4”。
- Web 侧：确认 Web Server 使用的是 PHP 8.0 的
php-fpmsocket（如/run/php/php8.0-fpm.sock），而非残留的 7.4 socket - CLI 侧：不要依赖系统
php命令，改用绝对路径，例如/usr/bin/php8.0或/opt/php80/bin/php；群晖用户需手动创建软链接或使用套件路径（如/var/packages/PHP8.0/target/usr/local/bin/php80） - 测试方法：在 Web 目录放一个
info.php（内容为<?php phpinfo(); ?>），浏览器访问；同时在终端执行/usr/bin/php8.0 -v，两个输出必须一致显示8.0.x
实际升级中最容易被忽略的，是框架底层对 PHP 8.0 新特性的隐式依赖 —— 比如 Laravel 8 引入了命名参数，但如果你项目里某个第三方 Service Provider 仍用 PHP 7.4 风格的反射调用，就会在容器解析时静默失败。务必在测试环境完整跑通登录、支付回调、文件上传等真实链路，不能只看首页能否打开。
