企业级conftest.py重构实战：从膨胀到分层治理-开发者社区

在接手过几个中型以上的测试团队项目之后，我越来越意识到一个规律：几乎所有测试工程腐烂的起点，都是同一个文件——conftest.py。用pytest写过几年测试的人应该都有这种体验，项目刚起步时，conftest.py只有几十行，放两个fixture就能跑通全部用例。半年后它开始悄悄膨胀，八个月后你发现它已经快两千行，里面什么都有：session级别的数据库连接、各类webdriver初始化、封装的请求客户端、各种hook函数、记录日志的装饰器、甚至还有从业务代码里拷来的工具函数。没人敢轻易动它，因为你根本不知道这个文件里某个看似多余的fixture到底被多少个测试用例依赖着。

这个文件一旦失控，整个测试工程的可维护性就开始断崖式下跌。这篇文章就以重构企业级conftest.py为切入点，把我在实际项目中梳理出来的一套完整重构思路、具体操作步骤和踩坑经验整理出来，希望能给同样被这个文件折磨的人一些参照。

1. 重构前先摸清家底：你的conftest.py病到什么程度了

1.1 企业级conftest.py的典型症状

我先说说什么样的conftest.py算“企业级”。字面意义有点唬人，其实就是测试用例数量上千、参与开发的人超过三五个、测试环境不止一套、对接的第三方服务好几个。这个规模下，conftest.py如果没有任何治理痕迹，几乎必然出现下面这些症状。

第一个症状是单一文件膨胀。我从一个真实项目里看到过一份conftest.py，2600多行，包含70多个fixture、十几个hook函数、5个辅助类。这个文件本身就很难浏览，编辑器打开都会卡。更麻烦的是，它里面的fixture名称大量重复，比如同一个模块的数据库连接，在session级别、module级别、function级别各定义了一份。出现这种情况的原因是不同开发者在不同阶段各写各的，谁也不知道别人已经定义过类似的东西，干脆再加一个，最后自然是灾难。

第二个症状是fixture的作用域滥用。我见过一种很典型的使用方式：为了省事，把几乎所有的fixture都定义成@pytest.fixture(scope="session")。session级别的fixture只在测试会话开始时执行一次，看起来效率很高，但代价是状态在用例之间被共享。一旦某个用例把数据库里的数据改了，后面几百个用例跑的就是“被污染”的状态。排查这种问题非常痛苦，因为你不确定是哪条用例先改了数据，只能靠二分法不断缩小范围，运维成本极高。

第三个症状是hook函数和工具函数的混入。有些项目会直接把pytest_collection_modifyitems排序逻辑、失败重试逻辑、Allure报告整理逻辑全部塞进conftest.py，再把生成随机字符串、解析配置文件、读取环境变量这些小工具也一起写下边。发这个文件的人出于好心，觉得“反正都是给测试用的，放在这里大家都能用”。可一旦连“去找某个工具函数都要搜索半天”的时候，这个文件就已经变成了一座没人理得清的地下仓库，每个人都在往里面扔东西，却没有人在做整理。

第四个症状是隐式依赖严重。autouse=True的fixture数量超过五六个以后，新来的同事基本只能靠翻代码来猜哪些用例被偷偷注入了什么。一旦想删掉某个autouse fixture，你没法通过搜索“这个fixture名在哪些用例里出现”来判断影响面，因为用例代码里可能压根没有引用它。这是重构时最棘手的一种技术债，因为它的连锁反应会扩散到整个测试套件，而不只是某一个文件。

1.2 体检的四个维度与判断标准

在动手重构之前，我建议先给现有conftest.py做一次“体检”，用数据来支撑后续的拆分决策，而不是凭感觉。

第一个维度是行数和“密度”。打开文件统计总行数，再看fixture平均行数。如果一个文件的80%内容都在定义fixture，其余20%塞了hook、常量、工具函数，基本可以确定需要拆分。我一般用两条硬性标准：超过800行的conftest.py就该启动重构评估；超过1500行必须重构。这条标准听起来很武断，但实际执行下来，几乎没有例外。

