多个*os.file不能共享，必须各自独立打开和关闭；每个goroutine应调用os.open获取独立句柄并defer关闭；错误做法是共享同一文件句柄；windows下需用filepath.join拼路径；os.readfile仅适用于小文件一次性读取。
多个 *os.File 不能共享，必须各自独立打开和关闭
并发读取多个文件时，每个 goroutine 必须调用 os.Open 获取自己的 *os.File 句柄，绝不能把一个打开的文件句柄传给多个 goroutine。即使只读，底层缓冲区、offset 位置、内部锁状态都可能被并发访问干扰，实测在某些 OS 或文件系统上会触发 panic 或读出错乱数据。
- 正确做法：每个 goroutine 内部
os.Open→ 处理 →defer f.Close() - 错误写法：
file, _ := os.Open("a.txt"); go read(file)然后在多个 goroutine 中调用file.Read() - Windows 下注意用
filepath.Join拼路径，别硬写"\"，否则os.Open直接返回invalid argument
os.ReadFile 看似方便，但隐藏了资源释放时机
os.ReadFile 内部确实封装了 Open → ReadAll → Close，适合小文件一次性读取；但它不暴露 *os.File，无法做流式处理、分块读或复用缓冲区。大文件用它会把全部内容加载进内存，GC 压力陡增，且无法控制读取过程中的错误中断点。
- 小文件（os.ReadFile 最简明
- 大文件或需逐行/分块处理：改用
os.Open+bufio.Scanner或io.ReadAt - 若要复用缓冲区降低 GC：配合
sync.Pool自己管理[]byte，不要依赖os.ReadFile的内部分配
并发数失控会导致 too many open files
每个 os.Open 都消耗一个文件描述符（fd），Linux 默认 per-process 限制通常是 1024。如果传入 5000 个文件路径并全量启动 goroutine，大概率在中间就卡住，后续 os.Open 返回 too many open files 错误，且已打开的 fd 不会自动释放——除非你显式 Close 或 goroutine 退出。
- 必须加限流：用带缓冲的 channel 当信号量，例如
sem := make(chan struct{}, 10) - 每个 goroutine 开始前先
sem ，结束后 <code> - 别用
runtime.GOMAXPROCS控制并发数——那是 CPU 调度，不是 IO 并发控制 - 临时提高系统 fd 限制（
ulimit -n 65536）只是掩耳盗铃，不解决根本问题
状态传递靠 channel，别用全局变量或闭包捕获循环变量
常见 bug 是这样写：
for _, path := range paths {
go func() {
data, _ := os.ReadFile(path) // path 是外部循环变量，所有 goroutine 共享同一地址
}()
}
结果所有 goroutine 都读同一个（最后一个）path。必须显式传参：
for _, path := range paths {
go func(p string) {
data, _ := os.ReadFile(p) // p 是副本，安全
}(path)
}
- 结果收集统一走
chan Result，结构体里带FilePath和Error - 不要用
map[string][]byte在 goroutine 里写结果——需要sync.Mutex，容易漏锁 - channel 缓冲大小建议设为
len(paths)或略大，避免 goroutine 因发送阻塞而卡住
真正难的不是启动 goroutine，而是让成百上千个文件读取器在不耗尽 fd、不压垮内存、不错乱数据的前提下，把每一份状态准确归位。多数崩溃都发生在“以为关了但其实没关”或“以为传进去了但其实是空指针”的瞬间。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
