测试中应优先使用 os.CreateTemp 创建临时文件，因其自动处理命名冲突、权限设置（默认0600）并返回已打开的 *os.File，比 os.MkdirTemp + 手动写入更安全简洁。
测试中创建临时文件用 os.CreateTemp 而非 os.MkdirTemp + 手动写入
临时文件和临时目录是两类操作：os.MkdirTemp 创建的是目录，想写文件还得 os.Create 或 os.OpenFile；而测试中多数场景只需一个可读写的临时文件路径，直接用 os.CreateTemp 更安全、更简洁。
它自动处理命名冲突、权限设置（默认 0600），且返回的 *os.File 已打开，可立即 Write 或 WriteString：
tmpFile, err := os.CreateTemp("", "test-*.txt")
if err != nil {
t.Fatal(err)
}
defer os.Remove(tmpFile.Name()) // 清理必须放 defer，但注意：见下一条
_, _ = tmpFile.WriteString("hello")
tmpFile.Close()
- 第一个参数为
dir，传空字符串表示使用默认系统临时目录（os.TempDir()） - 第二个参数是模板，
*会被随机字符串替换，避免重名 - 别在
defer里直接调用tmpFile.Close()—— 如果后续代码 panic，defer仍会执行，但文件句柄可能已失效；建议显式Close()后再defer os.Remove
defer os.Remove 在测试失败时可能不执行
Go 测试中，t.Fatal / t.Errorf 不会终止当前函数执行（只是标记失败），但 t.FailNow() 会触发 panic 并跳过后续 defer。这意味着：如果在 os.CreateTemp 后立刻 t.Fatal，defer os.Remove 根本不会运行，导致临时文件残留。
正确做法是把清理逻辑封装进辅助函数，并确保它在所有路径下都执行：
立即学习“go语言免费学习笔记（深入）”；
func withTempFile(t *testing.T, fn func(*os.File)) {
t.Helper()
f, err := os.CreateTemp("", "test-*.bin")
if err != nil {
t.Fatal(err)
}
defer func() {
if err := os.Remove(f.Name()); err != nil && !os.IsNotExist(err) {
t.Log("cleanup failed:", err)
}
}()
defer f.Close()
fn(f)
}
// 使用：
withTempFile(t, func(f *os.File) {
_, _ = f.Write([]byte("data"))
// 测试逻辑...
})
- 用
t.Helper()让错误行号指向调用处，而非辅助函数内部 -
os.Remove失败时只t.Log，不t.Fatal—— 清理失败不该让测试失败 - 检查
os.IsNotExist(err)，因为文件可能已被测试逻辑删除
需要多个临时资源时，用 testTempDir 统一管理
当测试涉及多个文件、子目录或需要预置结构（如模拟配置目录树），单独管理每个 os.Remove 易遗漏。此时应创建一个顶层临时目录，所有资源都在其下生成，最后一次性清理：
tmpDir, err := os.MkdirTemp("", "test-XXXXXX")
if err != nil {
t.Fatal(err)
}
defer os.RemoveAll(tmpDir) // 注意：用 RemoveAll，不是 Remove
cfgPath := filepath.Join(tmpDir, "config.yaml")
os.WriteFile(cfgPath, []byte("port: 8080"), 0600)
dataDir := filepath.Join(tmpDir, "data")
os.MkdirAll(dataDir, 0755)
-
os.RemoveAll可递归删除整个目录树，比逐个Remove更可靠 - 所有路径必须通过
filepath.Join拼接，避免硬编码/或\导致跨平台失败 - Windows 下临时目录路径含空格或特殊字符很常见，不要对路径做字符串截断或正则匹配
测试结束后残留文件暴露了资源未释放问题
运行 go test -v ./... 2>&1 | grep "test-" 常能发现未清理的临时文件。这不是环境问题，而是测试代码漏掉了清理逻辑，或者清理被提前跳过（比如在 goroutine 中 defer、或在子测试中未正确作用域绑定）。
真正该警惕的是：临时文件残留往往意味着底层代码本身也存在资源泄漏 —— 比如函数打开了文件但没关、启动了 goroutine 但没停止、注册了 signal handler 但没注销。测试中的临时资源只是第一道镜子。
所以每次看到残留文件，先确认测试是否真的覆盖了所有 error path 和 panic path；再顺藤摸瓜检查被测代码里是否有未关闭的 *os.File、未 cancel 的 context.Context、未 close() 的 channel。