第二个维度是fixture依赖关系。逐个fixture记录它依赖了哪些其他fixture、被哪些fixture依赖、在哪些用例中被引用。可以用pytest自带的命令快速拉一个清单，我在实操部分会详细说，这里先提思路：pytest的fixture机制会形成一个有向无环图，你把这个图画出来，凡是出现在图中间位置、同时被非常多层fixture依赖的节点，就是最需要优先治理的对象。比如一个session级的db_engine被几十个fixture间接依赖，它就是所有依赖的源头，必须先把它抽出来。

第三个维度是作用域分布。把现有fixture按function/module/class/session统计个数。正常情况下，一个设计良好的测试工程里，function级别fixture应该占绝大多数，session级别应该只用来准备那些真正全局共享、且只读的资源——比如配置文件、全局唯一的外部服务连接。如果你的session级别fixture超过总数的两成，说明很多本应该独立化的状态被过早共享了。作用域选大，本质上是拿隔离性换性能，这在企业级项目里往往是得不偿失的。

第四个维度是复用情况。把名字相同的fixture、功能相似的fixture列出来，统计有多少测试模块自己又额外定义了完全重复的fixture。这种重复通常是在“不知道conftest.py里已经有现成的”这个前提下发生的。检查手段是靠代码检索工具，搜索所有测试文件里@pytest.fixture的定义，人工比对一轮。很多团队的重复率高达三成，这意味着重构后光是删除重复代码，就能让测试收集时间快一大截。

体检做完，你会得到一张Excel表或者一份文档，里面列着：现有fixture清单、每个fixture的实现行数、依赖方向、作用域、被引用范围。有了这份清单，接下来划分模块才有依据。没有这份清单就直接重构，本质上是在赌运气。

2. 重构方案选型：不是把大文件拆成小文件这么简单

2.1 为什么不能简单按行数切分

很多人一听到重构，第一反应就是把conftest.py从中间咔嚓一刀切成两个文件。这种做法的确能让每个文件的行数降下来，但如果没有解决依赖和边界问题，半年后每个子文件又会膨胀成新的“小conftest”。拆分不是目的，让每个模块的职责清晰、边界稳定、可独立维护才是目的。

我在早期的项目里也犯过这个错误。当时把conftest.py按“前半部分fixture、后半部分hook”一刀切，结果两个文件之间互相引用，然后必须靠pytest_plugins来来回回加载，最后因为加载顺序问题到处报错，折腾了一周。后来想明白了：切分文件的核心是按照“领域”而不是“行数”来切。fixture和它管理的外部资源要放在一起，不是把所有fixture放在一起。一个webdriver初始化的fixture就该和浏览器相关的一整套机制放在同一个模块，而不是和数据工厂fixture排排坐。

2.2 分层架构怎么设计

结合多个项目的重构经验，我建议采用“三层结构 + 领域模块”的组合方式。这套结构不是凭空想的，而是从后端框架的分层思想借鉴过来的，测试工程同样需要分层的概念。

第一层是全局层，对应测试目录最顶层的conftest.py。这层只放三类东西：pytest插件的注册、全局级别的hook函数、极少数真正全局共享且只读的session fixture（比如统一的临时目录策略、全局性的命令行参数注入）。你只要让这一层精简到不做任何具体业务，它就很难再腐化。每次有人想把新东西塞进顶层conftest.py时，都应该先问一句：这个东西是所有模块都要用的吗？如果不是，请下移到领域层。

第二层是领域层，对应每个业务模块目录下的conftest.py。这一层可以放该模块专用的fixture和hook，作用域以module为主，负责给这个模块的测试用例提供贴近业务场景的组件。比如订单模块的目录下存放订单状态构造的fixture，用户模块下存放登录态相关fixture。这样做的收益是不同业务域的测试代码互不干扰，订单模块改了自己的fixture，不会惊动用户模块的测试。

