先描述一个我见过不止一次的现场。一个网关服务，八个 worker，SO_REUSEPORT开着，accept 惊群早就不见了，压测曲线漂亮。然后有一天，容量监控告诉你：worker-3 的 CPU 常年 80%，其余七个在 35% 上下晃；同一时刻，发布系统告诉你，每做一次滚动重启，对账系统就报大约 0.3% 的连接被 RST 掉了。大多数人会把这两件事分开排查——一个当成“负载均衡没做好”，一个当成“优雅退出没做好”。我想说服你的是：它们是同一件事。它们都源自SO_REUSEPORT底下那个你从没正眼看过的内核数据结构——一个用四元组哈希把连接分到socks[]数组里某个下标的、无状态、无记忆、对数组长度极度敏感的选择器。热 worker 是这个哈希在“连接生命周期”这个维度上的投影，重启踩踏是它在“worker 集合大小变化”这个维度上的投影。理解了这一个选择器，两个症状一起消失。这篇文章想告诉你的是：先把“惊群”这个词在 2026 年到底还剩多少含量说清楚，然后钻进内核net/core/sock_reuseport.c看那个选择器长什么样，再从第一性原理推出为什么它在长连接下必然产生热点、在滚动重启时必然踩踏，末了把分发决策权从内核默认哈希手里拿回来——用 eBPF、用一致性哈希、用和 RSS/CPU 亲和同源的对齐策略。这不是一篇“教你打开 reuseport”的文章。恰恰相反，我想让你在打开它之后，知道自己接下来会撞上什么。惊群这个词，在 EPOLLEXCLUSIVE 之后已经不是一个问题，而是三个我们先把