直接用 os.open + goroutine 并发读写同一文件句柄会导致数据错乱、偏移错位或 panic，因 *os.file 共享文件偏移量且无内置同步；应各自独立打开文件，或用 sync.mutex + file.seek() 保护，小文件推荐 os.readfile 一次性加载。
为什么直接用 os.Open + goroutine 会出问题
多个 goroutine 同时调用 os.Open 打开同一个文件是安全的，但若共享一个 *os.File 句柄并发读写（比如共用一个 file.Read()），就会出现数据错乱、偏移错位甚至 panic。根本原因是 *os.File 内部维护一个共享的文件偏移量（offset），并发调用 Read 或 Write 时没有自动同步，系统调用返回的字节数和实际读到的内容可能不一致。
常见错误现象包括：read /path/to/file: bad file descriptor（句柄被提前关闭）、读出空内容、重复读同一段、或某次读取跳过部分数据。
- 每个 goroutine 应该独立打开文件（
os.Open或os.OpenFile），处理完自行关闭 - 若必须复用句柄（如大文件分块读取），需用
file.Seek()显式定位，并配合sync.Mutex保护偏移操作 - 对小文件或配置类场景，更推荐一次性读入内存（
os.ReadFile），再分发给 goroutine 处理，避免 I/O 竞争
sync.WaitGroup + os.ReadFile 是最简安全的并发读方案
适用于文件不大（
files := []string{"a.json", "b.json", "c.json"}
var wg sync.WaitGroup
for _, f := range files {
wg.Add(1)
go func(filename string) {
defer wg.Done()
data, err := os.ReadFile(filename) // 每个 goroutine 独立读
if err != nil {
log.Printf("read %s failed: %v", filename, err)
return
}
// 处理 data，例如 json.Unmarshal 或 strings.Split
process(data)
}(f)
}
wg.Wait()
-
os.ReadFile内部已封装了Open→ReadAll→Close，无需手动管理句柄 - 注意控制 goroutine 数量，避免打开过多文件导致
too many open files，可用带缓冲 channel 限流 - Windows 下路径分隔符要用
filepath.Join，不要硬写"\"
写入并发必须用 os.O_APPEND 或外部锁
多个 goroutine 直接向同一文件调用 file.Write()，即使文件以 os.O_WRONLY 打开，也会因内核 write() 调用非原子性导致内容覆盖或交错。唯一内核级保证原子追加的方案是打开时指定 os.O_APPEND 标志——此时每次 Write 前内核自动 lseek 到末尾，再写入。
立即学习“go语言免费学习笔记（深入）”；
f, err := os.OpenFile("log.txt", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)
if err != nil {
panic(err)
}
// 后续所有 goroutine 共用 f.Write 都是线程安全的追加
-
os.O_APPEND仅保证“追加”动作原子，不保证多行写入的完整性（例如一行日志被两个 goroutine 拆成两段写） - 若需写结构化数据（如 JSON 数组）或严格顺序，应改用 channel 汇聚写请求，单 goroutine 串行落盘
- 临时文件 +
os.Rename替换是更健壮的并发写模式，尤其涉及整个文件重生成时
大文件分块处理要自己算 offset，别依赖 bufio.Scanner
bufio.Scanner 默认按行扫描，内部缓存和状态不可并发复用；且无法指定从任意 offset 开始读。真正的大文件（GB 级）并发处理，得手动切分 byte range，每个 goroutine 打开文件后 Seek 到起始位置再读固定长度。
- 用
os.Stat().Size()获取总大小，按 worker 数均分start和end偏移 - 每个 goroutine 中：用
os.Open→file.Seek(start, io.SeekStart)→io.ReadFull(file, buf) - 注意处理边界：最后一块可能不足预期长度，
io.ReadFull会报io.ErrUnexpectedEOF，应改用io.ReadAtLeast或直接Read - 避免用
strings.Split在分块边界截断行——需在块头/尾预留缓冲区，或由主 goroutine 合并行边界
并发读写文件不是单纯加 go 就行，关键在 I/O 资源归属和内核语义的理解。很多人卡在“为什么数据对不上”，其实只是忘了每个 goroutine 该有自己的一份文件句柄或明确的偏移控制。
