直接往io.Writer写日志会卡住主线程，因为日志写入（如文件、网络）是同步阻塞操作，磁盘忙或网络抖动时log.Print()会在syscall上阻塞，拖慢业务逻辑；双缓冲+channel的核心目的是解耦而非加速，使业务goroutine只发日志不等落盘。
为什么直接往 io.Writer 写日志会卡住主线程
因为多数日志写入（比如写文件、网络发送）是同步阻塞的，一旦磁盘忙、网络抖动或系统调用排队，log.Print() 会卡在 syscall 上，拖慢整个业务逻辑。双缓冲 + channel 的核心目的不是“加速”，而是“解耦”：让业务 goroutine 只管发日志，不等落盘。
chan string 容量设多少才不丢日志又不爆内存
通道容量不是越大越好。设成 0（无缓冲）会导致发送方立即阻塞；设得太大（比如 10000）可能把大量日志压在内存里，OOM 风险高。实际选值要结合吞吐和容忍丢失程度：
- 典型场景（如 Web API 日志）：用
make(chan string, 1024)—— 足够扛住短时峰值，也防住消费者卡顿几秒 - 高可靠场景（审计日志）：改用带背压的
select+default分支，丢弃新日志前先打个告警 - 注意：
len(ch)返回当前已缓存条数，但无法反映写入延迟；监控应看cap(ch) - len(ch)剩余空间
双缓冲怎么避免频繁内存分配
所谓“双缓冲”不是指两个固定数组，而是指生产者和消费者各自持有独立的 []byte 缓冲区，避免共用同一块内存导致锁竞争或拷贝。关键点在字符串转字节时不触发额外分配：
- 用
unsafe.String（Go 1.20+）或reflect.StringHeader将string转[]byte零拷贝（仅当确定字符串生命周期长于写入操作） - 更稳妥的做法：消费者 goroutine 拿到
string后，用bytes.Buffer或预分配的[]byte拼接，再批量写入磁盘 - 别在 channel 里传大字符串（如含完整 HTTP body），先做截断或哈希摘要
消费者 goroutine 崩溃后日志就丢了怎么办
channel 本身不提供持久化，消费者 panic 或 exit 后未消费的消息会永远卡在 channel 中，直到程序退出。必须主动处理：
立即学习“go语言免费学习笔记（深入）”；
- 用
defer+recover()包裹消费者主循环，恢复后继续消费 - 启动时加信号监听（
os.Interrupt），收到 SIGTERM 前清空 channel 并 flush 到磁盘 - 真正可靠的方案：把 channel 当作“暂存区”，定期 dump 到本地文件（如用
bufio.Writer批量写），再由另一个 goroutine 异步上传或归档
最易被忽略的是 channel 关闭时机——不能在消费者 panic 后直接 close(ch)，因为发送方可能还在写；要用 sync.WaitGroup 或 context 控制生命周期。
