SO_REUSEADDR 是解决服务器重启时“Address already in use”错误的关键选项，它允许新套接字绑定处于 TIME_WAIT 状态的端口，绕过 TCP 2MSL 等待限制，适用于单进程快速重启场景，对 TCP 和 UDP 均有效。
SO_REUSEADDR 是 TCP 服务重启时的保命选项
不加 SO_REUSEADDR，Swoole 服务一重启就报 Address already in use，根本起不来。这是因为主动关闭连接后，本地端口会进入 TIME_WAIT 状态（默认持续约 60 秒），内核还没彻底释放该 IP:PORT 组合。而 SO_REUSEADDR 的作用就是绕过这个限制，允许新 socket 绑定到仍处于 TIME_WAIT 的地址上。
在 Swoole 中，它默认已启用 —— 你不需要手动设置，但必须知道它在起作用。如果你用的是自定义 socket 层（比如基于 ext-sockets 封装），或调试底层行为，就得显式调用：setsockopt($sock, SOL_SOCKET, SO_REUSEADDR, 1)。漏掉它，bind() 直接失败。
-
SO_REUSEADDR不解决多进程共用端口的问题，只解决单进程重启卡住 - 它对 UDP 和 TCP 都有效，但在 Swoole 的 TCP server 场景下最常被感知
- Windows 下该选项行为不同（等效于 Linux 的
SO_REUSEADDR + SO_REUSEPORT），但 Swoole 不支持 Windows 生产环境，可忽略
SO_REUSEPORT 是 Swoole 多 Worker 并发监听的必要条件
Swoole 启动多个 worker 进程时，默认所有 worker 共享同一个监听 socket（由 master 进程创建并传递 fd）。但如果你用 swoole_server->addlistener() 手动添加监听，或在某些定制场景下让每个 worker 自己调用 socket() + bind()，那就必须启用 SO_REUSEPORT，否则第二个 worker 的 bind() 会失败，报 EADDRINUSE。
启用方式是在创建 socket 后、bind() 前设置：setsockopt($sock, SOL_SOCKET, SO_REUSEPORT, 1)。注意：所有参与复用的 socket 必须**全部启用**，缺一个都会导致整个绑定链失败。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- Linux 内核必须 ≥ 3.9；可通过
uname -r确认，低于此版本直接忽略该选项（设了也无效） - 启用后，内核在
accept()阶段做哈希分发，避免“惊群效应”，各 worker 真正独立收连接 - Swoole 本身不自动帮你设
SO_REUSEPORT，除非你明确配置了['open_tcp_nodelay' => true]之类触发底层重置的选项——别依赖这个，要自己控制
两个选项能同时用吗？要不要一起开？
可以且推荐同时启用：先设 SO_REUSEADDR，再设 SO_REUSEPORT。它们不冲突，作用域正交 —— 前者管 TIME_WAIT 复用，后者管多 socket 并发绑定。
典型错误是只开 SO_REUSEADDR 就以为能多 worker 监听，结果发现只有第一个 worker 收到连接，其余阻塞在 accept() 或根本 bind 不上。这是因为 SO_REUSEADDR 不提供“允许多个监听 socket 绑定同一地址”的能力，它只放宽对残留状态的检查。
- 验证是否生效：启动两个 Swoole 实例（非父子关系），都监听
127.0.0.1:9501，仅第一个开SO_REUSEADDR→ 第二个bind()失败；两个都开SO_REUSEPORT→ 均成功，且netstat -tlnp | grep :9501显示两条 LISTEN 记录 - 不要试图用
SO_REUSEADDR替代SO_REUSEPORT来实现负载均衡，它做不到 - 若用 Docker 或 systemd 启动，注意容器网络命名空间和 cgroup 限制可能干扰
SO_REUSEPORT行为，需额外验证
为什么 Swoole 官方文档很少提这两个选项？
因为 Swoole 把监听 socket 的生命周期交给了 master 进程统一管理：它只创建一次 listen_fd，然后通过 Unix Socket 或 sendmsg/recvmsg 把已建立的连接 fd 传递给 worker。所以绝大多数用户根本不会碰到 bind() 失败问题 —— 你不是在每个 worker 里调 bind()，自然不需要操心 SO_REUSEPORT。
但一旦你脱离这个模型（比如写协程 TCP client 池、自定义 UDP server、嵌入其他 event loop、或对接底层网络库），这些选项就会立刻浮现。真正容易被忽略的点是：你以为 Swoole “帮你搞定了”，其实只是它绕开了问题，而不是消除了问题本身。
