因为 pytest.main() 默认调用 sys.exit() 终止进程，导致后续代码无法执行；正确做法是传入 exitcode=false 参数（pytest ≥ 7.0），使其返回退出码而非直接退出。
为什么直接调用 pytest.main() 会卡住或不生效？
因为 pytest.main() 默认会调用 sys.exit()，一旦执行完就终止进程，导致后续 Python 代码无法运行。很多 wrapper 脚本在 pytest.main([...]) 后加日志或清理逻辑，结果根本执行不到。
- 正确做法是传入
exitcode=False参数（pytest ≥ 7.0），它让函数返回整数退出码而非直接退出 - 旧版本（pytest.main([...], plugins=[...]) + 捕获
SystemExit，但不稳定，建议升级 pytest - 别用
os.system("pytest ...")—— 丢失返回值、难调试、路径和环境变量易错
如何在 wrapper 中安全注入自定义参数和钩子？
pytest 的启动逻辑高度依赖命令行参数解析和插件生命周期，硬编码 sys.argv 或 patch sys.argv 极易被后续插件读错。推荐用 pytest.main() 的 args 参数显式传参。
- 所有参数必须是字符串列表，比如
["-x", "-v", "tests/"]；不能传["--maxfail=2"]这种带等号的写法，应拆成["--maxfail", "2"] - 若需动态加插件（如自定义收集器），用
plugins=[MyCollectorPlugin()]参数传实例，不要依赖conftest.py自动发现（wrapper 可能不在项目根目录） - 注意
pytest.ini/pyproject.toml仍会被加载 —— wrapper 不会绕过配置文件，想屏蔽就加--override-ini="addopts=""
怎样让 wrapper 支持 --collect-only 和其他调试模式？
很多人写 wrapper 时只测试正常执行流程，结果一加 --collect-only 就报错或输出混乱，因为该模式下 pytest 不真正运行测试，但会触发收集阶段的异常（比如 conftest 导入失败）。
- 务必在 wrapper 开头加
import sys; print(f"Running pytest with args: {sys.argv}")，确认实际传给pytest.main()的参数是否符合预期 - 对
--collect-only、--fixtures等只收集不执行的命令，exitcode=False仍有效，返回码为 0 表示成功收集，非 0 表示收集出错 - 如果 wrapper 里有耗时初始化（如启动 mock server），应包裹在
if not any(a in ["--collect-only", "--fixtures", "--help"] for a in args):条件中，避免无谓开销
为什么 wrapper 在 CI 中找不到 tests/ 目录？
根本原因是 pytest 默认以当前工作目录（os.getcwd()）为基准解析测试路径，而 wrapper 脚本可能被任意路径调用（比如 python scripts/run_tests.py），此时 os.getcwd() 是调用点，不是脚本所在目录。
- 统一用
pathlib.Path(__file__).parent.resolve()定位脚本所在目录，再拼接"../tests"或"tests/" - 传给
pytest.main()的路径必须存在且可读，建议加assert Path(test_dir).exists(), f"Test dir missing: {test_dir}" - CI 环境常禁用用户 site-packages，确保 wrapper 不依赖未安装的第三方插件；所有
import必须在pytest.main()前完成，否则收集阶段会失败
最常被忽略的是 exitcode 返回值处理 —— 很多人以为返回 0 就万事大吉，其实 pytest 在收集阶段出错（比如语法错误、fixture 定义冲突）也可能返回非 0，但 wrapper 若没检查就静默退出，CI 会误判为成功。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
