IO Wait 高主因是代码频繁调用 openat/read/close 导致内核忙于元数据操作而 CPU 空等；应限并发、复用句柄、批量读、缓存文件、避免无谓 stat。
IO Wait 高不是磁盘慢，是你的代码在反复调用 openat、read、close——每个小文件都触发三次系统调用，内核忙于查 inode、分配 fd、刷缓存，CPU 却在干等。
为什么并发开几百个小文件会让 IO Wait 爆表
常见现象：strace -e trace=openat,read,close 一跑全是密密麻麻的系统调用；top 显示 CPU 使用率低但 %iowait 超 70%；ulimit -n 打满后开始报 too many open files。
- 每个
os.Open都是openat系统调用，要走 VFS、权限检查、路径解析，开销远高于内存拷贝 - 大量小文件让内核
dentry和inode缓存压力飙升，后续查找更慢 - goroutine 自由并发打开 → fd 耗尽 → 新请求卡在
openat系统调用入口，形成阻塞雪崩 - HDD 上单次
open+read(1KB)+close平均耗时 >5ms，1000 个文件就是纯等 5 秒
用信号量控并发 + 复用已打开的文件句柄
重点不是“能不能并发”，而是“并发多少才不翻车”。盲目起 goroutine 只会放大瓶颈。
- 用
golang.org/x/sync/semaphore的semaphore.NewWeighted(4)限制同时打开的文件数：HDD 建议 2–4，SSD 可试 8–16 - 对同一目录下高频访问的小文件（如日志分片、配置模板），用
sync.Map缓存*os.File，避免反复open/close - 缓存前确认文件不会被外部轮转或删除；若会变，加
os.Stat时间戳校验或设 TTL - 别在循环里写
defer f.Close()——它只是推迟 close，goroutine 仍长期持有着 fd，close 本身也有延迟累积
批量读 + 合并缓冲区，砍掉 90% 的系统调用
与其让 100 个 goroutine 各自读 1KB，不如让 1 个 goroutine 批量读 100KB。小文件不是不能并发，是得“打包读”。
立即学习“go语言免费学习笔记（深入）”；
- 先收集所有待读路径，按大小分组（
、<code>1–8KB、>8KB），小文件优先合并处理 - 小文件场景下，
os.ReadFile仅限低频、单次使用；超过就改用os.Open+bufio.NewReaderSize(f, 4096)，缓冲区设为 4KB 整数倍 - 读完立即
f.Close()，别 defer —— close 系统调用积少成多，尤其在高频率小文件场景下不可忽略 - 若需解析内容（如 JSON/YAML），把读和解析拆到不同 goroutine：一个 reader goroutine 拿路径 → 读字节 → 发 channel；多个 worker 解析，解耦 I/O 和 CPU
绕过文件系统元数据开销：用 os.ReadDir 替代 filepath.WalkDir
当你只是想遍历目录、检查存在性或读取符号链接目标，根本不用打开文件。很多性能损耗来自无意义的 stat。
-
os.ReadDir只做一次getdents系统调用，返回fs.DirEntry，不含完整元数据；而filepath.WalkDir对每个项都隐式调用os.Lstat，开销翻倍 - 仅判断文件是否存在，别用
os.Stat，改用os.Lstat(path)或直接尝试os.OpenFile(path, os.O_RDONLY|os.O_CLOEXEC)看错误类型 - 批量判断多个路径时，用
os.ReadDir一次获取全部条目，再用entry.Type()快速过滤，避免 N 次系统调用
真正容易被忽略的点是：IO Wait 高从来不是因为“没用上 SSD”，而是你每读一个 2KB 的配置文件，都在重复走一遍完整的文件打开路径——从用户态到内核、查 dentry、查 inode、分配 fd、读数据、关 fd。这些步骤加起来，比 SSD 的 0.1ms 延迟还重得多。
