子进程崩溃时pytest-forked不输出错误堆栈，需加--forked -s强制显示stdout/stderr；仍无输出则启用pythonfaulthandler=1；避免os._exit()干扰异常流程，并注意fork后import失败、logging失效及multiprocessing.manager不可用等问题。
子进程崩溃时pytest-forked不输出错误堆栈怎么办
默认情况下，pytest-forked 会把子进程的标准错误重定向掉，崩溃时只显示 F 或直接静默退出，根本看不到报错原因。关键是要让子进程的异常浮上来。
实操建议：
- 加
--forked同时加上-s（即pytest --forked -s），强制 pytest 不捕获子进程 stdout/stderr - 若仍无输出，改用
PYTHONFAULTHANDLER=1 pytest --forked -s，触发 Python 的 fault handler，在 segfault 等底层崩溃时打印 traceback - 避免在测试里调用
os._exit()或直接sys.exit()—— 这会让 fork 出的子进程提前终止，且不走正常异常流程
为什么fork后import失败或ModuleNotFoundError频发
pytest-forked 是在 fork 后才导入测试模块，而 fork 会复制父进程内存状态，但不会重新执行 sys.path 初始化或 __pycache__ 文件校验 —— 所以如果父进程已修改过 sys.path、或缓存文件被并发写坏，子进程 import 就可能失败。
实操建议：
- 不要在
conftest.py或__init__.py中动态修改sys.path；改用pythonpath配置或-p no:pythonpath+ 显式sys.path.insert(0, ...) - 运行前清理缓存：
find . -name "__pycache__" -exec rm -rf {} + - 确认所有测试文件都在同一个 Python 解释器路径下运行，避免混用 virtualenv 和系统 Python 导致的 site-packages 不一致
forked模式下logging和multiprocessing.Manager失效
fork 之后，日志 handler（尤其是 FileHandler）和 multiprocessing.Manager 对象可能处于未初始化或损坏状态，导致子进程卡死或抛出 AssertionError: can only join a started process 类错误。
实操建议：
- 在每个测试函数开头重置 logging：
import logging; logging.getLogger().handlers.clear(); logging.basicConfig(level=logging.INFO) - 避免在测试中创建
multiprocessing.Manager()—— fork 后 manager server 进程不存在，子进程无法连接；改用dict、queue.Queue或临时文件共享数据 - 若必须用 multiprocessing，改用
spawn启动方式（但需配合pytest-xdist而非pytest-forked）
如何定位是pytest-forked本身还是测试代码引发崩溃
最可靠的方式是关闭 fork，对比行为差异：如果 pytest 正常运行，但 pytest --forked 崩溃，那问题一定出在 fork 上下文隔离或资源竞争上。
实操建议：
- 先跑
pytest --forked -x -v --tb=short，用-x在第一个失败就停，缩小排查范围 - 对疑似测试加
@pytest.mark.xfail(reason="fork crash")临时跳过，再逐个取消注释验证 - 用
strace -f pytest --forked -x 2>&1 | grep -E "(exit|kill|SIG)"查看系统调用级崩溃信号（如SIGSEGV）
fork 的本质是复制内存页，但不复制线程、文件锁、某些 C 扩展的全局状态 —— 所以看似简单的测试，在 fork 后可能因状态残留或竞态条件突然暴露问题。别假设“单测能过就代表 fork 安全”。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
