ThinkPHP高并发性能瓶颈常源于PHP字节码重复编译，需禁用APP_DEBUG、合理配置OPcache参数并关闭模板自动检测等机制。
OPcache启用后TP应用仍频繁编译PHP文件？
直接结论：ThinkPHP在高并发下性能瓶颈常不在框架本身，而在PHP字节码重复编译。OPcache必须启用且配置合理，否则opcache.enable=1只是形同虚设。
常见错误是只开了OPcache但没关掉开发模式下的自动刷新机制——TP默认开启APP_DEBUG=true时，会强制绕过OPcache缓存，每次请求都重新加载和编译文件。
- 确认
php.ini中已启用：opcache.enable=1、opcache.enable_cli=0（CLI环境通常不需缓存） - 禁用TP的调试模式：
APP_DEBUG=false，并清空runtime/cache/和runtime/log/ - 关键参数调优：
opcache.max_accelerated_files=20000（TP项目文件多，缺省4000易溢出）、opcache.memory_consumption=128（单位MB，根据项目规模上调） - 避免使用
opcache.validate_timestamps=1上线环境——它会让OPcache每秒检查文件修改时间，高并发下I/O压力陡增；应设为0，配合部署时执行opcache_reset()或kill -USR2平滑重启PHP-FPM
ThinkPHP内置缓存驱动选Redis还是File？
答案很明确：高并发场景下，File缓存驱动必须弃用。不是因为性能差，而是Linux文件系统在大量并发写入时极易触发锁竞争和inode耗尽，file_put_contents阻塞超时现象频发。
Redis是更稳妥的选择，但要注意TP 6.x默认的redis驱动底层用的是PHP原生Redis扩展（非Predis），连接池和异常重试能力弱。
立即学习“PHP免费学习笔记（深入）”；
- 配置
cache.php时指定'type' => 'redis'，并确保'host'、'port'、'password'正确；若Redis启用了protected-mode yes但未设密码，会静默连接失败 - 务必设置
'timeout' => 2.5（单位秒），防止Redis响应慢拖垮整个请求链路 - 避免把大对象（如完整查询结果集）直存Redis——TP的
Cache::set()对>1MB数据会触发序列化警告，建议先json_encode再存，读取时json_decode - 不要依赖
Cache::remember()的默认TTL（3600秒），高频更新的数据应显式传60或300，避免缓存雪崩
路由与模板编译缓存被忽略的三个硬伤
TP在高并发下最常被低估的开销，来自路由解析和模板编译。即便开了OPcache，route.php每次请求仍会被TP重新加载解析；而view目录下模板首次访问时生成的编译文件，若权限或路径配置不对，会导致反复重建。
- 启用路由缓存：
php think route:cache，生成runtime/route_cache.php。注意该命令仅在APP_DEBUG=false时生效，且修改route.php后必须重新执行 - 模板编译路径必须可写且不跨分区：
'compile_path' => runtime_path() . 'html/，若runtime挂载在tmpfs内存盘，需确认noexec未启用，否则include()编译后PHP文件会报Permission denied - 关闭模板自动检测更新：
'auto_detect_layout' => false、'strip_space' => true（减少输出体积，间接降低网络延迟），这两项在生产环境无实际用途却消耗CPU
为什么OPcache命中率总上不去？
监控opcache_get_status()返回的opcache.hit_rate低于95%，基本说明有严重配置或代码问题。TP项目里最常见的干扰源是动态加载和eval()类操作。
- 检查是否误用了
Loader::import()或include_once(__DIR__.'/xxx.php')等运行时动态引入——这类文件不会被OPcache预编译，命中率统计里算作“miss” - 禁用所有
eval()、create_function()、assert()含代码字符串的调用，它们强制PHP跳过OPcache缓存路径 - TP的
think\facade\Log在APP_DEBUG=true时会记录完整SQL和trace，产生大量临时字符串拼接，间接导致OPcache内存碎片化；上线前必须关掉LOG_RECORD=true
真正难处理的是混合部署场景：同一台服务器跑多个TP站点，共用一个OPcache内存池，opcache.interned_strings_buffer设太小会导致字符串表频繁淘汰，此时应按站点隔离PHP-FPM pool，并各自配独立OPcache配置。
