OPcache在网页中真正生效需三步确认：一是浏览器访问phpinfo()页面，核对Loaded Configuration File路径并确保Opcode Caching显示Enabled且opcache.enable为On；二是调用opcache_get_status()不报错；三是确认zend_extension=opcache.so（Linux/macOS）或带引号的绝对DLL路径（Windows）已正确配置，且重启了对应PHP-FPM服务而非仅Web服务器。
PHP 8.2 的 OPcache 不是“开了就快”，而是必须确认它真正在 Web 请求中加载、参数匹配项目规模、且时间戳策略不导致功能故障——否则你看到的可能是白屏、Class not found 或 TTFB 反而升高。
怎么确认 OPcache 在网页里真正生效了
命令行 php -m | grep opcache 成功 ≠ 网页请求用了 OPcache。关键看浏览器访问 info.php（内容为 <?php phpinfo(); ?>）后：
- 搜索
Loaded Configuration File，记下路径——后面所有修改都得改这个文件 - 页面里必须出现
Opcode Caching区块，且状态是Enabled - 旁边
opcache.enable显示On；如果搜不到该区块，或调用opcache_get_status()报Call to undefined function opcache_get_status()，说明扩展根本没进 PHP-FPM 进程
Windows 和 Linux 的 zend_extension 路径写法不能混用
写错这一行，整个 OPcache 就静默失效：
- Linux/macOS 必须用
zend_extension=opcache.so，不能写extension=opcache.so - Windows 必须用绝对路径 + DLL 文件名：
zend_extension="C:\phpenv\versions\8.2.12\ext\php_opcache.dll"，引号不能少，路径必须真实存在 - phpEnv 用户常误点 GUI “启用扩展”，但那不改 ini；要执行
php -r "echo extension_dir;"确认php_opcache.dll是否在输出目录下
opcache.validate_timestamps=0 是生产环境最大雷区
设成 0 不是“更省事”，而是把代码更新和缓存刷新完全解耦——上线后页面不刷新、类找不到、路由 404 全由此引发：
立即学习“PHP免费学习笔记（深入）”；
- 开发环境必须设为
opcache.validate_timestamps=1+opcache.revalidate_freq=2 - 生产环境可设为
1+opcache.revalidate_freq=60（每分钟检查一次），比0更安全 - 若用容器或只读文件系统必须关时间戳验证，则发布后必须执行
php -r 'opcache_reset();'，不能只 reload PHP-FPM
memory_consumption 和 max_accelerated_files 设太小反而拖慢
默认值 opcache.memory_consumption=64 和 opcache.max_accelerated_files=10000 在 Composer 项目里极易触发缓存踢出，CPU 升高、响应抖动：
-
opcache.memory_consumption建议从256起（单位 MB），Laravel/Symfony 项目直接设512 -
opcache.max_accelerated_files别硬套 10000，用find /var/www/html -name "*.php" | wc -l统计真实数量，再向上取最近质数（如32531） - 搭配
opcache.interned_strings_buffer=64（生产）能进一步减少内存碎片
最易被忽略的一点：改完 php.ini 后，只重启 Nginx 或 Apache 完全无效；必须 systemctl restart php82-fpm（或对应版本服务），且要确认 PHP-FPM 进程确实重新加载了那个 Loaded Configuration File 路径下的配置。
