scope="session" 的 fixture 无法安全清理分布式资源，因其生命周期覆盖整个测试会话，而分布式资源（如 Kafka topic、Redis namespace）需按模块或函数级隔离命名并独占清理，否则并发时会发生命名冲突、误删或清理失败；正确做法是结合 tmp_path_factory 生成哈希后缀、addfinalizer 保证异常清理、加锁防重复删除，并避免共享资源。
pytest.fixture 的 scope="session" 为什么不能直接清理分布式资源
因为 session 级 fixture 在整个测试会话生命周期内只初始化和销毁一次，而分布式系统里的资源（比如临时 Kafka topic、Redis namespace、MinIO bucket）往往需要按测试模块甚至测试函数隔离——否则并发执行时互相污染，清理失败或误删他人数据。
常见错误现象：pytest 运行时报 TopicAlreadyExistsError 或 KeyError，但单测通过、集成测试失败；或者清理逻辑在 teardown 阶段抛出 ConnectionRefusedError，因为服务已提前关闭。
- 用
scope="session"+ 全局变量管理资源名 → 并发下命名冲突 - 在
yield后写清理代码 → 若测试中途崩溃，finally不执行 - 依赖
atexit注册清理 → pytest 子进程里不触发
用 pytest 的 tmp_path_factory 和自定义 fixture 做命名隔离
核心思路：把每个测试模块的资源命名绑定到唯一路径哈希，既避免冲突，又支持并行执行。不用硬编码前缀，也不依赖时间戳（太慢且可能重复）。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 在
conftest.py中定义 fixture，接收request对象获取测试节点 ID - 用
tmp_path_factory.mktemp("dist-")生成临时目录，并取其路径哈希作为资源标识（如hashlib.md5(str(tmpdir).encode()).hexdigest()[:8]） - 所有外部资源（Kafka topic、S3 bucket）都带上该标识，例如
f"test-topic-{suffix}" - 清理逻辑放在
addfinalizer而非yield，确保即使异常也执行
示例片段：
def dist_resource_suffix(request, tmp_path_factory):
tmpdir = tmp_path_factory.mktemp("dist")
suffix = hashlib.md5(str(tmpdir).encode()).hexdigest()[:8]
request.addfinalizer(lambda: cleanup_dist_resources(suffix))
return suffix
清理失败时如何避免阻塞后续测试
分布式服务不稳定是常态，清理阶段网络超时或服务不可达会导致整个 pytest 会话卡住或报错退出。不能让清理失败影响测试结果判定。
关键处理点：
- 所有清理操作必须带超时（如
requests.delete(..., timeout=5)）和宽泛异常捕获（except (requests.RequestException, ConnectionError, TimeoutError)） - 日志级别设为
warning，不 raise 异常；清理失败不中断测试流程 - 可选：将失败清理任务写入本地
.cleanup-failed.json，供 CI 后置脚本重试
注意：不要用 os.system("kubectl delete ...") 这类阻塞调用，改用异步 HTTP client 或带 subprocess.run(..., timeout=10)。
pytest-xdist 并行下如何协调跨节点资源清理
当用 -n auto 启动多 worker 时，每个 worker 是独立 Python 进程，addfinalizer 只在当前进程生效。如果多个测试共用一套底层服务（比如共享一个本地部署的 ZooKeeper），就得防重复清理。
推荐做法：
- 用文件锁（
threading.Lock不跨进程，改用portalocker或fasteners.InterProcessLock）保护清理入口 - 清理前检查资源是否存在（如
if topic_exists(topic_name): delete_topic(topic_name)），而不是无脑删 - 避免“谁最后跑谁清理”的逻辑——改用中心化标记，比如在 Redis 里存
cleanup:topic:test-topic-abc123的 TTL key，由第一个发现该 key 不存在的 worker 执行清理
真正麻烦的不是怎么删，而是删完之后别人还在用——所以清理时机比清理动作更重要。多数情况下，应该让每个测试自己负责创建+销毁独占资源，而非共享+协调销毁。
