使用 sync.WaitGroup 可协调多个 goroutine 并发读文件：为每个文件启动 goroutine 并显式传参避免变量捕获错误，defer 关闭文件防止 fd 泄露，用带缓冲 channel 收集结果，同时需评估文件数量与大小以防 I/O 或内存过载。
用 sync.WaitGroup 控制并发 goroutine 读取多个文件
Go 并发读文件本身不难，难点在于协调多个 goroutine、避免资源竞争、统一错误处理。最常见做法是为每个文件启一个 goroutine，用 sync.WaitGroup 等待全部完成。
注意：不是所有场景都适合“为每个文件开 goroutine”——如果文件数极多（比如上万），或单个文件极大（GB 级），盲目并发反而会压垮系统 I/O 或内存。先评估实际负载。
-
os.Open后必须调用Close()，否则 fd 泄露；建议用defer f.Close()，但要注意 defer 在 goroutine 里生效时机 - 不要在循环里直接传循环变量（如
for _, path := range paths { go func() { os.Open(path) }() }），会导致所有 goroutine 读同一个path值；应显式传参：go func(p string) { ... }(path) - 若需收集结果，用带缓冲的 channel（如
make(chan Result, len(paths))）避免阻塞；别用无缓冲 channel 配大量 goroutine，易死锁
func readFilesConcurrently(paths []string) []Result {
var wg sync.WaitGroup
results := make(chan Result, len(paths))
for _, path := range paths {
wg.Add(1)
go func(p string) {
defer wg.Done()
data, err := os.ReadFile(p)
results <- Result{Path: p, Data: data, Err: err}
}(path)
}
go func() {
wg.Wait()
close(results)
}()
var out []Result
for r := range results {
out = append(out, r)
}
return out
}大文件分块读取 + io.ReadAt 实现真正并行 IO
上面方法只是“并发发起读请求”，底层仍可能串行等待磁盘响应。要榨干多核 + 多磁盘吞吐，得手动分块：把一个大文件按偏移切分成若干段，每个 goroutine 调用 io.ReadAt 读指定区间。
这要求文件支持随机读（普通磁盘文件可以，但某些网络文件系统或只读挂载可能不支持 ReadAt）；且必须保证各段不重叠、不越界，否则数据错乱。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先用
os.Stat().Size()获取文件总大小，再均分 offset/length - 每个 goroutine 打开自己的
*os.File（不能共享一个 file 对象并发ReadAt，虽然文档说线程安全，但实测某些 OS 有隐含状态冲突） - 结果合并时按 offset 排序拼接，别依赖 goroutine 完成顺序
- 注意
ReadAt返回的n可能小于请求长度（如遇 EOF），需检查并处理
用 errgroup.Group 统一取消和错误传播
当某个文件读失败，你可能想立刻中止其余读取（比如用户按了 Ctrl+C，或上游 context 已 cancel）。原生 WaitGroup 不支持中断，这时该上 golang.org/x/sync/errgroup。
它本质是带 error 收集和 context 支持的 WaitGroup，且一旦任一 goroutine 返回非 nil error，其余仍在运行的 goroutine 会收到 context cancel 信号（如果用了 eg.GoCtx）。
- 导入：
import "golang.org/x/sync/errgroup" - 用
eg.GoCtx(ctx, fn)替代go fn()，ctx 可来自context.WithTimeout或signal.NotifyContext - 调用
eg.Wait()会返回第一个非 nil error；若需所有错误，得自己收集到 slice - 注意：cancel 并不强制杀死 goroutine，只是通知，你的读逻辑里必须定期检查
ctx.Err()并退出
func readWithCancel(ctx context.Context, paths []string) error {
g, ctx := errgroup.WithContext(ctx)
for _, path := range paths {
path := path // 防止闭包引用
g.Go(func() error {
select {
case <-ctx.Done():
return ctx.Err()
default:
}
_, err := os.ReadFile(path)
return err
})
}
return g.Wait()
}别忽略文件系统和 OS 层限制
并发读文件性能卡点往往不在 Go 代码，而在系统层：打开文件数上限（ulimit -n）、磁盘 IOPS、ext4/xfs 文件系统对并发元数据操作的锁粒度、甚至 NFS 客户端缓存策略。
实测中常见问题：并发超 200 个 os.Open 直接报 too many open files；或大量小文件读取时，CPU 花在路径解析和 inode 查找上，而非真正 IO。
- 用
lsof -p $(pidof yourapp)查看当前打开文件数 - Linux 下可通过
/proc/sys/fs/file-max和ulimit -n调整上限，但治标不治本 - 对海量小文件，优先考虑归档（tar）或索引（SQLite 存路径+偏移），减少系统调用次数
- SSD 上并发 16–32 路通常已接近吞吐极限，盲目加 goroutine 数只会增加调度开销
真正的瓶颈经常藏在 strace -e trace=openat,read,close yourprogram 的系统调用耗时里，而不是 Goroutine 数写得够不够多。
