pytest --durations=N 是最直接的测试耗时分析手段，显示最慢的N个用例（N=0时列出全部），含setup/teardown耗时；它不替代@pytest.mark.slow，而是与其互补用于诊断与调度。
pytest --durations 是最直接、最无需配置的手段，能立刻告诉你哪些测试函数拖慢了整个 test session。它不依赖插件、不改代码、不注册 marker，运行完就出结果。
怎么用 --durations 看最慢的 N 个用例
命令格式固定：pytest --durations=N，其中 N 是你想看的条数（比如 5 或 10）。它只显示耗时最长的前 N 个用例，按 cumtime 降序排列。
- 输出里每行形如
1.00s call test_demo.py::test_demo10，数字越靠前，说明该用例越可能是瓶颈 - 注意：这个时间包含 setup/teardown 和所有 fixture 执行耗时，不只是
def test_xxx():里面的代码 - 如果
N设得太大（比如--durations=100），而你总共才跑 20 个用例，它会退化为显示全部；想看全量，直接用--durations=0
为什么 --durations=0 比只看 top N 更有用
pytest --durations=0 会列出所有测试用例的执行时间，排序后从最慢到最快。这对定位“隐藏慢用例”特别关键——有些测试单个不显眼（比如 0.8s），但和另外 4 个 0.7s 的凑一起，就吃掉 3 秒以上。
- 适合在 CI 报告里加一行：
pytest --durations=0 --tb=no -q，输出干净，方便 grep 或后续解析 - 注意：它不会标出“为什么慢”，只给事实数据；若看到某个
test_api_with_real_db耗时 2.3s，那大概率是网络或 I/O 问题，不是逻辑缺陷 - 别拿它当性能回归依据——同一台机器上两次运行，浮动 ±15% 很正常；要对比，得跑多次取中位数，或用
--durations-min过滤掉毛刺
常见误判：把 setup/teardown 耗时当成测试本身
很多“慢测试”其实慢在 fixture，比如一个 @pytest.fixture(scope="session") 启动了 Docker 容器，或加载了 200MB 的测试数据集。这类耗时会平摊到所有依赖它的测试用例上，导致多个用例都显示高耗时，但真正可优化的只有 fixture 本身。
- 检查输出中是否多个用例共享相似耗时（如都在 1.2–1.5s 区间），且名字都带相同前缀（如
test_with_db_*）→ 先查对应 fixture - 用
pytest --setup-show -v test_xxx.py::test_name看完整执行链，确认耗时发生在哪一环 - 别急着加
@pytest.mark.slow——如果慢的是共享 fixture，打标单个测试没意义；应该标记 fixture 或重构其作用域
和 @pytest.mark.slow 的关系：互补，不是替代
--durations 是事后诊断工具，@pytest.mark.slow 是事前分类机制。前者告诉你“谁慢”，后者帮你“怎么调度”。两者配合才完整。
立即学习“Python免费学习笔记（深入）”；
- 先用
--durations=10找出实际最慢的 10 个，再人工判断它们是否符合“慢”的语义（比如调外部 API、启浏览器、生成大文件） - 符合的，加上
@pytest.mark.slow并注册 marker；不符合的（比如只是临时写错循环），直接修复，不打标 - 千万别用
--durations输出自动打标——耗时阈值会随环境漂移，CI 机器快、本地 Mac 慢，自动打标会导致行为不一致
--durations 不反映稳定性**。一个测试平均 0.3s，但偶尔卡住 5s（比如 DNS 超时），它在 --durations=0 里可能排不进前 20，却会在 CI 里随机失败。这种 case 必须结合日志或重试机制处理，不能只靠耗时排序。 
