so_reuseport必须在bind前为每个进程单独设置，且所有进程需使用完全相同的地址结构、相同uid，内核3.9+支持，用于多进程公平分发连接而非仅解决time_wait。
SO_REUSEPORT必须在bind前设置，且每个进程都要设
很多人以为只要第一个进程设置了 SO_REUSEPORT，后面进程就能自动复用端口，结果还是报 Address already in use。错误根源在于：内核要求**每个 socket 在调用 bind() 前都必须显式启用该选项**，包括第一个。漏设任意一个，整个复用链就断了。
常见错误写法是只在父进程里设一次、fork后再直接 bind；正确做法是 fork 后每个子进程独立调用 setsockopt()，再 bind。
-
SO_REUSEPORT必须在bind()之前设置，顺序错则无效 - 所有参与共用端口的进程（无论父子关系）都得各自设置，不能继承
- 所有进程需具有相同 effective UID，否则内核拒绝绑定（防止端口劫持）
- Linux 3.9+ 才支持，旧内核会静默忽略该选项，务必用
getsockopt()验证是否生效
bind时地址结构要完全一致，否则内核不识别为“同一端口”
即使设置了 SO_REUSEPORT，如果多个进程 bind 的 sockaddr_in 地址字段存在细微差异（比如 sin_addr.s_addr 是 INADDR_ANY 还是具体 IP），内核可能把它们视为不同监听地址，导致负载不均或部分进程收不到连接。
典型陷阱：一个进程 bind "0.0.0.0:8080"，另一个 bind "127.0.0.1:8080" —— 它们不是同一个 socket address，SO_REUSEPORT 不起作用。
- 所有进程必须使用完全相同的
sin_family、sin_port、sin_addr.s_addr（推荐统一用INADDR_ANY） - 不要混用 IPv4 和 IPv6 地址族；若需双栈，用
AF_INET6+IPV6_V6ONLY=0，但SO_REUSEPORT对双栈的支持依赖内核版本（≥4.1 更稳） - 端口必须是数值型（
htons(8080)），别传字符串或未转换值
accept行为变化：每个进程独立 accept，无需额外同步
启用 SO_REUSEPORT 后，内核会在新连接到达时，根据四元组（源IP+端口+目的IP+端口）哈希，将连接分发给某个已就绪的 listening socket。这意味着每个进程可以像单进程一样调用 accept()，不会抢不到连接，也不用加锁或轮询。
但要注意：这不是“所有进程同时 accept 同一个连接”，而是“每个连接只被一个进程的 accept() 返回”。如果某个进程阻塞在 accept() 上太久（比如没设非阻塞），它会暂时退出调度队列，影响整体吞吐。
- 务必把 listening socket 设为非阻塞（
fcntl(fd, F_SETFL, O_NONBLOCK)），避免accept()挂住整个线程 - 每次
accept()失败且errno == EAGAIN或EWOULDBLOCK时，应立即返回事件循环，而非重试 - 不要在
accept()后立刻做耗时操作（如解析协议、查数据库），应交由线程池或异步任务处理，保持 accept 路径轻量
和SO_REUSEADDR的区别不能混淆
SO_REUSEADDR 解决的是 TIME_WAIT 状态下快速重启服务的问题，它允许新 socket 绑定到处于 TIME_WAIT 的旧端口上；而 SO_REUSEPORT 解决的是多进程/线程公平竞争新连接的问题。两者可共存，但作用完全不同。
常见误操作：只加 SO_REUSEADDR 就以为能实现负载均衡——结果所有连接仍涌向第一个 accept 的进程，CPU 利用率严重倾斜。
-
SO_REUSEADDR是“端口复用”，SO_REUSEPORT是“连接分发” - 高并发网关场景下，建议两个都设：
SO_REUSEADDR防止重启失败，SO_REUSEPORT实现横向扩展 - 测试是否真正生效：启动 4 个进程后，用
ss -tlnp | grep :8080应看到 4 行相同端口的 LISTEN 条目，且 PID 各不相同
最易被忽略的一点：SO_REUSEPORT 的哈希策略对短连接友好，但对长连接（如 WebSocket、gRPC 流）可能导致连接分布不均——因为哈希基于初始四元组，后续数据包不重新分发。如果业务中长连接占比高，需配合连接数限速或定期迁移机制，否则某些 worker 可能长期过载。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
