pm.max_children不是越大越好，需按可用内存×0.8÷单进程平均内存倒推计算，设高易致OOM或swap飙升，须配pm.max_requests=500防内存泄漏。
PHP-FPM 的 pm.max_children 不是越大越好
它直接决定你这台机器最多能同时处理多少个请求，但设高了反而会拖垮系统。进程数翻倍，内存和 CPU 上下文切换开销不是线性增长，而是指数级上升。
常见错误是看服务器有 16G 内存就盲目设成 200，结果每个 PHP 进程平均吃掉 80MB，光 FPM 就占满 16GB，系统开始频繁 swap，响应时间从 100ms 拉到 2s+。
- 估算公式：
pm.max_children≈ 可用内存 × 0.8 ÷ 单进程平均内存（用ps aux --sort=-%mem | head -n 10观察真实占用） - 必须配
pm.max_requests = 500，否则长期运行的子进程容易因未释放资源导致内存缓慢泄漏 - 禁用
pm = ondemand：启动慢、突发流量下子进程创建不及时，极易触发 502/504
Redis List 做队列时别用 GET/SET 模拟
用 SET key value EX 30 + 定时轮询“查有没有新任务”，本质是伪队列：CPU 白耗、并发冲突、延迟不可控，QPS 上千就撑不住。
真正轻量可靠的方案是 LPUSH + BRPOP 组合，消费端阻塞等待，无任务时不空转，延迟低且无竞态。
立即学习“PHP免费学习笔记（深入）”；
- 生产端：用
$redis->lPush('queue:order', json_encode($orderData)) - 消费端：用
$redis->brPop(['queue:order'], 30)，超时自动重试，不卡死 - 失败任务别直接
DEL，先lPush回队列尾部，并在 payload 里加retry_count字段，防止死信堆积 - 单个 worker 进程建议跑完 1000 条任务后主动退出，靠
supervisord拉起新进程，避免内存缓慢膨胀
缓存击穿不是小概率事件，互斥锁必须加在 DB 查询之前
热点 key（比如首页商品列表）过期瞬间，上百请求同时发现缓存为空，全部打到数据库，MySQL CPU 瞬间拉满——这不是假设，是上线当天就会发生的故障。
if (!$cache->get('goods:list')) { $data = $db->query(...); $cache->set(...); } 这种写法在并发下完全失效，因为多个请求几乎同时通过 get 判断，都进入查询分支。
- 加锁必须在
get之后、query之前：$redis->set('lock:goods:list', 1, ['nx', 'ex' => 5])，只有拿到锁的请求才查库 - 过期时间别写死：
$ttl = 3600 + rand(1, 600)，让 key 失效时间分散开，防雪崩 - 空值也得缓存：
$cache->set('goods:id:999', null, 60)，避免恶意或错误 ID 频繁穿透 - 别用 Memcached 的
cas()做锁——PHP 的Memcached::cas()在高并发下成功率极低，Redis 的原子命令更可靠
OPcache 开启后仍要检查 realpath_cache_size
即使开了 OPcache，如果文件路径解析频繁（比如大量 require_once 或自动加载），realpath_cache 耗尽会导致每次请求都重新 stat 文件，I/O 暴增，CPU 被 sys 时间吃掉大半。
默认 realpath_cache_size = 4096，中小项目够用；但 Composer 自动加载 + 大量 vendor 类时，很容易打满。
- 检查是否打满：用
php -r "print_r(realpath_cache_get());"看缓存条目数 - 调大配置：
realpath_cache_size = 4096k（注意单位是 k，不是字节） - 同时加大
realpath_cache_ttl = 600，避免每 2 分钟全量刷新一次路径缓存 - 这个配置改完必须重启 PHP-FPM，仅 reload 不生效
