PHP OPcache字节码缓存怎么调才能让站点真正快起来？

OPcache是PHP站点性价比最高的一档优化，开一个开关就能让动态页快一大截，可偏偏最容易被人配错、甚至配出"部署了代码不生效"的灵异事件。保哥这篇把它讲透：PHP为什么每次请求都在白白重复编译、OPcache缓的到底是什么、内存和文件数两个核心参数怎么定、validate_timestamps这个生产大坑怎么躲、命中率怎么看、preload和JIT到底值不值得碰。看完你就能把这层缓存调得明明白白，而不是抄一段配置提心吊胆。

做独立站、跑WordPress或Magento的朋友，多多少少听过OPcache这个词，知道它"能让PHP变快"。但真要问它快在哪、参数怎么配、为什么有时候改了代码前台死活不更新，能说清楚的就不多了。保哥见过太多服务器，OPcache要么压根没开白白浪费性能，要么参数照抄网上一段配置，内存设得要么撑爆要么不够，命中率惨不忍睹自己还蒙在鼓里。

这篇就把这层缓存彻底讲明白。它跟保哥之前写的Redis对象缓存是两个完全不同的东西——一个缓代码、一个缓数据，后面会专门掰开。咱们先从一个根本问题问起：PHP到底在重复做什么无用功。

PHP每次请求都在重复编译，OPcache到底省了什么？

要懂OPcache，得先知道PHP是怎么跑一段代码的。你写的 .php 文件，PHP不能直接执行，它得先翻译。整个过程大致分几步：先做词法分析和语法分析，把源码拆成结构化的语法树；再把语法树编译成一种叫opcode（操作码）的中间字节码；最后由Zend引擎一条条执行这些opcode，产出最终的HTML。

问题就出在中间那步。每来一个请求，PHP默认都要把涉及的PHP文件从头解析、编译一遍。可你的代码在两次请求之间根本没变啊——同一份 index.php，第一个访客来编译一次，第二个访客来又编译一次，第一万个访客来还编译，编译出来的opcode每次都一模一样。这是赤裸裸的重复劳动，纯属浪费CPU。

OPcache干的事就是终结这种浪费。它把编译好的opcode缓存到一块共享内存里，下次再有请求用到同一个文件，PHP一看缓存里有现成的opcode，直接拿来执行，跳过了词法分析、语法分析、编译这三大步。省下来的是实打实的CPU时间，反映到用户那头就是动态页响应更快、服务器在同样硬件下能扛更多并发。

这里有个关键词叫"共享内存"，它解释了OPcache为什么这么高效。PHP-FPM通常跑着一堆工作进程同时处理请求，OPcache的缓存是放在一块所有进程都能访问的共享内存区里，编译一次，全体进程共用，不是每个进程各缓一份。这就是为什么清缓存往往要重载整个FPM——你动的是这块大家共享的内存。也正因为缓存在内存里，服务器一重启，OPcache就空了，得重新预热。

那怎么确认你的服务器到底开没开OPcache？最简单是写个只有 <?php phpinfo(); 的页面访问，搜opcache那一段，看Opcode Caching是不是Up and Running；命令行下 php -i 配合查找opcache也行，但要注意——opcache.enable_cli默认是关的，命令行下的OPcache和PHP-FPM那个是两个独立实例，你在CLI看到的状态不代表网站实际跑的那个。这个区别后面讲清缓存时还会咬人，先记住。

这里要敲黑板：OPcache缓存的是代码编译的结果，不是页面内容，也不是数据库数据。它不管你的页面长什么样、数据库里有什么，它只管"这份PHP文件编译成opcode长这样，我记住了"。这个定位搞清楚，下一节那个最容易混的问题就迎刃而解了。

OPcache和Redis对象缓存、CDN是一回事吗？

不是，它们是缓存世界里三个站在完全不同位置的角色。保哥发现很多人把"缓存"当成一个笼统的概念，结果该上的没上、上了的又用错地方。咱们一次性理清楚。

• OPcache缓的是代码。它工作在PHP把源码编译成字节码这一层，省的是编译开销。只要你的站是PHP写的，它几乎无脑该开，跟你做什么业务无关。
• 对象缓存缓的是数据。像Redis对象缓存，缓的是数据库查询结果，省的是反复查库的开销。它治的是动态页和后台那种数据库往返频繁的场景。
• CDN缓的是分发。它把静态资源和整页HTML缓存到离用户近的节点，省的是网络传输距离。治的是全球访客的物理延迟。

