用os.Pipe捕获fmt.Println输出需先调用os.Pipe获取读写端，将os.Stdout设为写端，执行目标代码后关闭写端，再从读端读取内容并恢复os.Stdout；若混用log需同步替换log.SetOutput。
用 os.Pipe 捕获 fmt.Println 等直接写 Stdout 的输出
Go 标准库不提供“全局重定向 Stdout”的魔法开关，但可以通过替换 os.Stdout 为一个管道（pipe）来实现捕获。关键点在于：必须在目标代码执行前完成替换，并在执行后及时恢复，否则会影响后续所有写 Stdout 的行为。
常见错误是只替换 os.Stdout 却没处理 goroutine 并发写入、或忘记恢复导致测试后程序日志消失。
- 先调用
os.Pipe()得到reader和writer - 把
os.Stdout暂时设为writer - 运行你要捕获的代码（比如调用某个打印函数）
- 调用
writer.Close()—— 这步不能省，否则io.ReadAll(reader)会阻塞 - 从
reader读取内容，再把os.Stdout恢复为原始值
捕获 log.Printf 输出需同时替换 log.SetOutput
log 包默认也写 os.Stderr 或 os.Stdout，但它内部缓存了输出目标，仅改 os.Stdout 不生效。必须显式调用 log.SetOutput 才能生效。
如果代码里混用了 fmt 和 log，就得双管齐下：既替换 os.Stdout（和/或 os.Stderr），又调用 log.SetOutput 指向同一管道 writer。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 对
log输出，优先用log.SetOutput(writer)，而不是依赖它默认写os.Stdout - 若想统一捕获所有日志，建议初始化时就用
log.New(writer, "", 0)构造独立 logger，避免污染全局 - 注意
log默认带换行符，fmt.Println也带，拼接时容易多出空行
用 bytes.Buffer 替代 pipe 更轻量、无并发风险
如果被测代码接受 io.Writer 参数（比如函数签名是 func writeOutput(w io.Writer)），直接传 &bytes.Buffer{} 是最简单安全的方式，完全绕过 os.Stdout 替换。
但多数遗留代码直接调用 fmt.Fprintln(os.Stdout, ...)，这时 bytes.Buffer 就无法介入——它不是“替换 Stdout”，而是“让代码支持注入 Writer”。这是设计层面的区别。
-
bytes.Buffer是内存 buffer，无系统调用开销，适合单元测试中高频调用 - 它实现了
io.Writer和io.Reader，调用buf.String()即得结果 - 如果函数没暴露
io.Writer参数，就只能走os.Pipe路线；别强行改函数签名只为测试
注意子进程和第三方库可能绕过你的重定向
重定向 os.Stdout 只影响当前进程内 Go 代码通过 os.Stdout.Write 或 fmt/log 写出的内容。一旦调用 exec.Command 启动子进程，它的 Stdout 默认仍是终端，除非你显式设置 cmd.Stdout = yourWriter。
同理，某些 Cgo 绑定的库（如 SQLite 日志、OpenSSL 错误输出）可能直接调用 libc 的 write(1, ...)，完全绕过 Go 的 os.Stdout 抽象层。
- 子进程输出要捕获，必须单独配置
cmd.Stdout和cmd.Stderr - Cgo 库输出通常不可控，只能从外部重定向整个进程（如 shell 下
./myapp 2>&1） - 调试时可用
strace -e write ./myapp确认哪些输出真的走了 fd 1
writer.Close() 忘记调用或位置不对——这是最常卡住的地方。管道两端必须严格配对，buffer 类型则没这问题，但适用场景有限。 
