Go os.OpenFile 追加写如何避免多个进程互相覆盖

我在把几个独立进程的运行记录汇总到同一个文件时，最初想到的是“先把文件指针移到末尾，再写入一行”。这个做法在并发下并不稳：两个进程可能同时看到同一个末尾位置，后写入的数据就有覆盖风险。Go 里更合适的起点是 os.OpenFile 配合 os.O_APPEND|os.O_CREATE|os.O_WRONLY，让每次写入都由操作系统按追加语义处理。

要避免多个进程因为“先定位末尾、后写入”而互相覆盖，应让每个进程都用 O_APPEND 打开文件，并把一条完整记录交给一次 Write。这能解决追加定位竞争，但不能替代跨多次写入的锁、事务或消息队列。

先把追加写的边界说清楚

O_APPEND 的关键不是“把偏移量设置到末尾”这么简单，而是让写操作带着追加意图进入底层文件接口。Go 的 os.OpenFile 文档把它列为写入时追加数据的标志；同一组标志中，O_CREATE 负责文件不存在时创建，O_WRONLY 表示只写。这样每个进程都可以独立打开同一个路径，不需要共享一个 *os.File。

还有一个容易忽略的限制：Go 源码明确规定，文件以 O_APPEND 打开后，调用 WriteAt 会返回错误。因此追加日志不要再混用“指定偏移量写入”的思路，也不要用 Seek(0, io.SeekEnd) 伪造追加模式。

从零做一个只追加一条记录的小工具

为了让并发边界容易判断，示例项目只接受一条消息，把时间、进程号和消息先拼成完整字节切片，然后调用一次 Write。项目目录可以这样初始化：

mkdir appendlog
cd appendlog
go mod init example.com/appendlog # 初始化一个可独立运行的小项目
touch main.go # 创建命令行入口，后续只放追加写逻辑

核心函数如下。这里没有先 Seek，也没有把一条记录拆成多次写；打开失败、短写、写入失败和关闭失败都分别处理。

package main

import (
    "errors" // 用于判断是否发生短写
    "fmt"    // 负责拼出一条完整日志记录
    "os"     // 提供 OpenFile 和 File.Write
    "time"   // 给示例记录加入可读时间
)

func appendRecord(path, message string) error {
    // O_APPEND 让每次 Write 都以追加方式定位，避免手动 Seek 的竞争窗口。
    f, err := os.OpenFile(path, os.O_WRONLY|os.O_CREATE|os.O_APPEND, 0o644)
    if err != nil {
        return fmt.Errorf("open log: %w", err)
    }

    record := fmt.Sprintf("%s %s\\n", time.Now().Format(time.RFC3339), message)
    n, err := f.Write([]byte(record)) // 一次交付完整记录，降低行内交错概率
    if err != nil {
        _ = f.Close() // 写入错误优先返回，关闭错误不能覆盖它
        return fmt.Errorf("write log: %w", err)
    }
    if n != len(record) {
        _ = f.Close() // 短写同样要释放文件描述符
        return errors.New("write log: short write")
    }
    if err := f.Close(); err != nil {
        return fmt.Errorf("close log: %w", err)
    }
    return nil
}

真实命令行入口只需读取参数并调用这个函数：

func main() {
    // 示例固定使用相对路径，部署时可改成配置注入的绝对路径。
    if err := appendRecord("runtime.log", "worker-2 finished"); err != nil {
        panic(err) // 示例程序直接退出；服务中应交给统一日志或重试策略
    }
}

多个进程同时写时，哪些情况仍然需要加锁

这段实现解决的是“每个进程都把一条记录追加到当前文件末尾”。它不承诺所有更大的业务动作自动互斥。比如把一条 JSON 记录拆成三次 Write，另一个进程就可能插入中间；先写正文、再写校验行也不是一个原子事务。

我实际会按下面的边界选方案：单行日志用单次 Write 配合 O_APPEND；同一进程内多个 goroutine 还要维护共享缓冲区或记录顺序时，用 sync.Mutex；跨进程要保证多段写入的整体性，则增加操作系统锁、单独的写入进程，或者把记录交给消息队列。不要把 O_APPEND 当成“文件数据库”。

运行后怎么检查没有发生覆盖

可以启动多个相同的 appendlog 进程，让每个进程只写一条带有唯一标记的记录，然后检查文件行数和标记数。这里的检查关注文件内容，不把一次演示结果夸大成所有文件系统上的并发保证。

go run . &
go run . &
wait
wc -l runtime.log # 统计记录行数，检查是否少行
tail -n 5 runtime.log # 查看末尾记录是否保持完整换行

生产接入前再核对四点：日志目录已经存在且权限可写；路径不会让多个租户意外共用；每条记录的字节内容已经在一次 Write 前拼好；进程退出、磁盘满或关闭失败时有可观测的错误处理。如果必须保证严格顺序或可重放，直接使用集中写入组件通常比继续堆文件锁更清楚。

常见问题

用了 O_APPEND 还需要调用 Seek 吗？

不需要。追加定位已经由打开标志表达，额外 Seek 只会让代码更难读，也可能引入错误的偏移假设。

O_APPEND 能保证一条多行日志永远不被插入吗？

不能把多次写入当成一个整体。把记录先拼好并一次 Write，只能把协调范围缩小；多段写入的整体性需要锁或单写入者。

为什么不用 WriteAt 指定文件末尾？

因为 WriteAt 是偏移量写入模型，追加模式下 Go 会直接返回错误。多个进程也不应各自读取末尾后再竞争同一个偏移量。

小项目的验收标准很简单：每个进程都用 O_APPEND 打开、每条记录尽量一次 Write、所有返回值都检查；一旦需求从“追加日志”升级成“跨进程提交一组文件内容”，就及时换成锁、单写入者或队列。