其实还有第四个常被一起提的角色——页面缓存，它缓的是整张生成好的HTML页面。对纯游客访问的静态内容页，页面缓存最猛，直接吐现成HTML，连PHP都不跑，OPcache和对象缓存自然也用不上了。但它对登录用户、购物车这种个性化动态页基本失效，这时候才轮到OPcache省编译、对象缓存省查询去接力。所以严格说是四层：页面缓存接住游客整页、OPcache砍代码编译、对象缓存砍数据库查询、CDN管分发距离。

换个比方：OPcache是让厨师不用每次做菜前都重新研究一遍菜谱；对象缓存是把常用食材提前备好不用每次现采购；页面缓存是把招牌菜提前做好摆在窗口直接端；CDN则是在各个城市开分店让顾客就近取餐。几者各管一段，不冲突，理想状态是叠着用。

这也是为什么OPcache该被放在优化清单的最前面——它收益大、风险小、配置简单，开了几乎没有副作用（除了那个部署坑，后面细说）。保哥讲TTFB多层缓存优化时把它列为基础的一层，就是这个道理。它和对象缓存那一层配合起来，一个砍编译、一个砍查询，动态页的速度才能真正提上去。

内存和文件数这两个核心参数怎么配？

OPcache的配置项不少，但真正要你上心的就两个：分多少内存、能缓多少个文件。配好这俩，OPcache就八九不离十了。

内存：opcache.memory_consumption。这是分给OPcache存opcode的共享内存大小，默认128MB，最小不能低于8MB。怎么定？看你站点的代码体量。一个轻量博客128MB绰绰有余；Magento、大型Laravel这种代码量巨大的，128MB可能不够，得往上调到256MB甚至更多。判断够不够别拍脑袋，去看运行时状态（下一节讲怎么看），如果可用内存所剩无几、或者出现了因为内存满而被迫重启的记录，就是该加了。

opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.interned_strings_buffer=16

文件数：opcache.max_accelerated_files。这是OPcache能缓存的脚本文件数量上限，默认10000，可设范围是200到1000000。这个值特别容易被低估——你以为自己站没多少文件，可一个现代框架加上各种依赖包，PHP文件轻松上万。如果实际文件数超过了这个上限，超出的部分就缓存不进去，那些文件每次请求还得现编译，命中率被拖下水。

有个细节：OPcache内部用哈希表存这些文件，它会自动把你设的值向上取到最接近的质数。所以与其纠结设个整数，不如直接设一个略大于实际文件数的质数（比如实际有一万八千个文件，设个20011这样的质数）。怎么知道实际有多少文件？运行时状态里num_cached_scripts会告诉你当前缓了多少，拿它对照上限就知道够不够。

还有个 opcache.interned_strings_buffer（驻留字符串缓冲区），它把代码里重复出现的字符串去重存储省内存，默认8MB。要注意一个反直觉的点：这块缓冲是从memory_consumption总量里扣的，不是额外加的。你把它调大，可用于存opcode的内存就相应变少，两者要通盘考虑，别顾此失彼。

还有几个不那么核心但值得知道的开关。opcache.enable 是总开关，设1启用；它有个脾气——不能在运行时用ini_set临时打开，只能在配置文件里设好，所以改了它得重启FPM。opcache.save_comments 控制要不要保留代码里的注释（默认保留），很多框架靠PHP文档注释里的注解（annotation）干活，比如Doctrine、某些路由，这个要是关了会直接报错，别为了省一点内存乱动它。

另外有个 opcache.blacklist_filename，能指定一个黑名单文件，把某些不想被缓存的脚本路径列进去。这个一般用不上，但遇到某个文件确实不适合缓存（比如频繁动态生成的）时，知道有这么个口子。把上面那段示例配置逐行翻译一下：内存256MB、文件数上限两万、驻留字符串16MB，这是一套适合中大型站点的起步配置，小站点用默认值即可，大站点再往上加。配置改完别忘了重启PHP-FPM才生效。

validate_timestamps这个开关为什么是生产环境的大坑？

来了，这是OPcache最该单独拎出来讲的一个参数，无数"部署了代码不生效"的灵异事件都栽在它身上。

