要稳定支撑5万以上并发TCP连接，必须同步调整PHP层（常驻模式、进程数=CPU核数×2.5向上取整、启用CLI版opcache）、内核层（limits.conf设nofile为1048576、somaxconn等TCP队列参数调至65535）和应用层（全异步I/O、禁用阻塞调用、异步日志）。
Workerman 4.0.34 单机要稳定支撑 5 万以上并发 TCP 连接，必须同步调整 PHP 层、内核层和应用层三处关键参数，缺一不可，否则即使代码写得再规范，连接数卡在 1024 或 65535 就再也上不去。
PHP 层：启用常驻内存与进程数精准配置
第一步：确认 Workerman 已以守护进程模式启动，而非 php server.php 临时执行——后者每次请求都会重建进程，彻底失去高并发意义。
第二步：在 Worker 实例初始化后、Worker::runAll() 前，显式设置进程数：
$worker->count = 【CPU 核心数 × 2.5，向上取整】；若为 8 核服务器，则设为 20，而非盲目填 100。填过大反而因进程调度开销拖慢整体吞吐。
第三步：禁用 opcache.revalidate_freq（设为 0），并确保 opcache.enable_cli=1。Workerman 是 CLI 模式常驻，不启用 CLI 的 opcache，每个请求仍会重复解析 PHP 文件，CPU 会在无意义的字节码编译上空转。
内核层：突破文件描述符与 TCP 队列瓶颈
方法一：永久提升单进程文件描述符上限
编辑 /etc/security/limits.conf，追加两行：
* soft nofile 1048576
* hard nofile 1048576
重启用户 session 或重新登录生效。不改这个，php -r "echo posix_getrlimit()['soft'];" 永远显示 1024，Workerman 启动时会静默截断连接数。
方法二：调优 TCP 连接队列深度
执行命令：
sudo sysctl -w net.core.somaxconn=65535
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=65535
sudo sysctl -w net.core.netdev_max_backlog=5000
这三项必须同时调大，【net.core.somaxconn 是 accept 队列上限，而 listen() 系统调用传入的 backlog 参数若小于它，实际生效值取二者最小值】——Workerman 底层默认用 1024，必须通过 $worker->socketTransportOptions = ['backlog' => 65535]; 覆盖。
应用层：关闭阻塞操作，启用异步 I/O 组件
必须替换所有同步数据库调用。例如，将 mysqli_query() 全部改为 workerman/mysql 异步客户端，否则一个慢查询会让整个 Worker 进程卡住，后续所有连接排队等待，accept 队列迅速堆满。
HTTP 外部请求不能用 file_get_contents() 或 curl_exec()，改用 workerman/http-client，并确保设置了 timeout=3.0 和 connect_timeout=1.5。未设超时的阻塞请求，在网络抖动时会无限期挂起协程，导致连接泄漏。
日志写入必须异步。直接 error_log() 或 file_put_contents() 会阻塞事件循环。使用 workerman/logger 组件，或自行封装基于 swoole_timer_tick 的批量刷盘逻辑——每 200ms 合并写一次磁盘，而不是每次请求都落盘。
验证连接数是否真正生效
1. 启动服务后，立刻执行 ss -s | grep 'TCP:'，查看 total 的 established 数是否持续增长并稳定在目标值附近。
2. 用 ab -n 100000 -c 20000 http://127.0.0.1:8080/ 压测，观察 Workerman 自带 status 页面中 connections 字段——该值应接近你设定的并发目标，且无大量 time-wait 或 close-wait 积压。
3. 若 ss 显示 established 很高但 ab 报错 connection refused，说明 accept 队列已满，立刻检查 $worker->socketTransportOptions 中的 backlog 是否与 somaxconn 一致。
