Go OpenFile 为什么追加写仍覆盖文件

先给结论：os.OpenFile 只有在 flags 包含 os.O_APPEND 时，写入才会以追加语义落到文件末尾。最常见的覆盖原因是同时带了 os.O_TRUNC、实际调用了 os.Create，或者在循环里每写一条就重新打开一次文件。Write 通常只是把当前打开方式执行出来，并不会替你修正 flags。

官方文档：https://pkg.go.dev/os

先看 OpenFile 的 flags 是否真的支持追加

排查时先把打开文件的那一行单独拿出来，不要只看函数名里有没有 “append”。标准追加组合通常是 os.O_APPEND | os.O_CREATE | os.O_WRONLY：没有文件就创建，已有文件则按追加方式写入。这里的竖线是按位或，用来组合独立的打开选项。

例如 os.O_APPEND|os.O_CREATE|os.O_WRONLY|os.O_TRUNC 看起来像把需求都写上了，实际却把“追加”和“打开时清空旧内容”放在了一起。打开动作一发生，旧内容就可能先被截断，后续写到末尾也只能看到本次新内容。

用一个稳定的追加写函数复核打开、写入和关闭

下面的函数把文件打开一次、写入一条数据并关闭。示例没有把返回值或日志说成真实运行结果；它只展示排查时应该观察的资源边界。

package appendlog

import (
    "fmt"
    "os"
)

// AppendLine 将一行文本追加到文件末尾；调用者应在外层控制调用频率。
func AppendLine(path string, line string) error {
    // O_APPEND 保留已有内容；O_CREATE 只在文件不存在时创建。
    f, err := os.OpenFile(path, os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0o644)
    if err != nil {
        return fmt.Errorf("打开追加文件: %w", err)
    }
    // 确保所有返回路径都释放文件描述符，写入错误优先返回。
    defer f.Close()

    if _, err := f.WriteString(line + "\n"); err != nil {
        return fmt.Errorf("追加写入: %w", err)
    }
    return nil
}

这段代码的关键不是函数名，而是 flags 中没有 O_TRUNC，并且没有用 os.Create 替换 OpenFile。权限参数 0o644 只在文件需要创建时作为初始权限参考；它不会改变已有文件的内容，也不会让普通写入自动追加。

如果应用会连续写很多条记录，更适合在初始化阶段打开一次并复用 *os.File，最后统一关闭。每次调用都打开和关闭虽然不必然覆盖，但会让生命周期更难观察，也容易把另一条使用 os.Create 的路径混进来。

再查是不是每次写入都重新打开文件

如果 flags 看起来正确，但结果还是只有最后一条内容，下一步就查打开动作的位置。下面几类写法容易制造“追加失效”的错觉：

• 循环内调用 os.Create(path)：它带有截断语义，每一轮都会先清空旧文件。
• 循环内调用 OpenFile 时混入 O_TRUNC：即使同时写了 O_APPEND，打开阶段仍可能清空内容。
• 打开后调用 f.Seek(0, 0)：这会把当前位置移到开头，不能与“始终追加”目标混用。
• 使用 WriteAt(data, 0)：这是指定偏移写，不是普通的追加接口；不要把固定偏移当成文件末尾。

排查可以从一次写入的入口反向跟踪：谁负责打开、谁修改了文件偏移、谁关闭文件、是否还有另一个初始化函数重新打开同一路径。尤其要搜索同一文件路径是否同时出现在 os.Create、O_TRUNC 或固定偏移写入代码中。

修复后怎样判断方向是对的

先建立一份已有内容，再让程序追加一条；修复目标是旧内容仍在，新内容位于其后。若只保留最后一条，优先回到“是否每轮重新打开并截断”这条线索，而不是先怀疑 WriteString。

还要区分“文件被覆盖”和“读取时只读了一部分”：读取代码中的 Read 可能只返回部分字节，不能据此推断写入端清空了文件。写入端则应检查 Write 返回的字节数和错误，并让 Close 的错误有明确处理策略；示例用 defer 释放资源，但生产代码若特别关心关闭时的落盘错误，可以改为显式关闭并保留前一个错误。

常见补充问题

只加 O_APPEND，不加 O_CREATE 可以吗？

可以，但文件不存在时打开会失败。是否加 O_CREATE 取决于业务是否允许首次写入自动建文件。

O_APPEND 能替代文件锁吗？

不能把它当作通用的跨进程协调方案。它表达的是写入定位语义；多个写入者的记录边界、重试和业务顺序仍需要单独设计。

为什么不直接用 os.WriteFile？

WriteFile 更适合一次性写入完整内容，已有文件会被截断。持续追加日志时，应明确使用 OpenFile 的追加 flags 或复用已打开文件。

这次故障的定位顺序可以压缩成一句话：先看有没有 O_APPEND，再看有没有 O_TRUNC 或 os.Create，最后追踪是否有 Seek、WriteAt 和重复打开。只要把“打开时是否保留旧内容”和“写入时写到哪里”分开检查，追加写覆盖问题通常就能落到具体一行代码。