可用 len() 和 cap() 查看带缓冲 channel 的当前长度和容量；len(ch) 返回待读元素个数，cap(ch) 返回缓冲区总容量；无缓冲 channel 的 len(ch) 恒为 0 或瞬时 1，不反映积压。
用 len() 和 cap() 查看 channel 当前长度和容量
Go 的 channel 本身不提供“数据量监控接口”，但对带缓冲的 channel，len(ch) 返回当前队列中待读取元素个数，cap(ch) 返回缓冲区总容量。这是最轻量、最常用的方式。
注意：对无缓冲 channel（make(chan int)），len(ch) 永远是 0 或 1（仅在发送/接收瞬间有瞬时值），不能反映“积压”——它本质上没有缓冲，阻塞由 goroutine 调度决定，不是队列堆积。
-
len(ch)是并发安全的，可随时调用，不阻塞也不影响 channel 行为 - 不要在热循环里高频轮询
len(ch)，尤其当 channel 很少变动时，会浪费 CPU - 若需长期观测，建议采样间隔 ≥ 100ms，或只在关键路径（如背压触发点）检查
用 select 非阻塞探测是否可读/可写
当你要判断 channel 是否“有数据可读”或“是否已满”，又不想阻塞 goroutine，可以用 select + default 实现零等待探测。
例如检测是否有数据可读但不消费：
立即学习“go语言免费学习笔记（深入）”；
select {
case <-ch:
// 真的读走了，不推荐用于“探测”
default:
// 通道空，无数据可读
}
更稳妥的探测方式是用带缓冲的 channel 配合 len()，而 select 更适合做控制流决策（比如“有数据就读，没数据就干别的”）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 非阻塞
select无法告诉你“有多少数据”，只能回答“此刻能否收/发” - 对无缓冲 channel，
select成功只表示“对方 goroutine 正在等待”，不代表数据已就绪 - 如果误把
select当作监控手段频繁使用，可能掩盖真实背压问题，比如 sender 持续超速写入却从未被阻塞感知
在生产环境用 runtime.ReadMemStats 或 pprof 辅助定位 channel 泄漏
真正需要“监控 channel 数据量”的场景，往往背后是背压未处理、goroutine 泄漏或消费者滞后。这时单看 len(ch) 不够，得结合运行时指标。
例如：持续增长的 len(ch) + 不下降的 goroutine 数量，大概率说明消费者卡住或退出了。可配合：
-
runtime.NumGoroutine()观察协程是否异常增长 -
pprof.Lookup("goroutine").WriteTo(os.Stdout, 1)查看哪些 goroutine 堵在ch <-或<-ch - HTTP pprof 端点（
/debug/pprof/goroutine?debug=2）在线抓现场
注意：pprof 不直接暴露 channel 长度，但它能让你看到谁在等、等了多久——这才是定位数据积压根源的关键。
别用反射或 unsafe 获取 channel 内部字段
网上有些文章教用 unsafe 读取 runtime 包里的 hchan 结构体字段来“精确获取 buffer 地址或 count”，这属于未定义行为。
Go 运行时结构体布局不保证稳定，1.21 和 1.22 的 hchan 字段顺序/大小可能不同，且 gc 优化可能让某些字段被重排或内联。一旦升级 Go 版本，这类代码极易崩溃或返回错误值。
- 标准库明确不承诺
hchan可访问，go vet甚至会警告 unsafe 操作 runtime 内部类型 - 即使临时调试用了，也绝不能进生产代码
- 真要深度分析，用
go tool trace或go tool pprof -trace更可靠
实际工程中，len(ch) 覆盖 95% 的监控需求；剩下的 5%，靠 pprof 和日志上下文定位，而不是钻 runtime 底层。
