千万级小文件 ≠ 大文件，别用 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><-sem避免 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，需忽略
实际跑通的关键不在“怎么并发”，而在“怎么让每次系统调用都值得”。路径校验、句柄复用、缓冲区对齐、错误分类——这些细节堆叠起来，才撑得住千万级规模。
评论(0)