os.RemoveAll半途而废的根本原因是其“零容忍”策略：任一子项因权限不足、文件占用等失败，即刻返回错误且不告知具体路径，也不重试或跳过。
直接删不掉 os.RemoveAll 的目录，不是磁盘满了，也不是代码写错了，而是它遇到权限卡住或文件被占用就立刻放弃——不重试、不跳过、不提示具体哪一项失败。
为什么 os.RemoveAll 在清理时总半途而废
根本问题在于它的“零容忍”策略：只要某子项 remove 失败（比如只读文件、无写权限目录、Windows 下被进程锁住），整个调用就返回错误，且不会告诉你失败发生在哪个路径。
-
remove /tmp/logs/2024-01-01.log: permission denied—— 实际是文件属性为0444，os.RemoveAll不会自动chmod -
remove /tmp/cache: directory not empty—— 很可能某个子目录权限为0555，导致内部遍历失败，但错误信息完全误导人 - Windows 上删
chrome_cache_001时抛The process cannot access the file because it is being used by another process，os.RemoveAll直接退出，连日志路径都拿不到
用 filepath.WalkDir 替代 filepath.Walk 控制清理流程
filepath.WalkDir 是 Go 1.16+ 清理类工具的首选，它传入的是 fs.DirEntry，避免了每次访问都触发 os.Lstat，既快又稳；更重要的是能提前判断、跳过、中断，而不是等失败才反应。
- 用
d.Type().IsDir()判断类型，别再对每个路径都调os.Stat(path) -
d.Name()只是文件名，拼完整路径必须用filepath.Join(root, d.Name())，否则在嵌套目录下会误删或报错 - 遇到想跳过的目录（如
node_modules、.git），直接return filepath.SkipDir，它会跳过整个子树，不递归 - 若需按修改时间过滤（比如只删 7 天前的），用
d.Info()获取os.FileInfo，但注意它会触发一次stat；若只需类型和名字，完全不用Info()
处理权限与占用：删不掉时先改权限，删不了时就绕开
清理的本质不是“硬刚”，而是“让系统允许你删”。对只读文件、无写权限目录，先 os.Chmod；对 Windows 下被占用的文件，os.Remove 必败，但 os.Rename 通常成功——移走再删是唯一安全解法。
立即学习“go语言免费学习笔记（深入）”；
- 对文件：检查
err是否为*os.PathError且err.Err == syscall.ERROR_SHARING_VIOLATION（Windows）或syscall.EBUSY（Linux/macOS），命中则跳过或os.Rename(path, path+".to_remove") - 对目录：递归进入前先
os.Chmod(path, 0755)，确保自己有权限遍历和删除子项；注意os.Chmod作用于符号链接本身，要改目标得用os.Stat + os.Chmod - 不要用
syscall强行解锁句柄——不可移植、易崩溃、且违反操作系统语义
清理逻辑里最容易被忽略的细节
真正健壮的清理工具，90% 的工作量不在“删”，而在“确认可删”和“容错恢复”。比如 os.Rename 移走后，必须确保后续 os.RemoveAll 或循环 os.Remove 真的执行了，否则临时文件越积越多；又比如 filepath.WalkDir 中若某次回调 panic，整个遍历就中断——得包一层 recover 或用 errgroup 控制并发粒度。
