OpenFile使用追加与同步标志

用 Go 写追加日志、审计记录或断点文件时，os.OpenFile 里最容易混淆的是“写到文件尾”和“写入后尽快落盘”。前者由 os.O_APPEND 控制，后者可以用 os.O_SYNC，也可以在一批写入完成后调用 File.Sync()。它们不是同一个开关：追加只决定写入位置，同步只决定写入的同步边界。

先分清 OpenFile 正在保护什么

把文件当作一条不断增长的记录流时，通常有两个不同的资产：已有记录不能被新记录覆盖，以及已经确认成功的记录要尽快提交到稳定存储。O_APPEND 保护的是前一个资产；O_SYNC 或 File.Sync() 处理的是后一个资产。

这也是为什么“追加并同步”需要组合多个标志，而不是寻找一个万能参数。OpenFile 的第二个参数是按位或组合的标志，必须包含一个访问模式：O_RDONLY、O_WRONLY 或 O_RDWR 三者之一。文件不存在时，只有带上 O_CREATE 才会创建它；此时第三个参数 perm 是创建权限，最终还会受到系统 umask 影响。

O_APPEND 只改变写入位置，不负责数据提交

O_APPEND 表示每次写入都以文件末尾为目标，适合不断追加的日志和事件记录。它不等同于“给每行日志加锁”，也不负责把数据提交到稳定存储；如果业务把一条记录拆成多次写入，记录边界仍然需要由应用层设计。

package main

import (
    "fmt"
    "os"
)

func appendAudit(path, message string) error {
    // O_APPEND 保证写入目标是文件末尾；O_CREATE 只在文件不存在时创建。
    // 0o600 适合包含内部审计信息的文件，最终权限还会受 umask 影响。
    f, err := os.OpenFile(path, os.O_WRONLY|os.O_CREATE|os.O_APPEND, 0o600)
    if err != nil {
        return fmt.Errorf("打开审计文件: %w", err)
    }
    defer func() {
        // 关闭错误不能覆盖前面的写入错误，但这里仍保留关闭动作。
        _ = f.Close()
    }()

    // 一次 WriteString 写出一条完整记录，避免把一行拆成多次写入。
    if _, err := f.WriteString(message + "\n"); err != nil {
        return fmt.Errorf("追加审计记录: %w", err)
    }
    return nil
}

示例刻意没有加入 O_TRUNC。如果把它和追加标志一起写进常量组合，打开动作就可能先截断旧文件，再让后续内容从空文件开始。对敏感审计文件，创建权限也不要照抄公开示例中的宽权限。

O_SYNC 和 File.Sync() 的同步边界不同

Go 的文档把 O_SYNC 定义为以同步 I/O 打开文件。它适合每条记录都需要尽快提交的窄场景，但每次写都可能带来更高的 I/O 成本。另一种方式是普通追加写，等一批记录完成后调用 f.Sync()；Sync 的语义是把当前文件内容提交到稳定存储，调用者必须检查它返回的错误。

package main

import (
    "fmt"
    "os"
)

func appendCheckpoint(path string, lines []string) error {
    // 批量写入时不使用 O_SYNC，把同步边界放到这一批记录的末尾。
    f, err := os.OpenFile(path, os.O_WRONLY|os.O_CREATE|os.O_APPEND, 0o640)
    if err != nil {
        return fmt.Errorf("打开检查点文件: %w", err)
    }
    defer f.Close()

    for _, line := range lines {
        // 每条记录仍只调用一次写入，便于恢复时按换行符读取。
        if _, err := f.WriteString(line + "\n"); err != nil {
            return fmt.Errorf("写入检查点: %w", err)
        }
    }
    // 同步失败必须向上返回，不能只依赖 Close 的结果。
    if err := f.Sync(); err != nil {
        return fmt.Errorf("同步检查点: %w", err)
    }
    return nil
}

如果业务要求每条记录都在写入返回前完成同步，可以把 O_SYNC 加入打开标志；如果业务允许一个小批次共用同步边界，则显式调用 File.Sync() 更容易控制吞吐。两者都不等价于数据库事务，也不能替代目录重命名、校验和或恢复协议。

生产代码还要处理哪些风险

打开成功不代表整条记录已经安全完成。目录不存在、权限不足、磁盘空间耗尽、部分写入以及关闭时的错误，都可能让“看起来写过”变成无法恢复的状态。对于可重放的日志，可以把记录设计成一行一个事件，并在恢复时丢弃最后一条不完整记录；对于不能丢的状态，则需要更完整的临时文件、校验和和原子替换协议。

• 防误覆盖：追加文件不要使用 O_TRUNC；只允许写入时使用 O_WRONLY，减少无意读写。
• 控制权限：创建权限按数据敏感度选择，例如内部审计信息可从 0o600 起步，并确认目录本身的权限。
• 检查结果：同时处理 WriteString、Sync 和 Close 的错误；不要把“函数返回 nil”简化成“磁盘一定可恢复”。
• 界定并发：O_APPEND 解决写入偏移问题，不自动提供跨进程的业务记录锁；需要严格记录边界时，使用单次写入或独立协调机制。

常见问题

只想在文件尾写内容，必须使用 O_SYNC 吗？

不需要。只追加可以使用 O_WRONLY|O_CREATE|O_APPEND；是否同步落盘取决于丢失窗口和吞吐要求。

O_APPEND 和 O_TRUNC 能一起用吗？

不建议这样表达业务意图。O_TRUNC 会在以可写方式打开时截断普通文件，和“保留旧记录并追加”的目标冲突。

调用 Close 后还需要 File.Sync 吗？

如果“写入成功”必须对应明确的稳定存储边界，应在关闭前显式检查 Sync；Close 本身不应被当作你业务协议里的同步确认。

实际选择可以归结为一句话：O_APPEND 管位置，O_SYNC 管每次写的同步语义，File.Sync() 管你主动定义的提交点。先按丢失窗口和写入频率选同步策略，再把权限与错误处理补齐，OpenFile 的标志组合才不会变成隐蔽的覆盖或恢复风险。