登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  php教程

PHP OPcache区分 CLI 与 FPM 的缓存进程的实现方法

来源:17golang原创

时间:2026-09-19 23:32:12 304浏览 收藏

排查 PHP 缓存时,最容易混淆的是把命令行的 php 和网站请求使用的 PHP-FPM 当成同一个运行入口。实际配置应按 SAPI 分开确认:CLI 是否启用 OPcache 看 opcache.enable_cli,FPM worker 则看通用的 opcache.enable 及其加载配置。官方资料可从这里查阅:https://www.php.net/opcache

实用做法是先分别确认 php.ini 路径,再分别读取 OPcache 状态;不要因为 CLI 显示 Off 就断定 FPM 没有缓存,也不要因为 FPM 已启用就假设每次 CLI 运行都会复用它的缓存。
  • CLI:一次命令通常对应一个独立的 PHP 进程,重点核对 opcache.enable_cli
  • FPM:网站请求由 FPM worker 处理,重点核对 worker 实际加载的配置和进程重载方式。
  • 发布:若关闭时间戳检查,代码更新后必须安排 OPcache 重置或 FPM 重启。

先分清 CLI 与 FPM 的运行入口

CLI 和 FPM 都是 PHP,但它们的 SAPI、启动参数、php.ini 查找路径和进程生命周期可能不同。先在命令行查看 CLI 自己的配置,不要把它当作网站请求的证据:

# 查看当前 CLI 使用的配置文件和扫描目录
php --ini

# 只筛选 OPcache 相关值,便于记录本次 CLI 结果
php -i | grep -E 'opcache.enable(_cli)?|opcache.validate_timestamps|Loaded Configuration File'

FPM 的配置则应从实际启动方式、服务单元或池配置中确认。最稳妥的做法是在受保护的诊断入口中读取 php_ini_loaded_file(),因为它反映的是处理网站请求的 SAPI,而不是当前终端的 CLI。

PHP CLI 与 FPM 分别加载配置并连接各自缓存上下文的结构说明图
图1:SAPI 边界说明图,展示 CLI 与 FPM 应分别核对配置和缓存上下文,不是运行截图。

分别配置 CLI 与 FPM 的 OPcache

开发机上,CLI 是否开启取决于测试和脚本的需要;PHP 官方配置文档给出的 opcache.enable_cli 默认值是 0。如果要让长时间运行的 CLI 工具受益,可以在 CLI 使用的配置文件中设置:

; CLI 需要 opcode 缓存时开启,避免误以为 FPM 的设置会自动生效
opcache.enable_cli=1
; 开发阶段保留时间戳检查,代码修改后更容易看到新内容
opcache.validate_timestamps=1
opcache.revalidate_freq=0

FPM 则在它实际加载的 php.ini 或管理配置中确认:

; FPM worker 使用通用 OPcache 开关
opcache.enable=1
; 生产环境可按发布策略调整,不能只改文件后等待请求自行刷新
opcache.validate_timestamps=0
; 关闭时间戳检查时,发布脚本必须安排重载或显式刷新

这里不建议把两段配置机械地复制到所有环境。CLI 的短命令、测试进程和 FPM worker 的共享缓存目标不同;关键是配置写入正确的 SAPI,并在重启或重载后重新读取状态。

用同一份脚本验证两个缓存上下文

可以准备一个只在内网或临时保护下使用的诊断脚本。它同时输出配置文件、SAPI 和 OPcache 状态,避免只看某一个开关:

命令行直接执行这份脚本,网页端则通过 FPM 访问同一份文件,两次输出的 sapiini 才是比较重点。诊断文件不要长期暴露在公网,也不要把完整状态数组直接输出给访客。

PHP OPcache 诊断脚本分别输出 CLI 和 FPM 的 SAPI、配置文件与缓存状态的结构说明图
图2:诊断结果说明图,展示同一检查项在 CLI 与 FPM 两个入口中的对照关系,不是运行截图。

处理代码变更与缓存刷新边界

opcache.validate_timestamps=1 时,OPcache 会按 opcache.revalidate_freq 检查脚本更新时间;把频率设为 0 通常更适合开发排查。若生产环境关闭时间戳检查,文件已经更新并不代表 worker 立刻使用新 opcode,发布流程需要显式调用 opcache_reset()、针对脚本调用 opcache_invalidate(),或重启/平滑重载 FPM。

如果 CLI 输出是新代码而网页仍是旧代码,优先检查 FPM 使用的 php.ini、worker 是否已重载,以及发布是否遗漏缓存刷新;不要先改业务代码。反过来,CLI 显示缓存关闭也不影响已经启用 OPcache 的 FPM 请求。

常见问题与迁移清单

为什么改了 php.ini 仍看不到变化? 因为修改的可能是 CLI 配置,而请求实际由 FPM 处理;先比较两个入口的 php_ini_loaded_file()

FPM 开启了,CLI 要不要也开启? 只有 CLI 脚本本身需要重复执行并从 opcode 缓存获益时才开启,测试脚本则应结合测试隔离和结果稳定性决定。

生产环境怎样避免旧代码? 把 FPM 重载或 OPcache 刷新写进发布步骤,并把 validate_timestamps 的取值和回滚动作一起记录。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>