第三层是共享层，对应专门的fixtures包，里面再按具体领域细分，比如fixtures.db、fixtures.auth、fixtures.web、fixtures.data。这一层的模块通过pytest_plugins机制被全局层加载，供所有测试目录使用。凡是多个模块都会用到的东西，放在这一层，而不是放在某一个业务模块的conftest里。

这套结构的核心思想是：越通用的内容，层级越浅；越业务化的内容，越靠向具体模块。测试代码和业务代码一样，也需要依赖注入和分层边界，只是很多人写测试时没有这个意识，久而久之就形成了“一个大文件管所有事”的局面。

2.3 具体目录结构长什么样

我给出一个在实际项目中验证过的例子，大家可以根据自己的业务替换模块名。

tests/ ├── conftest.py ├── fixtures/ │ ├── __init__.py │ ├── config.py │ ├── db.py │ ├── auth.py │ ├── web.py │ └── data.py ├── hooks/ │ ├── __init__.py │ ├── report.py │ └── retry.py ├── test_order/ │ ├── conftest.py │ ├── test_create.py │ └── test_query.py └── test_user/ ├── conftest.py ├── test_login.py └── test_profile.py

注意这个结构里我把hooks单独放了一级。有读者可能会问，hook函数为什么不能放在fixtures包顶层？因为hook函数是在pytest框架生命周期里运行的钩子，作用在“测试收集、执行、报告”这些环节，和fixture这种“为用例提供依赖”的能力是两回事。放到一起还是职责混淆。hooks目录里每个文件聚焦一种运行行为，report负责报告整理，retry负责失败重试，需要在不同阶段接管的pytest事件，各管各的，互不越界。

顶层的conftest.py在我的方案里只负责两件事：注册pytest_plugins、继承那些必须全局生效的hook。它不再直接定义任何业务fixture。我实际测下来的效果是，顶层conftest.py通常不超过60行，非常清爽。

# tests/conftest.py import pytest pytest_plugins = [ "fixtures.config", "fixtures.db", "fixtures.auth", "fixtures.web", "fixtures.data", "hooks.report", "hooks.retry", ] @pytest.hookimpl(tryfirst=True) def pytest_configure(config): """全局配置入口，只在配置阶段执行一次。""" ...

顺带提醒一句，pytest_plugins里的路径是模块路径，不是文件路径，且这套配置强烈建议放在测试根目录顶层的conftest.py里。放在子目录的conftest.py中时，pytest的模块加载机制容易引发ImportError，这是官方文档里明确标注过的坑，我在下文排查部分再展开。

3. 实操：企业级conftest.py的完整重构演练

3.1 盘点与分类：先给fixture做台账

现在开始动手。第一步是在重构前把现有内容全部盘点清楚，我会用一个具体例子带着大家走一遍流程。

假设你的项目现在有一个tests/conftest.py，1200行。先用一段脚本把所有fixture清点出来，不需要太复杂，正则匹配@pytest.fixture和def中间的名字就行：

import ast from pathlib import Path source = Path("tests/conftest.py").read_text(encoding="utf-8") tree = ast.parse(source) for node in tree.body: if isinstance(node, (ast.FunctionDef, ast.AsyncFunctionDef)): decorators = [d.id if isinstance(d, ast.Name) else "" for d in node.decorator_list] if "fixture" in decorators: scope = "" for dec in node.decorator_list: if isinstance(dec, ast.Call) and isinstance(dec.func, ast.Attribute): for kw in dec.keywords: if kw.arg == "scope": scope = kw.value.value print(f"{node.name}\tscope={scope}\tline={node.lineno}")

这段脚本只是抛砖引玉，实际项目里你可能还要统计每个fixture的函数体行数、依赖的fixture名称（通过解析函数参数）。整理完之后，把这些fixture按用途分成几类：

