Go 程序使用 os.OpenFile 以 O_APPEND | O_CREATE 模式在 Linux/macOS 上创建并追加写入文件时，文件被成功创建但内容为空；根本原因是缺少写权限标志，需显式添加 O_RDWR 或 O_WRONLY。
go 程序使用 `os.openfile` 以 `o_append | o_create` 模式在 linux/macos 上创建并追加写入文件时，文件被成功创建但内容为空；根本原因是缺少写权限标志，需显式添加 `o_rdwr` 或 `o_wronly`。
在跨平台 Go 应用开发中，文件写入行为的差异常源于操作系统对文件打开标志（file flags）的语义要求不同。Windows 对 O_APPEND | O_CREATE 的组合具有宽松的隐式写权限处理，而 Linux 和 macOS 遵循 POSIX 标准：仅指定 O_APPEND 并不自动赋予写入能力，必须显式声明写操作权限（即 O_WRONLY 或 O_RDWR）。
上述示例代码的问题在于：
f, err := os.OpenFile("test.txt", os.O_APPEND|os.O_CREATE, 0777)该调用在 Linux 上等价于“以只读+追加+创建方式打开文件”，导致后续 bufio.Writer.Write() 实际写入失败（但 w.Flush() 不报错，因缓冲区清空成功，而底层系统调用 write() 已静默失败）。可通过检查 w.Flush() 的返回值验证这一点：
if err := w.Flush(); err != nil {
fmt.Printf("Flush failed: %v\n", err) // Linux 下将输出 "bad file descriptor" 或类似错误
}✅ 正确写法（兼容 Windows、Linux、macOS）：
package main
import (
"bufio"
"fmt"
"os"
)
func main() {
// 关键修复：添加 O_WRONLY（或 O_RDWR），确保写权限
f, err := os.OpenFile("test.txt", os.O_WRONLY|os.O_APPEND|os.O_CREATE, 0644)
if err != nil {
fmt.Printf("Failed to open file: %v\n", err)
return
}
defer f.Close()
w := bufio.NewWriter(f)
_, err = w.Write([]byte("hello"))
if err != nil {
fmt.Printf("Write failed: %v\n", err)
return
}
if err := w.Flush(); err != nil {
fmt.Printf("Flush failed: %v\n", err)
return
}
fmt.Println("Successfully wrote 'hello' to test.txt")
}? 注意事项：
- 文件权限建议使用 0644（而非 0777），避免过度开放执行权限，符合最小权限原则；
- O_WRONLY|O_APPEND|O_CREATE 是最精简且语义明确的组合；O_RDWR 也可用，但若仅需写入，O_WRONLY 更准确；
- 始终检查 w.Flush() 的返回值——bufio.Writer 的 Write() 成功不代表数据已落盘，Flush() 才触发实际系统写入并暴露 I/O 错误；
- 跨平台开发中，应以 Linux 行为为基准进行测试，因其对 POSIX 合规性要求最严格。
总结：跨平台文件操作不可依赖单一平台的宽容行为。明确指定 O_WRONLY 是保障 Go 程序在类 Unix 系统上可靠写入的关键一步。
