enable_reuse_port是触发内核级负载分发的机制，需配合worker_num≥2、增大backlog、启用daemonize等配置才有效，单worker或容器环境未适配时应禁用。
enable_reuse_port 是什么，为什么不能只设为 true 就完事
它不是开关，而是触发内核级负载分发机制的钥匙。Linux 从 3.9+ 开始支持 SO_REUSEPORT，启用后，多个 worker 进程能各自监听同一端口，由内核在 accept 队列层面做无锁分发——这直接绕开了传统单 accept 线程 + 多 worker 的锁争抢瓶颈。但前提是：必须配合 worker_num > 1，且不能和 reactor_num 混用（后者是单进程内 reactor 线程数，与端口复用无关）。
enable_reuse_port = true 时常见的三个错误现象
常见错误不是配置不生效，而是生效后引发新问题：
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 服务启动失败并报错
Address already in use：说明有残留进程占着端口，或前一次未正常退出导致TIME_WAIT堆积；执行ss -tuln | grep :9501清理后再启 - 连接数上不去，
netstat -s | grep -i "listen overflows"显示溢出：说明每个 worker 的 backlog 队列太小，默认是 512，需同步调大backlog参数（如设为 8192） - CPU 利用率不均衡，部分 worker 负载极高：未开启
process_cpu_affinity或未手动绑定 CPU，导致内核调度偏斜；建议搭配process_cpu_affinity => true或在WorkerStart中调用swoole_set_cpu_affinity()
和 enable_reuse_port 相关的必须配套参数
单独开 enable_reuse_port 是危险操作，以下三项必须同步检查：
-
worker_num至少为 2，否则复用无意义；推荐值为 CPU 核心数（非超线程数），例如 8 核机器设为 8 -
backlog必须显式增大，否则每个 worker 的连接队列仍是默认 512，容易丢连接；生产环境建议设为8192 -
daemonize应为true，避免前台运行时被信号中断导致端口未释放；同时确保日志路径可写，否则启动可能静默失败
为什么有些场景反而要禁用 enable_reuse_port
它不是银弹。以下情况应设为 false：
- 单 worker 场景（
worker_num = 1），此时复用无实际作用，还多一次系统调用开销 - 使用 Docker/K8s 且未配置
hostNetwork: true，容器网络栈可能不完全支持SO_REUSEPORT，导致部分 pod 启动失败 - 需要精确控制连接分发逻辑（比如按 IP 哈希路由），此时应关闭复用，改用反向代理层（如 Nginx + ip_hash）做前置分发
