多个goroutine并发写同一文件会导致内容覆盖、错乱或空文件，因O_TRUNC每次清空文件且写入顺序不可控；读写同一文件需sync.RWMutex互斥，bufio.Writer非并发安全，须为每个goroutine分配独立实例或用chan聚合写入。

多个 goroutine 同时写同一个文件会出什么问题

直接并发调用 os.WriteFile 或反复 os.OpenFile(..., os.O_WRONLY|os.O_CREATE|os.O_TRUNC) 写同一路径，会导致后写入的内容完全覆盖前写入的内容，甚至出现文件内容错乱、截断或空文件。根本原因是 O_TRUNC 每次都会清空文件，而写入顺序无法保证。

• 避免在多个 goroutine 中独立打开并写入同一文件路径
• 若必须多路写入，统一用一个 *os.File 实例（需确保线程安全），或改用带锁的写入器
• 临时文件 + 原子重命名是更稳妥的替代方案：每个 goroutine 写自己的 temp_*.txt，最后由主 goroutine os.Rename

读写同一文件时是否需要互斥

是的，即使只是“读”和“写”分离，也存在竞态：写操作可能正在修改文件长度或内容，而读操作恰好执行 os.ReadFile 或 file.Read，导致读到不完整、重复或损坏的数据。Go 标准库的文件操作本身不提供跨 goroutine 的同步保障。

• 使用 sync.RWMutex：写时用 Lock()，读时用 RUnlock()，适合读多写少场景
• 对小文件，优先考虑“读-改-写”全量替换，而非原地更新，避免部分写入风险
• 注意：os.File 的 WriteAt 和 ReadAt 是线程安全的，但仅限于偏移量不重叠；若多个 goroutine 写不同 offset，仍需外部协调范围，否则可能破坏结构（如 JSON、CSV）

为什么 bufio.Writer 在并发写时不能直接共用

bufio.Writer 自身不是并发安全的——它的缓冲区、内部计数器、Flush 状态都未加锁。多个 goroutine 同时调用 w.Write() 可能导致 panic、数据丢失或缓冲区越界。

• 不要把同一个 *bufio.Writer 传给多个 goroutine
• 可为每个 goroutine 分配独立的 bufio.Writer（写临时文件或管道），再汇总
• 若必须聚合输出，用 chan []byte + 单个 writer goroutine 消费，这是最常用且可控的方式

var wg sync.WaitGroup
ch := make(chan []byte, 100)
go func() {
    w := bufio.NewWriter(outputFile)
    defer w.Flush()
    for b := range ch {
        w.Write(b)
    }
}()
// 其他 goroutine 发送数据：ch <- []byte("log line\n")

Windows 下并发读写文件还有额外限制

Windows 默认禁止其他进程（或 goroutine，因底层是系统级句柄）同时以写方式打开已打开的文件。即使 Go 程序内多个 goroutine 共享同一 *os.File，若底层文件被其他程序占用，或未正确设置 syscall.FILE_SHARE_READ | syscall.FILE_SHARE_WRITE，os.OpenFile 会返回 "The process cannot access the file because it is being used by another process" 错误。

立即学习“go语言免费学习笔记（深入）”；

• 跨平台代码应默认假设文件不支持并发读写，除非明确控制句柄共享模式
• Windows 上如需多进程读写，需用 os.OpenFile 配合 syscall.Open 手动指定 share flags，但复杂度高、可移植性差
• 更实际的做法：用本地 socket、内存映射（memmap）或轻量数据库（如 bolt）替代高频并发文件 I/O

文件 I/O 的并发瓶颈往往不在 Go 调度，而在操作系统层面的锁和磁盘寻道。真正需要高并发写入时，先问自己：这个数据是否必须立刻落盘？能不能缓存、批处理、走消息队列？