直接用sync.Mutex锁住file.Write()是最简单有效的防覆盖手段，但必须确保锁对象全局唯一、锁粒度仅限写入调用、文件以os.O_APPEND打开，否则仍可能丢数据或乱序；因其底层依赖POSIX write(2)，内核不保证多goroutine对同一fd的原子性，会竞争文件偏移量导致覆盖、截断、空字节等问题。
直接用 sync.Mutex 锁住 file.Write() 是最简单有效的防覆盖手段，但必须确保锁对象全局唯一、锁粒度只包写入调用、且文件以 os.O_APPEND 打开——否则仍可能丢数据或乱序。
为什么并发写同一 *os.File 一定会覆盖
Go 的 *os.File.Write() 底层调用 POSIX write(2)，内核不保证多线程对同一 fd 的原子性。多个 goroutine 同时调用，会竞争文件偏移量（offset），导致：
- 两行日志被拼成一行（如 "user login" 和 "error: timeout" 写成 "user error: timeout"）
- go run -race 报 Write at 0x... by goroutine N
- 文件末尾出现空字节或重复块
这不是 Go 的 bug，是操作系统层面的语义限制。
sync.Mutex 正确用法：锁什么、什么时候解锁
关键不是“加锁”，而是锁的范围和生命周期是否精准：
- 锁对象必须是包级或结构体字段级变量，不能在函数里声明（否则每个 goroutine 拿到的是不同锁）
- 只包裹
file.Write()或file.WriteString()调用，不要把fmt.Sprintf、json.Marshal、time.Now().Format()等耗时操作包进去 - 如果一次写入需要多次
Write()（比如 header + body + footer），必须全部放在同一个mu.Lock()/mu.Unlock()块里，不能分段加锁 - 务必确认文件是以
os.O_APPEND模式打开的：追加模式下内核会自动定位到文件末尾，减少 offset 竞争；但WriteString本身仍非整行原子，所以锁不可省
高并发场景下 sync.Mutex 的瓶颈与替代方案
当写入频率高（如每秒上千条日志）、延迟敏感时，sync.Mutex 会让所有 goroutine 排队，吞吐受限。这时更合理的选择是：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 用
channel+ 单 writer goroutine：生产者发[]byte到带缓冲 channel（如make(chan []byte, 1024)），一个 dedicated goroutine 顺序消费并file.Write()。天然无锁，还能批量写、加file.Sync()控制落盘时机 - 每个 goroutine 写独立临时文件（如
"log_12345.tmp"），最后用os.Rename()原子合并——适用于批处理，不适用于实时流式日志 - 按 key 分片写入：比如用户 ID 取模，
log_user_001.txt、log_user_002.txt……完全规避竞争，后续再合并分析
容易被忽略的三个细节
实际部署中最常踩坑的不是逻辑，而是这些底层行为：
立即学习“go语言免费学习笔记（深入）”；
-
file.Write()只写入内核页缓存，不保证落盘；若要防断电丢数据，必须显式调用file.Sync()（性能代价大，按需启用） -
bufio.Writer不是并发安全的，不能多个 goroutine 共享同一实例；如要用，每个 goroutine 自配一个，或用sync.Pool复用，但每次Pool.Get()后必须wr.Reset(file) - 多进程写同一文件时，
sync.Mutex完全无效——得用syscall.Flock或第三方库如github.com/go-flock/flock做文件级锁
