Go测试中捕获fmt.Println输出最可靠方式是用os.Pipe重定向os.Stdout，但需保存原值、执行后及时恢复，避免污染其他测试；不能直接赋值bytes.Buffer因类型不匹配；并发测试中禁止重定向os.Stdout。
Go 测试中怎么捕获 fmt.Println 输出
直接重定向 os.Stdout 是最常用也最可靠的方式，但必须注意：它影响的是全局标准输出，不是当前 goroutine 局部的。测试函数跑完后不恢复，会污染后续测试。
- 用
os.Pipe()创建管道，把os.Stdout指向写端，读端用于获取内容 - 测试前保存原
os.Stdout，结束后务必用os.Stdout = originalStdout恢复 - 别忘了调用
pipeWriter.Close()，否则io.ReadAll()可能阻塞 - 如果被测代码用了
log.Printf且没自定义输出器，默认也会写到os.Stdout，一并被捕获
func TestMyFunc(t *testing.T) {
original := os.Stdout
r, w, _ := os.Pipe()
os.Stdout = w
MyFunc() // 它内部调用了 fmt.Println
w.Close()
out, _ := io.ReadAll(r)
os.Stdout = original
if string(out) != "hello
" {
t.Errorf("expected hello\n, got %s", string(out))
}
}
为什么不能用 bytes.Buffer 直接赋值给 os.Stdout
因为 os.Stdout 类型是 *os.File，而 *bytes.Buffer 不满足 io.Writer 在文件描述符层面的要求——os.File.Write 会尝试调用底层 syscall，bytes.Buffer.Write 虽然也实现 io.Writer，但类型不匹配，直接赋值会编译失败。
- 错误写法：
os.Stdout = &bytes.Buffer{}→ 编译报错：cannot assign *bytes.Buffer to os.Stdout (type *os.File) - 正确路径只有通过
os.Pipe()或临时替换为自定义io.Writer并用os.NewFile封装（不推荐，复杂且易出错） - 若只是想测试自己封装的打印函数（比如接收
w io.Writer参数），那就直接传&bytes.Buffer{}，无需碰os.Stdout
并发测试时重定向 os.Stdout 会出什么问题
多个测试用例或子测试同时修改 os.Stdout，极易相互干扰——A 测试还没恢复，B 测试就覆盖了，导致输出丢失或断言失败，而且这种问题在本地偶尔复现、CI 上高频爆发。
- 绝对避免在
t.Parallel()的测试里重定向os.Stdout - 即使不并行，也要确保每个测试都独立完成「保存→重定向→执行→恢复」闭环
- 更稳妥的做法：把需要输出的逻辑抽成接受
io.Writer的函数，测试时传&bytes.Buffer{}，彻底绕开全局状态 - 如果必须测真实
fmt行为，就加t.Parallel()的反向约束：t.Parallel()前先t.Skip()
Python 里捕获 print 怎么做才不踩坑
Python 的 unittest.mock.patch 看似简单，但容易漏掉模块层级或作用域问题；contextlib.redirect_stdout 更轻量，但必须确保上下文退出——哪怕 panic 或 return 都要触发恢复。
- 推荐用
contextlib.redirect_stdout+io.StringIO，简洁且自动清理 - 别 patch
sys.stdout到模块顶层（如my_module.sys.stdout），应 patch 实际调用处的sys（通常是builtins.print或目标模块的sys） - 如果被测函数里用了
flush=True或end=""，捕获内容要对应检查，比如换行符是否缺失 - 注意 Python 3.7+ 中
io.StringIO的getvalue()返回 str，不用再 decode
import io
from contextlib import redirect_stdout
def test_print_output():
f = io.StringIO()
with redirect_stdout(f):
print("hello world")
assert f.getvalue() == "hello world
"
有些边界情况没法靠重定向兜住——比如 C 扩展写的日志、syscall 直接写的 stdout、或者多进程里子进程的输出。真遇到这些，得换思路：改接口、加回调、或者用集成测试级的进程捕获。 
