建议设为20000，因默认4000远低于composer项目文件量，可避免哈希冲突导致缓存失效；该值覆盖中大型项目并兼顾内存效率，jit启用时更需保障此容量以维持命中率。
PHP 8.6 中 opcache.max_accelerated_files 建议设为 20000，中大型项目可稳妥使用该值。
为什么是 20000？
这个数值不是随意定的，而是基于实际项目结构和 OPcache 内部哈希机制权衡的结果：
- 默认值 4000 远低于现代 Composer 项目的文件总量（Laravel、Symfony 等框架+vendor 常超 1.5 万文件）
- OPcache 使用哈希表索引文件，若
max_accelerated_files小于实际脚本数，会引发哈希冲突，导致部分文件无法被缓存或频繁淘汰 - 设为 20000 可覆盖绝大多数中大型应用（含 vendor 类文件），同时避免过度分配影响内存利用率
怎么确认你是否需要调高？
别靠猜，用数据判断：
- 运行
opcache_get_status()['opcache_statistics']['num_cached_scripts']查看当前已缓存脚本数 - 对比你的项目 PHP 文件总数（含 vendor 下
*.php）：可用find /path/to/project -name "*.php" | wc -l - 如果缓存数长期接近或等于
max_accelerated_files，说明已到瓶颈，必须调高
PHP 8.6 特别注意点
在启用 JIT 缓存（opcache.jit_cache_enabled=1）时，更需确保文件容量充足：
- JIT 编译后的机器码也依赖 OPcache 的文件索引体系
- 若
max_accelerated_files不足，JIT 缓存命中率会下降，削弱 PHP 8.6 的性能优势 - 官方推荐配置中已将该值与
opcache.jit_buffer_size协同设定，20000 是经过验证的平衡点
要不要设成 0？
不建议。虽然设为 0 表示“无上限”，但：
- PHP 内部仍会按近似值（如 7963、39817）自动取整为质数，实际行为不可控
- 可能因哈希表过大导致内存碎片或初始化延迟
- 生产环境更推荐明确、可预期的值，比如 20000 或 32000（适用于超大型微服务项目）
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
