Go 的 select 是语言层面基于 channel 的多路复用机制，伪随机选择就绪 case，需配合 default、超时和 context 避免阻塞与泄漏。
Go 的 select 是多路复用的核心机制
Go 里没有传统意义上的“多路复用系统调用”（如 Linux 的 epoll），它的多路复用是语言层面对 channel 操作的调度抽象，由 select 语句实现。它让 goroutine 能同时等待多个 channel 的收发操作，并在任意一个就绪时立即响应。
常见错误是把 select 当成轮询或超时工具硬套，结果写出忙等或漏掉默认分支导致阻塞：
- 不加
default且所有 channel 都未就绪 → 当前 goroutine 永久阻塞 - 在
select中反复读同一 channel 却没考虑缓冲区耗尽 → 后续 case 可能永远无法触发 - 误以为
select会按书写顺序尝试 case → 实际是**伪随机公平选择**，不能依赖顺序
正确写法示例（带超时与非阻塞尝试）：
select {
case msg := <-ch:
fmt.Println("received:", msg)
case <-time.After(1 * time.Second):
fmt.Println("timeout")
default:
fmt.Println("no message ready, doing something else")
}用 net/http 的 Server 看真实多路复用场景
HTTP 服务器本身不是靠单个 goroutine 处理所有连接，而是每个新连接启动一个 goroutine；真正的多路复用发生在底层：Go 的 net 包用 epoll（Linux）或 kqueue（macOS）监听 socket 事件，再通过 channel 将就绪连接/数据通知到用户 goroutine —— 这部分对开发者透明，但理解它能帮你定位瓶颈。
立即学习“go语言免费学习笔记（深入）”；
关键配置点影响复用效率：
-
http.Server.ReadTimeout和WriteTimeout防止单个连接长期占用 goroutine -
http.Transport.MaxIdleConns控制客户端复用连接数，避免频繁建连 - 若手动用
net.Listen+accept循环，记得用SetDeadline配合select，否则 accept 可能阻塞整个循环
自己封装多路复用器：用 chan struct{} 做事件聚合
当需要监听多个信号源（如文件变更、定时器、退出通知）并统一响应时，可构建轻量级多路复用器，核心是把各类事件转为向同一 channel 发送。
本书是全面讲述PHP与MySQL的经典之作，书中不但全面介绍了两种技术的核心特性，还讲解了如何高效地结合这两种技术构建健壮的数据驱动的应用程序。本书涵盖了两种技术新版本中出现的最新特性，书中大量实际的示例和深入的分析均来自于作者在这方面多年的专业经验，可用于解决开发者在实际中所面临的各种挑战。
典型陷阱：
- 直接在 signal.Notify 中传入无缓冲 channel → 第二个信号就 panic（send on closed channel 或阻塞）
- goroutine 泄漏：启动监听后没提供关闭通道，导致后台 goroutine 无法退出
安全做法示例（信号+定时器聚合）：
done := make(chan struct{})
events := make(chan string, 10)
// 启动信号监听
go func() {
sigs := make(chan os.Signal, 1)
signal.Notify(sigs, syscall.SIGINT, syscall.SIGTERM)
for {
select {
case <-done:
return
case s := <-sigs:
events <- "signal:" + s.String()
}
}
}()
// 启动定时器
go func() {
ticker := time.NewTicker(5 * time.Second)
defer ticker.Stop()
for {
select {
case <-done:
return
case <-ticker.C:
events <- "tick"
}
}
}()
后续只需 select 读 events，就实现了跨类型事件的统一调度。
别混淆：sync.Pool 不是多路复用，context.WithCancel 才是协同基础
很多人看到 “复用” 就想到 sync.Pool，但它只是对象复用，和 I/O 多路复用无关。真正支撑多路复用协作的是 context：它让多个 goroutine 能感知同一个取消信号，避免因某个 channel 关闭而其他 goroutine 继续空跑。
必须注意的细节：
- 不要用
context.Background()直接传给长期运行的 goroutine → 无法外部中断 -
context.WithCancel返回的cancel函数需显式调用，且只能调用一次；重复调用会 panic - channel 关闭后，
会立即返回零值，但不会触发select的 case —— 必须配合ok := 判断是否已关闭
多路复用逻辑越复杂，越要靠 context 控制生命周期。漏掉这一环，看似跑通的代码在线上高负载下容易堆积 goroutine。
