os.removeall 递归删除但非“尽力而为”，遇权限/占用错误立即失败；测试需构造只读文件、持有句柄、子目录快照等边界场景，并避免直接删 t.tempdir()。
go 里用 os.RemoveAll 测试递归删除，先确认它真会删子目录
os.RemoveAll 确实递归删除，但它的行为和你手动 rm -rf 不完全一致：它不跳过只读文件，遇到权限不足或打开中的文件会直接报错退出，不会“尽力删完剩下”。测试时如果 mock 不够细，很容易漏掉这类失败路径。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 测试前用
os.MkdirAll+os.WriteFile构建多层嵌套结构，别依赖临时目录里已有的东西 - 显式 chmod 一个子文件为
0444（只读），再调os.RemoveAll，验证是否返回*os.PathError - 在 linux/macos 上用
syscall.Open持有某个子文件句柄（不 close），再删父目录，看是否报busy device类错误
写测试时别用 t.TempDir() 直接当被删目标
t.TempDir() 返回的路径会在测试结束自动清理，但如果测试中途调了 os.RemoveAll(t.TempDir())，会导致后续断言访问已不存在的路径，t.Cleanup 还可能 panic。更糟的是，某些 CI 环境里 t.TempDir() 路径可能被复用，残留文件干扰下个测试。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
filepath.Join(t.TempDir(), "testroot")创建独立子目录，删它，留t.TempDir()原封不动 - 删完立刻用
os.Stat检查路径是否存在，避免“删了但没完全删”——比如符号链接指向外部，os.RemoveAll只删 link 本身 - windows 下注意长路径限制，测试前用
os.Getwd()检查当前工作目录深度，太深可能触发ERROR_FILENAME_EXCED_RANGE
想测“删一半失败后状态”，得自己造中断点
os.RemoveAll 是原子性语义：成功就全删光，失败就停在出错位置，不会回滚。但默认没法控制它在哪一步失败，所以无法覆盖“删了 3 层，第 4 层权限不够”的中间态场景。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要试图 patch
os.RemoveAll，改用自定义递归函数，每步调os.RemoveAll或os.Remove，并在指定层级插入return errors.New("simulated fail") - 用
os.ReadDir配合filepath.WalkDir预扫描待删路径列表，删之前存快照，失败后比对哪些路径还存在 - 注意
filepath.WalkDir默认按字典序遍历，而os.RemoveAll内部是深度优先，顺序不同可能导致清理残留差异
并发删同一目录？Go 标准库不保你
os.RemoveAll 本身不是并发安全的，两个 goroutine 同时删同一个路径，结果取决于竞态时机：可能都返回 nil（第二个删空目录），也可能一个成功一个报 no such file，甚至因重命名冲突导致部分子目录残留。这不是 bug，是文档明确未承诺的行为。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 测试并发场景必须加锁或用
sync.Once控制入口，别指望靠重试掩盖问题 - 若业务真需要并发清理，把目标拆成不同子树，每个 goroutine 负责一个固定前缀，避免路径交叠
- 用
os.Chmod(path, 0)清除所有权限再删，能减少因“只读文件+并发”引发的不可预测失败
递归删除的边界情况太多，光测通路没用；最常被忽略的是符号链接循环、挂载点穿越、以及 Windows 下的短文件名（8.3）别名冲突——这些不会在简单 tempdir 测试里暴露，得专门构造。