Go os.CreateTemp关闭后再交给其他进程读取的资源方案

把 os.CreateTemp 生成的文件交给另一个进程时，关键不是把 *os.File 传过去，而是把“写入完成、关闭成功、路径可见”当成一次明确的资源交接。生产代码通常按“创建并写入 → 必要时同步 → Close → 传递 Name() → 消费者重新打开 → 消费结束后 Remove”的顺序执行。Close 会让 Go 侧文件对象不能继续 I/O，但不会自动删除临时文件；真正的删除责任仍由创建方或约定的清理方承担。

先把文件句柄、路径和清理责任分开

os.CreateTemp(dir, pattern) 会返回一个已经打开、可读写的 *os.File。它在文件名中加入随机串，避免并发调用选中同一个路径；如果 dir 为空，就使用系统临时目录。当前 Go 文档还明确了默认权限是 0600，因此同一用户的另一个进程通常可以按路径打开，但不同用户可能直接收到权限错误。

这里有三个独立对象：*os.File 是当前进程持有的句柄，f.Name() 是交接给消费者的路径，临时文件本身则是需要最终删除的磁盘对象。Close 只结束句柄生命周期，不能替代 os.Remove。这也是很多“关闭后找不到文件”排查中最容易混淆的一点：如果文件消失，通常是代码显式删除、外部清理器处理，或平台/目录策略另有约束，而不是 Close 的默认行为。

写入完成后再关闭，必要时补上 Sync

如果消费者只是读取已经写入的内容，先检查每次 Write 的错误，再关闭文件即可完成通常的交接。若文件必须在操作系统或机器异常后仍尽可能保留，才需要在 Close 前调用 Sync；它表达的是更强的持久化要求，不是跨进程读取的必选步骤。

package main

import (
	"context"
	"fmt"
	"os"
	"os/exec"
)

// prepareTempForConsumer 写完文件并关闭句柄，只把稳定路径交给消费者。
func prepareTempForConsumer() (string, func(), error) {
	f, err := os.CreateTemp("", "report-*.json")
	if err != nil {
		return "", nil, fmt.Errorf("创建临时文件: %w", err)
	}
	path := f.Name()
	cleanup := func() { _ = os.Remove(path) } // Close 不删除文件，清理动作单独负责。

	if _, err := f.WriteString(`{"status":"ready"}` + "\n"); err != nil {
		_ = f.Close() // 写入失败时也先释放句柄，再由调用方决定是否重试。
		cleanup()
		return "", nil, fmt.Errorf("写入临时文件: %w", err)
	}
	// 只有对崩溃后的持久性有要求时才打开这一行，普通读取不必强制 Sync。
	if err := f.Sync(); err != nil {
		_ = f.Close()
		cleanup()
		return "", nil, fmt.Errorf("同步临时文件: %w", err)
	}
	if err := f.Close(); err != nil {
		cleanup()
		return "", nil, fmt.Errorf("关闭临时文件: %w", err)
	}
	return path, cleanup, nil
}

func main() {
	path, cleanup, err := prepareTempForConsumer()
	if err != nil {
		panic(err)
	}
	defer cleanup() // 消费者退出后回收临时文件，避免异常路径泄漏。

	ctx := context.Background()
	cmd := exec.CommandContext(ctx, "report-reader", path) // 消费者按路径重新打开文件。
	if output, err := cmd.CombinedOutput(); err != nil {
		panic(fmt.Errorf("消费者读取失败: %w; 输出: %s", err, output))
	}
}

这个示例把 Sync 放在可选的强持久性路径中。交接协议应把“命令已经启动”与“消费者已经成功读取”区分开：前者只能说明路径传出，后者才是可以清理文件的可靠时机。如果消费者是异步服务，就不要在父进程刚启动命令后立即删除文件。

Close 之后交接路径，消费者重新打开文件

File.Name 在关闭后仍可调用，所以可以先把路径保存成字符串，再关闭句柄。消费者收到路径后调用 os.Open，这会创建属于消费者的新句柄。不要把已经关闭的 *os.File 当作可共享资源，也不要把 Fd() 当成跨平台的路径交接协议：关闭后文件描述符无效，而且不同进程的描述符继承还取决于启动方式和平台。

一个简单的交接约定可以写成三条：创建方负责生成唯一文件名；创建方在 Close 返回 nil 后发送路径；消费者明确回传成功、失败或超时状态。若消费者还会持续读取，就让它自己控制打开和关闭，创建方只负责在收到最终结果后执行清理。

权限和异常路径决定这套方案能否落地

默认 0600 对安全很有利，却也意味着“其他进程”若使用不同系统账号，可能无法读取。跨用户交接时，应在受控共享目录中创建文件，并用明确的目录权限、文件权限和访问控制解决问题；不要为了省事把临时文件改成全局可写。路径还可能包含空格或特殊字符，传给 exec.Command 时应作为独立参数传入，避免自行拼接 shell 命令。

错误处理至少覆盖四种情况：创建失败时没有路径可交接；写入失败时先关闭并删除；Close 失败时不要通知消费者；消费者失败或超时时仍要删除。若消费者需要重试，保留文件到重试窗口结束，再由单独的超时清理任务回收。清理失败也要记录路径和原因，但日志中不要输出文件内容或敏感数据。

常见问题

Close 之后临时文件会自动消失吗？

不会。CreateTemp 创建的是普通临时文件，调用方需要在不再使用时显式 os.Remove；只有外部清理策略或程序自身删除时它才会消失。

另一个进程能直接使用创建方的 *os.File 吗？

通常应交接路径，让消费者自己 os.Open。句柄和文件描述符的继承属于更特殊的进程启动协议，不能用普通的 Close 后路径读取方案替代。

什么时候必须调用 Sync？

只在你需要更强的崩溃后持久性保证时调用。单纯要求另一个进程读取已完成内容时，写入成功并 Close 通常就是清晰的交接边界。

官方资料：https://pkg.go.dev/os