应优先使用 filepath.WalkDir（Go 1.16+）替代 filepath.Walk，通过 fs.WalkDirFunc 处理 err 实现跳过权限错误、控制符号链接遍历，并避免在回调中执行耗时 I/O 操作。
如何用 filepath.Walk 安全遍历目标目录下的所有文件
直接用 filepath.Walk 是最常见也最容易出错的方式。它默认会递归进入所有子目录，包括符号链接（如果系统允许），一旦遇到权限不足或损坏的 symlink，就会触发错误并中断整个遍历。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
filepath.WalkDir替代（Go 1.16+），它支持跳过子树、不 panic、可控制是否跟随 symlink - 在
fs.WalkDirFunc回调中检查err：若为fs.SkipDir，则跳过当前目录；若为fs.ErrPermission，打印警告但继续 - 避免在回调里做耗时操作（如逐个读文件内容），先收集路径再批量处理，防止 I/O 阻塞遍历逻辑
err := filepath.WalkDir("/data/in", func(path string, d fs.DirEntry, err error) error {
if err != nil {
if errors.Is(err, fs.ErrPermission) {
log.Printf("skip %s: permission denied", path)
return nil
}
return err
}
if !d.IsDir() {
files = append(files, path)
}
return nil
})批量重命名时如何避免覆盖和并发冲突
用 os.Rename 批量改名看似简单，但两个典型风险：同名文件被覆盖（没加序号/哈希防重），多 goroutine 并发调 os.Rename 导致 invalid argument 或丢失文件。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 重命名前先用
os.Stat检查目标路径是否存在，存在则自动追加序号或时间戳 - 不要用 goroutine 池无限制并发 rename —— 文件系统调用本身不是纯 CPU 操作，高并发反而增加内核锁竞争
- 若必须并发，用带缓冲的 channel 控制并发数（如
sem := make(chan struct{}, 5)），每启动一个 rename 前sem ，完成后 <code>
用 io.Copy 批量压缩或转换文件时怎么控制内存不爆掉
常见写法是 os.Open → gzip.NewWriter → io.Copy，但如果源文件是几百 MB 的日志，又同时跑十几个，io.Copy 默认 32KB 缓冲就可能让 runtime GC 压力陡增，甚至 OOM。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 显式指定 buffer 大小：用
io.CopyBuffer(dst, src, make([]byte, 1（1MB 缓冲）平衡吞吐与内存 - 对大文件单独走流式处理路径，比如用
bufio.NewReaderSize(f, 1 预读，避免每次 <code>Read都 syscall - 压缩场景优先选
zlib而非gzip（后者 header 开销略大），且设置gzip.BestSpeed级别，批量处理不追求极致压缩率
为什么 os.RemoveAll 不该直接用于清理临时输出目录
它看起来省事，但实际线上出过问题：某个子目录正被另一个进程（比如日志轮转脚本） openat 打开，RemoveAll 就会失败并返回 device or resource busy，而且不会告诉你具体哪个 entry 卡住。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 换用
filepath.WalkDir+ 逐个os.Remove，遇到EBUSY时记录路径并跳过，最后汇总失败项供人工介入 - 更稳妥的做法是：输出目录按时间戳分层（如
/out/20240520_1423/），处理完后只删「上一周期」目录，永远保留当前正在写的那个 - 删除前加
os.Chmod(path, 0700)防止因权限残留导致部分文件删不掉（尤其跨用户运行时）
批量文件处理真正的难点不在语法，而在路径竞态、资源可见性、错误恢复粒度——这些没法靠一个库函数兜底，得靠每一步的防御性判断和明确的 fallback 行为。
