90%冗余系统调用源于重复打开文件、盲目遍历、未复用缓冲及热路径无意义stat；应优先用os.ReadDir替代filepath.WalkDir避免隐式stat，按需调entry.Info()，手动栈式递归，复用*os.File和bufio.Reader，前置轻量过滤路径与文件名。
直接结论：90% 的冗余系统调用来自重复打开文件、盲目遍历目录、未复用缓冲器、以及在热路径上做无意义的 stat 或 Info 调用。
os.ReadDir 替代 filepath.WalkDir 避免隐式 stat
filepath.WalkDir 每遇到一个文件或子目录，就自动调一次 os.Stat，哪怕你只想要路径名。而 os.ReadDir 一次性读取目录项（fs.DirEntry 列表），不触发任何 stat —— 元数据按需加载。
- 只需判断是否为目录？用
entry.IsDir()，不调entry.Info() - 只需拼接路径？用
entry.Name()，别用filepath.Join(dir, entry.Name())后再os.Stat - 真要元数据时才调
entry.Info()，且注意它内部缓存首次结果，但仍有 syscall 开销 - 递归遍历需手动实现（栈或队列），别依赖
filepath.WalkDir的“便利性”
复用 *os.File 和 bufio.Reader/Writer，别反复 Open/Close
高频场景（如日志写入、配置热重载、服务中持续读取监控文件）下，每次 os.Open / os.OpenFile 都是一次 open(2) 系统调用；每次 Close() 是一次 close(2)。这些开销在 QPS 上千时会立刻暴露。
- 长期运行的服务应复用
*os.File句柄；追加写用file.Seek(0, io.SeekEnd)，而非反复os.OpenFile(..., os.O_WRONLY|os.O_APPEND) - 读文件优先用
bufio.NewReaderSize(f, 64*1024)，默认 4KB 对大文件太小，64KB 在 NVMe 上已能显著摊薄read(2)次数 - 写文件务必显式
w.Flush()——defer w.Close()不保险，尤其当底层 writer 是网络连接或自定义类型时 - buffer 太小（如 512B）导致频繁 flush；太大（如 2MB）会让磁盘满等错误延迟暴露
跳过文件内容前先做轻量过滤
如果扫描目标只是“找某个后缀的配置文件”，别把所有文件都 os.Open 再读内容——先用名字和路径过滤，把 I/O 降到最低。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 用
strings.HasSuffix(entry.Name(), ".yaml")替代filepath.Match("*.yaml")，前者是 O(1) 字符串操作，后者涉及 glob 解析 - 维护一个忽略目录 map：
skipDirs := map[string]bool{"node_modules": true, ".git": true}，查表比strings.HasPrefix(path, ".git/")更稳 - 避免在循环里调
regexp.MustCompile；正则留到必要时，且复用编译好的*regexp.Regexp - 对 >1MB 的文件才考虑打开读内容；小文件可直接
os.ReadFile，因为 syscall 开销占比不高
哪些场景根本不该加 bufio
缓冲不是万能胶。加了反而拖慢、出错、或掩盖问题。
- 随机读写（如数据库 WAL、mmap 场景）：
bufio.Reader的预读逻辑会污染 page cache，还可能多读无用数据 - 实时流（串口、传感器、HTTP 响应体）：
bufio.Scanner默认等换行，一行没凑满就不吐，引入不可控延迟 - 底层已缓冲的接口（如
http.Response.Body）：标准库http.Transport已用bufio.Reader包装 socket，再套一层会干扰状态跟踪 - 单次写入极小数据（如写 16 字节 token）：
os.Write直接发 syscall 比 copy 到 buffer + flush 更快
最常被忽略的点是：buffer 大小设得再好，如果没在正确时机 Flush()，或者在不该用的地方硬套 bufio，性能优化就全白搭。系统调用省下来了，bug 却悄悄进来了。
