根本原因是 coverage.py 默认只监控主进程，子进程独立运行且未自动加载覆盖率插桩逻辑；必须显式启用子进程支持、正确传递环境变量（如 COV_CORE_SOURCE）、并手动执行 coverage combine 合并数据。
pytest-cov 默认不追踪子进程执行路径
根本原因不是插件“坏了”，而是 coverage.py 的默认行为只监控主进程。当你用 multiprocessing、subprocess.Popen 或 celery 启动新 Python 进程时，这些子进程完全独立——没有自动加载 coverage 插桩逻辑，也不会把覆盖率数据回传给主进程。
现象很典型：主流程的函数全绿，但 if __name__ == "__main__": 里的逻辑、Process(target=...) 中的代码、甚至 fork 出来的 worker 都在报告里彻底消失，连文件名都不出现。
必须显式启用子进程支持并配置环境变量
pytest-cov 提供了子进程支持，但需要手动激活，且依赖环境变量传递配置。漏掉任意一环，子进程就“裸奔”：
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 安装时确保所有 worker 节点（包括 CI runner、远程机器）都装了
pytest-cov，不能只在本地装 - 运行命令必须加
--cov+--cov-fork（pytest-cov ≥ 4.0）或--cov-config指向含[run] parallel = true的.coveragerc - 子进程中必须能读取到
COV_CORE_SOURCE等环境变量——这意味着不能用shell=True启动 subprocess，否则环境被清空 - 如果用
multiprocessing.set_start_method("spawn")，需确认 spawn 后的进程仍能继承这些变量（Linux/macOS 通常可以，Windows 可能需额外os.environ.update(...)）
HTML 报告里看不到子进程文件？先检查 .coverage 文件是否合并
即使子进程成功采集了数据，pytest-cov 默认也不会自动合并。你看到的只是主进程的 .coverage 文件：
立即学习“Python免费学习笔记（深入）”；
- 运行后先执行
coverage combine，它会扫描当前目录下所有.coverage.*文件（子进程生成的）并合并 - 再跑
coverage report -m或coverage html，这时多进程文件才会出现在报告中 - 若用
--cov-append，注意它只追加不合并，仍需手动combine - CI 环境中常见问题：worker 分散在不同节点，
.coverage.*文件没上传到主节点，导致无法合并
分支覆盖 + 子进程 = 更容易漏掉 else 块
子进程本身常带条件逻辑（比如根据参数决定是否启动 worker），而 --branch 和子进程支持是两套独立开关。只开 --cov-branch 不等于子进程里的分支就被统计了：
- 必须同时满足：主进程启用了
--cov-branch，且子进程也通过环境变量继承了该配置（COV_CORE_BRANCH=1） - 验证方式：在子进程代码里硬编码一个
print(os.environ.get("COV_CORE_BRANCH"))，确认值为"1" - 常见坑：用
pytest-xdist时，每个 worker 是独立进程，但它们不是你业务里的“子进程”，无需额外配置；真正要管的是你代码里主动fork()或spawn()出来的那些
--cov-fork 就万事大吉，却没检查子进程是否真收到了 COV_CORE_SOURCE，也没做 coverage combine。 
