前言装好了 PHP 8.1但就是不生效是一句有歧义的话。它可能指三种情况命令行的php -v还是旧版本浏览器里的phpinfo()还是旧版本或者版本号对了但某个新语法、某个扩展就是不能用。三者原因完全不同混在一起排查就是在原地打转。更麻烦的是PHP 的生效取决于四个互相独立的环节命令行的PATH顺序、Web 服务器指向的处理器Apache 的模块、Nginx 转发的 FastCGI 端口、IIS 的处理程序映射、php.ini的实际加载路径以及 OPcache 与正在跑的服务进程有没有重启。任何一环没对上别处做的努力都是白费。本文按先定位在哪一层 → 逐层排查的顺序讲并给出一个能一次打印出全部事实的探测脚本。PHP 8.1 带来的枚举enum、readonly属性、never返回类型、纯交叉类型等语法会在最后一节用来验证到底生效了没有。一、先把不生效拆成一个可以回答的问题先对着下面这张表定位你看到的现象属于哪一种答案就在对的列里。你在哪里看到的它反映的是什么排查入口php -vCLI 的 PHP由PATH决定where php/which -a phpphpinfo()页面Web 的 PHP由 Web 服务器处理器决定服务器配置 探测脚本composer报版本不满足CLI 的 PHPphp -v新语法报语法错误实际执行代码的那个 PHP上面的探测脚本扩展用不了比如enum_exists没定义加载的php.ini与extension_dirphp --ini/php -m把现象归到这几行里的任意一行后面的排查就变成逐条命令确认。二、探测脚本一次把全部事实打印出来先把这个脚本放到站点目录下访问一次它会把互相纠缠的事实分开打印。需要 PHP 7.0不依赖 8.1 语法可以在旧版本上跑起来做对比。?php declare(strict_types1); // probe.php —— 临时探测脚本用完删除 header(Content-Type: text/plain; charsetutf-8); echo 身份 , PHP_EOL; echo PHP_VERSION : , PHP_VERSION, PHP_EOL; echo PHP_SAPI : , PHP_SAPI, PHP_EOL; echo PHP_INT_SIZE : , PHP_INT_SIZE, 字节4 32 位8 64 位, PHP_EOL; echo PHP_EOL; echo ini 文件 , PHP_EOL; echo loaded ini : , (php_ini_loaded_file() ?: (none说明没加载任何 php.ini)), PHP_EOL; $scanned php_ini_scanned_files(); echo scanned ini : , ($scanned false || $scanned ? (none) : $scanned), PHP_EOL; echo extension_dir : , (ini_get(extension_dir) ?: (空)), PHP_EOL; echo open_basedir : , (ini_get(open_basedir) ?: (off)), PHP_EOL; echo PHP_EOL; echo OPcache 运行时状态 , PHP_EOL; if (function_exists(opcache_get_status) is_array($status opcache_get_status(false))) { echo opcache 已启用 : , (($status[opcache_enabled] ?? false) ? 是 : 否), PHP_EOL; echo 缓存的脚本数 : , (string) ($status[opcache_statistics][num_cached_scripts] ?? 未知), PHP_EOL; echo validate_timestamps : , ini_get(opcache.validate_timestamps), PHP_EOL; } else { echo opcache 未启用或扩展未加载, PHP_EOL; } echo PHP_EOL; echo 扩展 , PHP_EOL; $check [ pdo_mysql, mysqli, mbstring, curl, openssl, fileinfo, bcmath, dom, tokenizer, xml, zip, intl, gd, redis, ]; foreach ($check as $ext) { echo str_pad($ext, 30), : , (extension_loaded($ext) ? 已加载 : 未加载), PHP_EOL; } echo PHP_EOL; echo PHP 8.1 特性可用性 , PHP_EOL; // enum_exists() 是 PHP 8.1 新增的函数8.0 及以下不存在 echo enum_exists() : , (function_exists(enum_exists) ? 可用 8.1 : 不可用 8.1), PHP_EOL; echo array_is_list() : , (function_exists(array_is_list) ? 可用 8.1 : 不可用 8.1), PHP_EOL; echo Fiber 类 : , (class_exists(Fiber) ? 可用 8.1 : 不可用 8.1), PHP_EOL; echo fsync() : , (function_exists(fsync) ? 可用 8.1 : 不可用 8.1), PHP_EOL;访问方式建议用curl而不是浏览器绕开浏览器缓存和 CDN 的干扰curl -s http://blog.test/probe.php看三个地方就够了PHP_VERSION是不是 8.1、loaded ini是不是你改的那一份、PHP 8.1 特性可用性四行是不是都可用。三个都对说明这个 SAPI 上的 PHP 8.1 确实生效了。三、CLI 侧PATH 里到底有几个 php命令行不生效九成是PATH里躺着一个更靠前的旧版本。# Windows列出 PATH 中所有能命中的 php # 第一个就是最终被执行的 where php # Linux / macOS which -a php # 看真实版本和真实 ini php -v php --ini php -i | grep -i loaded configurationWindows 上常见的情况是同时装了 PhpStudy、XAMPP、WAMP或者用 Chocolatey 装过一个几个php.exe全在PATH里谁排前面谁赢。Linux 上用sudo update-alternatives --config php统一切换。这里有一条必须点明的分界线Composer 用的是 CLI 的 PHP。在面板里把站点切到 8.1而php -v还是 7.4composer install依然会按 7.4 去解析依赖。这两件事互不影响。要让命令行用的确定是 8.1最稳的不是去调PATH而是显式指定解释器D:/phpstudy_pro/Extensions/php/php8.1.27nts/php.exe -v # 用指定版本跑 Composer D:/phpstudy_pro/Extensions/php/php8.1.27nts/php.exe \ D:/phpstudy_pro/Extensions/composer/composer.phar install四、Web 侧三条技术路线各有各的检查点Web 侧的 PHP 由服务器怎么接上 PHP 决定三条路线的排查点完全不同。服务器接入方式排查命令常见症状Apache加载php8apache2_4.dll模块httpd -M \grep phpNginxfastcgi_pass转发到 PHP-FPM / php-cgi看配置端口 netstat502 Bad GatewayIISFastCGI 处理程序映射处理程序映射里的可执行文件路径404.3 / 500.0Apache用httpd -M列出已加载的模块看 PHP 那一行是不是你期望的版本对应的模块文件。这里有个容易踩的硬约束Apache 用的php8apache2_4.dll必须是Thread SafeTS构建且编译器版本和架构x64 / x86要和 Apache 本体匹配。用 NTS 构建的 DLL 配 Apache 模块Apache 会直接起不来而 FastCGI / CGI 方式则常用 NTS 构建。Nginx不直接加载 PHP它把请求转发给一个 FastCGI 进程。所以版本不生效在这里的正确表现是fastcgi_pass指向的端口后面跑的是旧版本的 PHP-FPM 或 php-cgi。# Linux看端口是谁在监听 netstat -tlnp | grep 9000 # Windows netstat -ano | findstr :9000 tasklist /FI PID eq 1234如果端口上跑的确实是旧版本要改的是谁的进程占着这个端口而不是php.ini。反过来如果端口根本没人监听症状是 502 而不是版本不对——这两个现象不要混为一谈。IIS的检查点在处理程序映射和FastCGI 设置里两者都要指向 8.1 目录下的可执行文件。只改一处会出现映射是新的、FastCGI 环境变量还是旧的这种半生效状态。五、php.ini到底加载了哪一个这是最容易被误判的一层。php -i输出里的Loaded Configuration File才是唯一事实别凭目录猜。现象含义处理Loaded Configuration File (none)没找到任何php.iniPHP 用内置默认值照样能跑但所有扩展都不会加载指向php.ini-development你改的是php.ini加载的却是另一份复制成php.ini或改PHPRCCLI 和 Web 指向不同文件两套环境各改各的分别确认别只改一个Scan this dir for additional .ini files是(none)额外的扩展配置目录没生效检查PHP_INI_SCAN_DIR(none)这一条尤其值得警惕PHP 在没有任何php.ini的情况下依然能正常启动、能执行脚本、能打印版本号只是所有扩展都是未加载状态。所以你会看到版本对了但pdo_mysql用不了这种看似矛盾的现象。# 交叉验证ini 路径 已加载扩展 有没有环境变量在覆盖 ini 位置 php --ini php -m set PHPRC # Windows echo $PHP_INI_SCAN_DIR # Linux / macOS六、扩展没生效extension_dir是关键改完php.ini打开了扩展重启后php -m里还是没有绝大多数情况是extension_dir指错了目录。; Windows 示例路径用正斜杠或双反斜杠 extension_dir D:/phpstudy_pro/Extensions/php/php8.1.27nts/ext extensionpdo_mysql extensionmbstring extensioncurl extensionopenssl排查顺序是php -i | grep extension_dir看实际值再去那个目录里看有没有对应的文件Windows 上是带php_前缀的php_pdo_mysql.dllLinux 上通常是pdo_mysql.so。目录里没有 装错了目录里有但没加载 配置行没生效。Linux 下用发行版包管理器装的 PHP扩展是独立的包要单独装。七、OPcache 与服务重启最容易被漏掉的一层前面几层都对页面还是老的那就是进程或缓存的问题。# Linux重启 FPM 与 Web 服务器 sudo systemctl restart php8.1-fpm sudo systemctl restart nginx # 或者只让 FPM 平滑重载不打断正在处理的请求 sudo kill -USR2 $(cat /run/php-fpm/php-fpm.pid)Windows 下通过面板或服务管理器重启。注意只重启 PHP 服务不够Nginx / Apache 也可能缓存了到后端的连接。OPcache 是另一条独立线索。它缓存的是编译后的字节码不是版本号所以它不会让版本切换失效但会让改了代码不生效; 开发环境务必这样设否则每次改代码都要重启 opcache.enable 1 opcache.validate_timestamps 1 opcache.revalidate_freq 0如果validate_timestamps是0PHP 永远不会去检查源文件有没有变改动要等到进程重启才生效——这会让人误以为换了 PHP 版本还是老行为。临时清一下缓存?php // 需要 PHP 5.5opcache_reset 自 PHP 5.5 起可用 if (function_exists(opcache_reset)) { var_dump(opcache_reset()); }实战用 8.1 的语法验证版本真的生效了版本号可以撒谎比如某个中间层做了替换语法不会。下面这段代码只使用 PHP 8.1 引入的特性在 8.0 及以下会因为语法错误或未定义函数直接失败。需要 PHP 8.1?php declare(strict_types1); // verify81.php —— 需要 PHP 8.1 // —— 1. 枚举enumPHP 8.1 新增 —— enum Status: string { case Draft draft; case Published published; case Archived archived; public function label(): string { return match ($this) { Status::Draft 草稿, Status::Published 已发布, Status::Archived 已归档, }; } } echo Status::Published-label(), PHP_EOL; // 已发布 echo Status::from(draft)-name, PHP_EOL; // Draft // —— 2. readonly 属性PHP 8.1 新增 —— final class Money { public function __construct( public readonly string $currency, public readonly int $amountInCents, ) { } } $price new Money(CNY, 1999); printf(%s %.2f\n, $price-currency, $price-amountInCents / 100); // CNY 19.99 // —— 3. never 返回类型PHP 8.1 新增 —— function fail(string $message): never { throw new RuntimeException($message); } // —— 4. 纯交叉类型pure intersection typePHP 8.1 新增 —— interface HasCount { public function count(): int; } interface HasLabel { public function label(): string; } // 参数必须同时满足两个接口注意这里只能是接口不能是类。 // 光是能声明出来就证明解析器接受了这套 8.1 语法。 function describe(HasCountHasLabel $value): string { return $value-label() . . $value-count() . 项; } // —— 5. array_is_list()PHP 8.1 新增 —— var_dump(array_is_list([1, 2, 3])); // true var_dump(array_is_list([1 a, 0 b])); // false // —— 6. 第一类可调用语法first-class callablePHP 8.1 新增 —— $lengths array_map(strlen(...), [a, bb, ccc]); print_r($lengths); // —— 7. new 出现在初始化器里PHP 8.1 新增 —— class NullLogger { public function __toString(): string { return NullLogger; } } // 默认参数值可以直接 new 一个对象PHP 8.1 之前只允许常量表达式 function makeLogger(object $logger new NullLogger()): string { return (string) $logger; } echo makeLogger(), PHP_EOL; // NullLogger echo PHP , PHP_VERSION, 的 8.1 特性全部可用, PHP_EOL;这个脚本能跑通说明执行它的那个 PHP 确实在 8.1 或更高版本上没有中间层在骗你。常见坑点坑 1php.ini在 Windows 上其实是php.ini.txt❌ 记事本保存时另存为文本文件文件名变成php.ini.txt资源管理器默认隐藏扩展名看起来完全正常✅ 打开显示文件扩展名确认或者直接看 PHP 怎么说的php --ini php -i | grep -i loaded configuration如果输出是(none)而你坚信自己改过php.ini八成就是这个原因。坑 2改的是php.ini-development或php.ini-production❌ 目录里有三个文件编辑了php.ini-development重启后毫无变化✅ 先php --ini看实际加载的是哪个文件名再改那一个坑 3Loaded Configuration File是(none)但 PHP 照样跑❌ 看到php -v能输出、脚本能执行就认为配置没问题✅ 没有php.ini时 PHP 用内置默认值运行所有扩展都不加载。php -m里缺东西就要查这里坑 4Apache 用了 NTS 构建的 DLL❌ 把php8apache2_4.dll配好Apache 启动失败或模块加载报错✅ Apache 模块方式必须用Thread SafeTS构建且架构x64 / x86和编译器版本要与 Apache 本体匹配。FastCGI 方式才常用 NTS坑 5Nginx 报 502却跑去改php.ini❌ 站点 502 Bad Gateway第一反应是去调 PHP 配置✅ 502 的含义是连不上后端进程。用netstat -tlnp | grep 9000确认fastcgi_pass指向的端口有没有进程在听坑 6只重启了 PHP 服务没重启 Web 服务器❌ 只重启 PHP-FPMNginx 仍然连着旧的 FastCGI 连接✅ Web 服务器和 PHP 服务一起重启或至少让 FPM 平滑重载坑 7CLI 与 Web 加载不同的php.ini只改了一个❌ 在命令行php -m里看到pdo_mysql已加载就以为站点也没问题✅ 两个 SAPI 各查一次用探测脚本在浏览器里再确认一遍总结排查层入口命令 / 位置关注点CLI 版本php -v、where phpPATH里第一个php是哪个Web 版本探测脚本 PHP_SAPIApache 模块 / Nginx FastCGI 端口 / IIS 映射ini 文件php --ini是不是(none)是不是你改的那份扩展php -m、extension_dir目录里有没有文件、配置行有没有写语法验证用 8.1 特性写的脚本枚举、readonly、never能否通过进程与缓存重启服务、opcache_get_status()有没有真重启validate_timestamps是不是 0排查不生效的核心方法是先定位再动手用探测脚本把版本、SAPI、ini 路径、扩展状态一次性打印出来问题会自己浮到水面上。最耗时间的做法是凭直觉改配置——改错文件、改错 SAPI、忘了重启这三种情况占了绝大多数。
PHP8.1安装后不生效怎么排查
前言装好了 PHP 8.1但就是不生效是一句有歧义的话。它可能指三种情况命令行的php -v还是旧版本浏览器里的phpinfo()还是旧版本或者版本号对了但某个新语法、某个扩展就是不能用。三者原因完全不同混在一起排查就是在原地打转。更麻烦的是PHP 的生效取决于四个互相独立的环节命令行的PATH顺序、Web 服务器指向的处理器Apache 的模块、Nginx 转发的 FastCGI 端口、IIS 的处理程序映射、php.ini的实际加载路径以及 OPcache 与正在跑的服务进程有没有重启。任何一环没对上别处做的努力都是白费。本文按先定位在哪一层 → 逐层排查的顺序讲并给出一个能一次打印出全部事实的探测脚本。PHP 8.1 带来的枚举enum、readonly属性、never返回类型、纯交叉类型等语法会在最后一节用来验证到底生效了没有。一、先把不生效拆成一个可以回答的问题先对着下面这张表定位你看到的现象属于哪一种答案就在对的列里。你在哪里看到的它反映的是什么排查入口php -vCLI 的 PHP由PATH决定where php/which -a phpphpinfo()页面Web 的 PHP由 Web 服务器处理器决定服务器配置 探测脚本composer报版本不满足CLI 的 PHPphp -v新语法报语法错误实际执行代码的那个 PHP上面的探测脚本扩展用不了比如enum_exists没定义加载的php.ini与extension_dirphp --ini/php -m把现象归到这几行里的任意一行后面的排查就变成逐条命令确认。二、探测脚本一次把全部事实打印出来先把这个脚本放到站点目录下访问一次它会把互相纠缠的事实分开打印。需要 PHP 7.0不依赖 8.1 语法可以在旧版本上跑起来做对比。?php declare(strict_types1); // probe.php —— 临时探测脚本用完删除 header(Content-Type: text/plain; charsetutf-8); echo 身份 , PHP_EOL; echo PHP_VERSION : , PHP_VERSION, PHP_EOL; echo PHP_SAPI : , PHP_SAPI, PHP_EOL; echo PHP_INT_SIZE : , PHP_INT_SIZE, 字节4 32 位8 64 位, PHP_EOL; echo PHP_EOL; echo ini 文件 , PHP_EOL; echo loaded ini : , (php_ini_loaded_file() ?: (none说明没加载任何 php.ini)), PHP_EOL; $scanned php_ini_scanned_files(); echo scanned ini : , ($scanned false || $scanned ? (none) : $scanned), PHP_EOL; echo extension_dir : , (ini_get(extension_dir) ?: (空)), PHP_EOL; echo open_basedir : , (ini_get(open_basedir) ?: (off)), PHP_EOL; echo PHP_EOL; echo OPcache 运行时状态 , PHP_EOL; if (function_exists(opcache_get_status) is_array($status opcache_get_status(false))) { echo opcache 已启用 : , (($status[opcache_enabled] ?? false) ? 是 : 否), PHP_EOL; echo 缓存的脚本数 : , (string) ($status[opcache_statistics][num_cached_scripts] ?? 未知), PHP_EOL; echo validate_timestamps : , ini_get(opcache.validate_timestamps), PHP_EOL; } else { echo opcache 未启用或扩展未加载, PHP_EOL; } echo PHP_EOL; echo 扩展 , PHP_EOL; $check [ pdo_mysql, mysqli, mbstring, curl, openssl, fileinfo, bcmath, dom, tokenizer, xml, zip, intl, gd, redis, ]; foreach ($check as $ext) { echo str_pad($ext, 30), : , (extension_loaded($ext) ? 已加载 : 未加载), PHP_EOL; } echo PHP_EOL; echo PHP 8.1 特性可用性 , PHP_EOL; // enum_exists() 是 PHP 8.1 新增的函数8.0 及以下不存在 echo enum_exists() : , (function_exists(enum_exists) ? 可用 8.1 : 不可用 8.1), PHP_EOL; echo array_is_list() : , (function_exists(array_is_list) ? 可用 8.1 : 不可用 8.1), PHP_EOL; echo Fiber 类 : , (class_exists(Fiber) ? 可用 8.1 : 不可用 8.1), PHP_EOL; echo fsync() : , (function_exists(fsync) ? 可用 8.1 : 不可用 8.1), PHP_EOL;访问方式建议用curl而不是浏览器绕开浏览器缓存和 CDN 的干扰curl -s http://blog.test/probe.php看三个地方就够了PHP_VERSION是不是 8.1、loaded ini是不是你改的那一份、PHP 8.1 特性可用性四行是不是都可用。三个都对说明这个 SAPI 上的 PHP 8.1 确实生效了。三、CLI 侧PATH 里到底有几个 php命令行不生效九成是PATH里躺着一个更靠前的旧版本。# Windows列出 PATH 中所有能命中的 php # 第一个就是最终被执行的 where php # Linux / macOS which -a php # 看真实版本和真实 ini php -v php --ini php -i | grep -i loaded configurationWindows 上常见的情况是同时装了 PhpStudy、XAMPP、WAMP或者用 Chocolatey 装过一个几个php.exe全在PATH里谁排前面谁赢。Linux 上用sudo update-alternatives --config php统一切换。这里有一条必须点明的分界线Composer 用的是 CLI 的 PHP。在面板里把站点切到 8.1而php -v还是 7.4composer install依然会按 7.4 去解析依赖。这两件事互不影响。要让命令行用的确定是 8.1最稳的不是去调PATH而是显式指定解释器D:/phpstudy_pro/Extensions/php/php8.1.27nts/php.exe -v # 用指定版本跑 Composer D:/phpstudy_pro/Extensions/php/php8.1.27nts/php.exe \ D:/phpstudy_pro/Extensions/composer/composer.phar install四、Web 侧三条技术路线各有各的检查点Web 侧的 PHP 由服务器怎么接上 PHP 决定三条路线的排查点完全不同。服务器接入方式排查命令常见症状Apache加载php8apache2_4.dll模块httpd -M \grep phpNginxfastcgi_pass转发到 PHP-FPM / php-cgi看配置端口 netstat502 Bad GatewayIISFastCGI 处理程序映射处理程序映射里的可执行文件路径404.3 / 500.0Apache用httpd -M列出已加载的模块看 PHP 那一行是不是你期望的版本对应的模块文件。这里有个容易踩的硬约束Apache 用的php8apache2_4.dll必须是Thread SafeTS构建且编译器版本和架构x64 / x86要和 Apache 本体匹配。用 NTS 构建的 DLL 配 Apache 模块Apache 会直接起不来而 FastCGI / CGI 方式则常用 NTS 构建。Nginx不直接加载 PHP它把请求转发给一个 FastCGI 进程。所以版本不生效在这里的正确表现是fastcgi_pass指向的端口后面跑的是旧版本的 PHP-FPM 或 php-cgi。# Linux看端口是谁在监听 netstat -tlnp | grep 9000 # Windows netstat -ano | findstr :9000 tasklist /FI PID eq 1234如果端口上跑的确实是旧版本要改的是谁的进程占着这个端口而不是php.ini。反过来如果端口根本没人监听症状是 502 而不是版本不对——这两个现象不要混为一谈。IIS的检查点在处理程序映射和FastCGI 设置里两者都要指向 8.1 目录下的可执行文件。只改一处会出现映射是新的、FastCGI 环境变量还是旧的这种半生效状态。五、php.ini到底加载了哪一个这是最容易被误判的一层。php -i输出里的Loaded Configuration File才是唯一事实别凭目录猜。现象含义处理Loaded Configuration File (none)没找到任何php.iniPHP 用内置默认值照样能跑但所有扩展都不会加载指向php.ini-development你改的是php.ini加载的却是另一份复制成php.ini或改PHPRCCLI 和 Web 指向不同文件两套环境各改各的分别确认别只改一个Scan this dir for additional .ini files是(none)额外的扩展配置目录没生效检查PHP_INI_SCAN_DIR(none)这一条尤其值得警惕PHP 在没有任何php.ini的情况下依然能正常启动、能执行脚本、能打印版本号只是所有扩展都是未加载状态。所以你会看到版本对了但pdo_mysql用不了这种看似矛盾的现象。# 交叉验证ini 路径 已加载扩展 有没有环境变量在覆盖 ini 位置 php --ini php -m set PHPRC # Windows echo $PHP_INI_SCAN_DIR # Linux / macOS六、扩展没生效extension_dir是关键改完php.ini打开了扩展重启后php -m里还是没有绝大多数情况是extension_dir指错了目录。; Windows 示例路径用正斜杠或双反斜杠 extension_dir D:/phpstudy_pro/Extensions/php/php8.1.27nts/ext extensionpdo_mysql extensionmbstring extensioncurl extensionopenssl排查顺序是php -i | grep extension_dir看实际值再去那个目录里看有没有对应的文件Windows 上是带php_前缀的php_pdo_mysql.dllLinux 上通常是pdo_mysql.so。目录里没有 装错了目录里有但没加载 配置行没生效。Linux 下用发行版包管理器装的 PHP扩展是独立的包要单独装。七、OPcache 与服务重启最容易被漏掉的一层前面几层都对页面还是老的那就是进程或缓存的问题。# Linux重启 FPM 与 Web 服务器 sudo systemctl restart php8.1-fpm sudo systemctl restart nginx # 或者只让 FPM 平滑重载不打断正在处理的请求 sudo kill -USR2 $(cat /run/php-fpm/php-fpm.pid)Windows 下通过面板或服务管理器重启。注意只重启 PHP 服务不够Nginx / Apache 也可能缓存了到后端的连接。OPcache 是另一条独立线索。它缓存的是编译后的字节码不是版本号所以它不会让版本切换失效但会让改了代码不生效; 开发环境务必这样设否则每次改代码都要重启 opcache.enable 1 opcache.validate_timestamps 1 opcache.revalidate_freq 0如果validate_timestamps是0PHP 永远不会去检查源文件有没有变改动要等到进程重启才生效——这会让人误以为换了 PHP 版本还是老行为。临时清一下缓存?php // 需要 PHP 5.5opcache_reset 自 PHP 5.5 起可用 if (function_exists(opcache_reset)) { var_dump(opcache_reset()); }实战用 8.1 的语法验证版本真的生效了版本号可以撒谎比如某个中间层做了替换语法不会。下面这段代码只使用 PHP 8.1 引入的特性在 8.0 及以下会因为语法错误或未定义函数直接失败。需要 PHP 8.1?php declare(strict_types1); // verify81.php —— 需要 PHP 8.1 // —— 1. 枚举enumPHP 8.1 新增 —— enum Status: string { case Draft draft; case Published published; case Archived archived; public function label(): string { return match ($this) { Status::Draft 草稿, Status::Published 已发布, Status::Archived 已归档, }; } } echo Status::Published-label(), PHP_EOL; // 已发布 echo Status::from(draft)-name, PHP_EOL; // Draft // —— 2. readonly 属性PHP 8.1 新增 —— final class Money { public function __construct( public readonly string $currency, public readonly int $amountInCents, ) { } } $price new Money(CNY, 1999); printf(%s %.2f\n, $price-currency, $price-amountInCents / 100); // CNY 19.99 // —— 3. never 返回类型PHP 8.1 新增 —— function fail(string $message): never { throw new RuntimeException($message); } // —— 4. 纯交叉类型pure intersection typePHP 8.1 新增 —— interface HasCount { public function count(): int; } interface HasLabel { public function label(): string; } // 参数必须同时满足两个接口注意这里只能是接口不能是类。 // 光是能声明出来就证明解析器接受了这套 8.1 语法。 function describe(HasCountHasLabel $value): string { return $value-label() . . $value-count() . 项; } // —— 5. array_is_list()PHP 8.1 新增 —— var_dump(array_is_list([1, 2, 3])); // true var_dump(array_is_list([1 a, 0 b])); // false // —— 6. 第一类可调用语法first-class callablePHP 8.1 新增 —— $lengths array_map(strlen(...), [a, bb, ccc]); print_r($lengths); // —— 7. new 出现在初始化器里PHP 8.1 新增 —— class NullLogger { public function __toString(): string { return NullLogger; } } // 默认参数值可以直接 new 一个对象PHP 8.1 之前只允许常量表达式 function makeLogger(object $logger new NullLogger()): string { return (string) $logger; } echo makeLogger(), PHP_EOL; // NullLogger echo PHP , PHP_VERSION, 的 8.1 特性全部可用, PHP_EOL;这个脚本能跑通说明执行它的那个 PHP 确实在 8.1 或更高版本上没有中间层在骗你。常见坑点坑 1php.ini在 Windows 上其实是php.ini.txt❌ 记事本保存时另存为文本文件文件名变成php.ini.txt资源管理器默认隐藏扩展名看起来完全正常✅ 打开显示文件扩展名确认或者直接看 PHP 怎么说的php --ini php -i | grep -i loaded configuration如果输出是(none)而你坚信自己改过php.ini八成就是这个原因。坑 2改的是php.ini-development或php.ini-production❌ 目录里有三个文件编辑了php.ini-development重启后毫无变化✅ 先php --ini看实际加载的是哪个文件名再改那一个坑 3Loaded Configuration File是(none)但 PHP 照样跑❌ 看到php -v能输出、脚本能执行就认为配置没问题✅ 没有php.ini时 PHP 用内置默认值运行所有扩展都不加载。php -m里缺东西就要查这里坑 4Apache 用了 NTS 构建的 DLL❌ 把php8apache2_4.dll配好Apache 启动失败或模块加载报错✅ Apache 模块方式必须用Thread SafeTS构建且架构x64 / x86和编译器版本要与 Apache 本体匹配。FastCGI 方式才常用 NTS坑 5Nginx 报 502却跑去改php.ini❌ 站点 502 Bad Gateway第一反应是去调 PHP 配置✅ 502 的含义是连不上后端进程。用netstat -tlnp | grep 9000确认fastcgi_pass指向的端口有没有进程在听坑 6只重启了 PHP 服务没重启 Web 服务器❌ 只重启 PHP-FPMNginx 仍然连着旧的 FastCGI 连接✅ Web 服务器和 PHP 服务一起重启或至少让 FPM 平滑重载坑 7CLI 与 Web 加载不同的php.ini只改了一个❌ 在命令行php -m里看到pdo_mysql已加载就以为站点也没问题✅ 两个 SAPI 各查一次用探测脚本在浏览器里再确认一遍总结排查层入口命令 / 位置关注点CLI 版本php -v、where phpPATH里第一个php是哪个Web 版本探测脚本 PHP_SAPIApache 模块 / Nginx FastCGI 端口 / IIS 映射ini 文件php --ini是不是(none)是不是你改的那份扩展php -m、extension_dir目录里有没有文件、配置行有没有写语法验证用 8.1 特性写的脚本枚举、readonly、never能否通过进程与缓存重启服务、opcache_get_status()有没有真重启validate_timestamps是不是 0排查不生效的核心方法是先定位再动手用探测脚本把版本、SAPI、ini 路径、扩展状态一次性打印出来问题会自己浮到水面上。最耗时间的做法是凭直觉改配置——改错文件、改错 SAPI、忘了重启这三种情况占了绝大多数。
