pytest失败后立即停止的参数是-x，它等价于--exitfirst，语义为首次失败即停；-x会中止整个进程池，而--maxfail=1仅限制失败总数，二者在并行场景下行为不同。
pytest失败后立即停止的参数是-x
直接在命令行加-x就能让pytest在第一个测试用例失败时立刻退出，不再运行后续用例。这是最常用也最可靠的方式，底层对应--exitfirst，两者完全等价。
常见错误是误用--maxfail=1——它确实也能实现类似效果，但语义不同：--maxfail统计的是“失败用例总数”，而-x是“首次失败即停”，尤其在有pytest-xdist并行时，-x会中止整个进程池，--maxfail=1可能仍会启动多个worker导致多条失败日志。
-
pytest -x：推荐，语义清晰，兼容所有插件 -
pytest --exitfirst：和-x完全一样，适合写进pyproject.toml配置里 -
pytest --maxfail=1：慎用，仅当需要“最多允许1个失败”逻辑时才考虑（比如CI中容忍偶发flaky）
如何在pyproject.toml中持久化配置-x
避免每次敲命令都加参数，把--exitfirst写进项目配置最稳妥。注意不能写成-x缩写形式，INI/TOML不支持短参数。
在pyproject.toml的[tool.pytest.ini_options]下添加：
立即学习“Python免费学习笔记（深入）”；
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
[tool.pytest.ini_options] exitfirst = true
这样执行pytest或pytest tests/都会自动生效。如果同时存在命令行参数（如pytest -x tests/），命令行优先级更高，会覆盖配置。
- 不要写
x = true，无效 - 不要写
addopts = ["-x"]，虽然能用，但exitfirst = true更语义明确且被官方文档推荐 - 若项目已用
pytest.ini，写法是exitfirst = true（同一行，等号前后可有空格）
与--tb=short搭配使用更高效
单测失败时默认显示完整traceback，信息量大但干扰快速定位。配合-x时，建议加上--tb=short只显示关键错误行，减少滚动查找成本。
命令示例：pytest -x --tb=short
-
--tb=short：只显示报错文件、行号和异常类型，适合日常开发 -
--tb=line：更精简，只显示一行摘要，适合CI日志快速扫描 - 避免用
--tb=no，会丢失关键上下文，调试困难 - 这些
--tb选项和-x无冲突，可安全组合
注意fixture teardown仍会执行
-x只中断测试函数本身，不会跳过已触发的teardown逻辑。比如用@pytest.fixture(scope="function", autouse=True)定义的清理操作，只要setup成功执行过，对应的teardown就一定会跑完。
这意味着：如果你的teardown里有耗时I/O（如删临时目录、关数据库连接），它们依然会发生；但如果teardown本身出错，pytest会把它当作新错误报告，可能掩盖原始失败原因。
- 想跳过teardown？不行——pytest没提供这种开关，强行跳过会导致资源泄漏
- teardown报错掩盖主失败？可在
conftest.py里用request.addfinalizer()包裹关键清理，并捕获内部异常 - 并行场景下（
pytest-xdist），-x中止的是当前worker，其他worker可能仍在运行未开始的测试
-x行为看似简单，但和fixture生命周期、并行插件、配置加载顺序交织在一起，最容易被忽略的是teardown不可跳过这一点——它保证了资源安全，也意味着失败后你看到的可能不是第一个错误，而是teardown抛出的第二个异常。 
