Go 不直接控制 Linux 软中断，仅能通过减少触发、避免阻塞、对齐内核行为间接缓解；net/http.Server 默认配置因 Keep-Alive 连接复用和 handler 阻塞导致 socket 缓冲区积压，加剧 NET_RX softirq 负载。
Go 本身不直接暴露或控制 Linux 的软中断（softirq）调度，所谓“Go 处理软中断负载优化”本质上是个误解——softirq 是内核网络栈在 CPU 上执行的下半部机制，由内核决定在哪颗 CPU 上运行、如何分发、是否聚合。Go 程序只能间接影响它，主要通过减少触发频率、避免阻塞、对齐内核行为来缓解其成为瓶颈。
为什么 net/http.Server 默认配置会加剧 softirq 压力
当大量 Keep-Alive 连接复用同一 TCP 连接时，每个 HTTP 请求仍需走完整内核协议栈：数据包到达 → NET_RX softirq 处理 → 交付 socket 接收队列 → Go runtime 从 epoll_wait 唤醒 → read() 系统调用拷贝数据。如果 Go 的 http.HandlerFunc 执行慢（比如同步 DB 查询、未设超时的外部调用），socket 接收缓冲区持续积压，就会导致：
-
NET_RXsoftirq 被反复唤醒，CPU 花费大量时间在中断上下文处理数据包 - 接收队列堆积引发丢包、重传，进一步抬高 softirq 负载
- Go goroutine 长时间阻塞在
read()，无法及时消费数据，形成恶性循环
用 SO_ATTACH_REUSEPORT + 多进程降低单 CPU softirq 峰值
Linux 4.5+ 支持 SO_ATTACH_REUSEPORT，允许多个 Go 进程监听同一端口，内核按四元组哈希将连接分散到不同 socket，从而把 NET_RX softirq 分摊到多核。这不是 Go 自己做的负载均衡，而是绕过用户态调度，让软中断天然并行化。
关键点：
- 每个 Go 进程必须调用
syscall.SetsockoptInt(…, syscall.SO_ATTACH_REUSEPORT, 1)启用该选项 - 不能用
http.ListenAndServe，得用net.ListenConfig{Control: …}手动创建 listener - 需配合
GOMAXPROCS=1+taskset -c N绑定进程到指定 CPU，否则 softirq 可能跨核迁移，失去缓存局部性 - 示例片段：
lc := net.ListenConfig{ Control: func(fd uintptr) { syscall.SetsockoptInt(fd, syscall.SOL_SOCKET, syscall.SO_ATTACH_REUSEPORT, 1) }, } l, _ := lc.Listen(context.Background(), "tcp", ":8080")
避免 goroutine 阻塞 recv buffer 导致 softirq 持续抢占
softirq 不会等 Go 应用读取数据；它只负责把包从网卡搬到 socket 缓冲区。若 Go 的 handler 不及时 read()，缓冲区满后内核会丢包或触发 TCP 流控，反过来又迫使对端重传，加重 softirq。
必须做到：
- 所有网络 I/O 操作都带
context.WithTimeout或SetReadDeadline，防止 goroutine 卡死 - 禁用
http.Transport.IdleConnTimeout = 0，否则长连接空闲时缓冲区仍被占用 - 用
pprof定期抓取goroutineprofile，过滤出长期处于IO wait状态的 goroutine，它们就是 softirq 压力的放大器 - 对高频小请求（如心跳），考虑用
io.CopyN(ioutil.Discard, r.Body, 1)快速清空 body，避免无意义 read
真正需要关注的是 netpoll 和 runtime 调度协同
Go 的 netpoll（基于 epoll/kqueue）和 softirq 共享同一颗 CPU 时，会出现争抢：softirq 抢占 runtime 的 M，导致 goroutine 唤醒延迟升高。这不是 Go 能改的，但可以规避：
- 用
runtime.LockOSThread()+syscall.SchedSetaffinity将 softirq 所在 CPU 与 Go 工作线程隔离（需 root 权限） - 调大
/proc/sys/net/core/netdev_max_backlog和rmem_default，减少 softirq 因缓冲区满而频繁执行 - 观察
/proc/softirqs中NET_RX和NET_TX的计数增长速率，若远高于 QPS，说明存在协议栈层面积压，此时优化 Go 代码已无效，必须调操作系统参数或加硬件卸载（如 RSS）
软中断不是 Go 的责任边界，强行在应用层“优化”它往往南辕北辙。重点永远是：让每个请求的端到端路径更短、更可预测，把压力留在它该在的地方。
