os.openfile是唯一可靠的追加方式，必须同时使用os.o_append、os.o_wronly、os.o_create三个flag，缺一不可；os.writefile等函数会覆写文件，不适用于追加；并发追加需mutex或channel同步，且windows下应使用"\r\n"换行。
os.OpenFile 是唯一可靠的方式，没有“追加专用函数”，所有看似便捷的封装（比如 os.AppendFile）底层仍是它——只是帮你固定了 flag 组合。选错 flag 会覆盖、报错、或创建失败，不是语法问题，是语义误用。
必须同时设置 os.O_APPEND、os.O_WRONLY 和 os.O_CREATE
这三个 flag 缺一不可，各自作用明确且不可替代：
-
os.O_APPEND：确保每次WriteString或Write都从文件末尾开始，系统级原子保证 -
os.O_WRONLY：只写模式，避免意外读操作干扰；若需边读边追加（如读头信息再写），才换os.O_RDWR -
os.O_CREATE：文件不存在时自动创建；漏掉它，OpenFile直接返回no such file or directory
常见错误：os.O_APPEND | os.O_WRONLY 单独使用 → 文件不存在时报错；os.O_APPEND | os.O_CREATE 缺少写权限标志 → 打开成功但写入失败（bad file descriptor）
os.WriteFile 和 ioutil.WriteFile 不能用于追加
这两个函数本质是“全量覆写”：
- 内部调用
os.Create，强制O_TRUNC，无论原文件多大，都会先清空再写入 - 并发下极危险：A goroutine 读全文件 → B goroutine 写入新内容 → A 拼接后全量写回 → B 的写入被覆盖
-
os.AppendFile虽名字像追加，但它不返回*os.File，无法做Sync或复用句柄，也不支持自定义换行符或缓冲写入
真正需要追加，就别碰这三个函数。
并发写同一个文件末尾要防乱序和截断
os.O_APPEND 保证系统调用层面的追加原子性，但 Go 的 WriteString 不是原子的：
- 它先拷贝字符串到内部 buffer，再 syscall write；多个 goroutine 同时调用，buffer 写入可能交错
- 结果可能是半行乱码、两行粘连、甚至某次写入被截断
- 安全做法只有两种：
sync.Mutex包住WriteString调用，或用 channel 把日志聚合到单个 writer goroutine
别信“O_APPEND 就线程安全”——那是对系统调用的误解，Go runtime 层面没做额外同步。
Windows 下换行符和首次创建权限容易被忽略
行为差异真实存在，不是开发环境问题：
- 用
"\n"追加后，在 Windows 记事本里显示为一行：记事本只识别"\r\n"，建议日志类文本统一用"\r\n" -
os.OpenFile第四个参数0644只在文件首次创建时生效；已有文件权限不变，但若目录本身无写权限（如 Windows Service 运行账户），创建会静默失败 - 调试时可加一句
os.Stat(filename)确认文件是否存在、权限是否可写，比盲猜快得多
跨平台追加最稳组合：os.O_APPEND | os.O_WRONLY | os.O_CREATE + "\r\n" + 显式检查 os.Stat。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
