直接替换 os.Stdout 会编译失败，因 bytes.Buffer 与 os.File 类型不兼容；正确做法是用 os.Pipe() 获取 *os.File 写端赋值，并在读取前显式 wr.Close()，同时注意 log 输出需单独调用 log.SetOutput()，并发测试中禁止修改 os.Stdout。
测试中直接替换 os.Stdout 会编译失败
因为 os.Stdout 类型是 *os.File，而 *bytes.Buffer 虽然实现了 io.Writer，但二者类型不兼容。写成 os.Stdout = &bytes.Buffer{} 会触发编译错误：cannot assign *bytes.Buffer to os.Stdout (type *os.File)。
常见错误是误以为“只要实现 io.Writer 就能赋值”，忽略了 Go 的类型系统对底层文件描述符的强约束。
- 正确做法只有两种：用
os.Pipe()创建可赋值的*os.File写端，或用os.NewFile()封装内存 buffer（不推荐，易出错） -
os.Pipe()返回的wr是*os.File，可直接赋给os.Stdout - 别在测试里用
io.MultiWriter或自定义 wrapper 混合 stdout/stderr——类型和生命周期都难控
os.Pipe 捕获必须配对 Close() 否则 io.ReadAll 阻塞
管道读端等待 EOF，而 EOF 只在写端关闭后才产生。若漏掉 wr.Close()，io.ReadAll(rd) 会永远卡住，测试超时失败。
这个细节在并发或 panic 场景下尤其危险：一旦被测函数 panic，Close() 没执行，整个测试套件可能挂起。
立即学习“go语言免费学习笔记（深入）”；
- 务必在调用被测函数后、读取前执行
wr.Close() - 不能靠
defer wr.Close()—— 它会在函数退出时才触发，但被测函数可能已返回，而读取还没开始 - 若被测逻辑含 goroutine 异步写入，需额外同步（比如
sync.WaitGroup），否则可能读到截断内容
混用 fmt 和 log 时只动 os.Stdout 不够
log.Printf 默认写 os.Stderr（不是 os.Stdout），且内部缓存了输出目标。仅替换 os.Stdout 对它完全无效。
现象是：你看到 fmt.Println 输出被捕获了，但 log.Printf 依然打到终端，断言失败。
- 要捕获
log输出，必须显式调用log.SetOutput(wr)，且wr必须和赋给os.Stdout的是同一个写端 - 如果同时捕获
os.Stderr（比如fmt.Fprintln(os.Stderr, ...)），还得额外替换os.Stderr = wr - 更干净的做法：初始化一个独立
log.Logger，传入&buf，避免污染全局log包状态
并发测试中绝对禁止重定向 os.Stdout
os.Stdout 是包级全局变量，所有 goroutine 共享。在 t.Parallel() 测试里修改它，会导致多个测试相互覆盖、输出丢失、断言错乱——本地偶尔通过，CI 上必崩。
这不是竞态“可能出问题”，而是“必然出问题”，只是表现时机不确定。
- 永远不要在
t.Parallel()测试内碰os.Stdout - 即使不并行，也要确保每个测试都完成「保存→替换→执行→恢复」闭环，且恢复语句放在
defer中 - 根本解法：把输出逻辑抽成接受
io.Writer参数的函数，测试时传&bytes.Buffer{}，彻底绕过全局状态
os.Stdout。很多代码表面调用 fmt.Println，实则封装在接收 w io.Writer 的方法里——这种情况下，根本不需要管道，直接传 buffer 就行。 
