Go语言高并发关键在于合理组织goroutine、channel和共享状态；channel是控制流枢纽，应依吞吐预估缓冲大小，避免盲目设大；用select+default实现非阻塞操作，超时channel保障下游慢时的健壮性。
Go 语言天生适合高吞吐并发场景，关键不在“用不用 goroutine”，而在于如何组织 goroutine、channel 和共享状态，让系统不卡、不漏、不崩、不慢。
用好 channel 做协调，别当数据搬运工
channel 不只是传数据的管道，更是控制流和生命周期的枢纽。高频写入时，避免无缓冲 channel 阻塞发送方；大量读写场景下，优先用带缓冲 channel（如 make(chan int, 1024)），但缓冲大小要结合业务吞吐预估，不能盲目设大——内存占用和延迟会反向增长。
- 用
select+default实现非阻塞尝试发送/接收 - 对下游可能慢的服务，用超时 channel 包裹：
select { case v := - 关闭 channel 前确保所有发送者已退出，否则 panic；只由发送方关闭，接收方只读不关
控制 goroutine 数量，用 worker pool 管理负载
每请求起 goroutine 看似简单，但流量突增时极易 OOM 或调度过载。应统一用固定数量的 worker 处理任务队列，把并发度收口到可控范围。
- 用
semaphore（如golang.org/x/sync/semaphore）或带缓冲 channel 模拟信号量，限制同时执行的任务数 - 典型 worker pool 结构：启动 N 个长期运行 goroutine，从同一输入 channel 读任务，处理完写结果到输出 channel
- 配合 context.Context 实现任务级取消，避免 worker 卡死在某个慢调用中
减少锁竞争，优先用无锁结构或局部状态
全局 mutex 是吞吐瓶颈常见源头。能用 channel 协作就不用锁；必须共享状态时，优先考虑 sync.Pool、atomic 操作或分片锁（sharded map）。
立即学习“go语言免费学习笔记（深入）”；
- 计数类场景多用
atomic.AddInt64替代 mutex + int - 高频读写的 map，用
sync.Map（适用于读多写少）或自行分片（如按 key hash % 32 分到 32 个sync.RWMutex + map） - 临时对象（如 JSON 解析中间结构）用
sync.Pool复用，显著降低 GC 压力
可观测性不是上线后才加，而是架构里长出来的
高吞吐系统一旦出问题，没指标等于蒙眼开车。在并发组件设计初期就埋点：goroutine 数、channel 长度、任务排队时长、worker 忙闲比。
- 用
runtime.NumGoroutine()定期采样，突增说明泄漏或积压 - 用
len(ch)和cap(ch)监控 channel 积压率（如 >80% 触发告警） - 每个 worker 启动时注册指标句柄，暴露 Prometheus 格式 /metrics 接口
基本上就这些。Go 并发不难，难的是在吞吐、延迟、稳定性之间做清醒取舍——每次加 goroutine 前，先问一句：它真的需要独立生命周期吗？
