phpEnv下OPcache不会自动生效，必须为每个PHP版本单独在php.ini中启用opcache.enable=1并调优参数，否则多项目共存时将反复编译、CPU虚高、TTFB延迟明显。
phpEnv 环境下 OPcache 不会自动生效，必须手动在每个 PHP 版本的 php.ini 中单独启用并调优，否则多项目共存时仍会反复编译、CPU 虚高、TTFB 延迟明显。
确认 phpEnv 下各版本是否加载了 opcache.so
phpEnv 是多版本 PHP 共存管理工具，它为每个 PHP 版本维护独立的 php.ini 和扩展目录。默认安装不保证开启 OPcache，也不能复用全局配置。
- 先查当前使用的 PHP 版本：
phpenv version - 再定位该版本的配置路径：
php --ini（输出类似Loaded Configuration File: /home/user/.phpenv/versions/8.2.12/etc/php.ini） - 检查扩展是否已载入：
php -m | grep opcache—— 若无输出，说明未启用或未编译进该版本 - 若缺失，需进入对应 PHP 源码目录重新编译：
./configure --enable-opcache ...，或使用 phpenv 安装时加--enable-opcache参数（部分旧版 phpenv 不支持，建议升级）
为每个 PHP 版本单独配置 opcache.enable=1 及关键参数
phpEnv 下不同项目可能绑定不同 PHP 版本（如 Laravel 用 8.2，老系统用 7.4），每个版本的 php.ini 必须独立配置，不能“配一个全生效”。
- 打开对应版本的
php.ini，在文件末尾添加或修改[opcache]区块 - 必设项（生产向）：
opcache.enable=1、opcache.memory_consumption=256、opcache.max_accelerated_files=20000 - 开发调试可设：
opcache.validate_timestamps=1+opcache.revalidate_freq=2（每 2 秒检查变更） - 严禁跨版本复用配置：PHP 7.4 的
opcache.optimization_level默认值与 8.2 不同，硬套可能触发 fatal error
重启对应 PHP-FPM 实例，而非全局服务
phpEnv 通常配合 php-fpm 使用，但它的 phpenv fpm-start 启动的是单版本 FPM 进程；改完配置后，必须只重启当前项目所用版本的 FPM，否则新配置不加载。
立即学习“PHP免费学习笔记（深入）”；
- 查正在运行的 FPM 进程：
ps aux | grep "php-fpm: master.*8.2" - 优雅重启（以 8.2 为例）：
kill -USR2 $(cat /home/user/.phpenv/versions/8.2.12/var/run/php-fpm.pid) - 验证是否生效：
php -r "var_dump(opcache_get_status()['opcache_enabled']);"应返回bool(true) - 注意：Nginx/Apache 不需要重启，只要 PHP-FPM 进程重载了配置即可
多项目部署后缓存冲突与清理策略
多个项目共享同一 PHP-FPM 进程池时（常见于 phpEnv + Nginx fastcgi_pass 到同一 socket），OPcache 是进程级共享内存，A 项目更新代码可能被 B 项目缓存污染，导致 Class not found 或逻辑错乱。
- 最稳妥方式：每个项目用独立 PHP 版本 + 独立 FPM socket（如
/tmp/php-fpm-8.2-laravel.sock），避免混用 - 若必须共用，上线时禁止设
opcache.validate_timestamps=0；推荐保持=1+opcache.revalidate_freq=5，平衡实时性与性能 - 紧急修复可用单文件刷新：
php -r "opcache_invalidate('/path/to/app/index.php', true);"，比opcache_reset()更精准，不影响其他项目 - 容器化部署中，
opcache_reset()常被禁用，此时只能 kill -USR2 重启对应 FPM master 进程
真正麻烦的不是开启 OPcache，而是多项目环境下每个 PHP 版本的配置隔离、FPM 进程归属判断、以及上线后缓存边界控制——这些细节一旦漏掉，反而会让性能更差。
