必然乱序、截断、丢数据；因*os.File无锁且无偏移隔离，O_APPEND仅保证单次系统调用追加原子性，但Go层WriteString可能拆分为多次write，导致粘连、错位，结构化日志必须用单writer goroutine+channel串行化。
直接用 go file.Write() 或 log.Println() 并发写同一个文件，必然乱序、截断、丢数据——这不是 Go 不行，而是 *os.File 没锁，也没偏移量隔离。
为什么 os.O_APPEND 不能解决所有并发写问题
Linux 内核对 os.O_APPEND 的 write 系统调用确实保证单次追加原子性，但 Go 层的 file.WriteString() 或 file.Write() 可能被拆成多次系统调用（尤其跨 bufio 缓冲边界时）。结果就是两行日志粘连成一行，比如 "req=123" 和 "status=200" 合并成 "req=123tatus=200"。更隐蔽的是：即使每个 goroutine 自己 os.OpenFile(..., os.O_WRONLY) 打开同一路径，也照样出错——因为多个 fd 共享同一 inode，write 偏移未同步。
所以：os.O_APPEND 只适用于“每条写入都短、独立、且可接受行内不乱”的场景（如简单日志），不适用于结构化记录、JSON 行、或需严格顺序的审计日志。
必须用单 writer goroutine + channel 串行化
这是唯一可控、通用、能适配各种写入语义（追加/覆盖/分片）的方案。核心不是“异步”，而是“解耦+串行”。
立即学习“go语言免费学习笔记（深入）”；
-
logCh := make(chan string, 2048)：缓冲大小按峰值 QPS × 平均处理延迟预估；超 5k 条/秒建议 ≤ 2048，避免 OOM 或延迟飙升 - 启动唯一后台 goroutine：
go func() { defer file.Close() w := bufio.NewWriterSize(file, 16*1024) for msg := range logCh { if _, err := w.WriteString(msg); err != nil { // 记录错误，但别 panic —— 否则 channel 阻塞 continue } } w.Flush() // 最后刷一次 }() - 业务侧只做
logCh ，绝不碰 <code>*os.File或bufio.Writer - 初始化文件必须显式组合标志：
os.OpenFile(name, os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)；漏os.O_CREATE在生产环境必报no such file or directory
bufio.Writer 和 file.Sync() 怎么选
bufio.Writer 是性能关键，但它的 WriteString() 只写到用户态缓冲区，不落盘。是否调 file.Sync() 取决于可靠性要求：
- 非关键日志（如 debug）：不用
Sync()，靠定时w.Flush()（如每 50ms）+ 满阈值刷（如 ≥128 条）平衡延迟与丢失风险 - 关键日志（如 error、支付流水）：每次写完立刻
w.Flush(); file.Sync()，但注意Sync()是阻塞系统调用，会拖慢吞吐 - 务必在
WriteString()前检查句柄有效性：if file.Fd() == ^uintptr(0) { return errors.New("file closed") }，防止已关闭 fd 继续写，报invalid argument
真正容易被忽略的点是：哪怕你用了 channel 和单 writer，如果没显式设 bufio.NewWriterSize(file, 16*1024)，默认 4KB 缓冲在高频写入下会频繁触发 syscall，性能反不如直写；另外，file.Sync() 不是万能的——它只保证当前写入落盘，不保证之前未 flush 的 bufio 数据，所以必须先 Flush() 再 Sync()。
