上周接到一个紧急任务：客户反馈系统太慢，核心接口响应时间超过 1200毫秒。排查下来发现，PHP 每次请求都在重新编译代码，Opcache 形同虚设。
经过一番调优，最终把接口响应时间从 1200ms 压到了 180ms，性能提升 6 倍多。今天分享一下整个排查和优化过程。
问题现象
客户的 PHP 项目跑在 4 核 8G 的服务器上，框架用的 Laravel。平时还好，一到高峰期接口就卡，响应时间飙到 1200ms 以上。
第一反应是查数据库，结果 SQL 都很快，慢查询日志干干净净。再看 CPU，高峰期直接跑满。
定位问题：Opcache 没生效
用 phpinfo() 一查，Opcache 确实开了，但是仔细看配置：
opcache.enable=1
opcache.memory_consumption=64 # 只给了 64MB
opcache.max_accelerated_files=2000 # 最多缓存 2000 个文件
opcache.validate_timestamps=1 # 每次都检查文件修改
opcache.revalidate_freq=2 # 2 秒检查一次
问题来了：Laravel 项目光 vendor 目录就有上万个 PHP 文件，2000 个缓存槽位根本不够用。Opcache 一直在淘汰缓存，等于没开。
Opcache 原理简单说
PHP 是解释型语言，每次请求都要经过：读取源码 → 词法分析 → 语法分析 → 编译成 Opcode → 执行。
Opcache 的作用就是把编译好的 Opcode 缓存在内存里，下次请求直接用，跳过编译步骤。
但如果缓存空间不够，或者频繁检查文件修改，缓存命中率就会很低，性能提升就打折扣。
优化配置
针对生产环境，我调整了以下配置：
; 内存给够，Laravel 项目建议 256MB 起步
opcache.memory_consumption=256
; 缓存文件数量，建议设置为项目文件数的 1.5 倍
; 用 find . -name "*.php" | wc -l 统计
opcache.max_accelerated_files=20000
; 生产环境关闭时间戳验证，部署时手动清缓存
opcache.validate_timestamps=0
; 字符串驻留内存，Laravel 用得多
opcache.interned_strings_buffer=16
; 快速关闭，加速请求结束
opcache.fast_shutdown=1
; 开启文件缓存，重启 PHP 后缓存不丢失
opcache.file_cache=/tmp/opcache
部署时清理缓存
关闭 validate_timestamps 后，代码更新不会自动生效。需要在部署脚本里加一行：
# 方式一：重启 PHP-FPM
systemctl reload php-fpm
# 方式二：调用 opcache_reset()
php -r "opcache_reset();"
# 方式三：用 cachetool（推荐）
cachetool opcache:reset --fcgi=/var/run/php-fpm.sock
优化效果
调整配置后，效果立竿见影：
如何监控 Opcache 状态
推荐用 opcache-gui 这个开源工具，放到项目里就能看到实时状态：
如果看到 "cache full" 或者命中率低于 95%，说明配置还需要调整。
常见坑点
1. max_accelerated_files 有上限，最大 100000，超过无效
2. 开发环境别关 validate_timestamps，不然改代码不生效
3. Docker 环境注意 opcache.file_cache 目录权限
4. 多台服务器部署时，每台都要清缓存
总结
PHP 性能优化，Opcache 是性价比最高的一招。配置得当，轻松提升几倍性能，而且不用改一行业务代码。
记住这几个关键配置：memory_consumption 给够、max_accelerated_files 设大、生产环境关闭 validate_timestamps。
