使用 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，易死锁
io.ReadAt
- 先用
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。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
它本质是带 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()并退出
ulimit -n
- 用
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 数写得够不够多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
