os.WriteFile并发调用会覆盖数据，因不支持追加且非并发安全；正确做法是加锁、通道+单goroutine写或临时文件+rename原子替换。
多个 goroutine 直接 os.WriteFile 会覆盖或丢失数据
不安全。os.WriteFile 是原子写入，但「原子」仅指「整个内容一次性替换文件」，不是「并发安全」。如果 10 个 goroutine 同时调用 os.WriteFile("log.txt", data, 0644)，最终文件只保留最后一次写入的内容，其余 9 次全部被覆盖——这不是竞态，是逻辑错误。
常见误用场景：日志收集、批量导出、事件聚合等需要「追加」或「累积写入」的地方。
- 想追加？
os.WriteFile不支持，它总是 truncate + write - 想并发写不同文件？可以，只要路径不重叠（如
"log_1.txt","log_2.txt"） - 想并发写同一文件的**不同偏移位置**？需手动
os.OpenFile+file.WriteAt，且必须确保 offset 不重叠，否则仍会覆盖
os.OpenFile + file.Write 需要自己加锁
默认的 *os.File 不是并发安全的：Write 方法内部操作文件偏移量（seek + write），多 goroutine 并发调用会导致偏移错乱、数据交错或部分写入失败（尤其在小缓冲、高频率场景下）。
正确做法是显式同步：
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Mutex包裹file.Write调用（适合低频、写入量小） - 用
sync.RWMutex不适用——因为Write是写操作，不能并发 - 避免用
file.Seek手动跳转后写，容易因锁粒度或顺序引发隐性 bug
示例关键片段：
var mu sync.Mutex
f, _ := os.OpenFile("data.bin", os.O_WRONLY|os.O_APPEND, 0644)
// ...
mu.Lock()
n, err := f.Write(buf)
mu.Unlock()
高频写场景推荐 bufio.Writer + 单 goroutine 消费通道
比锁更高效、更可控。核心思路是：所有生产者 goroutine 把待写数据发到一个 chan []byte，由**唯一一个 writer goroutine** 从通道收数据、批量刷盘。
优势明显：
- 完全规避锁竞争和系统调用开销（
Write变成内存拷贝 + 缓冲区管理） - 天然支持合并小写入（减少磁盘 IO 次数）
- 可轻松加入限速、落盘策略（如每 10ms 刷一次，或缓冲达 4KB 就 flush）
- 关闭时能优雅 drain 通道，避免数据丢失
注意点：
- 通道需设缓冲（如
make(chan []byte, 1000)），否则生产者可能被阻塞 - 每次
send前应做buf = append([]byte(nil), buf...)避免底层切片共享导致数据污染 -
bufio.NewWriterSize(f, 64*1024)的缓冲大小建议 ≥ 单次平均写入量
临时文件 + os.Rename 是唯一真正原子的「并发安全写」方案
如果你需要的是「多个 goroutine 都能独立完成一次完整写入，且不互相干扰、不丢失、不损坏」，唯一可靠方式是：每个写入都生成唯一临时文件（如用 os.CreateTemp），写完再 os.Rename 覆盖目标。Linux/macOS 下 Rename 是原子的，即使并发 rename 同一目标，也只会有一个成功，其余返回 syscall.EBUSY 或 os.ErrExist（取决于是否加 O_EXCL）。
适用场景有限但关键：
- 配置热更新（写
config.json.tmp→ rename 成config.json） - 数据库快照导出
- 任何要求「要么全写完，要么完全不影响原文件」的场合
代价是磁盘空间临时翻倍、rename 系统调用开销略高，且无法用于「追加」语义。
别指望 io.WriteString 或 fmt.Fprintln 自带并发保护——它们只是包装了 Write，底层仍是裸文件操作。
