TP6万并发超时主因是Nginx/FastCGI、PHP-FPM、TP6三层协同超时未对齐及资源不匹配；需同步调大fastcgi_connect/send/read_timeout至300秒，设pm=static且pm.max_children=500，关闭调试中间件并迁移至think-swoole协程模型。
一万并发下网关超时报错，核心不是TP6本身扛不住，而是整个请求链路在某个环节被卡住或提前中断。重点要分三层排查：Nginx/FastCGI层、PHP-FPM层、TP6应用层。
Nginx与FastCGI超时配置必须调大
默认的60秒超时在高并发长任务场景下完全不够用，尤其遇到导出、批量处理等操作时，Nginx会在后端还没返回时就主动断开连接，返回504 Gateway Timeout。
- 在Nginx站点配置中，增加或修改以下参数（单位为秒）：
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
proxy_connect_timeout 300;
proxy_send_timeout 300;
proxy_read_timeout 300; - 同时检查
fastcgi_pass指向的PHP-FPM socket路径是否正确（如unix:/run/php/php8.1-fpm.sock），权限是否允许Nginx用户读写 - 若使用宝塔或LNMP一键包，需进入面板→网站→设置→配置文件，直接编辑，不能只改“超时时间”输入框（它可能只改了部分参数）
PHP-FPM资源必须匹配并发量
一万并发不等于要起一万个PHP进程——那是灾难。关键是让FPM能稳定承接并排队调度，避免因资源耗尽直接返回502。
- 打开
/etc/php/{version}/fpm/pool.d/www.conf，重点调整：
pm = static
pm.max_children = 500
pm.start_servers = 100
pm.min_spare_servers = 100
pm.max_spare_servers = 200
request_terminate_timeout = 300s
request_slowlog_timeout = 60s -
pm.max_children是硬上限，设太小会排队溢出；设太大则内存爆炸。500是中等服务器（32G内存）较稳妥起点，需按实际内存和单进程占用测算 - 重启服务：
systemctl restart php{version}-fpm，再用php-fpm -t验证配置语法
TP6本身要规避阻塞和连接泄漏
框架层的问题往往在压力下才暴露：比如数据库连接没释放、日志同步写磁盘、调试中间件未关闭，都会拖慢单个请求，放大超时风险。
立即学习“PHP免费学习笔记（深入）”；
- 关闭所有调试相关中间件：注释掉
app/middleware.php里的think\middleware\Trace::class、think\middleware\Debug::class等 - 数据库配置中禁用
'persistent' => true，启用'break_reconnect' => true防MySQL server has gone away - 确保
runtime/目录可写且不在NFS或低性能存储上；日志建议异步写（如用topthink/think-swoole或monolog对接Redis队列） - 不要在控制器里执行
sleep()、file_get_contents(远程地址)等同步阻塞操作，改用协程客户端（Swoole）或异步HTTP库
真正扛万级并发，得换运行模型
PHP-FPM本质是多进程+阻塞IO，一万并发意味着至少几千个PHP进程常驻，内存和上下文切换成本极高。这不是调参能根本解决的。
- 生产环境万级并发，推荐迁移到
topthink/think-swoole：它用协程复用少量进程处理大量连接，MySQL/Redis都支持异步驱动，响应更快、资源更省 - 启动命令：
php think swoole，配置config/swoole.php中'http' => ['worker_num' => 8, 'max_coroutine' => 3000] - 注意：迁移后必须关闭session文件存储（改用Redis）、禁用
app_debug、所有全局静态变量需重置（官方扩展已封装生命周期管理）