opcache.validate_timestamps 默认是1（开启），含义是：OPcache会每隔一段时间检查一下源文件的修改时间，如果发现文件被改过了，就把旧缓存作废、重新编译。这个"每隔一段时间"由 opcache.revalidate_freq 控制，默认2秒，意思是同一个文件最多2秒检查一次时间戳；设成0就是每个请求都检查。

这个频率的取值有讲究。设成0（每请求都查）改代码反应最灵敏，但每个请求多一次文件系统访问，开销最大，适合开发调试。默认的2秒是个折中，对开发还算够用。生产环境如果保留时间戳检查（validate_timestamps=1），可以把revalidate_freq调大一点，比如60秒甚至更长，减少检查频率——代价是改了代码最多要等这么久才生效，但生产环境本来也不该频繁热改代码。关键是想清楚你这台机器是"会经常改代码"还是"部署后稳定运行"，按场景配。

开发环境这样挺好，你改了代码刷新页面很快就能看到效果。但到了生产环境，为了榨干性能，很多人会把 validate_timestamps设成0——彻底关掉时间戳检查。这一下性能确实更好了，OPcache连"文件改没改"这个判断都省了，认准缓存里的opcode一路用到底。

代价是什么？你改了代码、传了新文件，OPcache根本不去看文件时间戳，它压根不知道代码变了，前台跑的还是内存里那份旧opcode。你盯着页面纳闷"我明明改了啊"，其实改的是磁盘上的文件，跑的是内存里的旧缓存。

这就是那个经典坑的全貌。validate_timestamps=0不是bug，它是一个性能与便利的权衡：你拿"不自动感知代码变化"换"不做时间戳检查的性能"。一旦选了它，你的部署流程里就必须加一个主动清缓存的步骤，否则部署等于没部署。下一节专门讲这个。

部署后代码不更新，是不是OPcache没刷？

如果你的生产环境关了时间戳检查，那答案几乎一定是：对，就是OPcache没刷。修复思路很简单——部署完，主动让OPcache把旧缓存丢掉。具体有几种清法：

• 调用opcache_reset()。这个PHP函数会清空整个OPcache，下次请求重新编译。可以写个小脚本部署后访问一下触发，但要注意它得在和PHP-FPM同一个进程语境里执行才有效，命令行CLI跑的是另一个OPcache实例，清的不是FPM那个。
• 重载或重启PHP-FPM。systemctl reload php-fpm 之类，让FPM进程重来，OPcache自然清空。这是最干脆可靠的方式，配合PHP-FPM进程管理一起做，部署脚本里加一行就行。
• 用专门的工具。像cachetool这类命令行工具能通过FPM的socket远程触发清理，绕开了CLI与FPM实例不互通的问题，适合自动化部署。

还有个相关参数 opcache.file_update_protection，默认2秒，意思是文件修改时间在这个秒数以内的文件先不缓存。它防的是这种情况：你的文件正写到一半，OPcache就把这个残缺状态缓存了。留个几秒保护期，等文件确定写完了再缓，避免缓存到半成品。

这里还有个高级部署的坑值得一提。有些团队用"原子部署"——把新版本放到一个新目录，再用软链接一次性切过去。如果你的OPcache缓存key是按真实路径算的，软链接切换后真实路径变了，缓存key自然变了，相当于天然清了缓存；但如果配置让它认软链接路径，路径没变，旧缓存还在，照样得手动清。部署方式和清缓存策略要对上，别想当然。

命中率怎么看，低了从哪查？

OPcache配得好不好，不能靠感觉，得看数据。PHP提供了一个函数 opcache_get_status()，调一下就能拿到OPcache的完整运行状态，市面上各种OPcache监控面板底层都是读它。重点看这几个指标：

命中率低，通常逃不出三个根因，对照着查。一是文件数超限：num_cached_scripts顶到了max_accelerated_files上限，多出来的文件缓不进去，每次现编译，把命中率拉低。解法是调高文件数上限。

二是内存不足频繁淘汰：内存装不下所有opcode，OPcache不得不淘汰一部分，被淘汰的下次又得重编译。表现是free_memory很低、wasted_memory高、甚至oom_restarts在涨。解法是加memory_consumption。

三是时间戳检查太勤：revalidate_freq设得太小（比如0），每个请求都去查文件时间戳，虽然不直接砍命中率，但增加了额外开销。生产环境在确认会主动清缓存的前提下，可以把这个值调大或干脆关掉检查。三个根因里前两个最常见，先从内存和文件数这两个参数查起准没错。

