OPcache仅设opcache.enable=1远远不够，必须合理配置max_accelerated_files（需大于项目PHP文件总数并取质数）、validate_timestamps（生产环境应为0并配合opcache_reset或优雅重启）、revalidate_freq等参数，否则将导致命中率低、I/O压力大、代码不更新等问题。
opcache.enable=1 是 PHP 性能提升最直接有效的起点，但仅开这个远远不够——缓存不是“开了就赢”，而是要分层选型、按需配置、防住坑点。
OPcache 配置不当会导致缓存不生效或频繁失效
很多项目在 php.ini 里写了 opcache.enable=1 就以为万事大吉，结果 opcache_get_status() 显示命中率长期低于 60%，甚至 opcache.memory_consumption 常年只用到 5MB。根本原因常是：
-
opcache.max_accelerated_files设得太小（比如默认 2000），而项目有 8000+ 个 PHP 文件，大量文件被踢出缓存 -
opcache.validate_timestamps=1在生产环境没关，每次请求都去磁盘检查文件修改时间，抵消了大部分加速收益 -
opcache.revalidate_freq=2这类低值在上线后没调回，导致刚缓存的字节码几秒就被清掉 - 没配
opcache.file_cache，PHP-FPM 重启后所有 opcode 全丢失，首请求必然慢
建议值（中等规模项目）：opcache.memory_consumption=128、opcache.max_accelerated_files=10000、opcache.validate_timestamps=0、opcache.revalidate_freq=60。改完必须重启 PHP-FPM，不能只 reload。
Redis 缓存键设计错误会引发穿透、雪崩和脏数据
用 $redis->get('user_'.$id) 看似简单，但实际线上容易出三类问题：
- 缓存穿透：
$id是用户可控参数（如 URL 中的?id=-1），查不到就反复打 DB，$redis->setex()根本不执行 - 缓存雪崩：所有热门键设成相同过期时间（如统一
3600），整点集体失效，DB 瞬间被打满 - 脏数据：更新 DB 后只删了
user_123，但关联的user_profile_123、user_stats_123没删，读出来不一致
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 对空结果也缓存（如
$redis->setex('user_-1', 60, 'null')），并约定客户端识别该值为“不存在” - 过期时间加随机偏移：
3600 + rand(0, 600) - 用前缀 + 标签管理关联键：
user:123:profile、user:123:stats，删时用SCAN+DEL批量清理 - 写 DB 成功后再删缓存，而不是删完缓存再写 DB（防止写失败导致缓存永久丢失）
文件缓存不加锁会导致并发写损坏
小型项目用 file_put_contents() 存缓存很常见，但两个请求几乎同时执行 getCache() → 都发现文件不存在 → 都走 DB → 都执行 file_put_contents()，最终只有一个结果能留下，另一个被覆盖。
更隐蔽的问题是：文件内容写到一半就被另一个进程读取，解序列化失败。
安全做法只有两个：
- 用
flock()加锁（注意：必须在file_put_contents()前获取写锁，并在写完后释放） - 改用原子写法：先写临时文件（如
$tmp = $file . '.tmp'），file_put_contents($tmp, $content)完毕后，再rename($tmp, $file)—— 这个操作在绝大多数文件系统上是原子的
别信“小项目并发低不用锁”——缓存失效那一刻，就是并发峰值时刻。
cURL 请求缓存必须指纹化，不能只靠 URL
很多人用 md5($url) 当缓存键，但 POST 请求的 body 不同、Header 中 Authorization 或 X-User-ID 不同，都会导致返回结果不同。只哈希 URL 必然命中错误缓存。
正确指纹应包含：
- 请求方法（GET/POST）
- 完整 URL（含 query string）
- 标准化后的 POST body（如
ksort()后http_build_query()） - 关键 Header 键值对（如
['Authorization', 'X-Region']）
示例生成方式：md5(json_encode(['post', $url, $body, $headers]))。缓存文件名用这个哈希，才能保证语义一致的请求拿到一致结果。
