1. 引言很多朋友在部署 PHP 项目时都遇到过这样一个诡异的现象明明把代码改好了上传到服务器刷新页面却还是老样子。清浏览器缓存没用重启 Nginx 也没用折腾半天才发现问题出在 OPcache 上。今天这篇文章就结合我自己的踩坑经历聊聊 OPcache 配置里那些容易让人翻车的细节希望能帮大家少走弯路。2. 什么是 OPcacheOPcache 是 PHP 官方自带的一个字节码缓存扩展。它的原理很简单PHP 脚本第一次被请求时会先编译成字节码OPcache 把编译结果存到内存里下次再请求就直接用缓存省掉重复编译的过程从而提升性能。听起来很美好对吧但问题恰恰出在这里——缓存是双刃剑。如果配置不当它会把你的旧代码一直锁在内存里导致新代码迟迟不生效。3. 最常见的坑validate_timestamps 设置先看一个典型的错误配置opcache.enable1 opcache.validate_timestamps0 opcache.revalidate_freq0这里最大的问题就是validate_timestamps0。这个参数的意思是关闭文件时间戳校验。一旦关闭OPcache 就完全信任内存里的缓存根本不去检查源文件有没有被修改过。结果就是你改了代码服务器完全不知道一直用旧缓存。生产环境为了性能很多人喜欢把这个参数设成 0但代价就是每次发布代码后必须手动清缓存否则新代码永远不生效。如果你没有配套的清理机制建议还是老老实实开启时间戳校验。4. 推荐的稳妥配置下面这套配置是我在实际项目中验证过的兼顾了性能和代码更新的及时性opcache.enable1 opcache.memory_consumption128 opcache.interned_strings_buffer8 opcache.max_accelerated_files10000 opcache.validate_timestamps1 opcache.revalidate_freq2 opcache.fast_shutdown1关键点在于validate_timestamps1配合revalidate_freq2。意思是每 2 秒检查一次源文件的时间戳如果发现文件有更新就重新编译并替换缓存。这样既不会每次都去读磁盘性能损耗很小又能保证代码修改后最多 2 秒内生效。5. 代码更新后如何手动清缓存有时候你确实改了配置但线上环境还是缓存了旧代码这时候就需要手动清理。最直接的办法是重启 PHP-FPMsudo systemctl restart php-fpm如果你用的是 PHP 内置的 OPcache 函数也可以在代码里加一个管理接口通过调用opcache_reset()来清空缓存?php // 仅限管理员调用注意加权限校验 if (isset($_GET[action]) $_GET[action] clear) { opcache_reset(); echo OPcache 已清空; }不过要提醒一句这个接口一定要加权限控制否则任何人都能触发清缓存反而会影响线上性能。6. 其他容易忽略的配置项除了时间戳校验还有几个参数也值得注意。比如opcache.max_accelerated_files它决定了最多能缓存多少个 PHP 文件。如果你的项目文件很多这个值设小了超出部分就不会被缓存等于白开了 OPcache。再比如opcache.memory_consumption默认 128M 一般够用但如果项目特别大可以适当调高。不过也别盲目调大内存是有限的给 OPcache 太多反而挤压了其他进程的空间。7. 小结OPcache 本身是个好东西用好了能明显提升 PHP 应用的响应速度。但配置的时候一定要想清楚你是更看重性能还是更看重代码更新的及时性如果两者都想要那就用validate_timestamps1加一个合理的revalidate_freq再配合发布流程里的手动清缓存机制基本就能避免代码不更新这种坑了。希望这篇文章能帮到你。如果你也遇到过类似的坑欢迎在评论区聊聊你的解决方案。
1. 引言很多朋友在部署 PHP 项目时都遇到过这样一个诡异的现象明明把代码改好了上传到服务器刷新页面却还是老样子。清浏览器缓存没用重启 Nginx 也没用折腾半天才发现问题出在 OPcache 上。今天这篇文章就结合我自己的踩坑经历聊聊 OPcache 配置里那些容易让人翻车的细节希望能帮大家少走弯路。2. 什么是 OPcacheOPcache 是 PHP 官方自带的一个字节码缓存扩展。它的原理很简单PHP 脚本第一次被请求时会先编译成字节码OPcache 把编译结果存到内存里下次再请求就直接用缓存省掉重复编译的过程从而提升性能。听起来很美好对吧但问题恰恰出在这里——缓存是双刃剑。如果配置不当它会把你的旧代码一直锁在内存里导致新代码迟迟不生效。3. 最常见的坑validate_timestamps 设置先看一个典型的错误配置opcache.enable1 opcache.validate_timestamps0 opcache.revalidate_freq0这里最大的问题就是validate_timestamps0。这个参数的意思是关闭文件时间戳校验。一旦关闭OPcache 就完全信任内存里的缓存根本不去检查源文件有没有被修改过。结果就是你改了代码服务器完全不知道一直用旧缓存。生产环境为了性能很多人喜欢把这个参数设成 0但代价就是每次发布代码后必须手动清缓存否则新代码永远不生效。如果你没有配套的清理机制建议还是老老实实开启时间戳校验。4. 推荐的稳妥配置下面这套配置是我在实际项目中验证过的兼顾了性能和代码更新的及时性opcache.enable1 opcache.memory_consumption128 opcache.interned_strings_buffer8 opcache.max_accelerated_files10000 opcache.validate_timestamps1 opcache.revalidate_freq2 opcache.fast_shutdown1关键点在于validate_timestamps1配合revalidate_freq2。意思是每 2 秒检查一次源文件的时间戳如果发现文件有更新就重新编译并替换缓存。这样既不会每次都去读磁盘性能损耗很小又能保证代码修改后最多 2 秒内生效。5. 代码更新后如何手动清缓存有时候你确实改了配置但线上环境还是缓存了旧代码这时候就需要手动清理。最直接的办法是重启 PHP-FPMsudo systemctl restart php-fpm如果你用的是 PHP 内置的 OPcache 函数也可以在代码里加一个管理接口通过调用opcache_reset()来清空缓存?php // 仅限管理员调用注意加权限校验 if (isset($_GET[action]) $_GET[action] clear) { opcache_reset(); echo OPcache 已清空; }不过要提醒一句这个接口一定要加权限控制否则任何人都能触发清缓存反而会影响线上性能。6. 其他容易忽略的配置项除了时间戳校验还有几个参数也值得注意。比如opcache.max_accelerated_files它决定了最多能缓存多少个 PHP 文件。如果你的项目文件很多这个值设小了超出部分就不会被缓存等于白开了 OPcache。再比如opcache.memory_consumption默认 128M 一般够用但如果项目特别大可以适当调高。不过也别盲目调大内存是有限的给 OPcache 太多反而挤压了其他进程的空间。7. 小结OPcache 本身是个好东西用好了能明显提升 PHP 应用的响应速度。但配置的时候一定要想清楚你是更看重性能还是更看重代码更新的及时性如果两者都想要那就用validate_timestamps1加一个合理的revalidate_freq再配合发布流程里的手动清缓存机制基本就能避免代码不更新这种坑了。希望这篇文章能帮到你。如果你也遇到过类似的坑欢迎在评论区聊聊你的解决方案。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
