直接启用OPcache不等于性能提升，关键在参数协同、路径精准和验证到位；配置不当会引发缓存雪崩、内存浪费或更新失效，必须确认并加载Web环境真实php.ini，严格按系统差异启用扩展，合理设定核心参数，并上线前完成三项验证。
直接启用 OPcache 并不等于性能提升，关键在参数协同、路径精准和验证到位。配置不当反而可能引发缓存雪崩、内存浪费或更新失效。
确认并加载正确的配置文件
CLI 和 Web（PHP-FPM / Apache）使用两套独立的 php.ini，必须以 Web 请求为准：
- 在网站根目录建 info.php，内容为
<?php phpinfo(); ?> - 浏览器访问后搜索 Loaded Configuration File，记下真实路径（如
/etc/php/8.5/fpm/php.ini） - 别信宝塔/面板“一键启用”按钮——它不自动写入 ini；也别改错位置（比如改了 CLI 的配置却用在 FPM 上）
正确启用扩展（Linux/Windows有区别）
PHP 8.5.7 默认已编译 OPcache，但需显式加载，且写法严格：
- Linux/macOS：取消注释或添加
zend_extension=opcache.so，路径要匹配 Zend API 版本（可用php -v查看） - Windows（TS 版）：必须用绝对路径+英文引号+.dll，例如：
zend_extension="C:\phpenv\versions\8.5.7\ext\php_opcache.dll" - 切勿写
extension=opcache—— 在多数环境下无效
核心参数按项目规模设定
不是越大越好，而是要匹配实际文件量与框架特性：
立即学习“PHP免费学习笔记（深入）”；
-
opcache.memory_consumption：Laravel 中型项目设
384；ThinkPHP 轻量项目设192；Symfony 全栈项目至少512 -
opcache.max_accelerated_files：必须 ≥ 项目全部 PHP 文件数（含 vendor），建议设
65536或20000起步，避免哈希冲突导致缓存驱逐 -
opcache.interned_strings_buffer：设
16（单位 MB），对类名、方法名等高频字符串做池化，大型项目可提至32 - opcache.validate_timestamps=0：生产环境必须关闭文件时间戳检查，否则每请求都触发 I/O
-
opcache.revalidate_freq=0：配合上一条，表示永不自动检查——部署后必须立刻
opcache_reset()或重启 PHP-FPM - opcache.fast_shutdown=1：加速请求结束时的内存回收，降低高并发延迟
- opcache.enable_cli=1：命令行脚本（如 Artisan、Console 命令）也受益于缓存
上线前必须做的三件事
配置完不验证 = 白配：
- 执行
php -r "print_r(opcache_get_status()['memory_usage']);"，确认used_memory在增长，free_memory不长期低于总量 15% - 压测中持续调用
opcache_get_status()，确保cache_full === false，且命中率（opcache_get_status()['opcache_statistics']['hits']）稳定在 95% 以上 - 修改
validate_timestamps=0后，立即执行opcache_reset()或systemctl restart php8.5-fpm，否则旧缓存仍按老规则运行
