PHP-FPM 应选 static 模式，适用于 ThinkPHP + Redis 缓存完备、QPS＞200 且波动小的场景；需设 pm.max_children 防内存溢出，避免 dynamic 模式因频繁 fork/kill 导致抖动。
PHP-FPM 的 pm 模式选哪个？static 还是 dynamic？
ThinkPHP 应用在高并发下卡顿，八成出在 PHP-FPM 进程管理策略上。默认的 dynamic 模式看似智能，但实际容易因频繁 fork/kill 子进程导致响应抖动；而 static 在内存充足、请求较稳定时反而更稳。
-
static：适合 ThinkPHP + Redis 缓存完备、QPS 较高（>200）且波动小的场景；需手动设死pm.max_children，避免内存溢出 -
dynamic：适合低流量或开发环境；但pm.start_servers、pm.min_spare_servers、pm.max_spare_servers三者差值别超过 10，否则空闲进程反复启停 - 千万别用
ondemand：ThinkPHP 启动开销大，每次请求都 fork，首字节延迟直接翻倍
示例（4 核 8G 服务器跑中型 ThinkPHP 后台）：
pm = static<br>pm.max_children = 32<br>pm.max_requests = 1000
Nginx 的 fastcgi_pass 怎么配才不超时？
ThinkPHP 接口返回 504 Gateway Time-out，往往不是 PHP 执行慢，而是 Nginx 等不及 PHP-FPM 响应就断了连接。
-
fastcgi_read_timeout必须 ≥ PHP-FPM 的request_terminate_timeout（如果开了），且建议比 ThinkPHP 最长接口耗时多留 3–5 秒缓冲 -
fastcgi_connect_timeout和fastcgi_send_timeout通常设为 3–6 秒足够；设太大反而掩盖后端故障 - 确认
fastcgi_pass指向的是 Unix socket（如unix:/var/run/php/php8.1-fpm.sock）而非127.0.0.1:9000，后者在高并发下容易触发端口耗尽
关键配置片段：
location ~ \.php$ {<br> fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;<br> fastcgi_read_timeout 30;<br> fastcgi_connect_timeout 5;<br> fastcgi_send_timeout 5;<br>}
立即学习“PHP免费学习笔记（深入）”；
ThinkPHP 自身哪些配置会拖慢 PHP-FPM 进程回收？
PHP-FPM 进程卡在“idle”状态迟迟不退出，或者 pm.max_requests 到了却不重启，大概率是 ThinkPHP 的运行时残留没清干净。
- 关闭
app_debug = true：调试模式会加载大量日志、trace、异常捕获逻辑，显著延长单次请求生命周期 - 禁用
log_write_mode = 3（实时写文件）：高并发下磁盘 I/O 成瓶颈，改用log_write_mode = 1（异步队列）或对接monolog+syslog - 检查是否误启了
trace或debug中间件，尤其在生产路由里没关掉 - 确认
cache.type没设成file：文件缓存锁竞争严重，换成redis或apcu可释放大量进程等待时间
为什么调了 PHP-FPM 和 Nginx，ThinkPHP 还是偶发 502？
502 不是配置没生效，而是 PHP-FPM 子进程崩溃后，Nginx 拿不到响应——这时候得看错误链路最底端。
- 查
/var/log/php8.1-fpm.log里有没有WARNING: [pool www] child 12345 exited on signal 11 (SIGSEGV)，这是 PHP 扩展（比如 xdebug、imagick）引发的段错误 - 确认
opcache.enable_cli = 0：ThinkPHP 的命令行任务（如定时任务）若误启 opcache，会导致共享内存冲突 - 检查
memory_limit是否被 ThinkPHP 的ini_set('memory_limit', ...)动态修改过；动态设太高可能让 PHP-FPM 进程超出rlimit限制而被系统 kill - 留意
request_slowlog_timeout日志：慢日志里出现大量think\console\Command->execute卡住，说明命令行任务没做守护或超时控制
真正难调的从来不是参数数字，而是 PHP-FPM 进程状态和 ThinkPHP 生命周期之间的隐式耦合——比如一个没 close 的 Redis 连接、一个未 unset 的大数组、一次没 catch 的 PDO 异常，都会让进程带病服役到被强制杀死那一刻。
