go中无需freopen，常用方案有三：1. fmt.fprintf写文件；2. exec.command.stdout直连文件；3. log.setoutput重定向日志。关键在正确打开文件、及时刷新缓冲、管理生命周期。
Go 语言里没有 freopen 那种“全局替换 stdout 文件描述符”的 C 风格操作，但绝大多数实际需求——比如把日志、命令输出或格式化内容写进文件——根本不需要那么底层。直接用标准库提供的接口就能干净解决，关键是选对方法，别绕弯。
用 fmt.Fprintf 写格式化内容到文件最直接
如果你只是想把 fmt.Printf("hello %d", 42) 这类输出存到文件里，别动 os.Stdout，直接换函数：用 fmt.Fprintf，第一个参数传打开的文件句柄。
-
os.Create("out.txt")会清空已有内容；需要追加就用os.OpenFile("out.txt", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644) - 记得检查
os.OpenFile的返回错误，常见的是路径不存在（父目录没建）或权限不足 - 如果写入量大，套一层
bufio.NewWriter能显著提升性能，但必须在关闭文件前调用writer.Flush()，否则最后几 KB 可能丢 -
fmt.Fprintf和fmt.Printf参数完全一致，只是多了一个w io.Writer前缀，迁移零成本
用 cmd.Stdout 直接捕获外部命令输出
执行 exec.Command("ls", "-l") 后想把结果写进文件？别用 cmd.StdoutPipe() + io.Copy + goroutine，那是为“边读边处理”设计的。纯写文件，直接赋值：
- 创建文件后，把
*os.File赋给cmd.Stdout字段，例如cmd.Stdout = outfile -
cmd.Stderr同理，可单独重定向到另一个文件（比如err.log） - 必须在
cmd.Start()或cmd.Run()之前完成赋值，之后改无效 - 不用等
io.Copy完成，cmd.Wait()返回时文件已写满——内核直接把进程 stdout 指向了你的文件描述符
用 log.SetOutput 统一接管日志流向
想让所有 log.Printf 都进文件？log.SetOutput 是最轻量方案，但它影响的是全局 log 包实例：
- 传入一个已打开的
*os.File（推荐os.OpenFile(..., os.O_APPEND)，避免重启丢日志） - 若程序还依赖第三方库的日志，它们也会跟着进这个文件——这是优点也是风险点
- 更安全的做法是用
log.New创建独立日志器，例如debugLog := log.New(debugFile, "[DEBUG] ", log.LstdFlags)，互不干扰 - 注意：
log默认写os.Stderr，重定向后语义不变，只是目标变了；容器环境通常靠stderr抓日志，所以日志文件最好也对应 stderr 行为（比如不缓冲、及时刷盘）
别轻易碰 os.Stdout = fd 这种“伪 freopen”
只有当你明确需要底层系统调用（比如 C FFI、syscall.Write(1, ...)）仍写入目标文件时，才考虑复用文件描述符 1。但这极其危险：
- 必须在
main()开头、任何 goroutine 启动前做：先os.Stdout.Close()，再os.OpenFile(...)，靠内核自动分配 fd 1 - 一旦中间有其他代码（比如
log初始化、第三方库 init 函数）打开了新文件，fd 1 就可能被抢走，重定向失效 - Go 运行时某些内部日志（如 panic traceback）仍可能绕过
os.Stdout直接写 fd 1，但你无法控制它的行为 - 99% 的业务场景完全不需要它——
fmt.Fprintf、cmd.Stdout、log.SetOutput已覆盖全部常用路径
真正容易被忽略的不是语法，而是文件打开模式和生命周期管理：用 os.Create 会清空旧日志；忘记 defer f.Close() 可能导致程序退出时缓冲未刷盘；多个 goroutine 并发写同一个 *os.File 虽然线程安全，但内容会交错——这时候该上 bufio.Writer 加锁，而不是硬扛。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
