Go 程序使用 os.OpenFile 以 O_APPEND|O_CREATE 模式在 Linux/macOS 上打开文件时，若未显式指定写权限标志（如 O_WRONLY 或 O_RDWR），会导致 bufio.Writer 写入成功但文件内容为空——这是因底层系统调用拒绝无写权限的追加操作所致。
go 程序使用 `os.openfile` 以 `o_append|o_create` 模式在 linux/macos 上打开文件时，若未显式指定写权限标志（如 `o_wronly` 或 `o_rdwr`），会导致 `bufio.writer` 写入成功但文件内容为空——这是因底层系统调用拒绝无写权限的追加操作所致。
在跨平台 Go 服务开发中，一个常见陷阱是：代码在 Windows 上正常写入文件，但在 Linux 或 macOS 上创建了空文件。根本原因在于不同操作系统对文件打开标志（file flags）的语义要求存在差异。
Windows 的 CreateFile API 对 FILE_APPEND_DATA 权限较为宽松，即使未显式声明写入模式，追加操作仍可隐式生效；而 Linux 和 macOS 遵循 POSIX 标准，open(2) 系统调用要求必须明确指定写访问权限（如 O_WRONLY 或 O_RDWR），否则即使设置了 O_APPEND，内核也会拒绝写入——此时 bufio.Writer.Write() 返回 nil 错误（因缓冲区写入内存成功），但 Flush() 实际无法将数据落盘，最终文件保持为空。
✅ 正确做法是：始终为追加写入显式添加写权限标志。修改原代码中的 os.OpenFile 调用：
f, err := os.OpenFile("test.txt", os.O_RDWR|os.O_APPEND|os.O_CREATE, 0644)⚠️ 注意权限掩码：生产环境应使用 0644（而非 0777）避免不必要的执行位，符合最小权限原则。
Linux Ai Server下载Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
完整修正版示例：
package main
import (
"bufio"
"fmt"
"os"
)
func main() {
// 关键修复：添加 os.O_RDWR（或 os.O_WRONLY）
f, err := os.OpenFile("test.txt", os.O_RDWR|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\n"))
if err != nil {
fmt.Printf("write error: %v\n", err)
return
}
if err = w.Flush(); err != nil { // 显式检查 Flush 错误
fmt.Printf("flush error: %v\n", err)
return
}
}? 补充说明：
- os.O_WRONLY|os.O_APPEND|os.O_CREATE 同样有效，适用于仅需写入的场景；
- os.O_RDWR 更通用（支持后续读取），但若仅追加，O_WRONLY 语义更精准；
- 始终检查 w.Flush() 的返回值——它才是真正触发系统写入并暴露 I/O 错误的关键步骤；
- 跨平台开发中，建议统一在 Linux 环境下验证文件 I/O 行为，因其权限模型更严格，能提前暴露 Windows 容忍性掩盖的问题。
遵循此规范，即可确保 Go 文件追加逻辑在 Windows、Linux 和 macOS 上行为一致、可靠落地。
