并发写同一*os.File必然出错，必须隔离写路径并控制偏移量；因其Write()不保证原子性，多goroutine写同一fd会导致覆盖、截断、空字节等问题。
直接并发写同一 *os.File 必然出错，不是“要不要加锁”的问题，而是“必须隔离写路径+控制偏移量”的问题。
为什么 *os.File.Write() 并发调用会丢数据
Go 的 *os.File 本身不保证并发安全：它的 Write() 内部依赖系统调用 write(2)，而 POSIX 标准下，多个线程/协程对同一文件描述符（fd）的 write 调用不保证原子性，也不同步更新文件偏移量（offset）。结果就是：
- 两段日志内容被写到同一位置，相互覆盖
- 一行日志被截成两半，中间插入另一行的开头
-
go run -race明确报出Write at 0x... by goroutine N - 文件末尾出现空字节、重复块或长度异常
用 sync.Mutex 加锁的三个硬约束
加锁不是贴膏药，是重构写入契约。以下任一违反，锁就形同虚设：
- 锁变量必须是包级或结构体字段级 —— 函数内声明
var mu sync.Mutex，等于每个 goroutine 拿到的是不同锁 - 所有写入路径（包括
WriteString、fmt.Fprintln、json.NewEncoder(file).Encode()）必须走同一把锁 - 锁内只做
file.Write()或buf.Write()，禁止time.Now().Format()、json.Marshal()、http.Get()等任何耗时操作
正确示例：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
var logFile *os.File
var logMu sync.Mutex
func safeLog(msg string) {
data := []byte(msg + "\n") // 拼接提前完成
logMu.Lock()
defer logMu.Unlock()
logFile.Write(data) // 仅此一句 I/O
}
比 sync.Mutex 更适合高频写入的方案
当写请求密集（如 Web 请求日志），单锁排队会成为瓶颈。这时应放弃“保护共享 fd”，转为“消除共享”：
- 用
chan []byte+ 单 writer goroutine：生产者发字节切片，消费者顺序落盘；天然无锁，还能批量Write()、加bufio.Writer、控制Flush()频率 - 每个 goroutine 写独立临时文件（用
uuid.NewString()或time.Now().UnixNano()命名），最后用os.Rename()原子合并 —— 适合批处理，避免任何锁竞争 - 跨进程场景（不止一个 Go 进程写同一文件）必须用
syscall.Flock()或github.com/go-flock/flock，sync.Mutex完全无效
容易被忽略的底层陷阱
即使逻辑上加了锁，仍可能因 OS 层行为导致失败：
-
os.OpenFile(..., os.O_APPEND)不能替代锁：虽然O_APPEND让每次write自动 seek 到末尾，但多个 goroutine 同时触发 write，内核仍可能因调度顺序导致写入重叠（尤其在 NFS 或某些容器挂载场景） - 没调
file.Close()就退出？文件缓冲区可能未刷盘，且锁住的 fd 在 panic 时不会自动释放 - 用
bufio.Writer时忘了Flush()—— 数据卡在内存缓冲区，看似写成功，实则没落盘
