Playwright 官方推荐的 Fixture 模式，为什么大厂架构师却在偷偷弃用？

01. 引言：被"神化"的 Fixture

在自动化测试圈，Playwright 的出现几乎是降维打击。而其官方文档最引以为傲的特性，莫过于 Fixtures（固件）。

官方告诉我们："忘掉那些手动初始化 Page Object 的繁琐代码吧，把它交给 Fixture，你会得到最优雅的依赖注入。"

初看确实如此。但当你进入腾讯、阿里或字节跳动等大厂的复杂业务线，面对 1000+ 页面对象、5000+ 测试用例 的超大型项目时，你会发现，当初觉得"优雅"的 Fixture，正在悄悄变成项目的"维护噩梦"。

为什么很多架构师在后期选择了回归"懒加载（Lazy Approach）"？这篇文章带你拆解其中的工程化真相。

02. Fixture 模式：优雅的代价是"黑盒"

首先，我们必须承认 Fixture 的强大。它本质上是一种依赖注入（Dependency Injection）。

TypeScript 复制代码

// 官方推崇的模式：声明式注入
export const test = base.extend({
  userPage: async ({ page }, use) => {
    await use(new UserPage(page));
  },
  orderPage: async ({ page }, use) => {
    await use(new OrderPage(page));
  },
});

// 在用例中使用：看起来非常干净
test('下单流程', async ({ userPage, orderPage }) => {
  await userPage.login();
  await orderPage.create();
});

为什么它受宠？

代码脱水 ：测试脚本里没有一句多余的 new。
生命周期自动闭环 ：Fixture 可以在 use() 之后自动执行清理逻辑。

为什么大厂架构师开始皱眉？

当项目规模爆炸时，Fixture 会带来 "注册表膨胀"。

难以追踪的来源 ：当你解构出 10 个 Fixture 时，你想跳转到某个 Page Object 的定义，IDE 有时会迷失在复杂的 extend 链条中。
强制性的初始化逻辑：即便 Playwright 声明是按需加载，但在大型工程中，Fixture 之间的层层嵌套依赖，常会导致为了用一个 A，被迫触发了 B 和 C 的 Setup，增加了不必要的隐性复杂度。

03. 懒加载模式：回归"显式"的力量

懒加载（Lazy Approach）主张：只有在用到 Page Object 的那一刻，才去实例化它。

TypeScript 复制代码

// 架构师偏爱的模式：显式实例化
test('下单流程', async ({ page }) => {
  const userPage = new UserPage(page);
  await userPage.login();

  // 只有登录成功，才加载订单页
  const orderPage = new OrderPage(page);
  await orderPage.create();
});

为什么它在大型项目中更稳健？

完美的类型推导 ：new UserPage(page) 是标准的 TypeScript 行为，IDE 的跳转、重构、属性提示永远是秒回，不会因为复杂的类型注入而"卡死"。
零副作用 ：没有隐藏的 extend，没有复杂的配置文件。每个用例用到了什么、初始化了什么，一目了然。
条件分支友好 ：如果你的测试逻辑中有一个 if (discountAvailable)，懒加载可以让你只在条件成立时才初始化"优惠券页面"对象，节省内存和潜在的初始化耗时。

04. 深度对比：工程化视角的博弈

维度	Fixture (依赖注入)	Lazy Approach (显式初始化)
可读性	极高（脚本像自然语言）	中（可见初始化代码）
可维护性	随规模增长迅速下降	随规模增长保持线性
IDE 支持	偶尔失效，跳转复杂	完美支持，原生体验
依赖关系	隐式（在配置文件里）	显式（在测试用例里）
上手门槛	需要理解 Playwright 注入机制	只要会写 PO 类即可

05. 进阶方案：架构师的"秘密武器" ------ Container 模式

如果既想要 Fixture 的简洁，又想要懒加载的稳健，大厂架构师通常会封装一个 Page 容器 或 App 对象。

代码实现：

TypeScript 复制代码

// 这是一个"页面工厂"容器
export class App {
  constructor(private readonly page: Page) {}

  // 使用 Getter 实现真正的懒加载
  get loginPage() { return new LoginPage(this.page); }
  get cartPage() { return new CartPage(this.page); }
  get paymentPage() { return new PaymentPage(this.page); }
}

// 在 Fixture 中只注入这一个 App 容器
export const test = base.extend<{ app: App }>({
  app: async ({ page }, use) => {
    await use(new App(page));
  },
});

// 最终的用例：兼顾简洁与控制感
test('完整购物流', async ({ app }) => {
  await app.loginPage.goto();
  await app.cartPage.addItem('MacBook');
  await app.paymentPage.pay();
});

这种模式的妙处在于：

收拢入口 ：所有的页面对象都在 App 类里管理，不再有零散的 Fixture。
按需实例化 ：只有当你访问 app.cartPage 时，对象才会被创建。
IDE 极其友好 ：输入 app.，所有的页面对象都会自动弹出，支持一键跳转。

06. 总结：你该如何选择？

官方推荐 Fixture，是因为它在演示和中小型项目中能提供极致的"代码美感"。 但在大厂的生产环境中，"稳定"和"可维护性" 永远高于"美感"。

如果你的项目页面少于 50 个，且成员对 Playwright 非常熟悉，坚持使用 Fixture，它很快。
如果你正在构建一个企业级测试平台，或者团队中有大量初中级开发者，请优先考虑懒加载或 App 容器模式 。
- 记住： 优秀的架构不是用最炫的特性，而是用最简单、最透明的方式解决最复杂的问题。