pytest_xdist 并行策略探索：
--dist=load 策略:
1. 分组单位: 无固定分组
2. 分配规则: 动态分配给空闲worker
3. 执行规则: 完全并行，无顺序保证
--dist=loadscope 策略:
1. 分组单位: 测试类 (class) 或模块 (module)
2. 分配规则: 同一个类/模块的测试分配给同一个worker
3. 执行规则: 类内/模块内测试串行，不同类/模块可并行
--dist=loadfile 策略:
1. 调度单位: 文件 (file)
2. 分配规则: 每个文件分配给一个worker
3. 执行规则: 文件内测试串行执行
如果文件夹有多个文件 → 可能分配到不同worker → 文件夹内并行
如果文件夹只有一个文件 → 只在一个worker → 文件夹内串行
--dist=loadfile 是按文件分组，不是按文件夹分组。这意味着：inbound/test_1.py可能在一个workerinbound/test_2.py可能在另一个worker- 结果是：同一个文件夹的不同文件会并行执行
--dist=loadgroup 是按标记分组，不是按文件夹分组。测试都只标记了 @pytest.mark.ui，它们都属于同一个分组（ui组），所以被分配到不同的worker并行执行
--dist=loadgroup 是按标记分组，不是按文件夹分组。虽然你的测试有 @pytest.mark.inbound 标记，但：
loadgroup的分组逻辑：
相同标记的测试分到同一个worker
但这里的关键是：所有 @pytest.mark.ui1 的测试都属于同一个分组！
因为你的过滤条件是："ui1 and (inbound or monitor or dataservice)"
实际分组情况：
所有满足 ui1 条件的测试先被选中
所以以上pytest_xdist插件提供的并行策略不满足我们的需求，我们希望文件夹之间并行，文件夹内串行：
pytest-xdist 设计不是为了严格的"文件夹内串行"，而是为了最大化并行效率。我们的需求：
文件夹之间并行，文件夹内串行. inbound/dataservice/monitor 是并行的，test1/test2串行+testcases是串行执行
inbound/
└── test_1.py
└── test_2.py
dataservice/
└── test_1.py
└── test_2.py
monitor/
└── test_1.py
└── test_2.py
并行方案探索
方案1：使用--dist=loadfile + 单文件文件夹
text
项目结构调整：
inbound/
└── test_all_inbound.py # 所有inbound测试放一个文件
dataservice/
└── test_all_dataservice.py
monitor/
└── test_all_monitor.py
执行：
pytest -n=3 --dist=loadfile -m "ui1"
优点：
- loadfile保证文件内串行
- 每个文件夹一个文件 = 文件夹内串行
方案2：使用--dist=loadgroup + 每个testcase都有分组标签（测试下来不符合要求）
--dist=loadgroup理论上是loadgroup + 标签的，依赖标签，要是忘记添加标签，执行的策略就不是期望的了。但是测下来，这个分组并行策略还是不对
--dist=loadgroup 策略的最大问题！问题的核心：
--dist=loadgroup 策略完全依赖标记，存在以下风险：- 风险1：忘记添加分组标记
这个测试忘记加 group_inbound 标记
@pytest.mark.ui1 # 缺少 @pytest.mark.group_inbound
def test_forgot_mark():pass
结果：这个测试不会被分配到
group_inbound 组，可能：- 被分配到其他worker并行执行
- 或者根本不执行（如果过滤表达式严格）
- 风险2：标记拼写错误
@pytest.mark.group_indbound # 拼写错误：应该是 inbounddef test_typo():pass
结果：标记无效，分组失败
- 风险3：标记不一致
同一个文件内标记不一致
@pytest.mark.group_inbound
def test_a(): pass # 正确
@pytest.mark.group_inboundd # 多了一个d
def test_b(): pass # 错误
def test_c(): pass # 没有标记
结果：同一个文件夹的测试被分配到不同worker，文件夹内并行
方案3：受方案二的启发，tag filter自动分组
Pytest xdist各种策略的依赖风险对比
| 策略 | 依赖条件 | 忘记添加的后果 | 可靠性 |
| --dist=loadgroup | 必须有正确分组标记 | 分组失败，执行策略不符合预期 | 低 |
| --dist=loadfile | 按文件分组 | 自动按文件分组，无需标记 | 高 |
| --dist=loadscope | 按类/模块分组 | 自动按代码结构分组 | 高 |
| --dist=load | 无依赖 | 完全动态分配 | 高 |
| 每个文件夹独立进程 | 无依赖 | 100%符合预期 | 最高 |
每个文件夹独立执行分析：
使用多线程或者多进程，让每个文件夹独立执行。
线程进程核心区别
| 特性 | 进程 (Process) | 线程 (Thread) |
| 基本定义 | 程序的一次执行实例 | 进程中的一个执行单元 |
| 资源占用 | ⚡ 高：独立内存空间、资源 | ⚡ 低：共享进程资源 |
| 创建开销 | 🐌 大（需要分配独立资源） | 🚀 小（复用进程资源） |
| 独立性 | ✅ 强：相互隔离，一个崩溃不影响其他 | ❌ 弱：共享内存，一个崩溃可能影响整个进程 |
| 通信方式 | 📤 复杂：管道、消息队列、共享内存等 | 📤 简单：直接读写共享内存 |
| 切换开销 | 🐢 大（需要切换上下文） | 🐇 小 |
| Python GIL | ✅ 不受影响（每个进程独立GIL） | ❌ 受影响（同一进程内线程竞争GIL） |
所以为了之间不受影响，选择多进程的方式实现并发。那多进程又有手动和自动的
| 特性 | multiprocessing.Process | ProcessPoolExecutor |
| 创建方式 | 手动逐个创建和管理 | 自动化的进程池 |
| 资源管理 | 手动控制 | 自动复用和回收 |
| 错误处理 | 需要手动处理异常 | 内置异常捕获和传播 |
| 返回结果 | 需要队列或管道手动传递 | 通过Future对象自动返回 |
| 代码复杂度 | 较高（需要更多管理代码） | 较低（更简洁） |
| 适用场景 | 需要精细控制进程生命周期 | 批量任务处理，简单并行 |
选择 ProcessPoolExecutor 如果：
- 任务相似（都是执行pytest）
- 需要简单的结果收集
- 想要自动的进程池管理
- 需要限制最大并发数
选择 multiprocessing.Process 如果：
- 需要精细控制每个进程
- 进程有不同的配置或行为
- 需要复杂的进程间通信
- 需要按特定顺序启动或停止
自动化巡检的项目更适合线程池的方式。现在已经实现了（但linux上卡死，window可以），
目前问题：
本地执行正常， D:\automation\auto-test-icc2-fordz\tests\pytestcases\online_check\parallel_executor.py --env-config test1 --tag-filter "ui" --reruns 0 --parallel 我windows执行的很好，linux上执行总是再某个地方hung住，一直不动好几个小时了。
分析可能hung的原因（还在改，之前用的
multiprocessing.Process也是这个问题，需要继续看）：- 子进程输出处理问题
在Linux上，标准输出的缓冲机制与Windows不同
- 文件路径问题
Windows使用反斜杠
\，Linux使用正斜杠/- 环境变量设置
Linux环境变量可能需要不同的设置方式
- Linux上subprocess管道死锁是常见问题，通常是由于输出缓冲区填满导致的。使用
subprocess.run配合capture_output=True是最安全的做法 - 线程死锁风险
输出读取线程可能被阻塞：# read_output函数中for line in iter(pipe.readline, ''): # 如果pipe没关闭，这里会一直阻塞
- 资源清理问题
进程可能没有被正确终止。
- 进程超时处理不完善
可能的其他方案：
或者用
pytest-split 插件使用
pytest-test-groups 插件