phpEnv 默认不支持PHP-FPM，仅提供Apache mod_php或Nginx+PHP-CGI模式；真正可调的并发参数仅有Nginx worker数、PHP-CGI进程数、memory_limit和max_execution_time；强行引入PHP-FPM在Windows下不稳定且无运维价值。
phpEnv 是 Windows 下的 PHP 集成环境（类似 XAMPP、WAMP），但它不自带 PHP-FPM —— 它默认使用 Apache 的 mod_php 模式，或可选 Nginx + PHP-CGI（非 FPM）。所以如果你在 phpEnv 里看到 php-fpm.conf 或想调 pm.max_children，大概率是误配或手动启用了非标准组件。
确认你真在用 PHP-FPM
很多用户以为「装了 phpEnv 就能直接改 php-fpm 参数」，其实不是：
-
phpEnv默认不安装、不启用php-fpm；它启动的是php-cgi.exe（通过 Nginx 的fastcgi_pass转发），但这是「CGI 模式」，不是php-fpm进程管理器。 - 真正的
php-fpm需要 Windows 编译版（如 php-sdk binaries 提供的php-fpm.exe），且需手动配置服务、监听套接字、进程池等 ——phpEnv界面里没有对应开关。 - 你在
phpEnv的「PHP 配置」里看到的php.ini修改，只影响 PHP 解释器本身，不影响进程数 ——pm.*类参数根本不在php.ini里，而在php-fpm.conf或www.conf中。
phpEnv 下实际能调的并发相关参数
如果你坚持用 phpEnv（Windows 开发/测试场景），真正可调、有影响的只有这几个地方：
-
Nginx worker 数量：打开
phpEnv\nginx\conf\nginx.conf，改worker_processes。Windows 下建议固定为1（多进程效果差），别设成auto。 -
PHP-CGI 启动数量：在
phpEnv主界面 → 「服务设置」→ 「Nginx+PHP」选项卡 → 找到「PHP-CGI 进程数」滑块（常见值 4–12）。这个值决定同时能跑几个php-cgi.exe实例 —— 它就是你实际的「最大并发 PHP 进程数」，但和php-fpm的pm.max_children不是一回事。 -
每个 PHP-CGI 的内存上限：编辑
phpEnv\php\php.ini，调memory_limit = 128M（别超过 256M，Windows 内存碎片多，太高易崩溃）。 -
脚本超时控制：同样在
php.ini，确保max_execution_time = 30（太长会卡住 CGI 进程，拖垮整个池）。
为什么不要强行在 phpEnv 里塞 php-fpm
有人会下载第三方 php-fpm.exe 放进 phpEnv 目录，再手动写 php-fpm.conf，结果发现：
立即学习“PHP免费学习笔记（深入）”；
- Windows 下
php-fpm不支持dynamic模式，只能用static，pm.start_servers等参数无效； - 无法用
systemctl或service管理，得靠start /B php-fpm.exe -y ...，一关终端就退出； -
listen = 127.0.0.1:9000容易被杀毒软件拦截，或与 IIS/其他服务端口冲突； - 日志不自动轮转，
slowlog基本不可用，出问题只能看黑窗口一闪而过的报错。
换句话说：能跑，但不稳定、难排查、无运维价值 —— 这不是开发环境该干的事。
真正需要高并发？换环境
如果你的场景是「本地压测接口 QPS」「模拟多用户登录」「调试队列消费」，phpEnv 的 CGI 模式撑到 50–100 并发就到头了。这时更靠谱的做法是：
- 用
Docker Desktop for Windows跑官方php:8.3-fpm+nginx:alpine，完整复现生产 FPM 配置； - 或直接在 WSL2（Ubuntu）里搭 LNMP，
apt install php-fpm后所有pm.*参数原生可用； - 若只是临时验证逻辑，用
php -S内置服务器 +xdebug单步就够了，根本不需要并发。
硬在 phpEnv 里折腾 pm.max_children，就像给自行车加涡轮增压——方向错了，力气白费。
