不能，capfd仅对当前Python进程中经libc write()或fflush()路径的输出有效；C扩展若用带缓冲的printf且未fflush，或在子进程、自定义FILE*中输出，则无法捕获。
capfd 能捕获 C 扩展的 stdout 吗？不能，除非满足特定条件
pytest 的 capfd fixture 本质是用 Python 的 os.dup2 临时重定向文件描述符 1 和 2，但它只对**当前 Python 进程中调用 libc write() 或 fflush() 的路径有效**。C 扩展若直接调用底层系统 write()（比如通过 write(1, ...)），且未经过 Python 的 stdio 缓冲层，capfd 通常能捕获；但若 C 扩展使用了独立的 FILE* 流（如 fprintf(stdout, ...)）且该流已被 setvbuf 修改过缓冲模式，或在 fork 子进程里输出，则大概率失效。
为什么你的 C 扩展输出没被 capfd 捕获？常见原因
最常踩的坑是 C 扩展内部用了带缓冲的 printf 系列函数，而 Python 主进程的 capfd 重定向发生在 Python 层，不干预 C 运行时库对 stdout 的缓冲状态。尤其当 C 扩展在输出后没调用 fflush(stdout)，或使用了 setvbuf(stdout, NULL, _IONBF, 0)（无缓冲）以外的模式，输出会滞留在 C 库缓冲区，根本没到达被 capfd 重定向的 fd 1。
- C 扩展调用
printf但未fflush(stdout) - C 扩展在子进程中输出（例如用
fork()+exec），子进程的 stdout 不受父进程capfd控制 - C 扩展使用了自定义 FILE*（如
fopen("/dev/stdout", "w")），绕过了全局stdout流 - 扩展在多线程中输出，且未同步 fflush，导致部分输出丢失或乱序
实操：让 capfd 可靠捕获 C 扩展输出的三步法
核心思路不是“让 capfd 更强”，而是“让 C 扩展输出行为与 capfd 的重定向时机对齐”。关键动作必须在 C 层配合：
- 在 C 扩展初始化阶段（如
PyInit_yourmodule或模块加载时），调用setvbuf(stdout, NULL, _IONBF, 0)和setvbuf(stderr, NULL, _IONBF, 0)，关闭 stdio 缓冲——这是最简单有效的手段 - 每次调用
printf/fprintf(stdout, ...)后，紧跟着fflush(stdout)；同理处理 stderr - 测试代码中，在调用 C 函数后、读取
capfd.readouterr()前，加一句sys.stdout.flush()和sys.stderr.flush()（虽非必需，但可消除 Python 层残留缓冲干扰）
示例 C 片段：
立即学习“Python免费学习笔记（深入）”；
static PyObject* my_c_function(PyObject* self, PyObject* args) {
printf("hello from C\n");
fflush(stdout); // 必须！
Py_RETURN_NONE;
}对应 pytest 测试：
def test_c_output(capfd):
yourmodule.my_c_function()
out, err = capfd.readouterr()
assert "hello from C" in out替代方案：当 capfd 彻底失效时怎么办？
如果 C 扩展用了 write(1, ...) 但仍在子进程里跑，或你无法修改 C 源码，就别硬刚 capfd。改用 subprocess.run 启动一个独立 Python 进程来调用该扩展，并捕获其完整 stdout/stderr——这绕过了所有进程内重定向的限制，也更贴近真实使用场景。
另一个底线方案是让 C 扩展自己支持输出重定向：暴露一个 C API 函数，接受一个 FILE* 参数，把原本写 stdout 的逻辑改成写入传入的流，测试时传入内存 FILE（用 fmemopen）或临时文件句柄。但这需要你完全掌控 C 扩展源码。
真正麻烦的从来不是 capfd 本身，而是 C 运行时和 Python 解释器对“标准输出”这个概念的理解差异——它们不在同一套缓冲模型里。动手前先确认 C 扩展到底走哪条输出路径，比盲目套 fixture 有用得多。
