宝塔面板中PHP 7.4的OPcache默认未启用，必须手动在Web用php.ini中设opcache.enable=1、配置memory_consumption=192、max_accelerated_files=7963等参数，重载php74-fpm服务，并通过phpinfo()和opcache_get_status()双重验证生效。
宝塔面板里 PHP 7.4 的 OPcache 默认是关的，只点“安装扩展”或“启用开关”不等于真正生效——必须确认 opcache.enable=1 写在正确的 php.ini 里，并让 PHP-FPM 重载该配置。
怎么确认你改的是 Web 请求实际加载的 php.ini
很多人改完配置发现没用，是因为编辑了 CLI 模式下的 php.ini（比如 /etc/php/7.4/cli/php.ini），但网站走的是 PHP-FPM，用的是另一份（如 /www/server/php/74/etc/php.ini）。
- 新建一个
info.php文件，内容为<?php phpinfo(); ?>，用浏览器访问它 - 搜索
Loaded Configuration File，复制显示的完整路径 —— 这才是你要编辑的文件 - 打开该文件，搜索
[opcache]；若没有，就在文件末尾新增一行：[opcache] - 确保下面这行存在且未被注释：
zend_extension=opcache.so（不是extension=opcache.so）
PHP 7.4 必须设置的 OPcache 参数
宝塔后台“性能调整”页的默认值对 PHP 7.4 项目（尤其是 WordPress 或 ThinkPHP）太保守：max_accelerated_files=2000 容易打满，revalidate_freq=2 会频繁 stat 文件，拖慢响应。
-
opcache.enable=1（必须显式写，不能依赖默认） -
opcache.memory_consumption=192（小型站起步值，比默认 128 更稳） -
opcache.max_accelerated_files=7963（质数，减少哈希冲突；WordPress 插件多时建议 ≥10000） -
opcache.revalidate_freq=60（设为 0 会导致每次请求都检查文件时间戳，反而更慢） -
opcache.validate_timestamps=1（生产环境可设为 0，但必须配合部署时调用opcache_reset()，否则代码更新不生效） -
opcache.fast_shutdown=1和opcache.enable_cli=0（CLI 不开更安全，避免干扰命令行脚本）
改完配置后，重启什么才真正起作用
只点宝塔界面上的“保存”或只重启 Nginx，OPcache 依然不会加载进 PHP-FPM 进程。你必须让 PHP-FPM 完整重启，重新读取 ini 文件。
立即学习“PHP免费学习笔记（深入）”；
- 在宝塔中：PHP 设置页 → 右上角点击“重载配置”（它会自动执行
systemctl restart php74-fpm） - 手动操作：运行
sudo systemctl restart php74-fpm（注意服务名是php74-fpm，不是php-fpm或php74） - 验证是否生效：刷新
info.php页面，搜索Opcode Caching，状态必须是Enabled；再执行php -r "print_r(opcache_get_status());"，若报错Call to undefined function opcache_get_status()，说明扩展根本没加载成功
为什么开了 OPcache 还是慢？几个关键盲区
OPcache 生效 ≠ 性能就一定好。命中率低、内存不足、或与其他扩展冲突，都会让加速效果归零甚至倒退。
- 如果
opcache_get_status()['opcache_statistics']['opcache_hit_rate'] < 80%，优先调大max_accelerated_files，而不是盲目加内存 - 如果
oom_count > 0，说明共享内存真不够用了，此时才考虑提升memory_consumption；但 1G 内存服务器别设超过 192 - 禁用
xdebug：它和 OPcache 天然互斥，开启后 OPcache 缓存会被绕过 - 别忽略
file_cache_consistency_checks=0：PHP 7.4+ 支持磁盘文件缓存一致性校验，线上环境关掉能省一次 I/O
