php框架部署后页面响应慢、cpu占用高，很可能是opcache看似开启实则未真正生效——需依次确认扩展加载、cli/fpm配置同步、缓存写入内存、排除假生效陷阱，并用真实请求验证命中率。
PHP框架部署后页面响应慢、CPU占用高，很可能是OPcache看似开启实则未真正生效——它可能被禁用、配置错位、服务未重启，或缓存根本没写入内存。
第一步：确认OPcache扩展已加载
先排除最基础的“没装上”问题。执行命令：php -m | grep opcache，终端输出opcache才说明扩展已加载；若无任何输出，说明扩展未启用或根本未安装。
注意：有些环境（如Docker镜像）默认不启用OPcache，即使PHP版本≥5.5也需手动开启zend_extension。
第二步：检查Web与CLI两套配置是否分离
Web请求走PHP-FPM或mod_php，而命令行php -v或php -m走CLI模式——两者使用不同php.ini文件。
执行php --ini查看CLI配置路径，访问phpinfo()页面看Loaded Configuration File，对比二者是否一致。若不一致，你在CLI下改的php.ini对Web毫无影响。
【必须同步修改两处php.ini】：FPM模式下，/etc/php/8.2/fpm/php.ini 和 /etc/php/8.2/cli/php.ini 都要确保opcache.enable=1且zend_extension=opcache.so未被注释。
第三步：验证缓存是否实际写入内存
方法一：调用状态函数直接查内存使用
新建一个opcheck.php，内容为：<?php var_dump(opcache_get_status()['memory_usage']['used_memory'] > 0); ?>，通过浏览器访问。返回bool(true)才表示缓存正在写入，而非空转。
方法二：观察opcode命中率
在同个opcheck.php中追加：echo "hits: " . opcache_get_status()['opcache_statistics']['hits'];，刷新页面多次，如果数值持续增长，说明缓存确实在复用；若始终为0，说明所有请求都绕过了缓存。
第四步：排查常见“假生效”陷阱
① 修改php.ini后只reload nginx/apache，却没重启PHP-FPM——【必须systemctl restart php8.2-fpm】，否则新配置完全不加载。
② 生产环境误设opcache.validate_timestamps=1且opcache.revalidate_freq=0，导致每请求都stat()文件，I/O飙升反而拖慢整体性能。
③ Composer autoload生成的vendor/autoload.php被频繁重载，但opcache.max_accelerated_files仍用默认4000——Laravel项目轻易超1万文件，缓存池打满后旧opcode被踢出，命中率暴跌。
执行find ./vendor -name "*.php" | wc -l，结果若＞4000，立即调高该参数并重启服务。
第五步：用真实请求触发并观测
第一步：访问一个典型控制器路由（如Laravel的/api/user），确保该脚本被至少执行一次。
第二步：立刻执行php -r "print_r(opcache_get_status()['scripts']);"，输出中应出现该脚本的绝对路径及timestamp、memory_consumption等字段——没有就说明没进缓存。
第三步：再次访问同一URL，然后运行php -r "print_r(opcache_get_status()['opcache_statistics']);"，检查hits是否比上次+1，misses未增加。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
