带缓冲的 channel 是并发安全的 FIFO 队列；make(chan T, N) 创建标准队列，非同步点；无缓冲 channel 无法缓存，不能作队列；缓冲大小需合理，避免内存耗尽；len() 和 cap() 仅为瞬时快照，不可用于条件判断。
用 make(chan T, N) 就是正经队列，不是“模拟”
Go 里带缓冲的 channel 本身就是标准、并发安全的 FIFO 队列，不是玩具或教学演示。只要写 messages := make(chan string, 10)，你就拥有了一个能阻塞入队、非阻塞/阻塞出队、天然支持 goroutine 协作的消息队列。
- 不带缓冲的
chan string是同步点，一发就卡，根本不能当队列用——它连“缓存”都没有 - 缓冲大小不是越大越好：
make(chan []byte, 10000)可能瞬间吃光内存，且掩盖消费者处理慢的真实瓶颈 - channel 的
len()和cap()是瞬时快照，不能用于条件判断（比如if len(ch) ），因为读写并发下值随时变化 - 关闭 channel 后再写会 panic：
panic: send on closed channel；关闭前必须确保所有生产者已退出
select 不是可选项，是保命手段
裸写 queue 或 msg := 在真实服务中等于埋雷。一旦消费者宕机、处理变慢或队列满，生产者就会永久阻塞，最终触发 fatal error: all goroutines are asleep - deadlock。
- 发送端必须加超时或非阻塞兜底：
select { case queue <- msg: // 成功 default: // 队列满，丢弃或降级 } - 或者带超时：
select { case queue <- msg: case <-time.After(300 * time.Millisecond): // 超时放弃 } - 消费者也一样：别用
for range queue一直等，尤其在需优雅退出时，要用select配合done通道控制生命周期
封装成结构体不是为了“显得专业”，是为了留扩展口
直接暴露 chan 字段看似简单，但很快会遇到问题：没法统计积压量、无法记录入队时间、不能平滑切换到 Redis 后端、关不干净、日志难打点。
-
sync.Mutex在纯 channel 场景下**不保护 channel 本身**（它本就线程安全），而是为将来加计数器、打日志、插钩子预留位置 - 如果结构体里加了
length int字段来实时反映队列长度，那每次读写都得加锁更新它 - 方法命名建议用
Enqueue()/Dequeue()，比Send()/Receive()更准确——毕竟你操作的是队列，不是网络连接 - 不要在结构体里存
chan的len()值做判断，它过期速度比函数执行还快
什么时候必须换掉内存 channel？看这三点
纯 channel 队列只适合开发验证、单机轻量内部事件（如配置热重载通知、指标聚合）。一旦出现以下任一情况，就得切到 Redis Stream、NATS 或 Kafka：
立即学习“go语言免费学习笔记（深入）”；
- 需要进程重启后消息不丢 → 内存 channel 一崩全没
- 消费者要横向扩缩容，或部署在多台机器 → channel 无法跨进程共享
- 要求死信处理、延时消息、精确一次语义、按 key 分区 → 内存方案既不可靠也难维护
最容易被忽略的一点：你以为的“突发流量”，其实是在测试阶段没压测出 consumer 处理延迟，结果上线后 channel 持续满载，所有 select default 分支疯狂触发，业务逻辑悄悄降级——这时候不是换中间件的问题，是得先看清你的消费能力底牌。