环境配置类：读取环境变量、加载配置文件、临时目录、全局的ini参数。
外部服务类：数据库连接、Redis连接、MQ、第三方API客户端、浏览器实例。
状态构造类：造数据、构造订单、创建用户、生成token、打桩返回mock数据。
报告与运行类：接管pytest hook，比如失败重试、展示优化、性能埋点。

这个分类其实就是后续目录结构的雏形。大方向是：环境配置类进fixtures/config.py，外部服务类按服务拆分，状态构造类按业务模块分组，报告与运行类进hooks/。

3.2 拆分动作一：按领域模块迁移fixture

分类完成之后就开始真正动手。我强烈建议按“每迁一个fixture，就全量跑一遍相关用例”的节奏推进，不要一次性把1200行全搬完再跑测试。一次性大迁移的问题是，出错之后你根本不知道是哪个fixture导致的，排查范围太大会让人直接心态爆炸。

以数据库fixture为例。原来的代码大概是这样的：

# 重构前（在tests/conftest.py中） import pytest from db import get_engine, create_session @pytest.fixture(scope="session") def db_engine(): engine = get_engine() yield engine engine.dispose() @pytest.fixture() def db_session(db_engine): session = create_session(db_engine) yield session session.close()

迁移到tests/fixtures/db.py之后，代码几乎可以原样保留，唯一要注意的是：如果这个模块里还要定义其他fixture，这些fixture的依赖关系必须在本模块内清晰可见。也就是说，db_session依赖db_engine，两者都在同一个模块里，这个模块自洽，别人阅读这个文件就能把完整的依赖链看明白。

# tests/fixtures/db.py import pytest from db import get_engine, create_session @pytest.fixture(scope="session") def db_engine(): engine = get_engine() yield engine engine.dispose() @pytest.fixture() def db_session(db_engine): session = create_session(db_engine) yield session session.close()

然后顶层conftest.py里注册"fixtures.db"即可。

这里有个细节值得强调：迁移fixture时，要连同它依赖的所有外部资源接口一起考虑。比如db_engine读取的是DATABASE_URL环境变量，那这个读取动作是留在fixture内部，还是放到一个专门的config模块里？我倾向放到fixtures/config.py里定义一个app_configfixture，再把配置值传给db_engine。这样做的原因是config模块可以作为叶子节点被所有其他模块依赖，形成单向依赖链，不会出现循环依赖。

# tests/fixtures/config.py import os import pytest @pytest.fixture(scope="session") def app_config(): return { "database_url": os.getenv("DATABASE_URL", "postgresql://localhost/testdb"), "api_base_url": os.getenv("API_BASE_URL", "http://localhost:8080"), "timeout": int(os.getenv("HTTP_TIMEOUT", "30")), }

# tests/fixtures/db.py 改造成这样 @pytest.fixture(scope="session") def db_engine(app_config): engine = get_engine(app_config["database_url"]) yield engine engine.dispose()

依赖关系变得显式，哪个fixture需要什么配置一目了然。以后新增fixture时，也只需要问自己：这个东西依赖的配置从哪里来？把这条线的数据流理清楚，conftest.py就很难再变成一锅粥。

3.3 拆分动作二：hook函数独立管理

hook函数是企业级conftest.py里容易被忽视的另一大块。我将它们单独规划到hooks/目录，每个hook文件按职责组合，不要一个文件放所有hook。这样做的原因很简单：hook函数操作的往往是pytest内部对象（item、config、call），并且对执行顺序敏感，把它们混在一起会导致排错时根本分不清是谁改了谁。

举个例子，如果测试团队需要统计失败用例并自动重试一次，可以封装到hooks/retry.py：

# tests/hooks/retry.py import pytest @pytest.hookimpl(tryfirst=True) def pytest_runtest_makereport(item, call): """在用例执行结束后，判断是否需要重试。""" if call.when != "call": return if call.excinfo is not None and not hasattr(item, "retried"): item.retried = True # 这里预留重试逻辑，由外部runner统一调度

