ThinkPHP6稳定支撑1万并发需五层协同优化：一、DSN加connect_timeout=3并用IP绕DNS；二、PHP-FPM精调pm.max_children与OPcache；三、数据库启持久连接、读写分离、Redis缓存高频数据；四、邮件等耗时操作全异步入队；五、终极方案用think-swoole切换协程模型。
ThinkPHP6要稳定支撑1万并发请求并避免超时，不能只调大max_execution_time或等框架自动扛住——它本质是同步阻塞模型，必须从网络层、PHP运行时、数据库、缓存、任务调度五个层面系统性拆解瓶颈。单点优化无效，组合落地才有效。
一、先掐断建连超时这个“隐形杀手”
很多“卡30秒才报错”的情况，根本不是代码慢，而是TCP连接建立失败却等满系统默认超时（Linux 75秒）。这在高并发下会批量触发：
- 数据库DSN里强制加
connect_timeout=3，例如：mysql:host=192.168.1.100;port=3306;dbname=test;connect_timeout=3 - 把
hostname全换成IP地址，绕过DNS解析延迟 - TP6.1+启用连接池后，再配
'pool' => ['get_timeout' => 1000]（单位毫秒），控制“拿连接”这一步最多等1秒
二、让PHP-FPM真正撑住万级并发
默认配置下，一个FPM worker只能处理1个请求。1万并发意味着至少需要1万worker，内存直接爆掉。必须精调：
-
pm.max_children别盲目设大，按内存算：比如每个worker占30MB，64GB服务器最多设2000左右 - 改用
pm = ondemand模式，空闲时释放进程，高峰时快速拉起 - 配合OPcache：确保
opcache.enable=1且opcache.memory_consumption=256，避免重复编译脚本 - 关掉调试：
APP_DEBUG = false，禁用trace和大量日志写入
三、数据库不能成为单点堵点
MySQL默认max_connections=151，远不够万级并发。但也不能简单调到1万——连接数过多反而拖垮服务端。关键在复用与分流：
立即学习“PHP免费学习笔记（深入）”；
- 开启PDO持久连接：
'params' => [\PDO::ATTR_PERSISTENT => true]，复用底层TCP连接 - 读写分离必须落地：主库只写，从库分担90%以上SELECT；用中间件控制路由，别依赖框架自动识别
- 高频查询走Redis缓存，特别是用户会话、商品信息、配置项；缓存key要有明确过期时间，防雪崩
- 库存类操作用Redis原子命令（
DECRBY+GET）代替DB行锁，避免事务长时间占用连接
四、耗时操作必须剥离主线程
发邮件、生成PDF、同步第三方数据……这些操作在1万并发下若还在HTTP响应中执行，等于让所有用户排队等它完成。必须异步化：
- 订单创建后，立刻
Queue::push(new SendOrderEmailJob($order))，不等结果 - 中小规模选Redis驱动（低延迟、免部署），核心流程如支付回调用RabbitMQ（支持ACK、死信、重试）
- 消费者进程用
php think queue:work --daemon常驻，配合supervisor保活 - 队列任务内做步骤级超时控制，比如循环处理订单时每处理100条检查
time() - $start > 240，超时主动退出
五、终极方案：换运行模型，用Swoole协程
FPM天生不适合万级并发。Swoole能在一个进程里并发处理数千请求，是TP6突破QPS天花板的关键：
- 安装Swoole扩展，确认
extension=swoole已加载 - 用
think-swoole官方扩展启动协程HTTP服务器，替代Nginx+PHP-FPM - 数据库操作改用Swoole协程MySQL客户端，连接复用率提升10倍以上
- 原有同步代码基本不用大改，Swoole自动将
file_get_contents、cURL等IO操作协程化
不复杂但容易忽略：超时从来不是单一参数问题，而是连接、等待、执行、释放四个环节的连锁反应。从DSN加connect_timeout开始，一层层往下压，才能让1万请求真正跑得通、不卡、不崩。
