pytest输出捕获的两层边界：capsys与capfd在看什么

测试说明里写着“捕获了输出”，还没有说明捕获发生在哪一层。pytest官方指南把Python的sys.stdout、sys.stderr，与操作系统文件描述符1、2分开描述。[1] 这个区别尤其关系到测试输出来自哪里：同样出现在终端上的文字，未必都经过同一组Python对象。

指南将sys级捕获限定为写入Python的sys.stdout和sys.stderr的内容，并明确说它不捕获直接写往文件描述符的输出。capsys提供这一层面的访问接口。因此，用它取得的结果首先对应Python输出流；不能只因为名称里含有“标准输出”，就推断所有更底层的写入也已包含在内。

capfd的接口与capsys相同，但作用范围扩展到文件描述符层。文档具体指出，它可以捕获库或子进程直接写向操作系统级输出流FD1、FD2的内容。这里增加的是另一条输出路径，而不是把stdout与stderr合成一份没有区别的文字。原文也将fd列为pytest默认捕获层级，具体测试使用的夹具仍有自身身份。

从结果结构看，readouterr返回带out、err两个属性的命名元组，分别承载所捕获的输出。其调用会取得截至当时的输出快照，捕获随后继续。文档示例在第一次读取后又产生新输出，并在第二次读取中取得它。因此，“读到一次结果”不等于“捕获从此结束”；快照是时间上的一段结果，而不是对整个测试生命周期作出一次永久总结。

设想一份测试记录同时涉及Python输出与某个库直接写向FD2的文字，这只是用来解释来源的假设，没有实际运行代码。若记录只交代取得了capsys结果，尚不能由此声称库的底层输出也已被核验。换成capfd的语境，才涉及文档明确覆盖的描述符路径；是否真的出现了目标文字，仍要看那次读取的实际结果。

对软件测试工具的报告，捕获层级、输出来源与读取时点一起决定结果该怎样解释。它们回答的是“看到了哪一路、哪一段输出”，不会自行证明业务逻辑正确、日志完整或所有子进程行为已被测试。本篇采用pytest stable指南的层级定义和读取说明，来源没有明确首次发布日期，也没有把示例中的版本占位符当成实际安装版本。理解这两层边界，能够让输出断言的含义更具体。