os.readfile + goroutine 适合小文件（≤1mb）、并发数≤20、无需分块的场景；优点是代码简洁、无偏移风险、句柄自动管理；坑点是高并发易触发 too many open files，须用带缓冲 channel 限流。
直接用大量 goroutine 并发读写文件块，不加控制时往往更慢甚至崩溃——根本卡点不在 Go 调度，而在系统级资源争抢：文件描述符耗尽、磁盘 I/O 队列拥塞、内核缓冲区锁竞争。必须显式限流 + 分离读写职责。
os.ReadFile + goroutine 适合什么场景？
适用于小文件（单文件 ≤ 1MB）、并发数可控（≤ 20）、且无需分块处理的场景。它内部已封装 os.Open→io.ReadFull→file.Close，省去手动管理句柄的麻烦。
- 优点：代码简洁，无偏移错乱风险，每个 goroutine 独立生命周期
- 坑点：若传入 1000 个文件路径并启动 1000 个 goroutine，极大概率触发
too many open files - 正确用法：配合带缓冲 channel 限流，例如
sem := make(chan struct{}, 10)，每次进 goroutine 前sem ，退出时 <code>
大文件分块读取必须用 bufio.Reader + Seek
对单个 >10MB 的文件做并发读取，不能靠多个 goroutine 共享一个 *os.File，因为 Read 操作会互相干扰文件偏移量。必须按字节范围切片，并由每个 goroutine 独立打开、定位、读取。
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 先用
file.Stat()获取文件总长度，再按固定块大小（如 4MB）划分[start, end)区间 - 每个 goroutine 调用
os.Open()打开同一路径，然后file.Seek(start, 0)定位，再用io.ReadFull(file, buf)读指定长度 - 务必用
sync.Mutex保护Seek和Read组合操作——否则仍可能因调度导致偏移错位 - 避免用
bufio.Scanner，它内部维护缓冲和状态，不是并发安全的
并发写入同一文件只有 os.O_APPEND 是安全的
多个 goroutine 直接向同一个 *os.File 调用 Write()，即使加了 sync.Mutex，也无法保证写入位置一致——因为 Write 底层是 write(2) 系统调用，内核不保证多线程下原子追加。
- 唯一可靠方案：用
os.O_CREATE | os.O_WRONLY | os.O_APPEND打开文件，此时每次Write前内核自动lseek(fd, 0, SEEK_END) -
sync.Mutex只需保护“构造待写内容”的逻辑（比如拼接日志字符串），不用管写入本身 - 若需随机写（如更新某段二进制数据），必须由单个 writer goroutine 接收
struct{ offset int64; data []byte }请求，串行执行file.WriteAt()
bufio.Writer 在 goroutine 中不能复用
bufio.Writer 内部缓存未刷出的数据并维护写位置，多个 goroutine 同时调用 WriteString 或 Flush 会导致 panic 或输出错乱。
- 每个 goroutine 必须创建自己的
bufio.Writer实例，绑定独立的*os.File或io.Writer - 若写入目标是同一文件但不同 goroutine，不要共用
bufio.Writer，哪怕只写入不同行 - 高频小写入场景下，可考虑用
sync.Pool复用bufio.Writer底层 buffer，但 Writer 本体仍要 per-goroutine 创建
最易被忽略的是：文件系统类型（如 NFS、ext4、ZFS）对 os.O_APPEND 的原子性支持不一致，某些网络文件系统会退化为用户态加锁；生产环境若涉及跨平台或分布式存储，务必实测追加行为是否真原子。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
