OPcache未生效主因是opcache.enable或opcache.enable_cli为Off，需分别在Web和CLI的php.ini中设为1并重启服务；缓存调优需增大memory_consumption、关闭validate_timestamps；OPcache与APCu可共存，前者缓字节码，后者缓用户数据；TTFB高常因I/O或扩展冲突，非缓存本身问题。
OPcache 开启后为什么没生效？
常见现象是 phpinfo() 里显示 OPcache 已加载，但 opcache.enable 或 opcache.enable_cli 实际为 Off，导致脚本仍每次编译。PHP-FPM 和 CLI 的配置是分离的，Web 请求走 php.ini，而命令行调试常被忽略。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 检查实际生效的配置路径：运行
php --ini（CLI）和phpinfo()中 “Loaded Configuration File”（Web），确认两者是否指向同一文件 - 必须显式开启：在对应
php.ini中设opcache.enable=1；若需 CLI 下验证缓存行为（如跑单元测试），额外加opcache.enable_cli=1 - 重启服务：修改后务必重启
php-fpm或 Web 服务器（Apache 的mod_php需重启 httpd） - 验证是否命中：访问脚本中加入
var_dump(opcache_get_status()['opcache_enabled']);，或用opcache_get_status()['scripts']查看已缓存的文件列表
OPcache 缓存大小和过期策略怎么调？
默认 opcache.memory_consumption=64（MB）对中等规模项目往往不够，频繁出现 Cache full 导致缓存抖动；而 opcache.revalidate_freq=2（秒）会让开发环境反复校验文件修改时间，抵消加速效果。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 生产环境建议设
opcache.memory_consumption=128或更高，用opcache_get_status()['memory_usage']观察峰值占用 - 关闭运行时校验：设
opcache.validate_timestamps=0（上线后），配合部署时执行opcache_reset()或systemctl reload php-fpm - 避免全量失效：不推荐设
opcache.max_accelerated_files过低（默认 4000）， Composer 自动加载类多时易冲突，建议调至20000 - 注意
opcache.fast_shutdown=1可减少内存释放开销，但 PHP 7.4+ 已默认启用，旧版本可手动打开
APCu 和 OPcache 能一起用吗？怎么分工？
能，而且推荐。OPcache 只缓存 PHP 字节码，不处理用户数据；APCu 是用户态内存缓存，适合存 file_get_contents 结果、配置数组、查询结果等。两者无冲突，但共用共享内存段时需注意资源分配。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- APCu 不要替代 OPcache：不要试图用
apcu_store('code', $php_code); eval(apcu_fetch('code'))—— 这绕过 OPcache，且不安全 - 典型用法：缓存解析后的 YAML/JSON 配置（
apcu_fetch('config_app')比重复json_decode(file_get_contents('config.json'))快 3–5 倍） - 设置 TTL：APCu 的
$ttl参数别设太长（如 0 表示永不过期），否则配置更新后需手动apcu_clear_cache()，线上慎用 - 监控用量：通过
apcu_sma_info()查看内存碎片，若num_seg为 1 且seg_size接近memory_limit，说明 APCu 内存不足，需调大apc.shm_size
为什么开了 OPcache + APCu，首页 TTFB 还是高？
因为瓶颈可能根本不在 PHP 执行层。常见真实原因包括：MySQL 连接未复用（PDO 没开 PDO::ATTR_PERSISTENT）、模板引擎每次重编译 Twig 文件、或前端资源未启用 HTTP 缓存导致 PHP 被迫反复生成静态内容。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 先定位瓶颈：用
XHProf或Blackfire抓一次请求，看耗时大户是不是mysqli_query或filemtime调用，而不是include - OPcache 对 I/O 密集型无效：如果脚本 80% 时间花在读文件、查库、调 API，优化字节码缓存意义有限
- 检查是否误用：比如在循环里反复
include同一文件（应提前 require），或用eval()动态执行字符串（完全绕过 OPcache） - 留意扩展冲突：某些调试扩展（如
xdebug）在启用时会强制禁用 OPcache，检查php -m | grep -i xdebug，生产环境务必关闭
opcache.validate_timestamps=0 后若忘了部署时清缓存，就会跑旧代码；APCu 存了过期数据却没配好失效逻辑，问题更隐蔽。这些不是“开了就快”的开关，而是需要和部署流程、监控手段对齐的运维环节。 
