Go语言通过调度模型降低系统调用瓶颈影响，但需避免Accept阻塞、小I/O放大syscall开销、goroutine卡在netpoll等常见误用；应采用SO_REUSEPORT、bufio缓冲、context超时等实践优化。
Go 语言本身不直接“处理”系统调用瓶颈，而是通过调度模型和运行时设计，把系统调用对并发吞吐的拖累降到最低——但前提是开发者别绕过它、别滥用它、别在错误的地方卡住。
net.Listener.Accept 是最常被卡死的系统调用
默认 net.Listener.Accept 是同步阻塞的，内核 backlog 满了就丢连接，且单 goroutine 调用无法利用多核。压测时 CPU 很低但 QPS 上不去，ss -s 显示 ListenOverflows，基本就是它。
- 别用
http.ListenAndServe：它只启一个 listener goroutine，再快也单点瓶颈 - 改用
net.ListenConfig+SO_REUSEPORT，让内核分发连接到多个 listener goroutine - 启动的 listener 数量建议等于
runtime.NumCPU()，每个跑自己的for { conn, _ := lis.Accept() } - Linux 3.9+、Go 1.11+ 才支持；macOS 有类似机制；Windows 需 fallback 到单 listener + 连接队列分发
小块 I/O 调用会把 syscall 开销放大十倍
每次 conn.Read 或 os.File.Write 都是一次系统调用，而 syscall 的上下文切换成本远高于内存拷贝。高频小读写（比如每行日志都 WriteString）会让性能掉到十分之一。
- 一律用
bufio.NewReader和bufio.NewWriter包装连接或文件，显式设缓冲区大小（如64 * 1024） - 写入后必须调用
writer.Flush()，否则数据可能滞留用户态缓冲区不落网/不落盘 - 别在循环里反复
new bufio.Reader：要么复用，要么从sync.Pool取 - 大文件别用
os.ReadFile，改用io.CopyBuffer(dst, src, buf)流式处理，buf从池里拿
goroutine 卡在 syscall 不等于“忙”，而是“等内核通知”
pprof 看到大量 goroutine 处于 runtime.netpoll 状态，不是它们在计算，是在等 socket 就绪、文件可读、定时器触发——这是正常现象，但若数量持续上涨，说明上层没及时消费或分发。
- 检查是否在 handler 里做了阻塞操作（如未设超时的
http.Client.Do、裸调time.Sleep） - 用
context.WithTimeout包裹所有外部依赖调用，避免一个慢请求拖垮整条 worker 链 - 不要让 goroutine 直接
accept()后自己处理连接；应 accept 后立刻syscall.Dup复制 fd，再把新 fd 交给 worker，否则 close 行为不可控 - 若真要手写 epoll（仅限 Linux 网关类服务），必须
runtime.LockOSThread()，否则 M 切换导致 epoll fd 失效
真正难的不是知道该用 SO_REUSEPORT 或 bufio，而是当压测延迟突增、pprof 显示一堆 netpoll 时，你能快速判断是 Accept 卡了、还是 I/O 缓冲没配、还是某个数据库查询没设 context 超时——这些地方一漏，再多的 goroutine 也救不回吞吐。
