os.o_append在多进程下不保证原子性，因各进程拥有独立fd，内核无法协调写入顺序；sync.mutex仅限单进程有效，跨进程需临时文件+原子重命名或集中式日志服务。
os.OpenFile 的 O_APPEND 在多进程下是否原子
不是。os.O_APPEND 仅保证单次 write() 系统调用的“seek 到末尾 + 写入”两步原子性，但这个保证**只在同一个文件描述符（fd）上有效**。多进程各自调用 os.OpenFile 打开同一文件，会获得不同的 fd，内核无法协调它们之间的写入顺序——结果就是日志行交错、截断、甚至丢失。
现象包括：lsof -p PID 显示多个进程持有不同 fd 号；日志中出现半行、粘连行（如 "2026-06-24T07:20:00Z info\n2026-06-24T07:20:01Z warn" 变成 "2026-06-24T07:20:00Z info\n2026-06-24T07:20:01Z warn" 中间缺换行）；行数明显少于预期。
为什么 sync.Mutex 完全无效
sync.Mutex 是 Go 运行时级锁，只作用于当前进程内的 goroutine。它对其他进程完全不可见，也无法影响对方的 fd 或系统调用行为。你在自己的进程里加了锁，另一个进程照样打开文件、照样写——os.O_APPEND 的原子性只管自己那一次 write()，不管别人。
常见误用：
- 以为“只要我用了
os.O_APPEND | os.O_WRONLY | os.O_CREATE就安全”，忽略了多进程前提 - 在多进程程序中复用一个全局
*os.File句柄（根本不可行，fd 不跨进程传递） - 用
syscall.Flock却没在所有进程里统一加锁逻辑（Linux/macOS 下需每个进程都显式调用Flock才生效）
真正跨进程安全的追加方案只有两个
必须放弃“所有进程直接写同一个文件”的思路。可靠路径只有：
-
临时文件 +
os.Rename：每个进程写唯一命名的临时文件（如log_12345.tmp），完成后调用os.Rename("log_12345.tmp", "app.log")。POSIX 和 Windows NTFS 都保证同目录下Rename是原子的——目标文件要么是旧内容，要么是新内容，绝无中间态。注意：临时文件和目标文件必须在同一目录，否则Rename会退化为 copy+delete，失去原子性。 -
集中式日志服务：所有进程把日志发给一个专用进程（或本地 socket / Unix domain socket），由它单点写入。这本质是把多进程问题降级为单进程并发问题，再用
sync.Mutex或 channel 控制即可。
别碰 os.WriteFile 或 os.AppendFile：前者必清空重写，后者返回后立即关闭 fd，无法做 Sync()，也不支持缓冲，高并发下性能差且仍不解决多进程竞争。
Windows 下额外注意点
Windows 不支持 syscall.Flock，且 os.Rename 对已打开的目标文件会失败（ERROR_SHARING_VIOLATION）。所以：
- 确保没有进程以
os.O_RDWR或os.O_WRONLY持有目标日志文件句柄（比如某个进程用log.SetOutput后忘了关闭） - 临时文件命名要带随机后缀（如
log_12345_abcde.tmp），避免重名冲突 - 启动时扫描并清理残留的
*.tmp文件，防止磁盘占满
最易被忽略的是：你以为自己只开了一个进程在写，其实子进程、crontab 脚本、systemd service 实例可能同时运行——多进程不是理论风险，是部署常态。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
