goroutine切换开销约100–300 ns，远低于os线程切换；真正开销来自频繁上下文迁移，而非协程数量本身，需避免密集轮询等导致高频调度的行为。
goroutine 切换开销到底有多大？
它不取决于协程数量本身，而取决于「是否真在切换」——也就是有没有发生系统调用、channel 阻塞、定时器等待、或 runtime.Gosched() 主动让出。空转的 goroutine（比如死循环里没阻塞）不会触发调度，但会饿死其他协程；真正造成开销的是频繁进出运行队列的上下文迁移。
实测表明：一次非阻塞的 goroutine 调度（如被抢占）平均耗时约 100–300 ns，远低于 OS 线程切换（通常 > 1 μs），但若每毫秒触发几千次，累积延迟就明显了。
- 别用 goroutine 做密集轮询，比如
for { select { case —— 这会不断创建/销毁 timer 和 goroutine - 避免在 hot path 上无条件启新 goroutine，例如 HTTP handler 里对每个请求都起一个
go handle()，哪怕逻辑极轻 - 注意
time.Sleep、net.Conn.Read、sync.Mutex.Lock（争抢激烈时）都可能触发调度，不是“纯计算”就安全
怎么判断当前 goroutine 正在被频繁调度？
看 runtime.ReadMemStats 里的 NumGoroutine 波动不大，但延迟毛刺高，大概率是调度干扰；更直接的方式是用 go tool trace 抓取运行轨迹：
go run -gcflags="-l" -trace=trace.out main.go go tool trace trace.out
在 Web UI 中点「View trace」→ 查看「Proc X」时间线，如果看到大量绿色（Runnable）和黄色（Running）短块交替，中间夹着灰色（Syscall / GC / Block），说明调度频繁。
立即学习“go语言免费学习笔记（深入）”；
- 重点关注「SCHED」事件密度，每秒超过 5k 次调度就值得排查
-
Goroutine profile（go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2）能暴露长期阻塞的 goroutine，但不反映瞬时调度压力 - 启用
GODEBUG=schedtrace=1000可每秒打印调度器状态，适合快速验证是否“过载”
channel 使用不当如何放大调度开销？
无缓冲 channel 的 send 和 recv 是同步点，发送方若无接收方立刻就阻塞并让出，接收方同理——这本质就是一次调度决策。缓冲 channel 能缓解，但填满后行为退化为无缓冲。
常见陷阱：
- 用
make(chan struct{}, 0)做信号通知，却在 sender 端没配好 receiver，导致 sender 协程卡住再被抢占 - 把 channel 当作日志队列，但消费者太慢，生产者反复阻塞 → 大量 goroutine 堆积在 channel send 上
- 在 select 中写
case ch 却没加 default，一旦 channel 满或无人收，整个 goroutine 就挂起
替代方案：热路径优先用 sync.Pool + 循环 buffer；跨组件通信考虑 ringbuffer 或带背压的 worker pool，而非裸 channel。
哪些 sync 原语会隐式触发调度？
sync.Mutex 本身不调度，但锁争抢严重时，goroutine 会进入 gopark 等待唤醒，这就是一次调度；sync.RWMutex 的写锁同样如此。而 sync.Once、atomic 操作完全无调度开销。
- 高频读写共享计数器，别用
Mutex包一层int，直接上atomic.AddInt64 - 初始化逻辑用
sync.Once，比手写 double-check lock + mutex 更轻量且无竞争风险 -
sync.WaitGroup的Add/Done是原子操作，但Wait会 park，所以别在 tight loop 里反复Wait
真正危险的是混合使用：比如在持有 Mutex 期间调 time.Sleep 或发 HTTP 请求——锁占着，别的 goroutine 干等，同时自己又去调度，双重浪费。
协程调度不是黑盒，它响应的是阻塞与抢占。减少开销的关键，从来不是“少起 goroutine”，而是让每个 goroutine 尽可能跑得久、停得准、醒得快。那些看似无害的 time.After、select、甚至 fmt.Println（底层有锁+write syscall），在高频场景下都会变成调度放大器。
