千万级小文件处理禁用os.readfile循环，应复用目录句柄、用io.copy批量搬运、精准设置openfile标志、显式关闭文件并控制并发数在20–50之间。
千万级小文件 ≠ 大文件，别用 os.ReadFile 循环硬扛
单个几 KB 到几百 KB 的小文件，数量上达千万级（比如日志切片、用户上传的头像、API 响应缓存），这时候最危险的操作就是写个 for 循环反复调用 os.ReadFile 或 os.WriteFile。它看似简洁，但每轮都触发一次系统调用（open + read + close），I/O 开销爆炸，实测在 Linux 上吞吐常卡在 200–500 文件/秒，CPU 大量耗在内核态切换。
- 别指望
os.ReadFile缓存句柄——它每次都是全新打开、读完立刻关，没复用 - 路径拼接错误、权限不足、磁盘满等错误会在每次调用时重复暴露，日志刷屏且难定位根因
- 如果文件名含特殊字符或 Unicode，
os.ReadFile("data/用户_123.txt")在某些挂载点可能失败，但错误信息只报no such file or directory，不提示编码或路径规范化问题
用 os.OpenFile 复用句柄 + io.Copy 批量搬运
对同一目录下大量同类型小文件（如全为 JSON 配置、全为 PNG 图片），优先打开父目录句柄并缓存，再用相对路径构造 os.OpenFile 调用，能省掉部分路径解析开销；更关键的是，对读多写少场景，可预分配缓冲区并用 io.Copy 直接对接 io.Reader 和 io.Writer，绕过中间 []byte 分配。
-
os.OpenFile的flag参数要设准：os.O_RDONLY | os.O_NOFOLLOW可避免符号链接跳转开销；写入时用os.O_CREATE | os.O_WRONLY | os.O_TRUNC明确语义 -
io.Copy默认用 32KB 缓冲区，对小文件已足够；若发现大量 4KB 以下文件，可改用io.CopyBuffer(dst, src, make([]byte, 4096))减少内存碎片 - 不要在循环里反复
defer file.Close()——defer是栈管理，千万次 defer 会压垮 goroutine 栈；应显式file.Close()后判错
并发控制必须做，但别盲目开满 goroutine
千万级文件处理天然适合并发，但 goroutine 数不是越多越好。实测表明，在 NVMe SSD 上，20–50 个 goroutine 并发读取小文件能达到 I/O 吞吐峰值；超过这个数，调度开销反超收益，runtime.scheduler.lock 争用明显上升。
- 用带缓冲的 channel 控制并发数，例如
sem := make(chan struct{}, 32)，每个 goroutine 进入前sem ，退出后 <code> - 避免 goroutine 泄漏：所有通道接收端必须有明确退出条件，尤其当文件列表来自
filepath.WalkDir时，需用context.WithCancel支持中断 - 别让 goroutine 直接操作全局 map——用
sync.Map或分片 map +sync.RWMutex，否则fatal error: concurrent map writes会在压力测试后期突然爆发
路径和错误处理比想象中更脆弱
千万次文件操作里，哪怕 0.001% 的路径异常（如 ../etc/passwd 注入、空格未转义、NTFS 的 CON/AUX 保留名）都会导致静默失败或权限提升风险；而错误聚合不及时，会导致后续逻辑基于脏数据运行。
- 所有输入路径必须过
filepath.Clean，再检查是否仍在允许根目录下（如strings.HasPrefix(cleanPath, "/var/data/")） - 不要只看
err != nil就跳过：用errors.Is(err, fs.ErrNotExist)区分缺失与权限拒绝；用os.IsPermission(err)单独捕获权限类错误并告警 - 写入前确保父目录存在：
os.MkdirAll(filepath.Dir(destPath), 0755)，但注意MkdirAll本身也有竞态——多个 goroutine 同时创建同一目录会返回ErrExist，需忽略
实际跑通的关键不在“怎么并发”，而在“怎么让每次系统调用都值得”。路径校验、句柄复用、缓冲区对齐、错误分类——这些细节堆叠起来，才撑得住千万级规模。
