1. 从一段 Hello World 说起echo 背后到底发生了什么先别急着跳过我知道你看到“echo ‘Hello’”这种例子就想划走。但如果你真的把 PHP 的执行链路追到最底层会发现一个尴尬的事实很多写了三五年 PHP 的人对 echo 的理解停留在“它能输出字符串”这个层面而完全不知道这句话在 PHP 内部经历了什么。我最早意识到这个问题是在一次排查线上接口耗时的时候。某个接口逻辑非常简单但压测的时候 QPS 就是上不去CPU 占用却不低。后来查了 opcache 命中率发现只有不到 40%。也就是说大部分请求都在重复做同一件事把 PHP 源码编译成 opcode然后再执行。而这个过程恰恰就是 echo “Hello” 这条看似人畜无害的语句在你每次请求时默默付出的代价。在这篇文章里我会沿着一条线走从最基础的 echo 语句开始看 PHP 如何把人类能读懂的代码翻译成机器能执行的指令然后引出 opcode 这个概念再把 OpCache 扩展的完整机制拆开揉碎。整个过程是我自己从半懂不懂到彻底通透的经历希望能帮你少走弯路。这篇文章适合这几类人写过 PHP 但从来没开过 opcache 的人开了 opcache 但只知道“开了更快”的人想知道 PHP 请求生命周期全貌的进阶学习者以及所有对 PHP 性能优化有执念的同行。先剧透一个结论echop 本身不是性能瓶颈真正浪费性能的是 PHP 每次请求都要把源码重新编译一遍。搞清楚这条链路你才能理解 opcache 存在的意义也才能在配置它的时候做到心中有数而不是照抄网上的模板。2. 从源码到执行PHP 的生命周期与 Opcode 的诞生2.1 PHP 请求的完整生命周期我们平时说“PHP 处理一个请求”这个说法其实很笼统。严格来说一次完整的 PHP 请求包含以下几个阶段读取 PHP 源码文件.php 文件从磁盘加载到内存词法分析Lexing把源码拆分成一个个 token也就是把echo Hello拆成echo、字符串Hello、分号;这些基础单元语法分析Parsing把这些 token 按照 PHP 的语法规则组装成抽象语法树AST编译Compilation把 AST 转换成底层的操作码opcode也就是 Zend 虚拟机能够识别的中间指令执行ExecutionZend 虚拟机逐条执行这些 opcode返回结果把执行结果输出到客户端然后释放所有资源。这里有个关键点对于传统的 PHP 运行模式比如 PHP-FPM以上 6 个阶段在每一次请求中都会完整执行一遍。也就是说哪怕你的代码完全没有变化每一次请求来了PHP 都要重新把源码读一遍、拆一遍、编译一遍、再执行一遍。你可以想象一下一个爆款页面同一份代码短时间被访问一万次那就是把同一段源码完整编译一万次。这就像每次做菜都要重新背一遍菜谱再开火而不是把菜谱记在脑子里。OpCache 干的事情就是把“背菜谱”这一步的结果缓存下来下次直接用。2.2 Opcode 到底是什么长什么样Opcode全称是 Operation Code中文叫操作码。它是 PHP 编译器生成的中间指令类似于 Java 的字节码或者 Python 的 .pyc 文件里存的东西。Zend 虚拟机实际执行的就是这一串 opcode而不是源码本身。我们用一条最简单的语句来演示。假设你有这样一行代码echo Hello;PHP 内部会把它编译成一条 opcode大致长这样line # * op fetch ext return operands --------------------------------------------------------------------------------- 1 0 ECHO Hello 1 1 RETURN 1是不是很简单ECHO这条 opcode 的职责就是把操作数也就是字符串Hello输出到输出缓冲区。但实际上如果你写的是echo $variable;编译出来的 opcode 会多一两个步骤比如先有ASSIGN或者从符号表读取变量的操作再执行ECHO。再举一个复杂点的例子。看这段代码$a 1; $b 2; echo $a $b;编译后的 opcode 大致是line # * op fetch ext return operands --------------------------------------------------------------------------------- 1 0 ASSIGN $a, 1 2 1 ASSIGN $b, 2 3 2 ADD ~0 $a, $b 3 ECHO ~0 4 RETURN 1看到没有$a $b这个表达式在编译阶段就变成了生成一个临时变量~0然后 ECHO 直接输出临时变量。这些细节在源码里根本看不到却真实地存在于每次请求中。当你的代码里有循环、条件判断、函数调用时opcode 会呈几何级数增长。一个简单的业务接口几百上千条 opcode 是非常正常的。2.3 每个阶段的性能消耗在哪既然我们聊优化就得知道瓶颈具体在哪个环节。我做过一个简单的基准测试一个只输出 “Hello World” 的脚本在完全关闭 OpCache 的情况下用 PHP 内建服务器跑压测对比开启 OpCache 之后的数据。结论很直观场景QPS每秒请求数说明关闭 OpCache约 1800每次请求都完整执行编译链路开启 OpCache约 5300只执行 opcode跳过编译阶段当然这个数字和你服务器的 CPU、PHP 版本都有关系但比例是可信的开启 OpCache 之后纯 PHP 脚本的吞吐量能提升接近 2~3 倍。如果你有 Laravel、ThinkPHP 这类大型框架提升会更夸张因为框架本身就有海量的类定义、函数定义需要编译。这里多说一句很多人习惯把 PHP 慢归咎于语言本身其实对 PHP 来说最大的性能杀手不是执行 opcode而是编译生成 opcode 的过程。这个逻辑越复杂的文件编译耗时越长OpCache 的价值也就越大。3. OpCache 登场它是怎么把 opcode 缓存下来的3.1 OpCache 的基本架构与缓存内容OpCache 是 PHP 官方推出的一个字节码缓存扩展从 PHP 5.5.0 开始默认内置。它的核心思想非常简单既然每次请求都要编译同一个文件那编译一次之后把结果放在共享内存里下次请求直接复用不就行了具体点说OpCache 缓存的是编译完成后的 opcode 数组以及随之相关的元数据比如文件路径和文件哈希用于识别文件是否被修改编译后的 opcode 指令序列类、函数、常量等符号表信息文件的时间戳、大小等用于校验的信息。当 PHP-FPM 收到一个请求时它会先拿到脚本的路径去 OpCache 的共享内存里查一下如果命中就直接取出编译好的 opcode 交给 Zend 虚拟机执行完全跳过词法分析、语法分析、编译三个阶段。如果没命中就走完整的编译流程然后把编译结果写入共享内存供后续请求使用。3.2 共享内存与加锁机制OpCache 的实现离不开共享内存。在 Linux 系统上它默认使用mmap内存映射来创建共享内存段配合信号量实现进程间同步。这里有一个很重要的背景PHP-FPM 是一个多进程模型一个 master 进程管理若干个 worker 进程。每个 worker 进程都是独立的如果 OpCache 把编译结果存在某个进程自己的内存里其他 worker 进程根本看不到。所以 OpCache 必须把数据放到所有 worker 进程都能访问的共享内存段里。多进程同时访问共享内存就必然涉及锁机制。OpCache 内部在读取缓存时用的是读写锁多个进程同时读没问题互不干扰一个进程在写入新的缓存条目时会加上写锁此时其他进程只能等待。这个锁的粒度直接影响了并发性能。如果你在高并发下观察过 OpCache 的行为可能会发现一个现象opcache.file_update_protection 等配置设置不当或者 opcache.validate_timestamps 开启但文件频繁变动时OpCache 的锁竞争会变严重反而拖慢性能。我们后面会专门讲排查方法。3.3 OpCache 命中率是什么怎么看OpCache 命中率Hit Rate是衡量 OpCache 工作状况的核心指标。它的含义是所有访问 PHP 文件的请求中有多少比例直接命中了缓存而不需要重新编译。可以通过opcache_get_status()函数查看。一个简单的测试脚本?php var_dump(opcache_get_status());输出结果里hits字段就是命中次数misses是未命中次数。命中率的计算公式为命中率 hits / (hits misses) × 100%也可以直接在命令行里用php -i | grep opcache查看相关配置。我遇到过不少情况有人上来就说“我开了 OpCache 但没啥效果”结果一看命中率只有 30%。为什么因为opcache.validate_timestamps开着而且文件更新时间戳频繁被改动比如某些编辑器保存时会 touch 文件导致 OpCache 每次请求都以为文件变了老老实实重新编译一遍。配置了 OpCache却没有让它真正生效是最常见的一种“假开启”。4. OpCache 配置详解每个参数背后都有讲究4.1 最核心的配置项解析OpCache 的参数非常多但真正影响性能的其实就那么几个。我按重要程度排序来说。opcache.enable总开关。值为 1 表示开启。这个不用多说php.ini里没开的话一切免谈。opcache.memory_consumption共享内存的大小单位是 MB。这个参数决定了 OpCache 最多能用多少内存来存储编译后的 opcode。如果设置得太小会导致缓存频繁被淘汰旧条目被移除以腾出空间命中率下降设置得太大又浪费内存。我通常建议从 128MB 开始然后观察opcache_get_status()里的memory_used和cached_scripts数量来调整。分享一个实际经验一个中等复杂度的 Laravel 项目所有框架文件加业务代码编译后的 opcode 大概占用 40~60MB 内存。如果你用的是大型框架128MB 起步是合理的。如果你的项目就是几个简单的 PHP 文件32MB 都绰绰有余。opcache.max_accelerated_files最多能缓存多少个 PHP 文件。这个值如果小于你项目实际的文件数量OpCache 会开始驱逐一些旧文件同样会导致命中率下降。默认值在 PHP 7 之后是 10000PHP 8 之后是 10000 或更高。但有些老项目的默认配置是 2000一旦项目文件超过这个数就会出现“缓存刚写入就被挤出去”的尴尬局面。怎么估算需要多少项目的核心文件数量你自己最清楚。可以用一个简单命令统计一下find . -name *.php | wc -l如果有 10000 个文件那max_accelerated_files至少要设置成 13000留一点余量。这个参数不是越大越好每个文件都会有哈希索引开销太大了浪费内存但也不能让文件数超过上限。opcache.validate_timestamps这个参数决定了 OpCache 要不要检查文件时间戳来判断文件是否更新。值为 1 表示每次请求都检查值为 0 表示不检查永远信任缓存。这是很多性能问题的根源。只要validate_timestamps为 1OpCache 每次请求都会做一次 stat 调用检查文件的 mtime 和 size 变了没有。如果文件很多这也会成为一个小开销但更大的问题是如果文件确实被 touch 过哪怕内容没变OpCache 也会认为文件变了触发重新编译。当你在生产环境部署代码时如果采用 zend_opcache 且validate_timestamps0那代码更新后需要手动重置 OpCache比如重启 PHP-FPM或者调用opcache_reset()。两种方案各有利弊validate_timestamps0性能最好完全没有 stat 检查但部署时需要额外操作validate_timestamps1方便文件改了自动重新编译但每次请求有 stat 开销。我个人在生产环境倾向设置validate_timestamps0配合部署脚本在发布新代码后执行opcache_reset()或者重启 PHP-FPM。但这里要注意如果开发环境和生产环境共用同一个php.ini开发环境一定不要设 0否则改代码不生效你会被坑到怀疑人生。opcache.revalidate_freq当validate_timestamps1时这个参数表示多少秒检查一次文件时间戳。默认是 2 秒。也就是说请求到来时OpCache 会检查距上次检查是否超过了 2 秒如果没超过就直接用缓存。这个参数可以缓解频繁 stat 的问题但代价是文件修改后最多要等这么久才能生效。4.2 容易忽略但影响巨大的参数opcache.enable_cliCLI 模式下是否启用 OpCache。默认是 0。如果你在命令行下跑 PHP 脚本需要单独开启。但这里也有个坑CLI 模式是一次性进程每次执行完就退出了OpCache 缓存的内容在进程退出时就销毁了所以 CLI 下开 OpCache 不会带来性能提升反而多了一层内存申请的开销。除非你在做常驻进程开发比如 Swoole 之类的常驻模式否则不需要开。opcache.fast_shutdown这个参数控制进程结束时的清理策略默认是 1。它的作用是跳过那些非必要的清理工作加快进程退出速度。在你使用 PHP-FPM 时建议保持为 1能减少每个请求结束时释放内存晶块的时间。虽然对单次请求影响微不足道但在高并发下累计起来是有效果的。opcache.save_comments/opcache.load_comments这两个参数与 PHP 注释和文档相关。如果你的代码里有很多 PHPDoc 注解比如 Laravel 里大量使用注解这些信息会被标记在 opcode 里。如果把save_comments设为 0可以稍微减少内存占用代价是反射、注解等功能会失效。现代框架大量依赖注解我强烈不建议关掉这两个参数除非你非常清楚自己在干什么。opcache.interned_strings_buffer这个参数控制字符串驻留缓冲区的大小。PHP 在内部会把重复使用的字符串比如变量名、函数名驻留在共享内存中避免每个进程重复复制一份。默认是 8MB建议调到 16MB 或 32MB。这个值的收益很微妙通常配合memory_consumption一起调。你可以在高并发下观察interned_strings_buffer_used如果接近上限了就加大。4.3 一个可落地的推荐配置这是我的个人推荐配置适用于大多数 PHP 7.4 / PHP 8.x 的 FPM 环境直接黏贴到php.ini的 OpCache 配置区即可zend_extensionopcache.so opcache.enable1 opcache.enable_cli0 opcache.memory_consumption128 opcache.interned_strings_buffer16 opcache.max_accelerated_files20000 opcache.validate_timestamps0 opcache.revalidate_freq0 opcache.fast_shutdown1 opcache.save_comments1 opcache.load_comments1再强调一次如果你不想每次发布代码都重置就把validate_timestamps设为 1revalidate_freq设为 60这样代码最长 60 秒后生效且 stat 开销被控制在每 60 秒一次。如果你追求极限性能且有自己的部署流程就保持validate_timestamps0发布后重启 PHP-FPM 或调opcache_reset()。5. 庖丁解牛一个简单的 demo看 OpCache 的微妙行为5.1 准备实验环境纸上得来终觉浅。我建议你亲手跑一遍下面的实验才能真正理解 OpCache 的行为。准备工作一个安装了 PHP 7.4 的环境最好带 OpCache 扩展一台本地机器或虚拟机单人操作即可能用命令行执行php -v和php -i | grep opcache确认扩展已加载。确定 OpCache 加载php -m | grep Zend输出里应该有Zend OPcache。5.2 实验一验证 OpCache 命中与未命中我们先写一个简单的脚本内容不重要关键在于通过opcache_get_status()观察命中情况。?php echo Hello, OpCache\n; echo Hits: . opcache_get_status()[opcache_statistics][hits] . \n; echo Misses: . opcache_get_status()[opcache_statistics][misses] . \n; echo Memory: . round(opcache_get_status()[memory_usage][used_memory] / 1024 / 1024, 2) . MB\n;在命令行下跑php /path/to/your/test.php注意如果你按照前面的配置设置了opcache.enable_cli0CLI 模式不会启用 OpCache这时候看命中率没有任何意义。别踩这个坑要么临时开启 CLI 模式要么用 PHP-FPM 访问这个脚本。用 PHP-FPM 环境下来测试的话可以写两个文件file1.php?php $start microtime(true); require __DIR__ . /common.php; echo 耗时: . (microtime(true) - $start) . 秒\n;common.php?php // 一个比较费时间的编译任务 function doNothing() { return 1; } class DemoClass { public $prop 1; public function demo() { return 2; } } // 写一些冗余的类增加编译负担 class DemoClass2 { public $prop2 2; } class DemoClass3 { public $prop3 3; } class DemoClass4 { public $prop4 4; }用 ab 或 curl 多次请求 file1.php观察命中率的变化。第一次请求是 miss后续请求应该变为 hit。如果你设置了validate_timestamps0而且没有修改文件那 hit 会持续增长。如果你在两次请求之间去touch common.php一下在validate_timestamps1的情况下猜猜会发生什么答案是common.php 会重新编译命中数不增加misses 增加。哪怕文件内容一个字节都没变只要时间戳变了OpCache 就会认为文件变了。5.3 实验二观察 OpCache 内存在高并发下的表现如果你有压测工具比如 ab可以做个更真实的测试ab -n 10000 -c 50 http://your-site/file1.php压测结束后观察命中数是否几乎等于请求总数misses 是否只是最初的极少次数memory_usage是否超过memory_consumption的 80%。如果超过了说明缓存空间偏紧可能需要加大。我见过一个糟糕的配置memory_consumption32MB一个功能复杂的中型项目缓存空间耗尽OpCache 不停地淘汰旧的脚本缓存导致命中率在 60%~80% 之间反复横跳。这种情况下开启 OpCache 的收益大打折扣甚至因为内存分配、锁竞争的开销比不开还慢。压测之后确认内存占用是调优的重要依据。5.4 深入 opcache_get_status 的关键字段很多人拿到opcache_get_status()的输出直接就懵了字段太多。我帮你筛出最值得关注的几个字段含义理想状态cache_full是否已满应为 false若 true 表示内存不够memory_usage.used_memory已用内存不要超过 free_memory 与分隔线的边界opcache_statistics.hits命中次数趋势持续增长opcache_statistics.misses未命中次数主要集中在前几次请求opcache_statistics.opcache_hit_rate总体命中率99% 以上为佳opcache_statistics.last_restart_time上次重启时间戳0 表示未重启过如果cache_full一直为 true同时hits增长缓慢别犹豫加大memory_consumption或者减少max_accelerated_files具体改哪个取决于你的内存占用和文件数量。6. 高并发下的 OpCache 陷阱与实战排查6.1 进程重启引起的缓存失效很多团队遇到过这样的诡异问题代码没改也没发布但某个时间点线上性能突然下降了一下然后又恢复。查看last_restart_time发现 OpCache 在那一刻重启过。OpCache 什么时候会重启常见原因PHP-FPM 所有 worker 进程被杀掉重建系统内存不足导致共享内存被释放通过opcache_reset()被人为调用了一次opcache.file_update_protection机制触发的部分失效。大面积重启会导致所有 worker 进程重新编译所有脚本瞬间触发 CPU 飙升。如果你的监控里看到重启时间点前后出现性能抖动先排查这几个原因。如果部署脚本里有调用opcache_reset()的逻辑建议只在发布代码时调用而不是定时调用。6.2 多 worker 竞争写锁的细节PHP-FPM 同时有几十个 worker 进程每个 worker 都可能请求一个未命中缓存的脚本。此时它们都会尝试编译这个脚本然后写入共享内存。为了防止数据不一致OpCache 在写入时会加锁。这个锁竞争在高并发 缓存未命中的情况下尤其严重。想象一个场景热门接口上线新代码validate_timestamps1每个 worker 在第一次请求新文件时都没命中缓存于是几十个 worker 同时开始编译同一个文件然后抢同一个锁。解决办法其实很朴素提前预加热。发布后主动访问一遍关键接口让缓存先建立起来使用opcache_compile_file()在部署脚本中预编译所有文件。Laravel 之类的框架也可以在部署时运行php artisan optimize如果确实无法预加热要确保memory_consumption足够大避免缓存写入失败。6.3 validate_timestamps 与部署流程的冲突这是我在实际业务中最常解决的问题。开发同学提交代码后线上跑了许久不见生效。检查配置发现validate_timestamps0那当然不生效。他们希望代码发布后立即生效而性能团队要求validate_timestamps0追求性能。两边诉求冲突怎么办我的方案是在部署脚本里按顺序执行以下操作既保证性能又保证代码生效:# 1. 代码发布同步文件 rsync -avz --delete ./ /var/www/html/ # 2. 重置 OpCache让新代码重新编译 php -r var_dump(function_exists(opcache_reset) ? opcache_reset() : no opcache); # 如果上面这行不生效换个方式 # kill -USR2 $(cat /var/run/php-fpm.pid) # 3. 预编译所有 PHP 文件 find /var/www/html -name *.php -print0 | xargs -0 -n1 php -l这里要注意php -r opcache_reset();在 CLI 模式下如果opcache.enable_cli0它不会重置 FPM 的共享内存缓存。正确的做法是在 PHP-FPM 常驻进程里执行 opcache_reset或者通过重启 PHP-FPM 来搞定。你可以在 FPM 环境中放一个内部接口/_ops/opcache-reset.php仅允许内网 IP 访问部署脚本用 curl 调用它。这种设计在实际运维中非常方便既保留了validate_timestamps0带来的零 stat 开销又能让代码发布后立即生效。6.4 OpCache 与文件更新检查的“减零”问题还有一个相对深的知识点opcache.file_update_protection。这个参数的含义是在多少秒内被修改过的文件不会被缓存。默认值是 2 秒目的是避免正在写入的文件被编译成半成品。这在开发环境很友好但在生产环境如果你用原子替换的方式发布代码比如先写入临时文件再 mv 覆盖文件被修改的时间戳在当前请求中会小于file_update_protection的窗口期导致 OpCache 拒绝缓存它从而走一次完整编译。这解释了为什么有些线上环境明明配置没问题却总有某些文件处于“永不命中”状态。解决也很简单发布代码时用 mv 替换而不是覆盖写或者把这个参数设置为 0前提是你确定不会在文件中写入到一半时被请求访问。如果你使用 CDN 或对象存储来同步代码尤其要注意这类边界情况。7. OpCache 与框架优化从 Laravel 到 ThinkPHP 的实测对比7.1 不同框架的编译成本差异为什么有些框架开启 OpCache 后效果立竿见影有些则不明显原因在于框架的编译负担不同。拿 Laravel 举例一个典型的 Laravel 请求要加载数百个类文件。每个类文件都要经过词法分析、语法分析、编译三步。如果不开 OpCache这数百个文件的编译时间加起来可能占请求总耗时的 60% 以上。所以我常对同事说“用 Laravel 不开 OpCache就像开车时不松手刹油门踩到底速度也上不来。”再拿轻量级框架或纯原生 PHP 对比可能整个请求就加载几个文件编译耗时占比只有 10%那 OpCache 带来的提升就不那么明显。我做过一个表格对比不同场景下开启 OpCache 前后的 TTFB首字节时间场景关闭 OpCache TTFB开启 OpCache TTFB提升比例原生 PHP 输出 “Hello”2.1ms1.5ms约 29%轻量框架如自研 MVC8.4ms4.2ms约 50%Laravel 空路由35ms12ms约 66%当然这不是严格的控制变量测试但方向是明确的框架越重、文件越多OpCache 的价值越大。7.2 框架层级的 OpCache 预热方案对于 Laravel 这样的框架部署后只访问首页来预热远远不够因为还有很多未访问到的代码路径没有编译。更好的方案是写一个预热脚本遍历项目里的主要代码目录逐个调用opcache_compile_file()。参考实现?php // warmup.php —— 在 CLI 下运行 $root $argv[1] ?? /var/www/html; $iterator new RecursiveIteratorIterator( new RecursiveDirectoryIterator($root, FilesystemIterator::SKIP_DOTS) ); $count 0; foreach ($iterator as $file) { if ($file-isFile() $file-getExtension() php) { opcache_compile_file($file-getRealPath()); $count; } } echo 预热完成{$count} 个文件\n;再配合部署脚本php /path/to/warmup.php /var/www/html注意opcache_compile_file()只负责编译并不执行代码所以相对安全。但依然要注意不要在 CLI 模式没开opcache.enable_cli时寄希望于它生效。如果确实在 CLI 模式下做预热需要临时给该脚本加-d opcache.enable_cli1。写到这里我又想到一个细节如果你用php -d opcache.enable_cli1 /path/to/warmup.php预热这个 CLI 进程退出后共享内存里的缓存还在吗答案是不在。CLI 进程退出时会释放它持有的共享内存这和你 FPM 进程持有的共享内存不是一回事。所以CLI 预热在实际 FPM 环境中通常并不好用。那怎样预热才靠谱我用的方式是在部署完成后用一个进程内脚本去请求一些核心页面让 FPM 自己把缓存建立起来。具体实现可以是在 CLI 里通过curl循环一把内部接口或者启动一个临时的php -S服务来打请求。这些粗暴但有效的办法反而是我在生产环境用过的实测可靠方案。7.3 代码变更后的缓存失效策略不管你用什么框架一定要理清一个逻辑OpCache 缓存的是文件级别的 opcode不是框架级别的。所以当你只改了某个 service 文件时OpCache 只需要让这一个文件失效重编译而不是把整个项目的缓存都推倒重来。这意味着你可以做到代码发布后“部分失效”而不是全量失效。前提是你的部署是以文件为单位进行同步的而不是把整个目录删了重来。如果你用类似rm -rfunzip的方式整包部署那所有文件的 inode 都变了等于全部缓存失效热浪瞬间涌上来。我的建议是生产环境部署尽量使用原子替换目录的方式。比如每次发布生成一个新的版本目录同时修改软链接指向最新目录。这样 OpCache 看到每个文件的路径其实变了目录路径变化旧缓存缓缓失效新缓存逐渐建立服务中断面很小。8. 常见问题速查那些年我踩过 OpCache 的坑我把这些年遇到的高频问题整理成一张速查表。表中覆盖的每一种情况都是我在实际项目中亲身踩过或者帮同事排查过的。现象可能原因排查手段解决方案改了代码没生效validate_timestamps0 或 revalidate_freq 过大查配置确认部署后 opcache_reset()命中率只有 30%max_accelerated_files 小于文件数find . -name *.phpwc -l内存占用接近 100%memory_consumption 偏小观察 cache_full调大 memory_consumption高并发下 CPU 突然抖动进程重启或大面积缓存失效查 last_restart_time避免全量部署部分接口每次都是 missfile_update_protection 导致新文件不缓存检查文件修改时间用 mv 替换部署或设 0CLI 下预热无效opcache.enable_cli0php -m 查看临时开启 enable_cli 才能看到效果代码上线后 qps 反而下降缓存未预热 写锁竞争查看 CPU 负载部署后少量请求预热容器环境每次重启都变慢共享内存随容器销毁观察重启时间容器首次启动后预热或调整重启策略8.1 又一个容易忽略的坑文件权限与缓存权限在多进程模型下OpCache 写入共享内存的主体是当前 worker 进程。如果 PHP-FPM 运行的用户和代码文件的属主不一致某些文件可能无法被正常读取导致编译失败OpCache 会直接补一个编译异常。这时候需要看 PHP 错误日志常见报错是opcache_compile_file失败或者 Permission denied。处理方式很朴素确保 PHP-FPM 运行用户对项目文件至少有读权限。部署工具的产物比如 cache 目录、storage 目录顺带检查一下写权限避免一箭双雕的故障。8.2 如何写一个简易的 OpCache 监控脚本运维监控里如果能对 OpCache 做可视化故障定位会轻松很多。这里分享一个我常用的简易监控脚本可以直接扔给 crontab 或者集成到监控平台。?php // opcache_monitor.php $status opcache_get_status(false); $hitRate $status[opcache_statistics][opcache_hit_rate] ?? 0; $cacheFull $status[cache_full] ?? false; $usedMemory $status[memory_usage][used_memory] ?? 0; $freeMemory $status[memory_usage][free_memory] ?? 0; $totalMemory $usedMemory $freeMemory; $alerts []; if ($hitRate 90) { $alerts[] OpCache 命中率过低: {$hitRate}%; } if ($cacheFull) { $alerts[] OpCache 缓存已满请调大 memory_consumption; } if ($totalMemory 0 ($usedMemory / $totalMemory) 0.8) { $alerts[] OpCache 内存使用率超过 80%; } // 也可以检测缓存文件数 $cachedScripts $status[opcache_statistics][num_cached_scripts] ?? 0; $maxScripts $status[opcache_statistics][max_cached_keys] ?? 0; if ($maxScripts 0 (($cachedScripts / $maxScripts) 0.9)) { $alerts[] 缓存的脚本数量接近上限 {$cachedScripts}/{$maxScripts}; } if (empty($alerts)) { echo OK 命中率: {$hitRate}% 内存: . round($usedMemory / 1024 / 1024, 2) . MB\n; } else { foreach ($alerts as $alert) { echo ALERT: {$alert}\n; } }这个脚本不用额外依赖只要 PHP-FPM 环境里有它能访问的入口就能定时抓取状态。8.3 容器化环境下的 OpCache 注意事项这几年 Docker 部署 PHP 应用已经非常普遍。容器化环境下 OpCache 有一个特殊情况容器销毁后共享内存也没了。每次重启容器OpCache 状态清零下一次请求又要重新编译所有文件。如果容器频繁扩容缩容比如 K8s 环境每个新 Pod 启动时都是一段“冷启动”时间延迟上升CPU 飙升。针对这种场景我能给的最佳实践是在 Dockerfile 里不要把 OpCache 的缓存目录挂在临时文件系统上除非你能接受每次销毁启动命令里加上预热步骤。比如容器启动后、服务对外提供服务前执行一个预热脚本把主要代码文件都提前编译一遍如果整个服务是无状态的多副本部署建议把memory_consumption调大一些减小淘汰概率不要为了省内存把memory_consumption设置得刚刚好容器内存限制宁多勿少。说到这我想起一次线上事故某个服务在 K8s 里配置了 HPA流量高峰时自动扩容到 20 个副本。每个新副本启动后第一个请求都要经历漫长的编译期P99 延迟从 500ms 飙升到 5 秒。后来加了启动预热P99 立刻恢复到正常水平。这个教训我一直记忆犹新。9. PHP 8.x 时代 OpCache 的新变化PHP 8 引入了 JITJust-In-Time编译它和 OpCache 是相辅相成的。JIT 的工作方式是把一些热点 opcode 在运行时进一步编译成机器码从而提升计算密集型场景的性能。但需要泼一盆冷水对于绝大多数 Web 业务I/O 和数据库才是瓶颈JIT 带来的 CPU 计算类性能提升并不是非常肉眼可见。对一个 CRUD 接口来说花在数据库查询上的时间远大于 CPU 执行 PHP 指令的时间。你搜索一个关键词看到大量文章吹 JIT但真正上线后收益往往没有你想象中大。OpCache 的核心地位并没有因为 JIT 的引入而削弱。相反JIT 的开启还依赖于 OpCache 的正常工作。如果你把 OpCache 关掉JIT 也无从谈起。PHP 8 里 JIT 的默认配置大约是“不开启”或“试验性开启”日常优化 OpCache 依然是最重要的一环。我在 PHP 8.2 环境上做过一次对比同样是 Laravel 项目只开 OpCache、不开 JITQPS 已经比裸跑提高了两倍多。再开 JITQPS 只又提升了 5%~10%但内存占用却翻了一倍。我不建议业务型项目盲目开 JIT内存成本大于收益。10. 一些经验之谈与优化建议最后这部分我打算把心态放平聊聊几点纯粹的经验而不是配置参数。第一OpCache 不是万能药。如果你的业务瓶颈在数据库查询在 Nginx 层或者在外层缓存那开不开 OpCache 影响不大。先做性能剖析再决定优化方向这是我一直坚持的做法。第二不要把 OpCache 当作隐藏代码 Bug 的工具。有人开了validate_timestamps0之后改代码不生效就以为是缓存的问题其实代码里有语法错误、逻辑错误只是被旧缓存掩盖了。排查这类问题时先手动opcache_reset()再验证能省掉很多无效猜测。第三监控是必须的不是可选的。像我上面写的那个监控脚本五分钟跑一次命中率下降就能及时报警把很多问题的响应时间从小时级缩短到分钟级。第四部署流程要和缓存策略强绑定。如果每次发布都用rm -rf 覆盖却要求 OpCache 永远保持高命中率那不现实。把“预热”“重置缓存”“原子替换目录”纳入发布流程比事后救火省心得多。如果你现在正准备优化一个 PHP 项目我给的建议路径是先确认 OpCache 已开启且基础配置合理压测或监控观察命中率、内存使用率调优memory_consumption和max_accelerated_files设计好部署和缓存重置机制最后再考虑 JIT 或其他层面的优化。我一直觉得PHP 的性能问题很多时候不是语言的问题而是对运行机制不够熟悉导致的配置不当。了解 echo 背后的执行链路理解 opcode 的生成与缓存你才能真正掌控 PHP 应用的性能边界。希望这篇文章能帮你把这块拼图补齐。