排查 Go 并发写入冲突，第一步是准确识别现象：日志是否混乱？文件内容是否相互覆盖？还是程序直接 panic 崩溃？切忌盲目审查代码中是否缺少加锁——因为 sync.Mutex 在跨进程场景下根本无效，而 flock 又常因锁路径被忽略或阻塞逻辑而失效。抓住问题关键，才能事半功倍。

确认是否真的存在并发写入冲突

先别着急修改代码，利用系统工具获取可靠证据。

执行 lsof -p $(pidof your_app) | grep your_log_file，如果同一文件被多个 fd（例如 7u、8u、9u）同时打开，说明至少有 3 个 goroutine 或进程在并发操作该文件。

再运行 go run -race main.go，一旦出现 Write at 0x... by goroutine N 这样的告警，即可直接定位到对应代码行——这比逐行读代码快十倍。

【务必开启 race 检测，不加 -race 等于盲人摸象】

检查锁对象是否真正被共享

锁是否有效，关键在于它是否真正被所有写入操作所共享。

方法一：查看锁变量的作用域。找到所有 mu.Lock() 调用点，向上追溯 mu 的声明位置——如果它在函数内部（例如 func write() { var mu sync.Mutex }），那么每个 goroutine 拿到的都是新锁，完全无效。

方法二：搜索全局锁名称。使用 grep -r "var.*sync.Mutex" . --include="*.go"，确认锁变量是否定义在包级别或作为结构体字段。如果发现多个同名但不同包下的 mu，说明这些锁并未串联起来。

方法三：通过日志验证锁效果。在 mu.Lock() 后加一行 log.Printf("locked by %d", time.Now().UnixNano()%1000)，然后运行压力测试。如果日志中连续出现相同时间戳（毫秒级），则表明锁生效；如果时间戳跳跃剧烈，很可能锁已失效或未覆盖全部写路径。

验证写入路径是否全部被锁定

第一步：列出所有可能触发写文件的操作。包括 file.Write()、file.WriteString()、fmt.Fprintln(file, ...)、log.SetOutput(file) 后的 log.Print()——这些底层都调用 *os.File.Write，必须统一纳入同一把锁的保护范围。

第二步：逐一检查是否有遗漏。要特别注意错误处理分支：例如 if err != nil { file.WriteString("ERROR: " + msg) } 这种写法常常绕过主锁，直接裸写。

第三步：确认 defer mu.Unlock() 紧跟在 mu.Lock() 之后。如果中间插入了 return 或 panic，并且未使用 defer，锁将永远无法释放。正确写法必须是 mu.Lock(); defer mu.Unlock() 紧密相邻，中间不得插入任何可能导致提前退出的语句。

区分进程内锁与跨进程锁

方法一：判断是否有多个实例在运行。执行 ps aux | grep your_app_name，如果输出多行，说明不止一个进程在写同一文件——此时 sync.Mutex 完全无效，必须切换为 flock。

方法二：使用 flock 替代方案快速验证。引入 github.com/nightlyone/lockfile，初始化 lf, _ := lockfile.New("app.log.lock")，每次写前调用 lf.TryLock()，写完后调用 lf.Unlock()。如果数据错乱现象消失，即可证明是跨进程冲突。

【锁文件路径必须与业务文件在同一磁盘分区，否则 Windows 下 os.Rename 会失败】

检查是否误用了 bufio.Writer

很多人以为包裹一层 bufio.NewWriter(file) 就能实现线程安全，其实不然。它的 WriteString() 和 Flush() 仍然会调用底层的 *os.File.Write，并且缓冲区自身并未加锁——多个 goroutine 同时向同一个 bufio.Writer 写入，缓冲区内容一样会交错。

唯一安全的做法：让每个 goroutine 使用独立的 bufio.Writer，或者将 bufio.Writer 封装进单 writer goroutine 的通道模型中。