是的，os.TempDir() 返回容器内路径，但默认写入镜像rootfs的/tmp，易致inode耗尽或残留；应设TMPDIR=/tmp/in-pod并挂载emptyDir，注意tmpfs会消耗内存限额，需配足limit并流式处理文件。
Go 程序写临时文件时 os.TempDir() 返回的是容器内路径吗？
是的，但得看容器怎么挂载。Go 的 os.TempDir() 读取环境变量 TMPDIR，其次 fallback 到 /tmp（Linux）或系统默认路径。在容器里，如果没显式设置 TMPDIR，它就直接落在镜像根文件系统里的 /tmp —— 这个目录通常属于 rootfs，不是 EmptyDir，更不随 Pod 生命周期清理。
常见错误现象：io: read/write on closed pipe 或磁盘满报错，其实是因为写到了只读层或 overlayfs 的 upperdir，触发 inode 耗尽；或者临时文件堆积导致容器重启后残留。
- 务必在启动 Go 程序前通过
env设置TMPDIR=/tmp/in-pod，并确保该路径挂载的是emptyDir - Kubernetes 中需在
volumeMounts显式挂载到该路径，例如mountPath: /tmp/in-pod - 不要依赖
os.MkdirTemp("", "xxx")默认行为——它用的就是os.TempDir()，不自动感知 k8s 卷
EmptyDir 挂载后 Go 写文件仍被 OOMKilled？内存限制和 tmpfs 有关
当 emptyDir.medium: Memory 时，Kubernetes 会用 tmpfs 挂载，所有写入都走内存。这时候 Go 程序调用 os.WriteFile() 或 io.Copy() 写大文件，实际是在消耗容器的内存限额，而不是磁盘。
典型表现：容器没报磁盘错误，但频繁被 OOMKilled，kubectl top pod 显示内存使用飙升，df -h 却显示 /tmp/in-pod 使用率 100% —— 因为 tmpfs 的 “容量” 就是内存 limit。
立即学习“go语言免费学习笔记（深入）”；
- 检查容器内存 limit 是否 ≥ 预期最大临时文件体积 × 2（Go 的 slice 和 buffer 也会额外占内存）
- 避免用
ioutil.ReadFile()（已弃用）或os.ReadFile()读取大文件到内存；改用流式处理：os.Open()+io.CopyN()或分块Read() - 写文件前先用
syscall.Statfs()检查 tmpfs 剩余空间（注意：返回的是字节，不是块数），但别依赖它做精确判断——cgroup v2 下可能不准
Go 中如何安全地清理 EmptyDir 里的临时文件？
不能靠 defer 或 os.RemoveAll() 放在 main 函数末尾——容器可能被 SIGTERM 强杀，goroutine 没机会执行；也不能依赖容器退出时自动清理，因为 EmptyDir 的生命周期只绑定 Pod，不是进程。
真正可靠的做法是：把清理逻辑交给 Kubernetes 的 lifecycle hook 或外部管理，Go 程序只负责“用完即删”，且必须容忍删不掉（比如文件正被另一个 goroutine 打开）。
- 每个临时文件创建后，立刻用
defer os.Remove(path)，但仅限于短生命周期、单 goroutine 场景 - 对长时运行的服务（如 HTTP server），用
filepath.WalkDir()定期扫描 +time.Since(fi.ModTime()) > timeout清理陈旧文件 - 避免在信号处理中做阻塞清理（如遍历大目录），SIGTERM 处理应快速退出，清理交给 preStop hook 脚本
- 删除前加
os.Chmod(path, 0200)防止其他进程写入，再删；失败时记录日志但不 panic
EmptyDir 的 medium 类型切换成本：从 disk 切到 Memory 不只是改个字段，它会让所有 I/O 变成内存分配压力，而 Go 的 GC 和内存统计不会区分“这是 tmpfs 写入”还是“这是堆分配”。写一个 500MB 的临时文件，可能瞬间抬高 RSS 600MB，触发 cgroup memory.high 限流甚至 OOM。这事没法靠代码完全规避，得和运维一起看 limit/request 配置是否留了足够 buffer。 
