Go 追加日志时为什么原文件内容被清空

Go 里“追加日志却把原文件清空”，通常不是 WriteString 的问题，而是打开文件时把 os.O_TRUNC 和写权限一起传给了 os.OpenFile。这个标志会在打开普通可写文件时把长度截为 0；os.O_APPEND 只负责让每次写入落到文件末尾，不能抵消截断动作。

为什么 O_TRUNC 会让“追加”变成覆盖

os.OpenFile 的第二个参数是按位或组合的打开标志。它们的职责不同：O_APPEND 表示写入前定位到文件末尾，O_CREATE 表示文件不存在时创建，O_TRUNC 则表示打开时截断普通可写文件。于是下面这类写法虽然看起来同时包含“追加”和“创建”，但每次打开都会先清空旧内容：

// 错误示例：O_TRUNC 会在写入前把旧日志长度设为 0
f, err := os.OpenFile("service.log", os.O_WRONLY|os.O_CREATE|os.O_APPEND|os.O_TRUNC, 0644)
if err != nil {
    return err
}
defer f.Close()

// 这里能写入，但此前的内容已经被截断
_, err = f.WriteString("request finished\n")
return err

所以排查时先搜索 O_TRUNC，再检查是否存在 os.Create 或反复打开文件的封装。os.Create 本身就是“创建并截断”的语义，不能拿来做追加日志。

追加日志应该怎样组合 OpenFile 参数

只追加、不主动覆盖时，最小组合是 O_WRONLY|O_APPEND|O_CREATE。文件存在时保留旧内容并从末尾写入；不存在时创建新文件。权限位 0644 是创建时的请求权限，最终权限还会受到系统 umask 影响。

package main

import (
    "fmt"
    "os"
)

func appendLog(path, message string) error {
    // O_APPEND 保留旧内容并把写入位置放到末尾
    f, err := os.OpenFile(path, os.O_WRONLY|os.O_APPEND|os.O_CREATE, 0644)
    if err != nil {
        return fmt.Errorf("open log %q: %w", path, err)
    }
    defer f.Close() // 函数退出时释放文件描述符

    // 统一补换行，避免多条日志粘在同一行
    if _, err := f.WriteString(message + "\n"); err != nil {
        return fmt.Errorf("write log %q: %w", path, err)
    }
    return nil
}

这里没有把 O_RDWR 当成默认选项：日志只写不读时，O_WRONLY 更直接。若调用方已经带了换行，可把“补换行”改成约定好的格式化层，避免出现空行。

用三个检查点确认修复没有留下隐患

1. 看标志：确认追加函数中没有 O_TRUNC、os.Create 或其他会覆盖文件的路径。
2. 看路径：确认父目录已经存在；O_CREATE 不会递归创建目录，路径错误应直接返回并记录。
3. 看错误：分别处理打开和写入错误；如果对落盘时机有明确要求，再根据场景调用 f.Sync()，不要把它误认为并发锁。

并发方面，Go 文档说明同一个 *os.File 的方法可以并发使用，但这不等于多个进程的日志格式天然安全。多个进程同时追加时，尽量让每条记录一次写完，按文件轮转方案协调重命名与重新打开；需要严格顺序或结构化记录时，应交给专门的日志组件或集中采集端。

常见问题

只写 O_APPEND 不写 O_CREATE 可以吗？

可以，但文件不存在时会打开失败。希望日志首次运行自动出现时，应组合 O_CREATE，并确保父目录已创建。

O_APPEND 能保证多条日志绝不交叉吗？

它解决的是每次写入的追加位置，不是完整日志协议。跨进程、超长写入或轮转场景仍要设计记录边界和协调策略。

为什么删掉 O_TRUNC 后日志还是没有写进去？

继续检查 OpenFile 返回的错误、父目录、权限位和实际路径；不要只看 WriteString 的返回值。

记住一句话：O_APPEND 决定“写到哪里”，O_TRUNC 决定“打开时是否清空”。追加日志只需让前者存在，并明确排除后者。