Go 中调用 os.OpenFile 时若仅传入 os.O_APPEND 而未指定读写模式，会导致“bad file descriptor”错误；必须显式添加 os.O_WRONLY（或 os.O_RDWR）标志才能获得可写句柄。
先把这个关键结论摆在这儿——很多 Go 开发者第一次踩这个坑时，都会一脸懵：明明用了 O_APPEND，为什么打开文件后写入就报错？原因其实很简单，却藏得很深。
在 Go 程序里用 os.O_APPEND 模式打开文件做日志写入，是再常见不过的需求了。但有一个非常容易忽略的细节：只传 O_APPEND，不声明访问权限（比如只写或读写），是行不通的。底层系统调用 open() 会直接返回 EBADF（Bad file descriptor），因为 POSIX 标准强制要求 flags 参数必须包含且仅包含一个访问模式标志：O_RDONLY、O_WRONLY 或 O_RDWR。O_APPEND 本身只是个修饰符，它告诉内核“每次写入前自动 seek 到文件末尾”，但并没有告诉内核你要读还是写——内核默认给的是只读（O_RDONLY），而只读句柄用来写，自然就报错了。
回到你的代码，问题就出在这一行：
f, err := os.OpenFile("./log.log", os.O_APPEND, os.ModeAppend) // ❌ 错误：缺少 O_WRONLY
os.O_APPEND 本身不隐含写权限，它只是一个行为修饰符。Go 的 os.OpenFile 会把参数原样传给系统 open() 调用，而 Linux 内核碰到不含有效访问模式的 flags 时，默认当成 0（即 O_RDONLY），于是句柄无效，后续写入自然失败。
✅ 正确的写法是组合使用：
f, err := os.OpenFile("./log.log", os.O_APPEND|os.O_WRONLY, 0666)
if err != nil {
log.Fatalf("failed to open log file: %v", err)
}
defer f.Close() // 注意：此处应 defer，避免 panic 前未关闭
logTime := time.Now().Format(time.RFC3339)
_, err = f.WriteString(logTime + " - " + msg + "\n")
if err != nil {
log.Printf("failed to write log: %v", err)
}
这里有几个需要留意的坑：
- 第三个参数是权限位，应该用
0666（八进制字面量），而不是os.ModeAppend。后者是os.FileMode类型的常量，用于os.MkdirAll或os.Chmod等操作，不能作为os.OpenFile的 flag 使用，混用会导致静默逻辑错误——文件能打开，但行为不符合预期。 - 即使有
sync.Mutex保护，也不建议频繁反复OpenFile+Close。高频日志场景下，复用文件句柄，配合bufio.Writer能大幅提升性能。 - 如果需要在多个 goroutine 中安全写入，推荐使用
log.SetOutput(f)配合标准库log，或者自己封装一个带锁的io.WriteCloser，而不是手动管理文件描述符。
说到底，os.O_APPEND 必须与 os.O_WRONLY（或 os.O_RDWR）按位或组合使用，这是系统调用层面的契约，不是 Go 特有的行为。理解这个底层约束，就能从根本上避免 “bad file descriptor” 这类错误。
