Go如何在并发场景下读写文件_Go并发文件访问注意事项_技术教程

多个goroutine并发写同一文件会导致内容覆盖、截断或交错，因O_TRUNC重置文件且write()非原子；需复用*os.File并用sync.Mutex保护，配合bufio.Writer缓冲及显式flush，同时检查Write返回值。

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

直接并发调用 os.WriteFile 或反复 os.OpenFile(..., os.O_WRONLY|os.O_CREATE|os.O_TRUNC) 写同一路径，会导致文件内容被随机覆盖或截断——因为每次打开都带 O_TRUNC，且写入无顺序保证。更隐蔽的是用 os.O_APPEND 看似安全，但在 Linux 上若文件描述符未设 O_APPEND（比如通过 dup 复制），或在 NFS 等特殊文件系统上，仍可能产生交错写入。

现象：日志文件出现乱码、半截 JSON、缺失字段，甚至空文件
根本原因：系统调用 write() 本身不是原子的，尤其当写入超过 PIPE_BUF（通常 4KB）时，内核可能拆成多次 syscall
不要依赖 os.O_APPEND 做“并发安全”的错觉——它只保证每次 write() 追加到当前 EOF，不保证多 goroutine 调用间的执行顺序

用 `sync.Mutex` 保护文件句柄是否足够

对单个 *os.File 实例加锁能避免竞态，但要注意锁的粒度和生命周期。如果每次写都 os.OpenFile → 写 → Close，锁没意义

；必须复用文件句柄，并确保所有写操作都走同一把锁。

正确做法：在初始化时打开一次文件（如用 os.O_WRONLY | os.O_CREATE | os.O_APPEND），全局持有一个 *os.File 和一个 sync.Mutex
错误做法：锁包裹 os.WriteFile——它内部会打开/关闭文件，锁完全无效
注意 defer f.Close() 不能放在 goroutine 内部，否则可能提前关闭；应在程序退出前统一关闭

var (
    logFile *os.File
    logMu   sync.Mutex
)

func init() {
    f, err := os.OpenFile("app.log", os.O_WRONLY|os.O_CREATE|os.O_APPEND, 0644)
    if err != nil {
        log.Fatal(err)
    }
    logFile = f
}

func writeLog(msg string) {
    logMu.Lock()
    defer logMu.Unlock()
    logFile.Write([]byte(msg + "\n"))
}