多个goroutine并发写同一文件会导致内容覆盖、错乱或空文件，因O_TRUNC每次清空文件且写入顺序不可控；读写同一文件需sync.RWMutex互斥，bufio.Writer非并发安全，须为每个goroutine分配独立实例或用chan聚合写入。
多个 goroutine 同时写同一个文件会出什么问题
直接并发调用 os.WriteFile 或反复 os.OpenFile(..., os.O_WRONLY|os.O_CREATE|os.O_TRUNC) 写同一路径，会导致后写入的内容完全覆盖前写入的内容，甚至出现文件内容错乱、截断或空文件。根本原因是 O_TRUNC 每次都会清空文件，而写入顺序无法保证。
- 避免在多个 goroutine 中独立打开并写入同一文件路径
- 若必须多路写入，统一用一个
*os.File实例（需确保线程安全），或改用带锁的写入器 - 临时文件 + 原子重命名是更稳妥的替代方案：每个 goroutine 写自己的
temp_*.txt，最后由主 goroutineos.Rename
读写同一文件时是否需要互斥
是的，即使只是“读”和“写”分离，也存在竞态：写操作可能正在修改文件长度或内容，而读操作恰好执行 os.ReadFile 或 file.Read，导致读到不完整、重复或损坏的数据。Go 标准库的文件操作本身不提供跨 goroutine 的同步保障。
- 使用
sync.RWMutex：写时用Lock()，读时用RUnlock()，适合读多写少场景 - 对小文件，优先考虑“读-改-写”全量替换，而非原地更新，避免部分写入风险
- 注意：
os.File的WriteAt和ReadAt是线程安全的，但仅限于偏移量不重叠；若多个 goroutine 写不同 offset，仍需外部协调范围，否则可能破坏结构（如 JSON、CSV）
为什么 bufio.Writer 在并发写时不能直接共用
bufio.Writer 自身不是并发安全的——它的缓冲区、内部计数器、Flush 状态都未加锁。多个 goroutine 同时调用 w.Write() 可能导致 panic、数据丢失或缓冲区越界。
- 不要把同一个
*bufio.Writer传给多个 goroutine - 可为每个 goroutine 分配独立的
bufio.Writer（写临时文件或管道），再汇总 - 若必须聚合输出，用
chan []byte+ 单个 writer goroutine 消费，这是最常用且可控的方式
var wg sync.WaitGroup
ch := make(chan []byte, 100)
go func() {
w := bufio.NewWriter(outputFile)
defer w.Flush()
for b := range ch {
w.Write(b)
}
}()
// 其他 goroutine 发送数据：ch <- []byte("log line\n")
Windows 下并发读写文件还有额外限制
Windows 默认禁止其他进程（或 goroutine，因底层是系统级句柄）同时以写方式打开已打开的文件。即使 Go 程序内多个 goroutine 共享同一 *os.File，若底层文件被其他程序占用，或未正确设置 syscall.FILE_SHARE_READ | syscall.FILE_SHARE_WRITE，os.OpenFile 会返回 "The process cannot access the file because it is being used by another process" 错误。
立即学习“go语言免费学习笔记（深入）”；
- 跨平台代码应默认假设文件不支持并发读写，除非明确控制句柄共享模式
- Windows 上如需多进程读写，需用
os.OpenFile配合syscall.Open手动指定 share flags，但复杂度高、可移植性差 - 更实际的做法：用本地 socket、内存映射（
memmap）或轻量数据库（如bolt）替代高频并发文件 I/O
文件 I/O 的并发瓶颈往往不在 Go 调度，而在操作系统层面的锁和磁盘寻道。真正需要高并发写入时，先问自己：这个数据是否必须立刻落盘？能不能缓存、批处理、走消息队列？
