opcache 需通过改配置、查状态、处理缓存失效三步启用；验证需用 opcache_get_status() 确认 enabled 且 used_memory > 0，scripts 非空；invalidate 仅对已缓存文件有效，须绝对路径；compile_file 不执行脚本但预编译进内存；memory_consumption 和 max_accelerated_files 应按项目规模合理设置。
opcache 不是靠“学教程”启动的，而是靠改配置、看状态、处理缓存失效这三件事跑起来的。它默认在 PHP 5.5+ 就已内置，但多数生产环境根本没开，或者开了却配错参数，导致缓存不生效、脚本不更新、内存爆满。
怎么确认 opcache 真的在工作
别信 phpinfo() 里显示“enabled”，要验证实际缓存行为：
-
opcache_get_status()返回数组中opcache_enabled为 true，且memory_usage.used_memory> 0 才算真在用 - 如果
opcache_get_status()['scripts']是空数组，说明没缓存任何文件——常见原因是opcache.validate_timestamps=0且文件被修改过，或opcache.revalidate_freq设得太大（比如设成 600，10 分钟才检查一次） - CLI 下运行
php -d opcache.enable_cli=1 -r "var_dump(opcache_is_script_cached('test.php'));"可单独测试单个文件是否进缓存
opcache_invalidate 为什么调了没反应
这个函数只对「已加载并缓存」的脚本有效，不是万能刷新键：
- 必须传入绝对路径，相对路径、include_path 查找路径都不行；
opcache_invalidate(__FILE__)是安全写法 - 如果脚本从未被请求过（即没进过 opcode 缓存），
opcache_invalidate()返回 false，不报错也不提示 - 它只清当前进程看到的缓存项，PHP-FPM 多 worker 场景下，需配合
opcache_reset()或重启 FPM 才能全局清除 - 开发时频繁改代码，建议设
opcache.validate_timestamps=1+opcache.revalidate_freq=2，比手动调opcache_invalidate更可靠
opcache_compile_file 的真实用途和陷阱
它不是“预热缓存”的银弹，而是一个有明确副作用的底层操作：
- 执行后脚本立即编译进共享内存，但不会自动执行 —— 适合部署后提前加载核心类库，避免首请求卡顿
- 若文件含语法错误，
opcache_compile_file()会返回 false，且错误日志里可能只记 warning，不中断流程 - 多次调用同一文件不会重复编译，但会更新
last_used时间戳，影响 LRU 淘汰逻辑 - 它绕过
opcache.validate_timestamps判断，一旦编译成功，即使文件后续被删，只要缓存还在，仍可 serve（这点容易引发线上困惑）
内存不够用？先看 opcache.memory_consumption 和 max_accelerated_files
这两个参数配小了，缓存命中率直接掉到 20% 以下，比不开还糟：
立即学习“PHP免费学习笔记（深入）”；
-
opcache.memory_consumption=128对中小项目够用，但 Laravel/WordPress 类框架常需 256 或更高；用opcache_get_status()['memory_usage']观察used_memory / total_memory比值，持续 >90% 就得加 -
max_accelerated_files不是“最多缓存多少个”，而是哈希表桶数量，应设为项目实际 PHP 文件数的 1.5–2 倍；设太小会导致哈希冲突，大量文件挤在少数 slot 里，淘汰更频繁 -
interned_strings_buffer默认 8MB，如果项目大量用动态拼接字符串（如 JSON key、SQL 字段名），这里也容易吃紧，opcache_get_status()['interned_strings_usage']可查使用率