再比如报告优化类hook，比如给每个测试用例自动打上模块名称的标签：

# tests/hooks/report.py import pytest @pytest.hookimpl(tryfirst=True) def pytest_collection_modifyitems(config, items): """给收集到的每个用例自动添加所属模块的mark。""" for item in items: module_name = item.module.__name__.split(".")[-1] item.add_marker(getattr(pytest.mark, module_name))

这些hook之所以要独立成模块，是因为它们往往依赖pytest内部状态而且执行顺序敏感。和fixture混在一起，会让阅读的人分不清“这个函数到底是普通工具还是pytest扩展点”。独立以后，每个文件的顶部就能说明它的用途，排错时也容易定位。比如pytest运行行为变得诡异，就直接去hooks目录下对应的文件里看，而不是在一个两千行的文件里反复搜索。

有一点要特别注意：hook函数在不同模块里定义时，如果都设置了tryfirst=True或trylast=True，执行的先后顺序会影响结果。遇到这类依赖顺序的hook，建议在顶层conftest.py里统一显式调度，或者干脆把顺序敏感的hook都放进同一个模块，从上到下按顺序定义，不要拆开。顺序这种东西，跨文件管理几乎注定要出问题。

3.4 拆分动作三：配置与静态资源外移

除fixture和hook之外，conftest.py里还经常躺着两类东西：静态常量和资源路径。比如各种超时时间、账号密码、URL前缀、模板路径，这些其实都不该出现在测试代码里，更不该散落在conftest.py的各处。

重构时，我会把这类内容分三种方式处理：

与pytest运行参数有关的配置，写进pytest.ini或pyproject.toml的[tool.pytest.ini_options]下。
与运行环境有关的变量，统一从环境变量读取，集中到一个config模块里管理。
与业务相关的常量（比如默认订单金额、默认用户名），放到对应的领域模块目录下的constants.py，而不是塞给全局conftest。

举例说明：

# pytest.ini [pytest] markers = smoke: 冒烟用例 slow: 慢速用例 order: 订单模块用例 addopts = -ra -q --strict-markers

这些标签和命令行参数移出去之后，conftest.py彻底和“运行策略”解耦。如果后续要接CI流水线，CI只需要修改ini文件里的参数，或者通过命令行覆盖，不需要去碰测试代码。这是一个非常容易被忽略的收益点，很多项目直到接CI那天才发现，conftest.py里的配置写得太死，容器里一跑就各种水土不服。

静态资源路径的迁移也同理。原来conftest.py里可能有个DATA_DIR = Path(__file__).parent / "data"的常量，它应该被放到一个专门的config模块中：

# tests/fixtures/config.py（补充路径部分） from pathlib import Path PROJECT_ROOT = Path(__file__).resolve().parents[2] TEST_DATA_DIR = PROJECT_ROOT / "tests" / "data"

这样所有需要读测试数据的fixture，统一从这个模块取路径。重构之后，数据的目录结构变化，只需要改一个地方，而不是全局搜索替换两三种写法不同的路径拼接。

3.5 重构完成后的验证清单

拆分动作全部做完以后，我一般会走一遍验证清单，逐项确认没有遗漏：

顶层conftest.py行数是否已经压到可维护范围，我建议控制在100行以内。
每一个领域fixture模块是否自洽：模块内的fixture依赖关系清晰，跨模块依赖只有config层或公共服务层。
pytest --fixtures输出的fixture列表是否整洁：名称无重复、无大量语义相近的名字。
全量测试通过率是否和重构前一致：如果重构前有失败用例，重构后失败用例集合应该一致，不能凭空多出一批新失败。
随机抽几个用例，手动验证会话级fixture的清理动作是否生效，比如数据库连接确实被dispose了，浏览器确实被关闭了。
用pytest --collect-only -q确认测试收集没有遗漏或重复。

