capsys仅捕获print()、sys.stdout.write()和sys.stderr.write()的输出，不捕获logging、文件写入或子进程输出；需注意刷新缓冲区、sys.argv还原、换行符处理及isatty()返回False等问题。
capsys能捕获哪些输出
capsys 默认只捕获 print()、sys.stdout.write() 和 sys.stderr.write() 这类直接写入标准流的内容，不捕获 logging 输出、文件写入、子进程打印（如 os.system() 或 subprocess.run(..., stdout=...)）——这些得换 caplog 或重定向 subprocess 的流。
常见错误现象：assert "hello" in capsys.readouterr().out 失败，但代码里明明有 print("hello") —— 很可能是测试函数没被调用，或输出被缓存未刷新（尤其在循环里），加 flush=True 或末尾手动 sys.stdout.flush() 试试。
- 使用场景：验证 CLI 工具主函数的提示信息、帮助文案、处理结果等是否符合预期
- 参数差异：
capsys捕获所有测试函数内产生的 stdout/stderr；capfd还能捕获 C 扩展或子进程输出（更重，慎用） - 性能影响：几乎可忽略，但频繁调用
readouterr()会清空缓冲区，第二次调用返回空字符串
怎么在pytest中正确调用CLI入口函数
别用 subprocess 启动新进程测——慢、难调试、环境变量/路径易错。直接导入并调用你的 CLI 主函数（比如 main() 或 cli()），把 sys.argv 临时替换成测试参数即可。
示例：
立即学习“Python免费学习笔记（深入）”；
def test_cli_help(capsys):
import sys
# 保存原argv，避免污染其他测试
old_argv = sys.argv
sys.argv = ["mytool", "--help"]
try:
mytool.cli() # 假设这是你的入口函数
out, err = capsys.readouterr()
assert "Usage:" in out
finally:
sys.argv = old_argv- 容易踩的坑：忘记还原
sys.argv，导致后续测试行为异常；推荐用monkeypatch更安全（monkeypatch.setattr(sys, "argv", [...])） - 如果 CLI 用了
argparse.ArgumentParser().parse_args()，确保传入的参数格式匹配（比如带--的长选项不能漏掉） - 某些框架（如 Click）提供
CliRunner，比手动改sys.argv更稳，但capsys依然适用其内部 print 调用
断言输出时要注意换行和空格
print("done") 实际输出是 "done\n"，不是 "done"；print("done", end="") 才是纯字符串。很多断言失败就卡在这儿。
常见错误现象：assert capsys.readouterr().out == "done" 永远失败，因为实际是 "done\n"。
- 推荐写法：
assert "done" in capsys.readouterr().out.strip()或.out.rstrip("\n") - 如果要精确匹配多行输出，用三引号字符串 +
\n显式写出换行，再.replace("\r\n", "\n")兼容 Windows - 注意空格缩进、制表符、颜色 ANSI 码（如
\x1b[32mOK\x1b[0m）——它们都算输出内容，断言前先看print(repr(out))
为什么测试通过但终端看不到输出
因为 capsys 默认开启输出捕获，pytest 不会把 stdout/stderr 打到控制台——这是正常行为，不是 bug。想临时查看，加 -s 参数运行：pytest -s test_cli.py。
但这只是调试手段。正式测试中应依赖 capsys 断言，而不是靠肉眼观察。
- 容易被忽略的点：CI 环境默认不显示输出，若你误把
-s当成必需项，会导致测试在 CI 失败（因 pytest 报错“unknown option”） - 真正需要“看到输出”的场景，其实是调试阶段；上线前务必删掉
-s，让capsys控制捕获逻辑 - 如果 CLI 本身依赖终端特性（如
isatty()判断是否交互），capsys下sys.stdout.isatty()返回False，需额外 mock
