- 为什么需要 OPcache
PHP 是解释型语言，但它的执行并不是"读一行源码、执行一行"这么简单。一次请求中，PHP 引擎大致要经历下面几个阶段：
- 词法分析（Lexing）：把源码字符串切成 token；
- 语法分析（Parsing）：把 token 组织成抽象语法树（AST）；
- 编译（Compilation）：把 AST 编译成 Zend 虚拟机可执行的 opcode（字节码）；
- 执行（Execution）：Zend VM 逐条执行 opcode。
其中第 1～3 步与请求数据无关，只和源码文件内容有关。但在没有 OPcache 的情况下，每个请求、每个被 include 的文件都要重新做一遍词法分析、语法分析和编译。一个典型的 Laravel 项目单次请求可能加载几百个 PHP 文件，这部分开销相当可观。
OPcache 做的事情非常朴素：把编译好的 opcode 存进共享内存，下次请求直接复用，跳过前三步。
flowchart LR
A["PHP 源码文件"] --> B["词法分析 Lexing"]
B --> C["语法分析 Parsing"]
C --> D["编译 Compilation"]
D --> E["opcode 字节码"]
E --> F["Zend VM 执行"]
E -.->|"OPcache 写入"| G["共享内存 SHM"]
G -.->|"命中则直接读取"| F
- OPcache 提速的本质
2.1 省掉的是编译开销，不是执行开销
这是最容易误解的一点：OPcache 不会让业务逻辑变快。它缓存的是"编译产物"，不是"执行结果"。一段 for ($i = 0; $i < 1000000; $i++) 的循环，有没有 OPcache 都是一百万次迭代。
它真正省掉的是：
- 文件 I/O 与磁盘读取（部分场景下 opcode 直接从内存取）；
- 词法/语法分析的内存分配与字符串处理；
- 编译期的哈希表构建、常量折叠等操作。
2.2 收益与什么相关
| 影响因素 | 收益表现 |
|---|---|
| 文件数量多（框架、Composer 依赖多） | 收益大，因为每个文件都要编译 |
| 单文件代码量大 | 收益中等，编译成本随代码量增长 |
| 请求本身很轻（如静态接口） | 收益占比高，编译开销占比被放大 |
| 请求本身很重（大量 DB、外部 IO） | 收益占比低，编译开销被稀释 |
| 使用 opcache.file\_cache 持久化 | 冷启动/进程重启后仍能命中 |
经验值：在典型的框架类应用中，开启 OPcache 通常能带来 20%～50% 的吞吐提升，具体取决于应用的文件规模与请求特征。这个数字不是恒定值，压测时请以自己业务的 QPS / P99 为准。
2.3 与 JIT 的关系
PHP 8.0 引入的 JIT 建立在 OPcache 之上——没有 OPcache 就没有 JIT。但要注意：JIT 优化的是"执行阶段"的热点代码，而 OPcache 优化的是"编译阶段"。对 Web 请求这种短生命周期、IO 密集的场景，JIT 收益往往有限；对 CPU 密集的计算型任务收益更明显。两者是叠加关系，不是替代关系。
下面这张图对比了两者的作用阶段：
flowchart TD
subgraph P1["编译阶段（OPcache 优化）"]
A1["源码"] --> A2["Lexing / Parsing / Compilation"]
A2 --> A3["opcode"]
end
subgraph P2["执行阶段（JIT 优化）"]
A3 --> B1["Zend VM 解释执行"]
B1 --> B2{"是否热点代码"}
B2 -->|"是"| B3["JIT 编译为机器码"]
B2 -->|"否"| B1
B3 --> B4["直接执行机器码"]
end
A3 -.->|"缓存复用"| C["共享内存 SHM"]
C -.-> A3
- 关键配置项
OPcache 的配置全部在 php.ini 中，修改后需要 reload PHP-FPM（kill -USR2 或 systemctl reload php-fpm）才能生效。
3.1 开关与内存
; 是否启用 OPcache，生产环境必须为 1
opcache.enable=1
; CLI 环境下是否启用（调试脚本时通常关闭，避免缓存干扰）
opcache.enable_cli=0
; 共享内存段大小，单位 MB
opcache.memory_consumption=256
; 字符串驻留区大小，单位 MB（PHP 7 起独立于主内存段）
opcache.interned_strings_buffer=32
; 最多可缓存的脚本文件数量
opcache.max_accelerated_files=20000
memory_consumption 和 max_accelerated_files 是最容易配小的两项。文件数超限后，OPcache 会不断淘汰旧脚本，导致命中率下降。max_accelerated_files 的实际生效值会被向上取整到质数集合中的某个值，所以填 20000 和填 20001 效果可能一样。
估算文件数的一个办法：
find /path/to/project -name "*.php" | wc -l
再留出 30%～50% 的余量。
3.2 校验与失效相关
; 多久（秒）检查一次文件是否被修改，0 表示每个请求都检查
opcache.revalidate_freq=2
; 是否检查文件时间戳，0 表示完全不检查（性能最高，但改代码不生效）
opcache.validate_timestamps=1
; 文件修改时间戳的精度（秒），PHP 7.4+ 可用
opcache.file_update_protection=2
这三项是"性能 vs 生效速度"的核心权衡，下一节详细展开。
3.3 其他常用项
; 优化级别，默认即可，一般不需要改
opcache.optimization_level=0x7FFEBFFF
; 是否启用快速关闭，减少请求结束时的清理开销
opcache.fast_shutdown=1
; 文件缓存目录，进程重启后可从磁盘恢复 opcode
opcache.file_cache=/tmp/opcache
opcache.file_cache_only=0
; 记录命中统计，压测时打开，生产环境建议关闭
opcache.stats_enabled=0
- 失效机制：什么时候缓存会"不生效"
这是线上最容易踩坑的地方。OPcache 的失效分为几种情况，理解它们才能避免"改了代码没生效"。
4.1 时间戳校验失效
当 opcache.validate_timestamps=1 时，OPcache 会按 opcache.revalidate_freq 指定的间隔检查文件 mtime。也就是说：
revalidate_freq=2：文件修改后，最多 2 秒内新请求会重新编译；revalidate_freq=0：每个请求都检查，最实时，但每次都要 stat 文件；validate_timestamps=0：完全不检查，性能最高，但必须手动清缓存。
生产环境常见做法是 validate_timestamps=0 + 发布时清缓存，把 stat 开销也省掉。
4.2 手动清空缓存
# 方式一：reload PHP-FPM，共享内存会被重建
systemctl reload php-fpm
# 方式二：调用 opcache_reset()（需要在 Web 可访问的脚本中执行，注意安全）
curl https://example.com/opcache-reset.php
<?php
// opcache-reset.php —— 务必加访问控制，用完即删
if (($_SERVER['REMOTE_ADDR'] ?? '') !== '127.0.0.1') {
http_response_code(403);
exit;
}
opcache_reset();
echo 'opcache reset done';
注意：opcache_reset() 只清空当前进程所属的共享内存段。在多进程 FPM 下，它作用于整个共享内存，但如果开了 opcache.file_cache，磁盘缓存不会被清，需要手动删除目录。
4.3 内存不足导致的淘汰
当缓存脚本数超过 max_accelerated_files，或共享内存写满时，OPcache 会按策略淘汰旧条目。表现为：命中率上不去、opcache_get_status() 里 cache_full 为 true。
<?php
$status = opcache_get_status(false);
printf("命中率: %.2f%%\n", $status['opcache_statistics']['opcache_hit_rate']);
printf("已缓存脚本: %d / %d\n",
$status['opcache_statistics']['num_cached_scripts'],
$status['opcache_statistics']['max_cached_keys']
);
printf("内存已用: %.2f MB\n", $status['memory_usage']['used_memory'] / 1024 / 1024);
printf("是否写满: %s\n", $status['cache_full'] ? '是' : '否');
4.4 其他失效场景
- 文件被删除或重命名：旧条目会在校验时被标记失效；
include_path变化：同一文件可能被解析成不同路径，产生重复缓存；- 符号链接切换发布目录：如果
validate_timestamps=0，切换软链后必须清缓存，否则仍执行旧代码； opcache.file_update_protection：文件刚修改后的几秒内不缓存，避免缓存到写了一半的文件。
- 性能影响与调优建议
5.1 先看命中率
调优的第一步不是改参数，而是测量。核心指标是 opcache_hit_rate，健康值应在 99% 以上。如果明显偏低，优先排查：
max_accelerated_files是否太小；memory_consumption是否不足；- 是否存在大量动态生成、路径不固定的 PHP 文件（这类文件天然难命中）。
5.2 生产环境推荐配置
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.fast_shutdown=1
opcache.file_cache=/tmp/opcache
opcache.file_cache_only=0
配套要求：发布流程中必须包含清缓存步骤。否则 validate_timestamps=0 会让你改了代码却毫无反应，排查起来非常痛苦。
5.3 开发环境推荐配置
opcache.enable=1
opcache.validate_timestamps=1
opcache.revalidate_freq=0
opcache.max_accelerated_files=20000
开发环境保留时间戳校验，改代码立即生效，同时仍能享受大部分编译加速。
5.4 常见误区
- "开了 OPcache 就不用管内存"：内存不足会频繁淘汰，命中率暴跌，反而比不开更慢；
- "
validate_timestamps=0是万能优化"：它把正确性责任转移给了发布流程，没有配套清缓存机制就是灾难； - "OPcache 能优化慢 SQL"：完全无关，它只影响编译阶段；
- "CLI 也要开 OPcache"：常驻进程（如 Swoole、RoadRunner）有意义，一次性脚本基本无收益，反而干扰调试。
- 小结
OPcache 的原理可以一句话概括：把编译产物放进共享内存，让后续请求跳过词法分析、语法分析和编译。它提速的本质是省掉重复的编译开销，而不是加速业务逻辑执行。
配置上抓住三组关键项即可：
| 关注点 | 关键参数 |
|---|---|
| 容量是否够 | `memory_consumption`、`max_accelerated_files`、`interned_strings_buffer` |
| 何时失效 | `validate_timestamps`、`revalidate_freq`、`file_update_protection` |
| 是否持久化 | `file_cache`、`file_cache_only` |
失效机制的核心权衡是"实时性 vs 性能"：开发环境要实时，生产环境要性能，但必须用发布流程中的清缓存步骤来兜底。上线前先用 opcache_get_status() 看清命中率，再决定调哪个参数，比盲目抄配置可靠得多。
适合后端与运维在调优 PHP 服务时参考。文中对「实时性 vs 性能」的权衡和发布流程清缓存要求讲得很清楚，可据此排查命中率偏低、改代码不生效等问题。