Go语言的多路复用由runtime/netpoll自动实现，用户只需正常使用conn.Read()等阻塞API，netpoller会协同调度器在epoll/kqueue就绪时唤醒goroutine，无需手动干预或模拟。
Go 语言本身不提供“通过语言学习实现多路复用”的路径——多路复用是运行时（runtime）底层封装的 I/O 能力，不是靠学语法“写出来”的。你写的 conn.Read() 看似阻塞，实际背后由 netpoller 自动挂起 goroutine 并交由 epoll/kqueue/IOCP 处理。关键在于**正确使用 Go 的并发模型和网络原语，而不是手动实现多路复用逻辑**。
为什么不能自己用 select 实现网络多路复用
很多人初学时会尝试用 select 监听多个 net.Conn 的读通道，但这行不通：
-
net.Conn不是 channel，无法直接在select中使用；强行包装成 channel（如用 goroutine 转发Read结果）会引入额外 goroutine 和缓冲开销，反而破坏性能 -
select仅用于 channel 通信协调，它不参与 socket 状态监控——那是netpoller的职责 - 自己模拟事件循环（比如轮询
conn.SetReadDeadline+io.ErrTimeout）等于退化到低效的阻塞轮询，失去 epoll/kqueue 的 O(1) 就绪通知优势
真正生效的多路复用：靠 runtime 自动调度
Go 的多路复用能力来自 runtime/netpoll，你只需按常规方式写阻塞式网络代码，它就会自动启用：
- 每个
net.Listener.Accept()返回的conn，其Read()/Write()调用都会触发netpoller注册/等待事件 - Linux 下自动使用
epoll_ctl添加 socket fd，就绪后唤醒对应 goroutine，无需你干预 - 一个 goroutine 阻塞在
conn.Read()时，OS 线程会被释放去跑其他 goroutine，实现 M:N 调度
示例中看似“简单”的服务，已天然具备万级并发能力：
立即学习“go语言免费学习笔记（深入）”；
ln, _ := net.Listen("tcp", ":8080")
for {
conn, _ := ln.Accept() // 每个连接启动独立 goroutine
go func(c net.Conn) {
buf := make([]byte, 4096)
for {
n, err := c.Read(buf) // 这里被 netpoller 接管
if err != nil {
return
}
c.Write(buf[:n])
}
}(conn)
}
容易踩坑的配置与边界条件
多路复用能否发挥效果，取决于你是否无意中破坏了 runtime 的调度假设：
- 不要在 handler 中调用
time.Sleep或长时间 CPU 计算——这会让 goroutine 占用 OS 线程，阻塞其他 I/O 任务 - 避免对单个连接使用大缓冲区（如
make([]byte, 1<<20)），内存分配压力会拖慢 GC，间接影响 netpoller 响应延迟 - 连接数超限时，Linux 默认
fs.file-max和 per-processulimit -n会先于 Go 报错，错误信息通常是"too many open files"，而非网络超时 - HTTP 服务中，若用
http.Server{ReadTimeout: ...}，超时由 netpoller 内部的定时器触发，但需注意：短超时 + 高频连接会导致大量 goroutine 频繁创建销毁，比长连接更耗资源
最常被忽略的一点：多路复用的性能收益高度依赖连接复用率。如果客户端每请求都建新连接（HTTP/1.1 无 keep-alive 或 HTTP/1.0），epoll 就得反复 epoll_ctl(ADD/DEL)，开销反超长连接场景。真正的高并发，往往始于让客户端复用 TCP 连接。
