直接替换 os.stdout 为 bytes.buffer 是最轻量可靠的方式，需测试前替换、结束后用 defer 恢复；testing.t 无 captureoutput 方法；多输出需分别接管 stdout/stderr/log。
Go 测试中怎么捕获 fmt.Println 的输出
直接替换 os.Stdout 为内存缓冲区是最轻量、最可靠的方式。标准库的 fmt 系列函数（包括 fmt.Println、fmt.Printf）都依赖 os.Stdout，改它就能拦住所有输出。
常见错误是试图用 io.Pipe 或 goroutine 读取 stdout——容易死锁，尤其在测试超时或 panic 时；还有人想 patch fmt 函数本身，但 Go 不支持运行时函数重写，纯属白忙。
- 测试前用
os.Stdout = &buf替换，其中buf是bytes.Buffer{} - 测试结束后必须恢复：用
defer func() { os.Stdout = orig }()，否则污染其他测试 - 注意：如果被测代码显式传入了
io.Writer（比如fmt.Fprintln(w, ...)），那改os.Stdout没用，得从接口注入入手
为什么不能只用 testing.T.CaptureOutput
因为 testing.T 根本没有 CaptureOutput 这个方法——这是常见误解，可能混淆了其他语言（如 Python 的 unittest.mock.patch）或第三方库（如 testify）的 API。Go 标准测试框架不提供开箱即用的输出捕获机制。
强行封装一个“CaptureOutput”辅助函数看似省事，但容易埋坑：
立即学习“go语言免费学习笔记（深入）”；
- 没处理并发安全：多个子测试共用同一 buffer 会互相覆盖
- 忘记 defer 恢复
os.Stdout，导致后续测试输出消失，现象诡异 - 和
log.SetOutput冲突：如果被测代码也用了log包，默认也写到os.Stderr，但你只换了Stdout
真实项目里怎么处理多输出目标（stdout + stderr + log）
生产级命令行工具往往同时写 os.Stdout、os.Stderr 和 log 输出，测试时得一并接管。
关键不是“全换成 buffer”，而是按职责分离：
-
os.Stdout→bytes.Buffer（捕获用户可见输出） -
os.Stderr→ 另一个bytes.Buffer（捕获错误提示，避免和 stdout 混淆） -
log.SetOutput→ 指向第三个bytes.Buffer或直接设为io.Discard（日志通常不参与断言，静默更安全） - 如果用了结构化日志库（如
zap、zerolog），需查其文档看如何设置输出目标，不能只动log包
性能与兼容性要注意什么
用 bytes.Buffer 捕获输出几乎没有性能损耗，但它本质是内存拷贝，对超大输出（比如导出百万行 CSV）可能吃内存。不过测试场景极少遇到这种量级，真有也该拆成单元+集成双层验证。
兼容性方面唯一雷点是 Windows 下的换行符：fmt.Println 在 Windows 输出 \r\n，Linux/macOS 是 \n。别写死断言，用 strings.TrimSpace(buf.String()) 或正则清理后再比对。
另外，Go 1.21+ 支持 io.Discard 作为无副作用的 writer，比 bytes.Buffer 更轻——但你要的是捕获内容，不是丢弃，所以这不适用。
真正容易被忽略的是：任何对 os.Stdout 的修改都会影响 pprof、runtime/debug 等底层调试输出，如果测试里启用了这些，记得单独隔离或跳过相关 case。
