FrankenPHP 1.4 Worker 模式下必须启用并针对性配置OPcache：需设opcache.enable=1且opcache.enable_cli=1；内存建议≥256MB、文件数≥20000、禁用时间戳校验（validate_timestamps=0）并配合opcache_reset()或SIGUSR2热重载。
FrankenPHP 1.4 的 Worker 模式下，OPcache 不仅要开启，更要针对性配置——因为常驻进程会让 OPcache 的缓存行为和生命周期发生根本变化。传统 PHP-FPM 下 OPcache 主要省掉“编译”，而 Worker 模式中它还承担着避免重复加载类、配置与路由定义的关键角色。若配置不当，轻则缓存未命中、启动开销残留，重则内存持续增长或脚本失效。
必须启用并强制 CLI 环境也生效
Worker 进程由 FrankenPHP 启动，本质是 PHP CLI 模式运行（非 CGI/FastCGI），因此 opcache.enable_cli=On 是硬性要求。否则即使 opcache.enable=On，worker.php 入口及后续所有 require_once / autoload 加载的类文件都不会进入 OPcache，框架每次请求仍需重新解析。
- 在 php.ini 中确认两行均已开启：
opcache.enable=1
opcache.enable_cli=1 - 重启 FrankenPHP（不是 reload）使配置生效；可通过
php -i | grep opcache验证 CLI 环境下的 OPcache 是否 active
调大缓存容量与键值空间
Worker 模式长期运行，加载的文件远超单次请求量。默认的 64MB 和 2000 条脚本缓存很快会满，触发淘汰策略，导致热点类反复编译。
- 建议最小配置：
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.interned_strings_buffer=16 - 若项目含大量 Composer 包或模板文件，可进一步提升 memory_consumption 至 512；max_accelerated_files 建议设为实际文件数的 1.5 倍（可用
find ./app -name "*.php" | wc -l估算） - 注意：这些值需与服务器内存匹配，避免与其他服务争抢
禁用运行时校验，但保留部署级刷新机制
Worker 模式下，文件时间戳检查（opcache.validate_timestamps）若开启，每个请求都可能触发 stat() 系统调用，增加 I/O 开销；若关闭，则需人工控制更新时机。
立即学习“PHP免费学习笔记（深入）”；
- 生产环境推荐：
opcache.validate_timestamps=0
opcache.revalidate_freq=0 - 但必须配套部署流程：代码更新后执行
opcache_reset()或向 FrankenPHP 发送SIGUSR2信号（FrankenPHP 1.4 支持该信号热重载 OPcache） - 开发环境可设为
opcache.validate_timestamps=1并配合理想的revalidate_freq=2，兼顾便利与性能
配合 FrankenPHP 的 Worker 生命周期做清理控制
OPcache 本身不感知请求边界，但 Worker 模式要求每次请求前状态干净。若应用层未重置全局静态变量或单例，而 OPcache 又缓存了含静态状态的类，就可能引发跨请求污染。
- 这不是 OPcache 配置问题，但与其强相关：确保你的 worker.php 入口在每次请求开始前调用类似
CodeIgniter\Services::reset()或框架等效清理方法 - 避免在类定义中直接初始化耗资源的静态属性（如 new PDO(...)），改用延迟加载或容器管理
- 可借助
opcache_get_status()['scripts']定期采样，确认核心框架文件是否稳定驻留且未被频繁淘汰
