opcache 默认未启用，需在 php.ini 中通过 zend_extension 和 opcache.enable=1 显式开启，并重启 web 服务及 php-fpm；验证需用 phpinfo() 或 php -m，且配置须写入 web sapi 对应的 php.ini 文件。
PHP 本地环境启用 OpCache 后，页面加载和脚本执行速度通常能提升 20%–50%，但前提是它真的被加载且生效——很多本地开发环境（如 XAMPP、WAMP、MAMP、或手动编译的 PHP）默认是关闭 OpCache 的，或者只在 CLI 模式下禁用，而 Web SAPI（如 Apache 或 PHP-FPM）未启用。
确认 PHP 是否已编译并支持 OpCache
OpCache 是 PHP 5.5+ 内置扩展，无需额外安装，但可能被编译时禁用（如某些 Linux 发行版精简包）或运行时未启用。先验证支持性：
- 执行
php -v，若输出含with Zend OPcache字样，说明已编译支持 - 若无，检查
php -m | grep opcache—— 无输出表示未启用，也可能是未加载 - 在 Web 环境中访问
phpinfo()页面，搜索opcache，看是否有 “Opcode Caching” 区块
启用 OpCache 的核心配置项（php.ini）
OpCache 不是“开个开关”就行，必须在 php.ini 中显式启用并合理设置关键参数，否则即使 extension 加载了，也可能处于 disabled 状态。重点配置如下：
zend_extension=opcache.so ; Linux/macOS 下路径可能为 /usr/lib/php/.../opcache.so；Windows 用 opcache.dll ; 注意：不是 extension=opcache.so，而是 zend_extension= opcache.enable=1 opcache.enable_cli=0 ; CLI 模式默认关掉（避免测试脚本误缓存） opcache.memory_consumption=128 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=4000 opcache.revalidate_freq=2 opcache.fast_shutdown=1 opcache.validate_timestamps=1 ; 开发时建议保持开启，否则改代码不生效
⚠️ 容易踩的坑：opcache.enable=1 必须写在 php.ini 全局配置里，不能仅靠 ini_set('opcache.enable', '1') 运行时开启——它无效。
立即学习“PHP免费学习笔记（深入）”；
Apache / Nginx + PHP-FPM 环境下的生效验证
修改 php.ini 后，必须重启 Web 服务才能让 OpCache 加载。常见误区：
- 只重启 Apache/Nginx，没重启 PHP-FPM 进程 → OpCache 不加载（尤其 PHP-FPM 独立运行时）
- 多个
php.ini文件共存（如/etc/php/8.2/apache2/php.ini和/etc/php/8.2/cli/php.ini），改错了文件 - 使用
php -i | grep 'Loaded Configuration File'确认当前 Web SAPI 实际加载的是哪个 ini 文件
验证是否生效：
<?php var_dump(opcache_get_status()); // 若返回 array 且 'opcache_enabled' => true，则已启用 // 若提示 Call to undefined function opcache_get_status()，说明扩展未加载或被禁用
开发阶段的关键取舍：validate_timestamps 和 revalidate_freq
本地开发最常遇到的问题是“改了 PHP 文件，刷新页面没变化”——这恰恰说明 OpCache 太“尽责”。解决方式不是关掉 OpCache，而是调低校验频率：
-
opcache.validate_timestamps=1：必须为 1，否则文件变更完全不检测 -
opcache.revalidate_freq=2：设为 2 秒，即最多延迟 2 秒感知文件改动（生产环境可设为 0 或 60+） - 部分 IDE（如 PHPStorm）配合“File Watchers”可触发
opcache_reset()，但不推荐日常使用，容易误清全量缓存
OpCache 的加速效果真实存在，但本地开发中最难把握的其实是“缓存可见性”——它不像 Redis 那样有明确的 key 清除命令，所有操作都依赖配置粒度和进程生命周期。别跳过 opcache_get_status() 的实时检查，这是唯一可信的判断依据。
