不能共用一个channel做读写，因其send/recv原子性导致无法单独限流熔断：下游消费慢时缓冲区满→发送阻塞→生产者goroutine卡死，且select中混用case无法解决根本问题。
Go 里没有“高并发读写队列”这个现成组件，所谓“拆分”不是调一个方法就能完成的，而是必须手动把读、写逻辑隔离到不同 channel + 不同 goroutine 模型中——否则所有操作挤在同一个无缓冲 channel 上，一卡全卡。
为什么不能共用一个 channel 做读写
共用 channel 表面省事，实际埋雷：写操作（如生产任务）和读操作（如消费结果）共享缓冲区时，一旦下游消费慢，整个 channel 就堵死，连带上游写入阻塞；更糟的是，channel 的 send/recv 是原子操作，无法对“读端”或“写端”单独限流或熔断。
- 写端持续发任务，但读端处理慢 → 缓冲区填满 →
send阻塞 → 生产者 goroutine 卡住 - 想给读端加超时？
select中混用case 和 <code>case 会干扰写端感知背压 - 无法单独监控“读积压量”或“写失败率”，故障定位变成猜谜
怎么用两个 channel 实现真正读写分离
核心是让写通道只负责接收任务，读通道只负责吐出结果，中间靠 worker pool 桥接。不共享任何 channel 实例，也不复用指针。
- 定义
tasksCh = make(chan Task, 1000)（写专用），容量按峰值 QPS × 1.5 预估 - 定义
resultsCh = make(chan Result, 500)（读专用），容量按平均响应时间 × 并发 worker 数估算 - worker 启动后只从
tasksCh读、向resultsCh写，不反向操作 - 写端用
select { case tasksCh 实现非阻塞入队 - 读端用
select { case r := 支持上下文取消
sync.Pool 怎么配合读写分离减少 GC
Task 和 Result 结构体高频创建销毁是 GC 主因，但 Pool 不能跨 channel 生命周期乱放——比如把刚从 resultsCh 取出的 Result 直接 Put 回 Pool，而它可能还在被业务层引用。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 只对纯数据载体（如
type Task struct { ID int; Payload []byte }）用 Pool，避免含指针或回调函数的结构体 - 写端获取：
t := taskPool.Get().(*Task); t.ID = id; t.Payload = append(t.Payload[:0], data...) - worker 处理完后立刻
taskPool.Put(t)，绝不等到结果写进resultsCh之后 - 读端拿到
Result后自行拷贝关键字段，不用 Pool 管理返回值，防止悬垂引用
连接池参数错配会让读写分离失效
很多人以为拆了 channel 就万事大吉，结果压测时发现 CPU 没跑满，数据库连接却先打满——因为没意识到：读写分离的 channel 模型，最终要落到数据库连接池上，而主库、从库的连接池必须独立配置且参数差异显著。
- 写通道下游的 worker 如果批量更新数据库，必须用
masterDB，且masterDB.SetMaxOpenConns(20)，避免长事务占满连接 - 读通道下游的 worker 查缓存或从库，要用
slaveDB，并设slaveDB.SetMaxOpenConns(100)和slaveDB.SetMaxIdleConns(50) - 千万别用
db := masterDB这种浅拷贝，每个库必须调独立的sql.Open()和db.Ping() - 从库连接池没设
SetConnMaxIdleTime(5 * time.Minute)？K8s Pod 重启后大量 idle conn 会卡住，表现为读请求延迟陡增
最常被忽略的点是：读写分离不是 channel 拆开就结束，而是从 goroutine 调度、内存复用、到数据库连接池，每一层都要对应解耦。少做一层，瓶颈就会出现在下一层。
