os.ReadFile并发处理千万级小文件时不可无脑起百万goroutine，因会触发too many open files、permission denied及CPU空转超70%等系统级错误。
直接用 os.readfile 和 os.writefile 并发处理千万级小文件，90% 场景下可行，但必须控制并发数、预热文件句柄、规避路径竞争——否则不是慢，而是进程被系统 kill。
为什么不能无脑起百万 goroutine 调用 ReadFile
常见错误现象：too many open files（Linux 默认 per-process 1024）、permission denied（大量 stat 系统调用触发 SELinux 审计风暴）、CPU 在 syscall 上空转超 70%。
-
os.ReadFile每次都走完整流程：open → read → close，对小文件（ - Go 运行时不会复用底层 fd，哪怕你反复读同一路径，也每次新建 fd
- 千万级意味着至少千万次
openat(AT_FDCWD, "path", O_RDONLY)，内核 inode cache 压力陡增，尤其在 ext4 + noatime 未设时
用 sync.Pool 缓存 *os.File 句柄，复用 open 成本
适用场景：小文件路径固定、重复读取（如模板文件、静态资源、配置片段），且总量可控（比如几千个路径，但每个被读几万次）。
- 手动用
os.OpenFile打开一次，放进sync.Pool[*os.File]，Get()后Seek(0, 0)重置偏移，避免反复 open - 注意：不能缓存写入句柄（
O_WRONLY或O_RDWR），因写操作会改变文件状态，Seek不解决原子性问题 - Pool 的
New函数里做os.Open，但必须检查errors.Is(err, os.ErrNotExist)—— 不存在的文件不能放池里占位
var filePool = sync.Pool{
New: func() interface{} {
f, err := os.Open("template.html")
if err != nil && !errors.Is(err, os.ErrNotExist) {
log.Printf("failed to open template: %v", err)
}
return f
},
}
// 使用时：
f := filePool.Get().(*os.File)
defer filePool.Put(f)
f.Seek(0, 0)
data, _ := io.ReadAll(f)
批量路径预检 + 分片并发，绕过单点 stat 瓶颈
当小文件路径来自列表（如日志归档目录下千万个 log_20260425_000001.txt），逐个 os.Stat 是最慢环节。
- 用
filepath.Glob或os.ReadDir一次性获取全部路径，避免千万次系统调用 - 按首字母或哈希分片（如
sha256(path)[0] % 16），每片交给一个 goroutine worker 处理，天然分散 inode lookup 压力 - 并发数别硬设成
runtime.NumCPU()—— 实测 SSD 上 32～64 并发吞吐最高；机械盘压到 8 就见顶 - 写文件时禁用
fsync（除非金融级要求），os.WriteFile("x", data, 0644)默认不落盘，靠内核刷回，速度翻倍
别碰 ioutil，也别信“自动编码检测”
Go 1.16+ 已彻底移除 ioutil，还在用 ioutil.ReadFile 的代码无法通过 go vet 或 staticcheck，CI 直接失败。
-
os.ReadFile返回[]byte，它不猜编码 —— 如果文件是 GBK 或 Shift-JIS，string(data)得到的是乱码字节流，不是“自动转 UTF-8” - 小文件读取后若需文本处理，优先用
golang.org/x/text/encoding显式解码，别依赖strings.ToValidUTF8这类补丁逻辑 - Windows 下
0644权限参数无效，但 Linux/macOS 上漏设会导致后续chmod失败或容器内不可读，必须写死
真正卡住千万级小文件性能的，从来不是 Go 的 IO 函数，而是你没意识到：文件系统元数据操作（open/stat）比读内容贵十倍，而内核对 fd 数量的限制比你的 goroutine 调度器更早发难。