我习惯在验证阶段顺手生成一份fixture清单快照，存到docs里，方便团队后续审查。以后任何人再往conftest.py里加fixture，先对照快照看是否与已有fixture重复。这个动作虽然简单，但对保持重构成果的作用相当明显。

4. 重构过程中的常见问题与排查技巧

4.1 fixture找不到或加载顺序异常

fixtures.*模块注册了，但运行测试时提示fixture 'xxx' not found，这是拆分后最常见的报错。我排查时按这个顺序走。

先确认模块路径是否正确。pytest_plugins里写的是“模块导入路径”，不是目录路径。假如tests/fixtures/db.py文件的包名叫fixtures.db，并且tests/fixtures/目录下有__init__.py，这个导入才是合法的。如果没有__init__.py，pytest的导入机制虽然在某些版本下也能工作，但强烈建议补上，否则后续越发越乱。

然后确认顶层conftest.py里的pytest_plugins列表是否被覆盖。有个很隐蔽的坑：如果在conftest.py里把pytest_plugins放在某个函数内部赋值，或者用变量名覆盖了它，pytest根本不会读取。它必须是一个模块级别的名字，且直接出现在conftest.py的顶层作用域。

如果确认了路径没问题，那就是加载顺序问题。pytest_plugins在列表中的顺序虽然大体决定了加载顺序，但并不是绝对可靠的保障。当模块A的fixture依赖模块B的fixture，而B又依赖A时，就形成了循环导入。解决办法是打破循环，把公共依赖抽到更底层，比如都依赖config模块。循环依赖是设计问题，靠调顺序解决不了，只能从依赖图结构上动手。

4.2 作用域膨胀导致测试串联

这是重构后最容易暴露的存量问题。session级fixture太多的时候，用例之间“隐形串数据”特别严重。最常见的是数据库session：两个用例先后修改了同一行记录，第二个用例断言失败，可单独跑第二个用例又是通过的。出现这种“单独跑过、一起跑挂”的情况，十有八九就是session级别共享状态在作祟。

重构时遇到这类问题，我的处理手法是：把绝大多数数据库相关的fixture降级到function级，session级只保留连接池或engine。真正的CRUD操作session，每次用例新建，用完即关。这样做的缺点是性能会略下降，但换来的是隔离性。如果要兼顾性能，可以在fixture里做“事务回滚”策略：用例开始时开启事务，结束后回滚，不真正commit。

# tests/fixtures/db.py import pytest @pytest.fixture() def db_session(db_engine): """每个用例独立事务，结束后回滚，避免数据污染。""" session = create_session(db_engine) session.begin() yield session session.rollback() session.close()

这个方案在单元测试和接口测试中都很实用。这里要注意：如果代码内部自行commit了事务，回滚就失效了，需要配合嵌套事务或者让代码支持事务回调，否则只能老老实实清理数据。遇到回滚失效时，不要怀疑方案本身，先检查业务代码里是不是把commit写死在了底层方法中。

4.3 隐式依赖：autouse滥用

重构过程中我问得最多的一个问题：“这个autouse的fixture到底对哪些用例生效？”答案往往是没人说得清。我遇到过一个团队，conftest.py里autouse的fixture有7个，分别做了：设置locale、设置环境变量、创建临时目录、mock时间、mock了远程调用、修改了log级别、还预先加载了大批测试数据。结果就是每个用例跑起来都很慢，但谁都不敢动，因为不知道删掉哪个会影响什么。

我的建议是：autouse只适用于那些“所有用例都无条件需要、且没有副作用”的全局准备动作。比如设置一个全局性的环境变量，确保每个用例都跑在测试环境，这就是合理的autouse。而mock远程调用、加载数据这类有业务语义的fixture，应当显式地在用例参数里声明依赖，让代码可读性更强。