顺便说说那几个restart（重启）计数，它们是判断健康度的好信号。OPcache内部在某些情况下会自己重启、清空缓存重来，状态里分了三类计数，分别对应不同的诱因。

oom_restarts 是内存耗尽（out of memory）被迫重启，这个涨了说明内存严重不足；hash_restarts 是哈希表满了（文件数撞上限）触发的重启，涨了说明max_accelerated_files该调大；manual_restarts 是你主动调opcache_reset() 清的，部署时涨是正常的。盯着前两个，只要它们在持续增长，就是配置不够用的铁证，比命中率更直接。

保哥举个真实排查。有台跑着电商的服务器，老板抱怨后台越来越卡。一查opcache_get_status()，命中率才八成出头，num_cached_scripts死死贴着默认的10000上限，hash_restarts还在不停涨——典型的文件数超限。那套电商系统加上插件早过万个PHP文件，默认上限根本装不下，一部分文件每次请求现编译，能不卡吗。

把max_accelerated_files提到两万多、内存也加到256MB，命中率立马回到99%，后台顺滑如初。整个排查没碰一行业务代码，纯靠看状态数据定位，这就是会读opcache_get_status() 的价值。与其等用户投诉了再救火，不如把这几个指标接进监控，命中率掉到阈值以下、或者oom_restarts开始涨就自动告警，问题萌芽阶段就摁住。这一步跟保哥讲服务器运维时强调的"指标可观测"是一个思路，缓存层尤其不能当黑盒。

preload和JIT这些进阶功能值得开吗？

OPcache这些年加了两个进阶特性，preload和JIT，听着很唬人，但保哥要给你泼点冷水：它们不是人人都该开，得看场景。

preload（预加载，PHP 7.4起）。普通OPcache是"用到才缓"——第一个访问某文件的请求还是得编译一次，之后才走缓存。preload更进一步：服务器启动时就把你指定的一批核心文件（通常是框架本体）预先编译好、常驻内存，连第一次请求都不用编译，而且这些类和函数全程可用。

对代码量大的框架，preload能再省一截首次编译的开销。但它有两个代价：一是改了预加载的文件必须重启PHP-FPM才能生效，没有时间戳检查那一说；二是多个站点共享同一个PHP进程时，预加载的文件是全局的，可能撞命名空间。所以preload适合单一的、重型框架站点，多站混跑的环境要谨慎。顺便一提，Windows上不支持preload。

配置上，preload靠 opcache.preload 指向一个预加载脚本（这个脚本负责把要常驻的文件opcache_compile_file进来，很多框架直接提供了现成的预加载脚本），再用 opcache.preload_user 指定以哪个系统用户身份执行（出于安全，不允许用root跑）。Laravel、Symfony这些框架的官方文档通常会给出推荐的预加载配置，照着接就行，别自己硬写。

记住核心代价没变：预加载文件一改就得重启FPM，所以它适合给那些上线后基本不动的框架核心文件用，业务代码那种常改的别往里塞。否则你每改一次业务逻辑都要重启整个FPM，反而把开发效率拖垮，得不偿失。

JIT（即时编译，PHP 8.0起）。它在OPcache基础上再进一步，把热点opcode直接编译成CPU能跑的机器码，理论上更快。但关键在于：JIT的收益高度依赖工作负载类型。对计算密集型任务（图像处理、数学运算、AI推理）效果明显；可典型的Web应用是IO密集型——时间大多花在等数据库、等网络上，CPU计算占比不高，JIT能优化的那部分本来就不是瓶颈，提升有限，个别场景甚至因为额外开销出现微小负优化。

真要开JIT，配置上也有讲究。它通过 opcache.jit 设模式，常见的有tracing（跟踪热点路径，通常效果最好）和function（函数级），还有 opcache.jit_buffer_size 单独划一块内存存编译出来的机器码（默认64MB，设0等于关闭JIT）。这块缓冲是在OPcache内存之外另算的，开JIT记得给它留够。配错了buffer_size，JIT等于没生效你还以为开了，又是一个看着配了实则空转的坑。

保哥的结论很明确：OPcache本体，所有PHP站点都该开，这是基本功；preload，重型框架站点可以上，能再榨一点；JIT，别盲目跟风，先搞清楚你的站是不是计算密集型，是再开，不是就别折腾。把OPcache这个根本的开关用对、参数调好，收益已经远超那两个花哨特性。像Magento这种重型应用，OPcache更是性能调优里不可省略的一环，先把它配扎实，再谈别的。

