排查Go并发写入冲突需先用lsof和-race检测真实并发，再验证锁作用域、覆盖范围及进程间隔离，避免bufio.Writer误用导致缓冲区交错。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
排查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通道模型里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
