真异步日志需缓冲格式化、批量落盘与背压控制，仅用log.printf()或裸chan string因无缓冲、无批量、无背压，高并发下会丢日志、卡主线程或oom。
为什么 go log.Printf() 或裸 chan string 不算真异步
它只把“调用写”挪到另一个 goroutine，但日志格式化（如 time.Now().Format()）、file.WriteString() 底层仍是同步 write(2) 系统调用，主流程虽不卡，后台协程会堆积阻塞。更严重的是：多个 goroutine 并发写同一 *os.File，即使带 os.O_APPEND，在 ext4/xfs 上仍可能因内核 page cache 导致行截断、时间戳错位；channel 没缓冲或太小（如 make(chan string, 10)），高峰期直接满载，select { case ch 走不到 <code>default 就卡死主 goroutine。
logChan 缓冲大小怎么设才不丢日志也不爆内存
不是拍脑袋定 1024 或 8192，得看峰值日志速率和消费能力：
- 低于 128：低流量服务 flush 太频繁，I/O 毛刺明显
- 高于 8192：单条日志均 200B，满载即占 1.6MB 内存，QPS 高时 GC 压力飙升
- 推荐起点：
make(chan *LogEntry, 2048)；若含大 JSON 或 panic 堆栈，下调至 512，并配select { case logChan 防堵死
必须用单写 goroutine + bufio.Writer + 双触发 Flush
真正削峰填谷靠两级缓冲：channel 做流量整形，bufio.Writer 合并系统调用。缺一不可：
- 打开文件必须复用同一个
*os.File，权限用os.O_CREATE | os.O_WRONLY | os.O_APPEND，别每次写都os.OpenFile() -
bufio.NewWriterSize(file, 16*1024)显式设 buffer 大小，避免默认 4KB 在高频日志下 flush 过频 - flush 必须双条件触发：
len(batch) >= 100（满载）或（50ms 超时），只靠一个必出问题：满载导致低流量日志滞留数秒，定时则突发流量撑爆 batch -
batch切片要用batch[:0]清空，避免底层数组残留拖慢 GC 或混入旧数据
file.Sync() 不是可选项，而是落盘强保证
w.Flush() 只刷到内核 buffer，断电或 crash 会丢数据。生产环境必须显式调用 file.Sync()：
- 不是每条都 Sync：性能代价太大，仅
ERROR或审计级日志启用 - Sync 失败必须处理：
if err := file.Sync(); err != nil { handleSyncError(err) }，忽略会导致“写了却没落盘”的幻觉 - 注意 ext4 默认挂载是
data=ordered，Sync()成功率高；若用data=writeback，Sync 后仍可能丢最后几 KB - 关键错误日志不能走 channel：应绕过异步路径，直写专供
os.O_SYNC的*os.File，否则丢了就难排查
真正容易被忽略的点是：日志格式化必须发生在生产者 goroutine 栈上，而不是消费者里做 time.Now().Format() 或 json.Marshal() —— 否则会引入锁、时间误差，甚至 panic；还有就是 file.Sync() 的失败路径，没人处理，等于没写。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