如果在重构时必须保留某个autouse fixture，我建议在pytest_collection_modifyitems的hook里输出一份日志，打印每个用例被哪些autouse fixture注入了，至少在排查时有线索。手动搜索源码根本找不到引用关系，因为你搜“tmp_path”会搜出一堆结果，但你根本没法判断哪个用例是隐式依赖的，哪个是显式声明的。

4.4 多环境配置管理

企业级测试还有一个绕不开的问题：dev、staging、test多套环境。很多团队把所有环境的地址写成常量放在conftest.py顶部，每次手工改。重构之后，这部分被集中到config模块，配合TEST_ENV变量切换。

我常用的做法是用os.getenv加默认值，同时加白名单校验：

# tests/fixtures/config.py import os ALLOWED_ENVS = {"dev", "staging", "test"} @pytest.fixture(scope="session") def app_config(): env = os.getenv("TEST_ENV", "dev") if env not in ALLOWED_ENVS: raise ValueError(f"未知环境: {env}") return { "env": env, "database_url": os.getenv(f"DATABASE_URL_{env.upper()}", "postgresql://localhost/testdb"), "api_base_url": os.getenv(f"API_BASE_URL_{env.upper()}", "http://localhost:8080"), }

环境切换的入口收敛到一处，CI里只需要注入TEST_ENV变量。这比在conftest.py里散落几十个地址常量要稳得多。还有一个附带的好处：写文档的时候只需要说明一组环境变量的命名规则，而不是把每个环境的地址列成一个超长表格。

4.5 回归风险控制

最后聊一下重构期间的回归风险。我的经验是所有前提中最重要的就是“小步走”。每次只迁一个fixture或者一个hook模块，迁移完立刻跑这一模块相关的用例，通过后再继续。不要试图用一整个周末把全量重构完，周一直接提交一个大PR——出了问题光review就要一天，情绪成本太高。

另外，重构前给tests目录做一个git分支，跑一遍全量测试并记录失败清单。重构完成后对照这份清单，确保新引入的失败用例为零。这个动作看起来简单，但很多团队懒得做，最后重构完上线发现一堆回归，反而对“重构”这件事产生不信任。实际上，大部分回归问题都是可以在小步迁移的过程中提前暴露的，只是大家习惯性跳过了这一步。

提示：如果团队没有统一格式化工具，先统一引入flake8/ruff/black再进行重构。混着不同风格挪代码，后续diff查看会非常痛苦，review的时候注意力都会被格式乱七八糟带跑。

5. 写在最后：重构之后怎么防止它再次腐烂

到这里，重构流程已经完整走过一遍。我想再分享一个实务层面的体会：conftest.py之所以容易烂，不是因为写代码的人水平差，而是因为它天然就处在一个“极端方便”的位置——任何东西放进去都能被所有测试立刻使用，这种即时满足感会让大家无意识地在里面堆垃圾。重构的作用是给这个文件立规矩，但规矩立完还要有人维护。

从个人经验来说，重构完成后最有效的一个制度是“fixture新增提案制”。虽然听起来有点形式主义，但至少要让团队约定：新增fixture先看docs/fixtures.md清单，确认没有现成的，再决定是加到领域模块还是共享层。我还会在CI里加一个轻量检查，如果顶层conftest.py行数超过150行，直接让流水线亮黄牌警告。限制文件行数说白了很机械，但对抑制膨胀确实立竿见影，因为一旦超过阈值，就会有人去问“这东西为什么在这里”。

最后再分享一个操作性很强的小技巧：重构后建议至少用一整周持续观察pytest的收集时间和单条用例耗时。你很快会发现，某些“看起来做了一次、实际上根本没被用到”的session级fixture被删除后，收集时间会明显缩短。如果发现重构后收集时间反而变长了，优先检查是不是pytest_plugins列表里加载了过多不必要的模块，精简掉那些只在少数用例中使用的共享模块，改用业务模块目录下的局部conftest.py加载。