Go框架不提供CPU亲和性控制，runtime.LockOSThread()仅防goroutine迁移，不能绑定核心；必须用unix.SchedSetaffinity()设线程亲和性并配合numactl绑定NUMA节点，否则跨节点内存访问延迟高2–3倍。
Go 框架本身不提供 CPU 亲和性控制能力，runtime.LockOSThread() 不能绑定线程到指定核心，仅防止 goroutine 迁移；真正生效的必须是系统调用（如 unix.SchedSetaffinity）配合进程级 NUMA 绑定。
为什么 runtime.LockOSThread() 对 HTTP 服务无效
它只锁定 goroutine 到当前 OS 线程，但无法控制该线程运行在哪颗 CPU 上。Go 运行时仍可能将已锁定的线程调度到任意核心——尤其在 GC、sysmon 抢占或负载变化时。更关键的是：
- net/http.Server 共享全局 netpoller，所有
epoll_wait始终由单个 OS 线程执行，LockOSThread()完全无法分散网络事件监听 - 多个 goroutine 调用
srv.Serve(l)会因监听器已被占用而立即返回http: Server closed错误 - 若没检查
err，容易误以为“起了多个实例”，实际只是假并发、真报错
Linux 下用 unix.SchedSetaffinity() 绑定当前线程
这是最直接、最小侵入的方式，适用于启动即绑定的长期服务（如 API 网关、音视频处理模块）。注意必须在业务逻辑开始前执行，且需配合 runtime.LockOSThread() 防止 goroutine “逃逸”：
-
unix.SchedSetaffinity(0, &cpuset)中第一个参数为 0，表示作用于当前线程（不是进程） -
cpuset.Set(cpuID)只接受整数 ID；绑多个核心需循环调用（如cpuset.Set(4); cpuset.Set(5)） - ARM big.LITTLE 架构下，
/sys/devices/system/cpu/cpu*/topology/core_id才反映真实物理核心编号 - 绑定后必须立刻调用
runtime.LockOSThread()，否则后续 goroutine 可能被调度到其他线程，破坏绑定效果
SO_REUSEPORT + 多进程才是高并发网络服务的正解
单进程无法突破 Go 的单 netpoller 架构限制，多 goroutine 跑 http.Server.Serve() 不等于多核网络并行。生产环境应采用多进程部署，并配合内核级连接分发：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- Linux 3.9+ 支持
SO_REUSEPORT，允许多个进程bind()同一端口，内核自动做连接级负载均衡 - Go 1.11+ 可通过
net.ListenConfig{Control: ...}启用：syscall.SetsockoptInt32(fd, syscall.SOL_SOCKET, syscall.SO_REUSEPORT, 1) - macOS 不支持连接级分发，仅端口复用，必须加 nginx 或 HAProxy 做前端分发
- 每个进程应搭配
numactl --cpunodebind=0 --membind=0启动，避免跨 NUMA 节点内存访问（延迟高 2–3 倍）
CPU 密集型任务才值得手动绑核
I/O 密集型框架（如 Gin、Echo 默认 HTTP 服务）绑核收益极低，反而可能因线程固定导致调度僵化。只有明确满足以下条件时才考虑：
- 任务纯计算、无阻塞 I/O（如图像编解码、加密验签、向量检索）
- 单进程承担稳定高负载，且可预估核心资源需求
- 避开超线程逻辑核（例如只用 CPU 0、2、4…，而非 0、1、2、3…）
- 双路服务器或 ARM 多 die 架构下，必须同步绑定 CPU 和 NUMA 内存节点，否则缓存失效率飙升
绑核不是银弹——它把调度权从内核交还给应用，一旦配置错误（比如绑到小核、跨 NUMA），延迟抖动可能从 0.2ms 涨到 8ms，比不绑更差。
