OPcache内存持续上涨主因是缓存条目堆积与淘汰失效，非OPcache本身吃内存；需调优memory_consumption、max_accelerated_files、validate_timestamps等参数，并关闭校验、排除黑名单、优化Composer加载。
OPcache 内存持续上涨说明缓存没被有效回收
不是 OPcache 本身“吃内存”，而是缓存条目长期堆积、无效脚本没被淘汰，或配置导致缓存策略失效。PHP 8.4 的 OPcache 默认参数偏保守，对低配或中高并发线上环境容易造成内存滞胀——尤其当 opcache.validate_timestamps=1 且 opcache.revalidate_freq 过小，会频繁触发全量校验并延迟淘汰旧缓存。
必须收紧的三个核心参数
重点不是加内存，而是让缓存“动起来”：进得有节制，出得有依据。
-
opcache.memory_consumption=64（1GB 内存机器）或128（2GB+），别设 256+；过大会掩盖淘汰问题，反而让无效缓存赖着不走 -
opcache.max_accelerated_files必须略大于实际 PHP 文件数（find /path/to/app -name "*.php" | wc -l），超太多会浪费哈希表空间；中小项目设4000，Laravel/Symfony 类多项目可到10000，但绝不盲目堆到 20000+ -
opcache.validate_timestamps=0+opcache.revalidate_freq=0（上线后必须成对关闭校验），否则每次请求都 stat 文件，不仅慢，还会抑制缓存清理逻辑
容易被忽略的“内存隐形消耗点”
这些配置不显眼，但直接影响 OPcache 实际内存占用和稳定性：
-
opcache.interned_strings_buffer=8：字符串缓冲区，默认 8MB 足够；设太高（如 16 或 32）会在每个 FPM worker 中重复分配，1GB 机器上 3 个子进程就多占 24MB+ -
opcache.fast_shutdown=1：启用后能减少 worker 退出时的内存残留，避免碎片化累积 -
opcache.enable_cli=0：CLI 模式下完全不需要 OPcache，留着会白占几 MB - 禁用
xdebug：哪怕只是加载未启用，也会强制禁用 OPcache JIT 和部分缓存机制，检查php -m输出里是否还有 xdebug
验证和定位真实瓶颈
光改参数不够，得看它到底在缓存什么：
立即学习“PHP免费学习笔记（深入）”；
- 执行
php -r "print_r(opcache_get_status());"，重点关注：memory_usage.used_memory（已用）、opcache_statistics.hits（命中率）、opcache_statistics.misses（未命中）——如果 hits 很低，说明缓存根本没用上 - 检查
opcache_statistics.blacklist_misses：若数值高，说明大量文件被黑名单过滤（比如日志、临时目录被扫描进来），需在opcache.blacklist_filename中明确排除 - 用
opcache_get_status()['scripts']看缓存了哪些文件，确认没把vendor/composer/autoload_*.php这类大体积文件反复加载进来（Composer 自动加载优化见下条）
最常被漏掉的是 Composer 自动加载——vendor/autoload.php 单次加载就可能占 20–40MB，且每次请求都重新 include。务必运行 composer dump-autoload --optimize --classmap-authoritative，再配合 opcache.preload 预加载关键类（注意 preload 脚本本身不能含动态逻辑）。