说到底，OPcache是那种"花十分钟配好、长期默默省钱"的优化。它不像换硬件那么烧钱，也不像重构代码那么伤筋动骨，一个开关加两三个参数，就能让你的PHP站点在同样的服务器上跑得更快、扛得更多。唯一要记牢的，就是生产环境关时间戳检查后，部署务必带上清缓存这一步——把这个坑躲过去，OPcache就是稳赚不赔的买卖。

常见问题解答

OPcache和Redis对象缓存只配一个行不行，非得都上吗？

建议都上，因为它们优化的是完全不同的环节，不是二选一。OPcache缓的是PHP代码编译成字节码的结果，省的是每次请求重复编译的CPU开销，只要是PHP站点几乎都该开，跟业务类型无关，而且配置简单、风险极小。Redis对象缓存缓的是数据库查询结果，省的是反复查库的开销，治的是动态页和后台那种数据库往返频繁的场景。一个砍编译、一个砍查询，作用在请求处理的不同阶段，叠加起来动态页才能真正快。如果只能先上一个，OPcache优先——它收益面最广、几乎零副作用；对象缓存则看你的站是不是数据库密集型再决定。理想状态是两层都配齐，再加上CDN分发，各管一段。

改了PHP代码，刷新页面前台却还是旧的，是什么原因？

如果你的生产环境把opcache.validate_timestamps设成了0（关闭时间戳检查），那几乎可以肯定就是OPcache没刷。关闭时间戳检查后，OPcache不再去看源文件改没改，认准内存里那份旧字节码一直用，你改的是磁盘文件，跑的是内存旧缓存，自然看不到变化。解决办法是部署后主动清OPcache：调用opcache_reset()、重载或重启PHP-FPM、或者用cachetool这类工具触发清理。最可靠的是部署脚本里加一行reload php-fpm。如果你的环境validate_timestamps还是默认开启的，那等revalidate_freq那几秒过去就会自动更新，不是这个问题，得往别的缓存层（对象缓存、页面缓存、CDN）去查。

opcache.memory_consumption到底该设多大？

看你站点的代码体量，并以运行时数据为准，别照抄。默认128MB对轻量博客、小型站点通常够用；像Magento、大型Laravel这类代码量巨大的应用，128MB往往不够，要调到256MB甚至更高。判断够不够的办法是看opcache_get_status() 返回的内存使用情况：如果free_memory（空闲内存）所剩无几、wasted_memory（碎片）占比偏高、或者出现了oom_restarts（因内存不足被迫重启），就说明内存不够，该往上加。反过来如果空闲内存还很充裕，说明设大了也是浪费，可以适当回收。记住interned_strings_buffer是从这块总内存里扣的，调它会挤占存opcode的空间，要一起算账。

max_accelerated_files设大一点会不会浪费资源？

会占一点管理用的内存，但比起设小了导致文件缓不进去、命中率被拖垮，这点开销完全值得。这个参数是OPcache能缓存的文件数上限，默认10000，现代框架加上依赖包文件数轻松上万，一旦实际文件数超过上限，超出的部分每次请求都得现编译，命中率直接受损。所以宁可设得宽裕些。具体设多少？看opcache_get_status() 里的num_cached_scripts知道实际缓了多少文件，设一个略高于它的值即可。还有个小技巧：OPcache内部会把你设的数向上取到最近的质数，所以直接设个质数（比如20011）更省事，免得它自己调整。设大带来的额外内存占用很有限，不必为此纠结。

JIT开了能让我的网站快很多吗？

对绝大多数普通网站，提升有限，别抱太大期望。JIT是PHP 8.0引入的，它把热点字节码进一步编译成机器码，理论上执行更快。但它的收益高度依赖你的工作负载：对计算密集型任务——图像处理、复杂数学运算、AI推理这类CPU吃满的场景，JIT效果明显；而典型的Web应用是IO密集型，时间大多耗在等数据库查询、等网络响应上，CPU计算本来就不是瓶颈，JIT能优化的那部分占比很小，整体提升不明显，个别情况下因为额外开销甚至有轻微负优化。所以别因为它新就盲目开。先把OPcache本体配扎实——开启、调好内存和文件数，这部分收益远大于JIT。确实是计算密集型业务再去评估JIT，普通内容站、电商站没必要折腾。

权威参考资料