应根据业务流量特征、资源约束和延迟敏感度选择php-fpm pool模式：dynamic适合波动流量的web服务；static适用于稳定高吞吐场景；ondemand仅限极低频或资源受限环境；须先定模式再调参。
选哪种 PHP-FPM pool 进程管理模式，关键看你的业务流量特征、资源约束和延迟敏感度，不是配置越“高级”越好，而是匹配真实场景。
dynamic（动态模式）：大多数 Web 服务的默认选择
适合流量有波动、需要兼顾响应速度与内存效率的典型场景，比如 CMS 系统、用户后台、电商前台、API 接口层（非网关级）。
- 启动时按 pm.start_servers 预热一批进程，避免冷启动抖动
- 空闲进程数维持在 pm.min_spare_servers～pm.max_spare_servers 区间，既防突发又不堆闲置
- pm.max_children 是硬上限，必须大于等于峰值并发 ÷ 单请求平均耗时（秒）× 安全冗余（1.2–1.5），否则会丢请求
- PHP 8.5.5 中注意：pm.max_spare_servers 设太高易导致空闲进程滞留，因内存回收机制响应滞后
static（静态模式）：高吞吐、低延迟、负载稳定的专用服务
适用于内部 API 网关、定时任务调度器、微服务后端等——流量可预测、CPU/内存充足、不能容忍任何 fork 延迟。
- 所有子进程数量固定为 pm.max_children，无创建/销毁开销，稳定性高
- 内存占用恒定，适合容器化部署中资源配额明确的环境
- 风险点明显：若预估并发不准，要么浪费内存（设太高），要么排队超时（设太低）
- 不推荐用于 Nginx + PHP-FPM 的通用 Web 入口，慢脚本会直接卡死全部连接
ondemand（按需模式）：极低频或资源极度受限场景
仅建议用于个人博客、CI 构建钩子、后台管理页（日均请求数＜100）、调试环境等。
- 启动时不创建任何 worker，首个请求触发 fork，节省冷态内存
- pm.process_idle_timeout 必须设短（如 10–30 秒），否则空闲进程长期驻留反而更耗内存
- PHP 8.5.5 中冷启动延迟比 8.1/8.2 略高，频繁请求下 master 进程 CPU 占用上升明显
- 不适用于用户直连入口，也不适合配合负载均衡器使用——连接风暴会压垮 master 调度逻辑
不复杂但容易忽略：模式选错，调参再细也救不了架构失配。先定模式，再调参数，顺序不能反。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
