接口测试时序问题需按依赖顺序执行用例，用pytest-ordering插件标记序号；异步场景加轮询或回调；状态隔离靠setup/teardown和唯一临时资源；并发下需进程级资源隔离与合理--dist策略。
直接加 pytest -n auto 能跑，但大概率不是最快、最稳的；真正提速的关键不在开了几个进程，而在每个测试是否真的互不干扰。
为什么加了 -n 反而变慢或随机失败
常见现象是单测全过，pytest -n 2 后偶尔失败，或者卡在 Waiting for workers；报错信息包括 sqlite3.OperationalError: database is locked、PermissionError: [WinError 32]、断言值飘移等。
根本原因：多个 worker 进程同时操作同一份资源。比如：
- 多个 test 都写
open('cache.json', 'w') - 共用一个 SQLite 文件路径：
sqlite:///test.db - HTTPServer 绑定固定端口：
HTTPServer(('', 8000), handler) -
@pytest.fixture(scope='session')初始化了全局字典或数据库连接——每个 worker 都会独立执行一次，不是共享
怎么让 fixture 和临时资源真正隔离
不能依赖 tmpdir 或硬编码路径，必须显式构造进程级唯一实例。
立即学习“Python免费学习笔记（深入）”；
正确做法示例（SQLite）：
import tempfile
import sqlite3
import pytest
@pytest.fixture(scope="session")
def temp_db(request):
worker_id = request.config.workerinput["workerid"]
db_path = tempfile.mktemp(suffix=f"_{worker_id}.db")
conn = sqlite3.connect(db_path)
conn.execute("CREATE TABLE IF NOT EXISTS logs (msg TEXT)")
yield conn
conn.close()
关键点：
- 用
request.config.workerinput["workerid"]获取唯一标识（如'gw0'） - 所有临时文件、DB 路径、端口、缓存目录都带该 ID 后缀
- 优先用
tmp_path（pathlib.Path类型），它天然支持多进程隔离 - 避免在
conftest.py的session或packagescope 中做非幂等操作（如改os.environ、写配置文件）
--dist 参数到底该选 load、loadfile 还是 loadscope
默认 --dist=load 按单个 test_* 函数分发，粒度最细，但也最容易撞状态。
按场景换策略：
- 测试文件之间完全独立（如
test_api.py和test_utils.py）→ 用--dist=loadfile - 同一个 class 里多个 test 共享 setup/teardown 或内部状态 → 用
--dist=loadscope - 想确保某组标记的测试（如
@pytest.mark.slow）不被拆开 → 用--dist=loadgroup+@pytest.mark.xdist_group(name="slow")
特别注意：--dist=load 在含长耗时用例的文件里会导致负载严重不均——比如一个 test_heavy.py 有 180 个慢用例，它会被整个塞给一个 worker。
-n 数值设多少才合理
-n auto 是个幻觉：它调用 os.cpu_count()，但在笔记本上开满核常因磁盘/内存争抢反而更慢；CI 环境里更危险（GitHub Actions 默认只暴露 2 核，os.cpu_count() 却可能返回 4）。
实操建议：
- I/O 密集型测试（HTTP、DB 查询、文件读写）→ 从
-n 2开始试，上限建议 ≤ CPU 物理核心数 - CPU 密集型测试（算法校验、数据转换）→ 可尝试
-n $(($(nproc) / 2))或-n 4 - CI 上别信
-n auto，显式写-n 2更稳 - 加
--max-worker-restart=2防止单点崩溃拖垮整轮测试
真正容易被忽略的是：并行收益有明确边界——I/O 密集型测试提升有限，甚至因连接池争抢变慢；而 fixture 是否可序列化、临时路径是否隔离、worker ID 是否参与资源命名，这些细节比核数选择更决定成败。
