千万小文件并发读需避免os.ReadFile和filepath.Walk，改用filepath.WalkDir+fs.DirEntry、os.ReadDir（扁平结构）、限流channel控制并发（SSD设32–64，机械盘≤8），优先合并存储。
直接用 os.ReadFile 并发读千万个小文件，大概率触发 too many open files、permission denied 或 CPU 在 syscall 上空转超 70%，进程被系统 kill——不是慢，是根本跑不起来。
别用 filepath.Walk 遍历百万级目录
它为每个文件调一次 os.Stat，生成完整 os.FileInfo，开销大且无法跳过符号链接。实测百万文件遍历耗时翻倍，strace 显示密集的 stat 和 openat 系统调用。
- 改用
filepath.WalkDir：Go 1.16+ 提供，暴露轻量fs.DirEntry，不触发stat，性能提升 2–5 倍 - 过滤逻辑写在回调里：用
entry.Name()判断后缀，别拼路径再调os.Stat - 主动跳过不需要的子目录：
return filepath.SkipDir，比如node_modules或.git - 若目录结构扁平（如日志根目录下全是
xxx.log），直接用os.ReadDir更快，它只读当前层，不递归
并发数不能拍脑袋设成 runtime.NumCPU()
硬盘类型决定吞吐上限：SSD 上 32～64 并发最稳；机械盘压到 8 就开始排队，再多 goroutine 只是徒增调度和句柄竞争。
- 用带缓冲的 channel 控制 worker 数量，例如
sem := make(chan struct{}, 32) - 每启动一个 goroutine 前
sem ，结束时 <code><-sem - 避免无脑起百万 goroutine 调
os.ReadFile：每个调用都走open → read → close，内核 inode cache 压力爆炸 - 预热文件句柄池？只适用于路径固定、重复读取场景（如模板文件），且总量可控（几千个路径 × 几万次读）
小文件读取别依赖 os.ReadFile
它内部用 bytes.Buffer 动态扩容，哪怕你清楚文件大小，也会多次内存拷贝；而手动控制可预分配切片，零扩容。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 先
stat, _ := os.Stat(path)获取大小，再buf := make([]byte, stat.Size()) - 然后
f, _ := os.Open(path)，n, err := f.Read(buf)，注意检查n是否等于len(buf) - 若需严格保证读满，用
io.ReadFull(f, buf)，失败返回io.ErrUnexpectedEOF，不是静默截断 - 流式处理更省内存：开 goroutine 后用
bufio.Scanner或bufio.NewReader逐行读，边读边处理，内存恒定几 KB
真瓶颈不在 Go 代码，在文件系统层
100 万个 4KB 文件 = 100 万次元数据操作，机械盘卡在 10–20 IOPS，SSD 也扛不住随机寻道。此时优化 os.Open 或加 goroutine 收效甚微。
-
df -i查 inode 使用率，>95% 就说明文件系统已撑不住 - pprof 看 CPU profile，热点若集中在
syscall.Syscall和runtime.futex，就是系统调用卡住 - 优先考虑合并存储：用
go-fastdfs或自建容器文件（如.merge），把小文件打包，元数据存 LevelDB - 上传后查真实位置？别
os.Stat("xxx.jpg")—— 文件物理不存在，得走 HTTPHEAD /group1/xxx.jpg?op=meta
最容易被忽略的是：你以为在优化 Go 代码，其实问题早就在文件系统层定了型；合并存储不是“可选方案”，而是百万小文件场景下的事实标准。
