From e7db97ff0f197213443dc3a6c2f54a06a794fd93 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Wed, 12 Nov 2025 20:33:41 +0800
Subject: [PATCH 01/50] !docs: recovery /guide/migration

---
 guide/migration.md | 711 ++++++++++++++++++++++++++-------------------
 1 file changed, 416 insertions(+), 295 deletions(-)

diff --git a/guide/migration.md b/guide/migration.md
index 2ce929a1..feafbcc6 100644
--- a/guide/migration.md
+++ b/guide/migration.md
@@ -5,409 +5,522 @@ outline: deep
 
 # 迁移指南 {#migration-guide}
 
-## 迁移到 Vitest 4.0 {#vitest-4}
+## 迁移到 Vitest 3.0 {#vitest-3}
 
-### V8 Code Coverage Major Changes {#v8-code-coverage-major-changes}
+### 测试选项作为第三个参数 {#test-options-as-a-third-argument}
 
-Vitest 的 V8 覆盖率提供器现在使用了更精准的结果映射逻辑，从 Vitest v3 升级后，你可能会看到覆盖率报告的内容有变化。
+Vitest 3.0 如果我们将一个对象作为第三个参数传递给 `test` 或 `describe` 函数，会打印一条警告：
 
-之前 Vitest 使用 [`v8-to-istanbul`](https://github.com/istanbuljs/v8-to-istanbul) 将 V8 覆盖率结果映射到源码文件，但这种方式不够准确，报告中常常会出现误报。现在我们开发了基于 AST 分析的新方法，使 V8 报告的准确度与 `@vitest/coverage-istanbul` 一致。
+```ts
+test('validation works', () => {
+  // ...
+}, { retry: 3 }) // [!code --]
 
-- 覆盖率忽略提示已更新，详见 [覆盖率 | 忽略代码](/guide/coverage.html#ignoring-code)。
-- 已移除 `coverage.ignoreEmptyLines` 选项。没有可执行代码的行将不再出现在报告中。
-- 已移除 `coverage.experimentalAstAwareRemapping` 选项。此功能现已默认启用，并成为唯一的映射方式。
-- 现在 V8 提供器也支持 `coverage.ignoreClassMethods`。
+test('validation works', { retry: 3 }, () => { // [!code ++]
+  // ...
+})
+```
 
-### 移除 `coverage.all` 和 `coverage.extensions` 选项 {#removed-options-coverage-all-and-coverage-extensions}
+下一个主要版本将在第三个参数是对象时抛出错误。请注意，超时时间（timeout number）并没有被弃用：
 
-在之前的版本中，Vitest 会默认把所有未覆盖的文件包含到报告中。这是因为 `coverage.all` 默认为 `true`，`coverage.include` 默认为 `**`。这样设计是因为测试工具无法准确判断用户源码所在位置。
+```ts
+test('validation works', () => {
+  // ...
+}, 1000) // Ok ✅
+```
 
-然而，这导致 Vitest 覆盖率工具会处理很多意料之外的文件（例如压缩 JS 文件），造成报告生成速度很慢甚至卡死。在 Vitest v4 中，我们彻底移除了 `coverage.all`，并将默认行为改为**只在报告中包含被测试覆盖的文件**。
+### `browser.name` 和 `browser.providerOptions` 已弃用 {#browser-name-and-browser-provideroptions-are-deprecated}
 
-在升级到 v4 后，推荐在配置中显式指定 `coverage.include`，并视需要配合使用 `coverage.exclude` 进行排除。
+[`browser.name`](/guide/browser/config#browser-name) 和 [`browser.providerOptions`](/guide/browser/config#browser-provideroptions) 都将在 Vitest 4 中删除。请使用新的 [`browser.instances`](/guide/browser/config#browser-instances) 选项来代替它们：
 
-```ts [vitest.config.ts]
+```ts
 export default defineConfig({
   test: {
-    coverage: {
-      // 包含匹配此模式的被覆盖和未覆盖文件：
-      include: ['packages/**/src/**.{js,jsx,ts,tsx}'], // [!code ++]
+    browser: {
+      name: 'chromium', // [!code --]
+      providerOptions: { // [!code --]
+        launch: { devtools: true }, // [!code --]
+      }, // [!code --]
+      instances: [ // [!code ++]
+        { // [!code ++]
+          browser: 'chromium', // [!code ++]
+          launch: { devtools: true }, // [!code ++]
+        }, // [!code ++]
+      ], // [!code ++]
+    },
+  },
+})
+```
 
-      // 对上述 include 匹配到的文件应用排除规则：
-      exclude: ['**/some-pattern/**'], // [!code ++]
+使用新的 `browser.instances` 字段，我们还可以指定多个浏览器配置。
 
-      // 以下选项已移除
-      all: true, // [!code --]
-      extensions: ['js', 'ts'], // [!code --]
-    }
-  }
-})
+### 现在 `spy.mockReset` 恢复原始实现 {#spy-mockreset-now-restores-the-original-implementation}
+
+之前没有好的方法在不重新应用 spy 的情况下将其重置为原始实现。现在，`spy.mockReset` 会将实现函数重置为原始函数，而不是假的 noop（空操作）。
+
+```ts
+const foo = {
+  bar: () => 'Hello, world!'
+}
+
+vi.spyOn(foo, 'bar').mockImplementation(() => 'Hello, mock!')
+
+foo.bar() // 'Hello, mock!'
+
+foo.bar.mockReset()
+
+foo.bar() // undefined [!code --]
+foo.bar() // 'Hello, world!' [!code ++]
 ```
 
-如果未定义 `coverage.include`，报告将只包含测试运行中被加载的文件：
+### `vi.spyOn` 如果方法已被模拟，则复用模拟对象 {#vi-spyon-reuses-mock-if-method-is-already-mocked}
 
-```ts [vitest.config.ts]
-export default defineConfig({
-  test: {
-    coverage: {
-      // 未设置 include，只包含运行时加载的文件
-      include: undefined, // [!code ++]
+之前，Vitest 在监视对象时总会分配一个新的 spy。这会导致 `mockRestore` 出现错误，因为它会将 spy 恢复到之前的 spy，而不是原始函数：
 
-      // 匹配此模式的已加载文件将被排除：
-      exclude: ['**/some-pattern/**'], // [!code ++]
-    }
-  }
-})
+```ts
+vi.spyOn(fooService, 'foo').mockImplementation(() => 'bar')
+vi.spyOn(fooService, 'foo').mockImplementation(() => 'bar')
+vi.restoreAllMocks()
+vi.isMockFunction(fooService.foo) // true [!code --]
+vi.isMockFunction(fooService.foo) // false [!code ++]
 ```
 
-更多示例请参考：
-- [覆盖率报告中的文件包含与排除](/guide/coverage.html#including-and-excluding-files-from-coverage-report)
-- [性能分析 | 代码覆盖率](/guide/profiling-test-performance.html#code-coverage) 了解调试覆盖率生成的方法
+### Fake Timers 默认值 {#fake-timers-defaults}
 
-### `spyOn` and `fn` 支持构造函数 {#spyon-and-fn-support-constructors}
+Vitest 不再提供默认的 `fakeTimers.toFake` 选项。现在，如果存在任何与定时器相关的 API（除 `nextTick` 外），Vitest 都会对其进行模拟。具体来说，当调用 `vi.useFakeTimers` 时，`performance.now()` 也会被模拟。
 
-在之前版本中，如果你对构造函数使用 `vi.spyOn`，会收到类似 `Constructor <name> requires 'new'` 的错误。从 Vitest 4 开始，所有用 `new` 调用的 mock 都会正确创建实例，而不是调用 `mock.apply`。这意味着 mock 实现必须使用 `function` 或 `class` 关键字，例如：
+```ts
+vi.useFakeTimers()
 
-```ts {12-14,16-20}
-const cart = {
-  Apples: class Apples {
-    getApples() {
-      return 42
-    }
-  }
-}
+performance.now() // 原始的 [!code --]
+performance.now() // 假的 [!code ++]
+```
 
-const Spy = vi.spyOn(cart, 'Apples')
-  .mockImplementation(() => ({ getApples: () => 0 })) // [!code --]
-  // 使用 function 关键字
-  .mockImplementation(function () {
-    this.getApples = () => 0
-  })
-  // 使用自定义 class
-  .mockImplementation(class MockApples {
-    getApples() {
-      return 0
-    }
-  })
+你可以通过在调用 `vi.useFakeTimers` 时或在全局配置中指定定时器来恢复到之前的行为：
 
-const mock = new Spy()
+```ts
+export default defineConfig({
+  test: {
+    fakeTimers: {
+      toFake: [ // [!code ++]
+        'setTimeout', // [!code ++]
+        'clearTimeout', // [!code ++]
+        'setInterval', // [!code ++]
+        'clearInterval', // [!code ++]
+        'setImmediate', // [!code ++]
+        'clearImmediate', // [!code ++]
+        'Date', // [!code ++]
+      ] // [!code ++]
+    },
+  },
+})
 ```
 
-请注意，如果此时使用箭头函数，调用 mock 时会报 [`<anonymous> is not a constructor` 错误](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Not_a_constructor)。
+### 更严格的错误相等性检查 {#more-strict-error-equality}
 
-### Mock 的变更 {#changes-to-mocking}
+现在，Vitest 在通过 `toEqual` 或 `toThrowError` 比较错误时会检查更多的属性。Vitest 会比较 `name`、`message`、`cause` 和 `AggregateError.errors`。对于 `Error.cause`，比较是不对称进行的：
 
-Vitest 4 除新增构造函数支持外，还重构了 mock 的创建机制，一举修复多年累积的模块模拟顽疾；尤其在类与 spy 交互时，行为更易预测、不再烧脑。
+```ts
+expect(new Error('hi', { cause: 'x' })).toEqual(new Error('hi')) // ✅
+expect(new Error('hi')).toEqual(new Error('hi', { cause: 'x' })) // ❌
+```
 
-- `vi.fn().getMockName()` 现默认返回 `vi.fn()`，而不再附带 `spy`。这一改动会使快照中的 mock 名称从 `[MockFunction spy]` 简化为 `[MockFunction]`；而 `vi.spyOn` 创建的 spy 仍沿用原始名称，便于调试。
-- `vi.restoreAllMocks` 现已缩小作用范围：仅还原由 `vi.spyOn` 手动创建的 spy ，不再触及自动 mock ，亦不会重置其内部状态（对应配置项 [`restoreMocks`](/config/#restoremocks) 同步更新）。`.mockRestore` 仍按原行为重置实现并清空状态。
-- 现对 mock 调用 `vi.spyOn` 时，返回的仍是原 mock，而非新建 spy。
-- 自动 mock 的实例方法已正确隔离，但仍与原型共享底层状态；除非方法已自定义 mock 实现，否则修改原型实现会同步影响所有实例。此外，调用 `.mockReset` 不再破坏此继承关系。
+除了检查更多的属性外，Vitest 现在还会比较错误原型。例如，如果抛出的是 `TypeError`，相等性检查应该引用 `TypeError`，而不是 `Error`：
 
 ```ts
-import { AutoMockedClass } from './example.js'
-const instance1 = new AutoMockedClass()
-const instance2 = new AutoMockedClass()
+expect(() => {
+  throw new TypeError('type error')
+})
+  .toThrowError(new Error('type error')) // [!code --]
+  .toThrowError(new TypeError('type error')) // [!code ++]
+```
 
-instance1.method.mockReturnValue(42)
+更多详情请参见 PR：[#5876](https://github.com/vitest-dev/vitest/pull/5876)。
 
-expect(instance1.method()).toBe(42)
-expect(instance2.method()).toBe(undefined)
+### 在 Vite 6 中，默认不会解析 `module` 的条件导出 {#module-condition-export-is-not-resolved-by-default-on-vite-6}
 
-expect(AutoMockedClass.prototype.method).toHaveBeenCalledTimes(2)
+Vite 6 allows more flexible [`resolve.conditions`](https://vite.dev/config/shared-options#resolve-conditions) options and Vitest configures it to exclude `module` conditional export by default.
+See also [Vite 6 migration guide](https://v6.vite.dev/guide/migration.html#default-value-for-resolve-conditions) for the detail of Vite side changes.
 
-instance1.method.mockReset()
-AutoMockedClass.prototype.method.mockReturnValue(100)
+### `Custom` 类型已被弃用 <Badge type="danger">API</Badge> {#custom-type-is-deprecated}
 
-expect(instance1.method()).toBe(100)
-expect(instance2.method()).toBe(100)
+`Custom` 类型现在等同于 `Test` 类型。需要注意一下，Vitest 在 2.1 版本中更新了公共类型，并将导出的名称更改为 `RunnerCustomCase` 和 `RunnerTestCase`。
 
-expect(AutoMockedClass.prototype.method).toHaveBeenCalledTimes(4)
+```ts
+import {
+  RunnerCustomCase, // [!code --]
+  RunnerTestCase, // [!code ++]
+} from 'vitest'
 ```
-- 自动 mock 方法一经生成即不可还原，手动 `.mockRestore` 无效；`spy: true` 的自动 mock 模块行为保持不变。
-- 自动 mock 的 getter 不再执行原始逻辑，默认返回 `undefined`；如需继续监听并改写，请使用 `vi.spyOn(object, name, 'get')`。
-- 执行 `vi.fn(implementation).mockReset()` 后，`.getMockImplementation()` 现可正确返回原 mock 实现。
-- `vi.fn().mock.invocationCallOrder` 现以 `1` 起始，与 Jest 保持一致。
 
-### 带文件名过滤器的独立模式 {#standalone-mode-with-filename-filter}
+如果我们正在使用 `getCurrentSuite().custom()`，返回的任务的 `type` 现在等于 `'test'`。`Custom` 类型将在 Vitest 4 中被移除。
 
-为了提升用户体验，当 [`--standalone`](/guide/cli#standalone) 与文件名过滤器一起使用时，Vitest 现在会直接开始运行匹配到的文件。
+### `WorkspaceSpec` 类型已被弃用 <Badge type="danger">API</Badge> {#the-workspacespec-type-is-no-longer-used}
 
-```sh
-# In Vitest v3 and below this command would ignore "math.test.ts" filename filter.
-# In Vitest v4 the math.test.ts will run automatically.
-$ vitest --standalone math.test.ts
-```
+在公共 API 中，此类型之前用于自定义 [sequencers](/config/#sequence-sequencer)。请迁移到 [`TestSpecification`](/advanced/api/test-specification)。
 
-这允许用户为独立模式创建可复用的 `package.json`。
+### 现在 `onTestFinished` 和 `onTestFailed` 接收上下文参数 {#ontestfinished-and-ontestfailed-now-receive-a-context}
 
-::: code-group
-```json [package.json]
-{
-  "scripts": {
-    "test:dev": "vitest --standalone"
-  }
-}
-```
-```bash [CLI]
-# Start Vitest in standalone mode, without running any files on start
-$ pnpm run test:dev
+[`onTestFinished`](/api/#ontestfinished) 和 [`onTestFailed`](/api/#ontestfailed) 钩子之前接收测试结果作为第一个参数。现在，它们像 `beforeEach` 和 `afterEach` 一样，接收一个测试上下文。
 
-# Run math.test.ts immediately
-$ pnpm run test:dev math.test.ts
-```
-:::
+### Snapshot API 变更<Badge type="danger">API</Badge> {#changes-to-the-snapshot-api}
 
-### Replacing `vite-node` with [Module Runner](https://vite.dev/guide/api-environment-runtimes.html#modulerunner) {#replacing-vite-node-with-module-runner}
+`@vitest/snapshot` 中的公共 Snapshot API 已更改，以支持在单次运行中处理多个状态。更多详情请参见 PR：[#6817](https://github.com/vitest-dev/vitest/pull/6817)。
 
-Module Runner 已取代 `vite-node`，直接内嵌于 Vite, Vitest 亦移除 SSR 封装，直接调用。主要变更如下：
+请注意，这些更改仅影响直接使用 Snapshot API 的开发者。`.toMatchSnapshot` API 没有任何变化。
 
-- 环境变量：`VITE_NODE_DEPS_MODULE_DIRECTORIES` → `VITEST_MODULE_DIRECTORIES`
-- 注入字段：`__vitest_executor` → `moduleRunner`（[`ModuleRunner`](https://vite.dev/guide/api-environment-runtimes.html#modulerunner) 实例）
-- 移除内部入口 `vitest/execute`
-- 自定义环境用 `viteEnvironment` 取代 `transformMode`；未指定时，Vitest 以环境名匹配 [`server.environments`](https://vite.dev/guide/api-environment-instances.html)
-- 依赖列表剔除 `vite-node`
-- `deps.optimizer.web` 重命名为 [`deps.optimizer.client`](/config/#deps-optimizer-client)，并支持自定义环境名
+### 修改 `resolveConfig` 类型签名 <Badge type="danger">API</Badge> {#changes-to-resolveconfig-type-signature}
 
-Vite 已提供外部化机制，但为降低破坏性，仍保留旧方案；[`server.deps`](/config/#server-deps) 可继续用于包的内联/外部化。
+[`resolveConfig`](/advanced/api/#resolveconfig) 现在更加有用。它不再接受已经解析的 Vite 配置，而是接受用户配置并返回解析后的配置。
 
-未使用上述高级功能者，升级无感知。
+此函数不用于内部，仅作为公共 API 暴露。
 
-### `workspace` is Replaced with `projects` {#workspace-is-replaced-with-projects}
+### 已清理 `vitest/reporters` 类型定义 <Badge type="danger">API</Badge> {#cleaned-up-vitest-reporters-types}
 
-The `workspace` configuration option was renamed to [`projects`](/guide/projects) in Vitest 3.2. They are functionally the same, except you cannot specify another file as the source of your workspace (previously you could specify a file that would export an array of projects). Migrating to `projects` is easy, just move the code from `vitest.workspace.js` to `vitest.config.ts`:
+`vitest/reporters` 入口现在仅导出报告器实现和选项类型。如果您需要访问 `TestCase`、`TestSuite` 以及其他与任务相关的类型，请另外从 `vitest/node` 中导入它们。
 
-::: code-group
-```ts [vitest.config.js]
-import { defineConfig } from 'vitest/config'
+### 即使覆盖了 `coverage.excludes` 配置，代码覆盖率仍会忽略测试文件。 {#coverage-ignores-test-files-even-when-coverage-excludes-is-overwritten}
 
+不再可以通过覆盖 `coverage.excludes` 来将测试文件包含在覆盖率报告中。测试文件现在总是被排除。
+
+## 迁移到 Vitest 2.0 {#vitest-2}
+
+### 默认数据池为 `forks` {#default-pool-is-forks}
+
+为了提高稳定性，Vitest 2.0 将 `pool` 的默认配置改为 `'fork'`。您可以在 [PR](https://github.com/vitest-dev/vitest/pull/5047)中阅读完整的动机。
+
+如果使用了 `poolOptions` 而未指定一个 `pool`，则可能需要更新配置：
+
+```ts
 export default defineConfig({
   test: {
-    workspace: './vitest.workspace.js', // [!code --]
-    projects: [ // [!code ++]
-      './packages/*', // [!code ++]
-      { // [!code ++]
-        test: { // [!code ++]
-          name: 'unit', // [!code ++]
-        }, // [!code ++]
+    poolOptions: {
+      threads: { // [!code --]
+        singleThread: true, // [!code --]
+      }, // [!code --]
+      forks: { // [!code ++]
+        singleFork: true, // [!code ++]
       }, // [!code ++]
-    ] // [!code ++]
+    }
   }
 })
 ```
-```ts [vitest.workspace.js]
-import { defineWorkspace } from 'vitest/config' // [!code --]
 
-export default defineWorkspace([ // [!code --]
-  './packages/*', // [!code --]
-  { // [!code --]
-    test: { // [!code --]
-      name: 'unit', // [!code --]
-    }, // [!code --]
-  } // [!code --]
-]) // [!code --]
-```
-:::
+### 钩子函数在堆栈中运行 {#hooks-are-running-in-a-stack}
 
-### Browser Provider Rework {#browser-provider-rework}
+在 Vitest 2.0 之前，所有钩子函数都是并行运行的。 在 2.0 中，所有钩子都是串行运行的。 除此之外，`afterAll`/`afterEach` 以相反的顺序运行。
 
-In Vitest 4.0, the browser provider now accepts an object instead of a string (`'playwright'`, `'webdriverio'`). The `preview` is no longer a default. This makes it simpler to work with custom options and doesn't require adding `/// <reference` comments anymore.
+要恢复钩子的并行执行，请将 [`sequence.hooks`](/config/#sequence-hooks) 改为 `'parallel'`：
 
 ```ts
-import { playwright } from '@vitest/browser-playwright' // [!code ++]
-
 export default defineConfig({
   test: {
-    browser: {
-      provider: 'playwright', // [!code --]
-      provider: playwright({ // [!code ++]
-        launchOptions: { // [!code ++]
-          slowMo: 100, // [!code ++]
-        }, // [!code ++]
-      }), // [!code ++]
-      instances: [
-        {
-          browser: 'chromium',
-          launch: { // [!code --]
-            slowMo: 100, // [!code --]
-          }, // [!code --]
-        },
-      ],
-    },
+    sequence: { // [!code ++]
+      hooks: 'parallel', // [!code ++]
+    }, // [!code ++]
   },
 })
 ```
 
-The naming of properties in `playwright` factory now also aligns with [Playwright documentation](https://playwright.dev/docs/api/class-testoptions#test-options-launch-options) making it easier to find.
+### `suite.concurrent` 同时运行所有测试 {#suite-concurrent-runs-all-tests-concurrently}
 
-With this change, the `@vitest/browser` package is no longer needed, and you can remove it from your dependencies. To support the context import, you should update the `@vitest/browser/context` to `vitest/browser`:
+以前，在套件上指定 `concurrent` 时，并发测试仍会按套件分组并逐个运行。现在，它会遵循 jest 的行为，一次运行所有测试（仍受 [`maxConcurrency`](/config/#maxConcurrency)限制）。
 
-```ts
-import { page } from '@vitest/browser/context' // [!code --]
-import { page } from 'vitest/browser' // [!code ++]
+### 默认启用 V8 覆盖的 `coverage.ignoreEmptyLines` {#v8-coverage-s-coverage-ignoreemptylines-is-enabled-by-default}
+
+将 `coverage.ignoreEmptyLines` 的默认值改为 `true`。此更改将对用户的代码覆盖率报告产生重大影响。使用覆盖率阈值的项目很可能需要在此之后调整这些值。此更改仅影响 `coverage.provider` 为 `'v8'` 时的默认设置.
 
-test('example', async () => {
-  await page.getByRole('button').click()
+### 移除 `watchExclude` 选项 {#removal-of-the-watchexclude-option}
+
+Vitest 使用 Vite 的监视器。您可以将排除项添加到 `server.watch.ignored`：
+
+```ts
+export default defineConfig({
+  server: { // [!code ++]
+    watch: { // [!code ++]
+      ignored: ['!node_modules/examplejs'] // [!code ++]
+    } // [!code ++]
+  } // [!code ++]
 })
 ```
 
-The modules are identical, so doing a simple "Find and Replace" should be sufficient.
+### 移除 `--segfault-retry` {#segfault-retry-removed}
 
-If you were using the `@vitest/browser/utils` module, you can now import those utilities from `vitest/browser` as well:
+默认程序池更改后，不再需要此选项。如果遇到分离故障错误，请尝试切换到`'forks'`池。如果问题仍然存在，请重现问题并打开一个新问题。
+
+### 删除套件任务中的空任务 {#empty-task-in-suite-tasks-removed}
+
+这是对高级[task API](/advanced/runner#your-task-function)的更改。以前，遍历 `.suite`最终会导致使用空的内部套件，而不是文件任务。
+
+这使得 `.suite`成为可选项；如果任务是在顶层定义的，则不会有 suite。您可以回退到 `.file`属性，该属性现在存在于所有任务中（包括文件任务本身，因此要小心不要陷入无休止的递归）。
+
+这一更改还删除了 `expect.getState().currentTestName` 中的文件，并使 `expect.getState().testPath` 成为必填项。
+
+### `task.meta` 已添加到 JSON 报告器中 {#task-meta-is-added-to-the-json-reporter}
+
+JSON 报告器现在会为每个断言结果打印 `task.meta` 。
+
+### 简化的模拟函数通用类型 (e.g. `vi.fn<T>`, `Mock<T>`) {#simplified-generic-types-of-mock-functions-e-g-vi-fn-t-mock-t}
+
+以前 `vi.fn<TArgs, TReturn>` 分别接受参数和返回值的两个泛型。现在改为直接接受一个函数类型 `vi.fn<T>` 以简化用法。
 
 ```ts
-import { getElementError } from '@vitest/browser/utils' // [!code --]
-import { utils } from 'vitest/browser' // [!code ++]
-const { getElementError } = utils // [!code ++]
+import type { Mock } from 'vitest'
+import { vi } from 'vitest'
+
+const add = (x: number, y: number): number => x + y
+
+// using vi.fn<T>
+const mockAdd = vi.fn<Parameters<typeof add>, ReturnType<typeof add>>() // [!code --]
+const mockAdd = vi.fn<typeof add>() // [!code ++]
+
+// using Mock<T>
+const mockAdd: Mock<Parameters<typeof add>, ReturnType<typeof add>> = vi.fn() // [!code --]
+const mockAdd: Mock<typeof add> = vi.fn() // [!code ++]
 ```
 
-::: warning
-Both `@vitest/browser/context` and `@vitest/browser/utils` work at runtime during the transition period, but they will be removed in a future release.
-:::
+### 访问已解析 `mock.results` {#accessing-resolved-mock-results}
+
+之前，Vitest 会在函数返回 Promise 时解析 `mock.results` 的值。现在，增加了一个独立的 [`mock.settledResults`](/api/mock#mock-settledresults) 属性，仅在返回的 Promise 被解析或拒绝时填充。
 
-### Reporter Updates {#reporter-updates}
+```ts
+const fn = vi.fn().mockResolvedValueOnce('result')
+await fn()
+
+const result = fn.mock.results[0] // 'result' [!code --]
+const result = fn.mock.results[0] // 'Promise<result>' [!code ++]
 
-Reporter APIs `onCollected`, `onSpecsCollected`, `onPathsCollected`, `onTaskUpdate` and `onFinished` were removed. See [`Reporters API`](/advanced/api/reporters) for new alternatives. The new APIs were introduced in Vitest `v3.0.0`.
+const settledResult = fn.mock.settledResults[0] // 'result'
+```
 
-The `basic` reporter was removed as it is equal to:
+通过这一更改，我们还引入了新的 [`toHaveResolved*`](/api/expect#tohaveresolved) 匹配器，类似于 `toHaveReturned`，以便如果您之前使用过 `toHaveReturned`，迁移会更加容易：
 
 ```ts
-export default defineConfig({
-  test: {
-    reporters: [
-      ['default', { summary: false }]
-    ]
+const fn = vi.fn().mockResolvedValueOnce('result')
+await fn()
+
+expect(fn).toHaveReturned('result') // [!code --]
+expect(fn).toHaveResolved('result') // [!code ++]
+```
+
+### 浏览器模式 {#browser-mode}
+
+Vitest 浏览器模式在测试周期内发生了很多变化。您可以在[GitHub discussion](https://github.com/vitest-dev/vitest/discussions/5828)上阅读我们关于浏览器模式的理念。
+
+大多数改动都是附加的，但也有一些小的突破性改动：
+
+- `none` provider 更名为 `preview` [#5842](https://github.com/vitest-dev/vitest/pull/5826)
+- `preview` provider 现在是默认的 [#5842](https://github.com/vitest-dev/vitest/pull/5826)
+- `indexScripts` 更名为 `orchestratorScripts` [#5842](https://github.com/vitest-dev/vitest/pull/5842)
+
+### 删除已弃用的选项 {#deprecated-options-removed}
+
+一些已弃用的选项已被删除：
+
+- `vitest typecheck` 命令 - 使用 `vitest --typecheck` 代替
+- `VITEST_JUNIT_CLASSNAME` 和 `VITEST_JUNIT_SUITE_NAME` 环境变量（改用 reporter 选项）
+- 检查 `c8` 覆盖率（使用 coverage-v8 代替）
+- 从 `vitest` 导出 `SnapshotEnvironment` - 改为从 `vitest/snapshot` 导入
+- 删除 `SpyInstance` 改用 `MockInstance`
+
+## 迁移到 Vitest 1.0 {#migrating-to-vitest-1-0}
+
+### 最低要求 {#minimum-requirements}
+
+Vitest 1.0 需要 Vite 5.0 和 Node.js 18 或更高版本。
+
+所有 `@vitest/*` 子软件包都需要 Vitest 1.0 版本。
+
+### Snapshots 更新 [#3961](https://github.com/vitest-dev/vitest/pull/3961) {#snapshots-update-3961}
+
+快照中的引号不再转义，即使字符串只有一行，所有快照也都使用回车引号 (`)。
+
+1. 引号不再转义：
+
+```diff
+expect({ foo: 'bar' }).toMatchInlineSnapshot(`
+  Object {
+-    \\"foo\\": \\"bar\\",
++    "foo": "bar",
   }
-})
+`)
 ```
 
-The [`verbose`](/guide/reporters#verbose-reporter) reporter now prints test cases as a flat list. To revert to the previous behaviour, use `--reporter=tree`:
+2. 单行快照现在使用"`"引号，而不是"'"：
 
-```ts
+```diff
+- expect('some string').toMatchInlineSnapshot('"some string"')
++ expect('some string').toMatchInlineSnapshot(`"some string"`)
+```
+
+对 `@vitest/snapshot` 也有[修改](https://github.com/vitest-dev/vitest/pull/4076)。如果不直接使用它，则无需做任何更改。
+
+- 我们不再需要扩展 `SnapshotClient` 以覆盖 `equalityCheck` 方法：只需在启动实例时将其作为 `isEqual` 传递即可。
+- `client.setTest` 更名为 `client.startCurrentRun`
+- `client.resetCurrent` 更名为 `client.finishCurrentRun` 。
+
+### Pools 标准化 [#4172](https://github.com/vitest-dev/vitest/pull/4172) {#pools-are-standardized-4172}
+
+我们删除了大量配置选项，以便根据需要配置运行程序。如果你已经使用了 `--threads` 或其他相关标记，请查看迁移示例。
+
+- `--threads` 现在是 `--pool=threads`
+- `--no-threads` 现在是 `--pool=forks`
+- `--single-thread` 现在是 `--poolOptions.threads.singleThread`
+- `--experimental-vm-threads` 现在是 `--pool=vmThreads`
+- `--experimental-vm-worker-memory-limit` 现在是 `--poolOptions.vmThreads.memoryLimit`
+- `--isolate` 现在是 `--poolOptions.<pool-name>.isolate` 和 `browser.isolate`
+- `test.maxThreads` 现在是 `test.poolOptions.<pool-name>.maxThreads`
+- `test.minThreads` 现在是 `test.poolOptions.<pool-name>.minThreads`
+- `test.useAtomics` 现在是 `test.poolOptions.<pool-name>.useAtomics`
+- `test.poolMatchGlobs.child_process` 现在是 `test.poolMatchGlobs.forks`
+- `test.poolMatchGlobs.experimentalVmThreads` 现在是 `test.poolMatchGlobs.vmThreads`
+
+```diff
+{
+  scripts: {
+-    "test": "vitest --no-threads"
+     // For identical behaviour:
++    "test": "vitest --pool forks --poolOptions.forks.singleFork"
+     // Or multi parallel forks:
++    "test": "vitest --pool forks"
+
+  }
+}
+```
+
+```diff
+{
+  scripts: {
+-    "test": "vitest --experimental-vm-threads"
++    "test": "vitest --pool vmThreads"
+  }
+}
+```
+
+```diff
+{
+  scripts: {
+-    "test": "vitest --isolate false"
++    "test": "vitest --poolOptions.threads.isolate false"
+  }
+}
+```
+
+```diff
+{
+  scripts: {
+-    "test": "vitest --no-threads --isolate false"
++    "test": "vitest --pool forks --poolOptions.forks.isolate false"
+  }
+}
+```
+
+### Coverage 的变化 [#4265](https://github.com/vitest-dev/vitest/pull/4265), [#4442](https://github.com/vitest-dev/vitest/pull/4442) {#changes-to-coverage-4265-4442}
+
+选项 `coverage.all` 现在默认启用。这意味着，所有符合 `coverage.include` 模式的项目文件都将被处理，即使它们未被执行。
+
+更改了覆盖阈值 API 的形状，现在它支持使用 glob 模式为特定文件指定阈值：
+
+```diff
 export default defineConfig({
   test: {
-    reporters: ['verbose'], // [!code --]
-    reporters: ['tree'], // [!code ++]
+    coverage: {
+-      perFile: true,
+-      thresholdAutoUpdate: true,
+-      100: true,
+-      lines: 100,
+-      functions: 100,
+-      branches: 100,
+-      statements: 100,
++      thresholds: {
++        perFile: true,
++        autoUpdate: true,
++        100: true,
++        lines: 100,
++        functions: 100,
++        branches: 100,
++        statements: 100,
++      }
+    }
   }
 })
 ```
 
-### Snapshots using custom elements print the shadow root {#snapshots-using-custom-elements-print-the-shadow-root}
-
-In Vitest 4.0 snapshots that include custom elements will print the shadow root contents. To restore the previous behavior, set the [`printShadowRoot` option](/config/#snapshotformat) to `false`.
-
-```js{15-22}
-// before Vite 4.0
-exports[`custom element with shadow root 1`] = `
-"<body>
-  <div>
-    <custom-element />
-  </div>
-</body>"
-`
-
-// after Vite 4.0
-exports[`custom element with shadow root 1`] = `
-"<body>
-  <div>
-    <custom-element>
-      #shadow-root
-        <span
-          class="some-name"
-          data-test-id="33"
-          id="5"
-        >
-          hello
-        </span>
-    </custom-element>
-  </div>
-</body>"
-`
-```
-
-### Deprecated APIs are Removed {#deprecated-apis-are-removed}
-
-Vitest 4.0 移除了以下废弃的配置项：
-
-- `poolMatchGlobs` 配置项。请使用 [`projects`](/guide/projects) 代替。
-- `environmentMatchGlobs` 配置项。请使用 [`projects`](/guide/projects) 代替。
-- `deps.external`、`deps.inline`、`deps.fallbackCJS` 配置项。请改用 `server.deps.external`、`server.deps.inline` 或 `server.deps.fallbackCJS`。
-- `browser.testerScripts` 配置项。请使用 [`browser.testerHtmlPath`](/guide/browser/config#browser-testerhtmlpath) 代替。
-- `minWorkers` 配置项。只有 `maxWorkers` 会对测试运行方式产生影响，因此我们正在移除这个公共选项。
-- Vitest 不再支持将测试选项作为第三个参数提供给 `test` 和 `describe`。请改用第二个参数。
+### Mock 类型 [#4400](https://github.com/vitest-dev/vitest/pull/4400) {#mock-types-4400}
 
-```ts
-test('example', () => { /* ... */ }, { retry: 2 }) // [!code --]
-test('example', { retry: 2 }, () => { /* ... */ }) // [!code ++]
-```
+删除了一些类型，改用 Jest 风格的 "Mock "命名。
 
-同时，所有弃用类型被一次性清理，彻底解决误引 `@types/node` 的问题（[#5481](https://github.com/vitest-dev/vitest/issues/5481)、[#6141](https://github.com/vitest-dev/vitest/issues/6141)）。
+```diff
+- import { EnhancedSpy, SpyInstance } from 'vitest'
++ import { MockInstance } from 'vitest'
+```
 
-## 从 Jest 迁移 {#jest}
+::: warning
+`SpyInstance` 已被弃用，取而代之的是 `MockInstance` ，并会在下一个主要版本中移除。
+:::
 
-Vitest 的 API 设计兼容 Jest，旨在使从 Jest 迁移尽可能简单。尽管如此，你仍可能遇到以下差异：
+### 模拟计时器 [#3925](https://github.com/vitest-dev/vitest/pull/3925) {#timer-mocks-3925}
 
-### 默认是否启用全局变量 {#globals-as-a-default}
+`vi.useFakeTimers()` 不再自动模拟 [`process.nextTick`](https://nodejs.org/api/process.html#processnexttickcallback-args) 。
+仍然可以通过使用 `vi.useFakeTimers({ toFake: ['nextTick'] })` 明确指定来模拟 `process.nextTick`。
 
-Jest 默认启用其 [globals API](https://jestjs.io/docs/api)。Vitest 默认不启用。你可以通过配置项 [globals](/config/#globals) 启用全局变量，或者修改代码直接从 `vitest` 模块导入所需 API。
+但是，在使用 `--pool=forks` 时，无法模拟 `process.nextTick` 。如果需要模拟 `process.nextTick` ，请使用不同的 `--pool` 选项。
 
-如果选择不启用全局变量，注意常用库如 [`testing-library`](https://testing-library.com/) 将不会自动执行 DOM 的 [清理](https://testing-library.com/docs/svelte-testing-library/api/#cleanup)。
+## 从 Jest 迁移 {#jest}
 
-### `mock.mockReset`
+Vitest 设计了与 Jest 兼容的 API ，方便你从 Jest 的迁移尽可能简单。尽管做出了这些努力，你仍然可能会遇到以下差异：
 
-Jest 的 [`mockReset`](https://jestjs.io/docs/mock-function-api#mockfnmockreset) 会将 mock 实现替换为空函数，返回 `undefined`。
+### 全局变量作为默认值 {#globals-as-a-default}
 
-Vitest 的 [`mockReset`](/api/mock#mockreset) 会将 mock 实现重置为最初的实现。也就是说，使用 `vi.fn(impl)` 创建的 mock，`mockReset` 会将实现重置为 `impl`。
+Jest 默认启用[全局 API](https://jestjs.io/zh-Hans/docs/api)。然而 Vitest 没有。你既可以通过 [`globals` 配置选项](/config/#globals)启用全局 API，也可以通过更新你的代码以便使用来自 `vitest` 模块的导入。
 
-### `mock.mock` 是持久的 {#mock-mock-is-persistent}
+如果你决定禁用全局 API，请注意像 [`testing-library`](https://testing-library.com/) 这样的通用库不会自动运行 DOM [cleanup](https://testing-library.com/docs/svelte-testing-library/api/#cleanup)。
 
-Jest 调用 `.mockClear` 后会重建 mock 状态，只能以 getter 方式访问； Vitest 则保留持久引用，可直接复用。
+### `spy.mockReset` {#spy-mockreset}
 
-```ts
-const mock = vi.fn()
-const state = mock.mock
-mock.mockClear()
+Jest 的 [`mockReset`](https://jestjs.io/docs/mock-function-api#mockfnmockreset) 方法会将模拟函数的实现替换为一个返回 `undefined` 的空函数。
 
-expect(state).toBe(mock.mock) // fails in Jest
-```
+而 Vitest 的 [`mockReset`](/api/mock#mockreset) 方法会将模拟函数的实现重置为其原始实现。
+也就是说，通过 `vi.fn(impl)` 创建的模拟，使用 `mockReset` 将会把模拟的实现重置回 `impl`。
 
-### 模块 Mock {#module-mocks}
+### 模拟模块 {#module-mocks}
 
-在 Jest 中，mock 模块时工厂函数返回值即为默认导出。在 Vitest 中，工厂函数需返回包含所有导出的对象。例如，以下 Jest 代码需要改写为：
+在 Jest 中模拟一个模块时，工厂参数的返回值是默认导出。在 Vitest 中，工厂参数必须返回一个明确定义了每个导出的对象。例如，下面的 `jest.mock` 必须更新如下：
 
 ```ts
 jest.mock('./some-path', () => 'hello') // [!code --]
-vi.mock('./some-path', () => ({ // [!code ++]
+vi.mock('./some-path', () => ({
+  // [!code ++]
   default: 'hello', // [!code ++]
 })) // [!code ++]
 ```
 
-更多细节请参考 [`vi.mock` API](/api/vi#vi-mock)。
+有关更深入的详细描述，请参阅 [`vi.mock` api section](/api/#vi-mock)。
 
-### 自动 Mock 行为 {#auto-mocking-behaviour}
+### 自动模拟行为 {#auto-mocking-behaviour}
 
-与 Jest 不同，Vitest 仅在调用 `vi.mock()` 时加载 `<root>/__mocks__` 中的模块。如果你需要像 Jest 一样在每个测试中自动 mock，可以在 [`setupFiles`](/config/#setupfiles) 中调用 mock。
+区别于 Jest，在 `<root>/__mocks__` 中的模拟模块只有在 `vi.mock()` 被调用时才会加载。如果你需要它们像在 Jest 中一样，在每个测试中都被模拟，你可以在 [`setupFiles`](/config/#setupfiles) 中模拟它们。
 
-### 导入被 Mock 包的原始模块 {#importing-the-original-of-a-mocked-package}
+### 导入模拟包的原始版本 {#importing-the-original-of-a-mocked-package}
 
-如果只部分 mock 一个包，之前可能用 Jest 的 `requireActual`，Vitest 中应使用 `vi.importActual`：
+如果你只需要模拟一个 package 的部分功能，你可能之前使用了 Jest 的 `requireActual` 函数。在 Vitest 中，你应该将这些调用替换为 `vi.importActual`。
 
 ```ts
 const { cloneDeep } = jest.requireActual('lodash/cloneDeep') // [!code --]
 const { cloneDeep } = await vi.importActual('lodash/cloneDeep') // [!code ++]
 ```
 
-### 扩展 Mock 到外部库 {#extends-mocking-to-external-libraries}
+### 将模拟扩展到外部库 {#extends-mocking-to-external-libraries}
 
-Jest 默认会扩展 mock 到使用相同模块的外部库。Vitest 需要显式告知要 mock 的第三方库，使其成为源码的一部分，方法是使用 [server.deps.inline](https://vitest.dev/config/#server-deps-inline)：
+在 Jest 的默认情况下，当模拟一个模块并希望将此模拟扩展到使用相同模块的其他外部库时，您应该明确告知您希望模拟哪个第三方库，这样外部库就会成为您源代码的一部分，方法是使用  [server.deps.inline](https://vitest.dev/config/#server-deps-inline).
 
 ```
 server.deps.inline: ["lib-name"]
 ```
 
-### `expect.getState().currentTestName`
+### expect.getState().currentTestName {#expect-getstate-currenttestname}
 
-Vitest 的测试名使用 `>` 符号连接，方便区分测试与套件，而 Jest 使用空格 (` `)。
+Vitest 的 `test` 名称用 `>` 符号连接，以便于区分测试和套件，而 Jest 则使用空格 (` `)。
 
 ```diff
 - `${describeTitle} ${testTitle}`
@@ -416,56 +529,59 @@ Vitest 的测试名使用 `>` 符号连接，方便区分测试与套件，而 J
 
 ### 环境变量 {#envs}
 
-与 Jest 类似，Vitest 会将未设置时的 `NODE_ENV` 设为 `test`。Vitest 还有对应 `JEST_WORKER_ID` 的 `VITEST_POOL_ID`（小于等于 `maxThreads`），如果依赖此值，需重命名。Vitest 还暴露 `VITEST_WORKER_ID`，表示唯一的运行中 worker ID，受 `maxThreads` 不影响，随 worker 创建递增。
+与 Jest 类似，如果未提前设置，Vitest 会将 `NODE_ENV` 设置为 `"test"`。 Vitest 还提供了与 `JEST_WORKER_ID` 对应的 `VITEST_POOL_ID` (该值始终大于等于 `maxThreads`)，如果你依赖它请记得重命名。此外，Vitest 还会暴露 `VITEST_WORKER_ID` 作为运行中 worker的唯一标识 —— 此数值不受 `maxThreads`限制，并且随着 worker 创建递增。
 
-### 替换属性 {#replace-property}
+### 属性替换 {#replace-property}
 
-如果想修改对象，Jest 使用 [replaceProperty API](https://jestjs.io/docs/jest-object#jestreplacepropertyobject-propertykey-value)，Vitest 可使用 [`vi.stubEnv`](/api/#vi-stubenv) 或 [`vi.spyOn`](/api/vi#vi-spyon) 达成相同效果。
+如果你想修改测试环境，你会在 Jest 中使用 [replaceProperty API](https://jestjs.io/docs/jest-object#jestreplacepropertyobject-propertykey-value)，你可以使用 [vi.stubEnv](/api/vi#vi-stubenv) 或者 [`vi.spyOn`](/api/vi#vi-spyon) 也可以在 Vitest 中执行此操作。
 
-### Done 回调 {#done-callback}
-
-Vitest 不支持回调式测试声明。你可以改写为使用 `async`/`await` 函数，或使用 Promise 来模拟回调风格。
+### Done 回调函数 {#done-callback}
+从 Vitest v0.10.0 开始，声明测试的回调样式被弃用。建议改用 `async`/`await` 函数，或者使用 Promise 回调风格。
 
 <!--@include: ./examples/promise-done.md-->
 
-### Hooks {#hooks}
+### 钩子 {#hooks}
 
-Vitest 中 `beforeAll`/`beforeEach` 钩子可返回 [清理函数](/api/#setup-and-teardown)。因此，如果钩子返回非 `undefined` 或 `null`，可能需改写：
+`beforeAll`/`beforeEach` 钩子可能在 Vitest 的 [teardown 函数](/api/#setup-and-teardown)中返回。因此，如果它们返回的不是 `undefined` 或 `null`，你可能需要重写你的钩子声明：
 
 ```ts
 beforeEach(() => setActivePinia(createTestingPinia())) // [!code --]
-beforeEach(() => { setActivePinia(createTestingPinia()) }) // [!code ++]
+beforeEach(() => {
+  setActivePinia(createTestingPinia())
+}) // [!code ++]
 ```
 
-在 Jest 中钩子是顺序执行的（一个接一个）。默认情况下，Vitest 在栈中运行钩子。要使用 Jest 的行为，请更新 [`sequence.hooks`](/config/#sequence-hooks) 选项：
+在 Jest 中，钩子是按顺序调用的（一个接一个）。默认情况下，Vitest 并行运行钩子。要使用 Jest 的行为，请更新 [`sequence.hooks`](/config/#sequence-hooks) 选项：
 
 ```ts
 export default defineConfig({
   test: {
-    sequence: { // [!code ++]
+    sequence: {
+      // [!code ++]
       hooks: 'list', // [!code ++]
-    } // [!code ++]
-  }
+    }, // [!code ++]
+  },
 })
 ```
 
 ### 类型 {#types}
 
-Vitest 没有 Jest 的 `jest` 命名空间，需直接从 `vitest` 导入类型：
+Vitest 没有等效于 `jest` 的命名空间，因此你需要直接从 `Vitest` 导入类型：
 
 ```ts
-let fn: jest.Mock<(name: string) => number> // [!code --]
-import type { Mock } from 'vitest' // [!code ++]
+// [!code --]
+// [!code --]
+import type { Mock } from 'vitest'
+let fn: jest.Mock<(name: string) => number> // [!code ++]
 let fn: Mock<(name: string) => number> // [!code ++]
 ```
 
-### 定时器 {#timers}
-
-Vitest 不支持 Jest 的遗留定时器。
+### Timers {#timers}
+Vitest 不支持 Jest的 传统计时器。
 
-### 超时 {#timeout}
+### 定时器 {#timeout}
 
-如果使用了 `jest.setTimeout`，需迁移为 `vi.setConfig`：
+如果你之前在测试中使用了 jest.setTimeout ，那么你需要迁移到 Vitest 中的`vi.setConfig` :
 
 ```ts
 jest.setTimeout(5_000) // [!code --]
@@ -474,16 +590,21 @@ vi.setConfig({ testTimeout: 5_000 }) // [!code ++]
 
 ### Vue 快照 {#vue-snapshots}
 
-这不是 Jest 特有的功能，但如果你之前在 vue-cli 预设中使用 Jest，你需要安装 [`jest-serializer-vue`](https://github.com/eddyerburgh/jest-serializer-vue) 包，并在 [`snapshotSerializers`](/config/#snapshotserializers) 中指定它：
-
-```js [vitest.config.js]
-import { defineConfig } from 'vitest/config'
+如果你以前在 vue-cli preset 中使用 Jest，那么这不是一个 Jest 独有的新特性。你可能需要安装 [`jest-serializer-vue`](https://github.com/eddyerburgh/jest-serializer-vue) 包，然后在 [setupFiles](/config/#setupfiles) 中配置：
 
+:::code-group
+```js [vite.config.js]
+import { defineConfig } from 'vite'
 export default defineConfig({
   test: {
-    snapshotSerializers: ['jest-serializer-vue']
-  }
+    setupFiles: ['./tests/unit/setup.js'],
+  },
 })
 ```
+```js [tests/unit/setup.js]
+import vueSnapshotSerializer from 'jest-serializer-vue'
+expect.addSnapshotSerializer(vueSnapshotSerializer)
+```
+:::
 
-否则快照中会出现大量转义的 `"` 字符。
+否则你的快照将出现大量的 `"` 字符。

From 9eb63977099320cd6c5c252a5b543a5d8d2fe172 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Thu, 13 Nov 2025 00:26:50 +0800
Subject: [PATCH 02/50] !docs: recovery /guide/coverage

---
 .vitepress/config.ts |   4 +-
 guide/coverage.md    | 213 ++++++-------------------------------------
 2 files changed, 32 insertions(+), 185 deletions(-)

diff --git a/.vitepress/config.ts b/.vitepress/config.ts
index f5e1e610..750977bc 100644
--- a/.vitepress/config.ts
+++ b/.vitepress/config.ts
@@ -659,8 +659,8 @@ function guide(): DefaultTheme.SidebarItem[] {
       collapsed: false,
       items: [
         {
-          text: '迁移到 Vitest 4.0',
-          link: '/guide/migration#vitest-4',
+          text: '迁移到 Vitest 3.0',
+          link: '/guide/migration#vitest-3',
         },
         {
           text: '从 Jest 迁移',
diff --git a/guide/coverage.md b/guide/coverage.md
index ea19b509..47ab5c5d 100644
--- a/guide/coverage.md
+++ b/guide/coverage.md
@@ -135,14 +135,15 @@ globalThis.__VITEST_COVERAGE__[filename] = coverage // [!code ++]
 
 ## 覆盖率配置指南 {#coverage-setup}
 
-::: tip
-你可以在 [覆盖率配置参考](/config/#coverage) 中查看所有可用的覆盖率选项。
+:::tip
+建议始终在配置文件中定义 [`coverage.include`](/config/#coverage-include)。
+这有助于 Vitest 减少 [`coverage.all`](/config/#coverage-all) 选择的文件数量。
 :::
 
-如果想要在测试中开启覆盖率统计，可以在命令行里加上 `--coverage` 参数，或者在 `vitest.config.ts` 文件里将 `coverage.enabled` 设置为 `true` ：
+要在启用的情况下进行测试，你可以在 CLI 中传递 `--coverage` 标志。
+默认情况下, 将使用 `['text', 'html', 'clover', 'json']` 作为测试报告器。
 
-::: code-group
-```json [package.json]
+```json
 {
   "scripts": {
     "test": "vitest",
@@ -150,91 +151,21 @@ globalThis.__VITEST_COVERAGE__[filename] = coverage // [!code ++]
   }
 }
 ```
-```ts [vitest.config.ts]
-import { defineConfig } from 'vitest/config'
 
-export default defineConfig({
-  test: {
-    coverage: {
-      enabled: true
-    },
-  },
-})
-```
-:::
-
-## 在覆盖率报告中设置需要统计或忽略的文件 {#including-and-excluding-files-from-coverage-report}
-
-你可以通过设置 [`coverage.include`](/config/#coverage-include) 和 [`coverage.exclude`](/config/#coverage-exclude) 来决定覆盖率报告中展示哪些文件。
+要对其进行配置，需要在配置文件中设置 `test.coverage` 选项：
 
-Vitest 默认只统计测试中实际导入的文件。如果希望报告里也包含那些未被测试覆盖到的文件，需要在 [`coverage.include`](/config/#coverage-include) 中配置一个能匹配你源代码文件的模式：
-
-::: code-group
-```ts [vitest.config.ts] {6}
+```ts
+// vitest.config.ts
 import { defineConfig } from 'vitest/config'
 
 export default defineConfig({
   test: {
     coverage: {
-      include: ['src/**.{ts,tsx}']
+      reporter: ['text', 'json', 'html'],
     },
   },
 })
 ```
-```sh [Covered Files]
-├── src
-│   ├── components
-│   │   └── counter.tsx   # [!code ++]
-│   ├── mock-data
-│   │   ├── products.json # [!code error]
-│   │   └── users.json    # [!code error]
-│   └── utils
-│       ├── formatters.ts # [!code ++]
-│       ├── time.ts       # [!code ++]
-│       └── users.ts      # [!code ++]
-├── test
-│   └── utils.test.ts     # [!code error]
-│
-├── package.json          # [!code error]
-├── tsup.config.ts        # [!code error]
-└── vitest.config.ts      # [!code error]
-```
-:::
-
-如果你想从覆盖率中排除已经被 `coverage.include` 匹配到的部分文件，可以通过额外配置 [`coverage.exclude`](/config/#coverage-exclude) 来实现：
-
-::: code-group
-```ts [vitest.config.ts] {7}
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    coverage: {
-      include: ['src/**.{ts,tsx}'],
-      exclude: ['**/utils/users.ts']
-    },
-  },
-})
-```
-```sh [Covered Files]
-├── src
-│   ├── components
-│   │   └── counter.tsx   # [!code ++]
-│   ├── mock-data
-│   │   ├── products.json # [!code error]
-│   │   └── users.json    # [!code error]
-│   └── utils
-│       ├── formatters.ts # [!code ++]
-│       ├── time.ts       # [!code ++]
-│       └── users.ts      # [!code error]
-├── test
-│   └── utils.test.ts     # [!code error]
-│
-├── package.json          # [!code error]
-├── tsup.config.ts        # [!code error]
-└── vitest.config.ts      # [!code error]
-```
-:::
 
 ## 自定义覆盖率的报告器 {#custom-coverage-reporter}
 
@@ -334,14 +265,31 @@ export default CustomCoverageProviderModule
 
 请参阅类型定义查看有关详细信息。
 
+## 更改默认覆盖文件夹位置 {#changing-the-default-coverage-folder-location}
+
+运行覆盖率报告时，会在项目的根目录中创建一个 `coverage` 文件夹。 如果你想将它移动到不同的目录，请使用 `vite.config.js` 文件中的 `test.coverage.reportsDirectory` 属性。
+
+```js
+import { defineConfig } from 'vite'
+
+export default defineConfig({
+  test: {
+    coverage: {
+      reportsDirectory: './tests/unit/coverage',
+    },
+  },
+})
+```
+
 ## 代码忽略 {#ignoring-code}
 
 两个覆盖率提供商都有自己的方法来忽略覆盖率报告中的代码：
 
 - [`v8`](https://github.com/AriPerkkio/ast-v8-to-istanbul?tab=readme-ov-file#ignoring-code)
 - [`istanbul`](https://github.com/istanbuljs/nyc#parsing-hints-ignoring-lines)
+- 启用 [`experimentalAstAwareRemapping: true`](/config/#coverage-experimentalAstAwareRemapping) `v8` 的覆盖率工具，详见 [ast-v8-to-istanbul | 代码忽略](https://github.com/AriPerkkio/ast-v8-to-istanbul?tab=readme-ov-file#ignoring-code)
 
-使用 TypeScript 时，源代码使用 `esbuild` 进行转译，这会从源代码中删除所有注释([esbuild#516](https://github.com/evanw/esbuild/issues/516))。
+使用 TypeScript 时，源码使用 `esbuild` 进行转译，这会从源码中删除所有注释([esbuild#516](https://github.com/evanw/esbuild/issues/516))。
 被视为[合法注释](https://esbuild.github.io/api/#legal-comments)的注释将被保留。
 
 你可以在忽略提示里加入 `@preserve` 关键字。
@@ -357,110 +305,9 @@ if (condition) {
 if (condition) {
 ```
 
-### 示例 {#examples}
-
-::: code-group
-
-```ts [if else]
-/* v8 ignore if -- @preserve */
-if (parameter) { // [!code error]
-  console.log('Ignored') // [!code error]
-} // [!code error]
-else {
-  console.log('Included')
-}
-
-/* v8 ignore else -- @preserve */
-if (parameter) {
-  console.log('Included')
-}
-else { // [!code error]
-  console.log('Ignored') // [!code error]
-} // [!code error]
-```
+## 其他选项 {#other-options}
 
-```ts [next node]
-/* v8 ignore next -- @preserve */
-console.log('Ignored') // [!code error]
-console.log('Included')
-
-/* v8 ignore next -- @preserve */
-function ignored() { // [!code error]
-  console.log('all') // [!code error]
-  // [!code error]
-  console.log('lines') // [!code error]
-  // [!code error]
-  console.log('are') // [!code error]
-  // [!code error]
-  console.log('ignored') // [!code error]
-} // [!code error]
-
-/* v8 ignore next -- @preserve */
-class Ignored { // [!code error]
-  ignored() {} // [!code error]
-  alsoIgnored() {} // [!code error]
-} // [!code error]
-
-/* v8 ignore next -- @preserve */
-condition // [!code error]
-  ? console.log('ignored') // [!code error]
-  : console.log('also ignored') // [!code error]
-```
-
-```ts [try catch]
-/* v8 ignore next -- @preserve */
-try { // [!code error]
-  console.log('Ignored') // [!code error]
-} // [!code error]
-catch (error) { // [!code error]
-  console.log('Ignored') // [!code error]
-} // [!code error]
-
-try {
-  console.log('Included')
-}
-catch (error) {
-  /* v8 ignore next -- @preserve */
-  console.log('Ignored') // [!code error]
-  /* v8 ignore next -- @preserve */
-  console.log('Ignored') // [!code error]
-}
-
-// 由于 esbuild 不支持，需要使用 rolldown-vite。
-// 参阅 https://vite.dev/guide/rolldown.html#how-to-try-rolldown
-try {
-  console.log('Included')
-}
-catch (error) /* v8 ignore next */ { // [!code error]
-  console.log('Ignored') // [!code error]
-} // [!code error]
-```
-
-```ts [switch case]
-switch (type) {
-  case 1:
-    return 'Included'
-
-  /* v8 ignore next -- @preserve */
-  case 2: // [!code error]
-    return 'Ignored' // [!code error]
-
-  case 3:
-    return 'Included'
-
-  /* v8 ignore next -- @preserve */
-  default: // [!code error]
-    return 'Ignored' // [!code error]
-}
-```
-
-```ts [whole file]
-/* v8 ignore file -- @preserve */
-export function ignored() { // [!code error]
-  return 'Whole file is ignored'// [!code error]
-}// [!code error]
-```
-:::
+要查看有关覆盖率的所有可配置选项，请参见 [覆盖率配置参考](https://cn.vitest.dev/config/#coverage)。
 
 ## 覆盖率性能 {#coverage-performance}
 

From 3f797e9ccf81e1280ae374dfde9eb595c902ce46 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Thu, 13 Nov 2025 01:13:34 +0800
Subject: [PATCH 03/50] !docs: recovery /guide/reporters

---
 guide/reporters.md | 68 ++++++++++++----------------------------------
 1 file changed, 17 insertions(+), 51 deletions(-)

diff --git a/guide/reporters.md b/guide/reporters.md
index 65436754..5a58c018 100644
--- a/guide/reporters.md
+++ b/guide/reporters.md
@@ -142,67 +142,31 @@ export default defineConfig({
    Duration  1.26s (transform 35ms, setup 1ms, collect 90ms, tests 1.47s, environment 0ms, prepare 267ms)
 ```
 
-如果只有一个测试文件在运行，Vitest 将输出该文件的完整测试树，类似于 [`tree`](#tree-reporter) 报告器。如果文件中至少有一个测试失败，default 报告器也会打印测试树。
+### 基础报告器 {#basic-reporter}
 
-```bash
-✓ __tests__/file1.test.ts (2) 725ms
-   ✓ first test file (2) 725ms
-     ✓ 2 + 2 should equal 4
-     ✓ 4 - 2 should equal 2
-
- Test Files  1 passed (1)
-      Tests  2 passed (2)
-   Start at  12:34:32
-   Duration  1.26s (transform 35ms, setup 1ms, collect 90ms, tests 1.47s, environment 0ms, prepare 267ms)
-```
-
-### 详细报告器 {#verbose-reporter}
-
-详细报告器会在每个测试用例完成后打印出来。它不会单独报告套件或文件。如果启用了 `--includeTaskLocation`，它还会在输出中包含每个测试的位置。与 `default` 报告器类似，你可以通过配置报告器来禁用摘要。
-
-除此之外，`verbose` 报告器会立即打印测试错误消息。完整的测试错误会在测试运行结束时报告。
-
-这是唯一一个在测试未失败时报告[注解](/guide/test-annotations)的终端报告器。
+`basic` 报告器等同于没有 `summary` 的 `default` 报告器。
 
 :::code-group
 
 ```bash [CLI]
-npx vitest --reporter=verbose
+npx vitest --reporter=basic
 ```
 
 ```ts [vitest.config.ts]
 export default defineConfig({
   test: {
-    reporters: [
-      ['verbose', { summary: false }]
-    ]
+    reporters: ['basic'],
   },
 })
 ```
 
 :::
 
-Example output:
+使用基础报告器的输出示例:
 
 ```bash
-✓ __tests__/file1.test.ts > first test file > 2 + 2 should equal 4 1ms
-✓ __tests__/file1.test.ts > first test file > 4 - 2 should equal 2 1ms
-✓ __tests__/file2.test.ts > second test file > 1 + 1 should equal 2 1ms
-✓ __tests__/file2.test.ts > second test file > 2 - 1 should equal 1 1ms
-
- Test Files  2 passed (2)
-      Tests  4 passed (4)
-   Start at  12:34:32
-   Duration  1.26s (transform 35ms, setup 1ms, collect 90ms, tests 1.47s, environment 0ms, prepare 267ms)
-```
-
-一个带有 `--includeTaskLocation` 参数的示例：
-
-```bash
-✓ __tests__/file1.test.ts:2:1 > first test file > 2 + 2 should equal 4 1ms
-✓ __tests__/file1.test.ts:3:1 > first test file > 4 - 2 should equal 2 1ms
-✓ __tests__/file2.test.ts:2:1 > second test file > 1 + 1 should equal 2 1ms
-✓ __tests__/file2.test.ts:3:1 > second test file > 2 - 1 should equal 1 1ms
+✓ __tests__/file1.test.ts (2) 725ms
+✓ __tests__/file2.test.ts (2) 746ms
 
  Test Files  2 passed (2)
       Tests  4 passed (4)
@@ -210,24 +174,26 @@ Example output:
    Duration  1.26s (transform 35ms, setup 1ms, collect 90ms, tests 1.47s, environment 0ms, prepare 267ms)
 ```
 
-### 树状报告器 {#tree-reporter}
+### 详细报告器 {#verbose-reporter}
 
-树状报告器与 `default` 报告器相同，但它还会在套件完成后显示每个单独的测试。与 `default` 报告器类似，你可以通过配置报告器来禁用摘要。
+详细报告器与 `default` 报告器相同，但它还会在测试套件完成后显示每个单独的测试。它还会显示当前正在运行且耗时超过 [`slowTestThreshold`](/config/#slowtestthreshold) 的测试。与 `default` 报告器类似，我们可以通过配置报告器来禁用摘要。
 
 :::code-group
+
 ```bash [CLI]
-npx vitest --reporter=tree
+npx vitest --reporter=verbose
 ```
 
 ```ts [vitest.config.ts]
 export default defineConfig({
   test: {
     reporters: [
-      ['tree', { summary: false }]
+      ['verbose', { summary: false }]
     ]
   },
 })
 ```
+
 :::
 
 使用默认 `slowTestThreshold: 300` 的情况下，测试进行中的示例输出：
@@ -268,7 +234,7 @@ export default defineConfig({
 
 ### Dot 报告器 {#dot-reporter}
 
-每当一个测试完成时，就会打印一个点，以最小化输出量，同时让你看到所有执行过的测试。只有当测试失败时才会显示详细信息，并在最后提供套件的汇总。
+为每个已完成的测试打印一个点，以提供最少的输出，并显示所有已运行的测试。只提供失败测试的详细信息，以及套件的基本报告摘要。
 
 :::code-group
 
@@ -417,7 +383,7 @@ JSON 报告示例:
 ```
 
 ::: info
-自Vitest 3起，如果启用了代码覆盖率功能，JSON 报告器会在 `coverageMap` 中包含覆盖率信息。
+自 Vitest 3 起，如果启用了代码覆盖率功能，JSON 报告器会在 `coverageMap` 中包含覆盖率信息。
 :::
 
 ### HTML 报告器 {#html-reporter}
@@ -448,7 +414,7 @@ export default defineConfig({
 
 ### TAP 报告器 {#tap-reporter}
 
-按照 [Test Anything Protocol](https://testanything.org/) (TAP)输出报告。
+按照 [Test Anything Protocol](https://testanything.org/) (TAP) 输出报告。
 
 :::code-group
 
@@ -491,7 +457,7 @@ not ok 1 - __tests__/test-file-1.test.ts # time=14.00ms {
 
 ### TAP 扁平报告器 {#tap-flat-reporter}
 
-输出 TAP 扁平报告。与 `TAP Reporter` 一样，测试结果的格式遵循 TAP 标准，但测试套件的格式是扁平列表，而不是嵌套层次结构。
+输出 TAP 扁平报告。与 `TAP` 报告器一样，测试结果的格式遵循 TAP 标准，但测试套件的格式是扁平列表，而不是嵌套层次结构。
 
 :::code-group
 

From 8e703f673a5b79dcc9a2efb56bc9307f46adf7f2 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Thu, 13 Nov 2025 01:37:07 +0800
Subject: [PATCH 04/50] !docs: recovery /guide/profiling-test-performance

---
 guide/profiling-test-performance.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/guide/profiling-test-performance.md b/guide/profiling-test-performance.md
index 0e1c3287..639fe939 100644
--- a/guide/profiling-test-performance.md
+++ b/guide/profiling-test-performance.md
@@ -83,9 +83,9 @@ export default defineConfig({
 ```
 :::
 
-测试运行后，应该会生成 `test-runner-profile/*.cpuprofile` 和 `test-runner-profile/*.heapprofile` 文件。想要知道如何分析这些文件，可以仔细查看[「 检查分析记录 / Inspecting profiling records 」](#inspecting-profiling-records)。
+测试运行后，应该会生成 `test-runner-profile/*.cpuprofile` 和 `test-runner-profile/*.heapprofile` 文件。想要知道如何分析这些文件，可以仔细查看 [性能分析记录](#inspecting-profiling-records)。
 
-也可以看看[性能分析 | 示例](https://github.com/vitest-dev/vitest/tree/main/examples/profiling)。
+也可以看看 [性能分析 | 示例](https://github.com/vitest-dev/vitest/tree/main/examples/profiling) 。
 
 ## 主线程 {#main-thread}
 

From b1011c3333c64e265e52097bcd0a9750527eb20f Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Thu, 13 Nov 2025 11:10:49 +0800
Subject: [PATCH 05/50] !docs: recovery /guide/index

---
 guide/index.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/guide/index.md b/guide/index.md
index 91927ec2..61d070ac 100644
--- a/guide/index.md
+++ b/guide/index.md
@@ -66,7 +66,7 @@ test('adds 1 + 2 to equal 3', () => {
 ```
 
 ::: tip 提示
-一般情况下，执行测试的文件名中必须包含 ".test." 或 ".spec." 。
+一般情况下，执行测试的文件名中必须包含 `.test.` 或 `.spec.` 。
 :::
 
 接下来，为了执行测试，请将以下部分添加到你的 `package.json` 文件中：
@@ -120,7 +120,7 @@ export default defineConfig({
 ```
 
 ::: tip 提示
-即使你自己不使用 Vite，Vitest 的转换管道也严重依赖它。因此，你还可以配置[Vite 文档](https://cn.vitejs.dev/config/)中描述的任何属性。
+即使你自己不使用 Vite，Vitest 的转换管道也严重依赖它。因此，你还可以配置 [Vite 文档](https://cn.vitejs.dev/config/) 中描述的任何属性。
 :::
 
 如果你已经在使用 Vite，请在 Vite 配置中添加 `test` 属性。你还需要使用 [三斜杠指令](https://www.typescriptlang.org/docs/handbook/triple-slash-directives.html#-reference-types-) 在你的配置文件的顶部引用。
@@ -168,7 +168,7 @@ export default defineConfig({
 
 ## 多项目支持 {#projects-support}
 
-通过 [测试项目](/guide/projects) 功能，你可以在同一个项目里运行多套不同的配置。只需在 vitest.config 文件中列出对应的文件和文件夹，即可定义各个项目。
+通过 [测试项目](/guide/projects) 功能，你可以在同一个项目里运行多套不同的配置。只需在 `vitest.config` 文件中列出对应的文件和文件夹，即可定义各个项目。
 
 ```ts [vitest.config.ts]
 import { defineConfig } from 'vitest/config'
@@ -221,7 +221,7 @@ export default defineConfig({
 要在不监视文件更改的情况下运行一次测试，请使用 `vitest run`。
 你还可以指定其他 CLI 选项，例如 `--port` 或 `--https`。 有关 CLI 选项的完整列表，可以在你的项目中运行 `npx vitest --help`。
 
-了解更多有关 [命令行界面](/guide/cli) 的更多信息
+了解更多有关 [命令行界面](/guide/cli) 的信息
 
 ## 自动安装依赖项 {#automatic-dependency-installation}
 
@@ -233,7 +233,7 @@ export default defineConfig({
 
 [从 VS Code 插件市场进行安装](https://marketplace.visualstudio.com/items?itemName=vitest.explorer)
 
-了解更多有关 [IDE 插件](/guide/ide) 的更多信息
+了解更多有关 [IDE 插件](/guide/ide) 的信息
 
 ## 示例 {#examples}
 

From 1e8df5f9dcba7c20d28aa059f8319f3b25f9e71e Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Sat, 15 Nov 2025 22:22:34 +0800
Subject: [PATCH 06/50] !docs: recovery /guide/features

---
 .vitepress/components/FeaturesList.vue |  6 +++---
 .vitepress/config.ts                   |  4 ++--
 guide/features.md                      | 17 +++++++++--------
 3 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/.vitepress/components/FeaturesList.vue b/.vitepress/components/FeaturesList.vue
index dd43d850..fa581170 100644
--- a/.vitepress/components/FeaturesList.vue
+++ b/.vitepress/components/FeaturesList.vue
@@ -21,7 +21,7 @@
       支持基准测试
     </ListItem>
     <ListItem>支持套件和测试的过滤、超时、并发配置</ListItem>
-    <ListItem>支持 <a href="/guide/projects">Projects</a> / <a href="/guide/workspace">Workspace</a></ListItem>
+    <ListItem>支持 <a href="/guide/projects">Projects</a></ListItem>
     <ListItem>
       <a href="/guide/snapshot">Jest 快照功能</a>
     </ListItem>
@@ -37,8 +37,8 @@
     </ListItem>
     <ListItem>
       使用
-      <a target="_blank" href="https://github.com/jsdom/jsdom" rel="noopener noreferrer">jsdom</a> 或
-      <a target="_blank" href="https://github.com/capricorn86/happy-dom" rel="noopener noreferrer">happy-dom</a>
+      <a target="_blank" href="https://github.com/capricorn86/happy-dom" rel="noopener noreferrer">happy-dom</a> 或
+      <a target="_blank" href="https://github.com/jsdom/jsdom" rel="noopener noreferrer">jsdom</a>
       模拟 DOM
     </ListItem>
     <ListItem><a href="/guide/browser/" rel="noopener noreferrer">浏览器模式</a>：在浏览器中运行组件测试</ListItem>
diff --git a/.vitepress/config.ts b/.vitepress/config.ts
index 750977bc..f2ecccc1 100644
--- a/.vitepress/config.ts
+++ b/.vitepress/config.ts
@@ -567,11 +567,11 @@ function guide(): DefaultTheme.SidebarItem[] {
       link: '/guide/reporters',
     },
     {
-      text: '测试覆盖率',
+      text: '覆盖率',
       link: '/guide/coverage',
     },
     {
-      text: '测试快照',
+      text: '快照',
       link: '/guide/snapshot',
     },
     {
diff --git a/guide/features.md b/guide/features.md
index 739d5675..b17db28b 100644
--- a/guide/features.md
+++ b/guide/features.md
@@ -7,14 +7,15 @@ outline: deep
 
 <FeaturesList class="!gap-1 text-lg" />
 
+<CourseLink href="https://vueschool.io/lessons/your-first-test?friend=vueuse">通过视频了解如何编写你的第一个测试</CourseLink>
+
 ## 一套配置可以运用在多种环境 {#shared-config-between-test-dev-and-build}
 
 <div h-2 />
-<CourseLink href="https://vueschool.io/lessons/your-first-test?friend=vueuse">通过视频了解如何编写你的第一个测试</CourseLink>
 
 与 Vite 的配置、转换器、解析器和插件通用，将会使用应用中的相同配置来运行测试。
 
-了解更多信息 [配置 Vitest](/guide/#配置-vitest)
+了解更多信息 [配置 Vitest](/guide/#configuring-vitest) 。
 
 ## 监听模式(watch mode) {#watch-mode}
 
@@ -45,7 +46,7 @@ Vitest 还隔离了每个测试文件的运行环境，因此一个文件中的
 
 Vitest 提供了许多缩小测试范围的方法，以便在开发过程中加快速度并集中精力。
 
-了解更多信息 [测试筛选](/guide/filtering)
+了解更多信息 [测试筛选](/guide/filtering) 。
 
 ## 同时运行多个测试 {#running-tests-concurrently}
 
@@ -116,7 +117,7 @@ it('renders correctly', () => {
 
 注意，如果你正在使用添加匹配器的第三方库，将 [`test.globals`](/config/#globals) 设置为 `true` 将提供更好的兼容性。
 
-## 对象模拟(Mocking) {#mocking}
+## 对象模拟 (Mocking) {#mocking}
 
 内置 [Tinyspy](https://github.com/tinylibs/tinyspy) 用于在 `vi` 对象上使用 `jest` 兼容的 API 进行对象模拟。
 
@@ -157,7 +158,7 @@ export default defineConfig({
 })
 ```
 
-了解更多信息 [模拟对象](/guide/mocking)
+了解更多信息 [模拟对象](/guide/mocking) 。
 
 ## 测试覆盖率 {#coverage}
 
@@ -187,11 +188,11 @@ export default defineConfig({
 })
 ```
 
-了解更多信息 [测试覆盖率](/guide/coverage)
+了解更多信息 [覆盖率](/guide/coverage) 。
 
 ## 源码内联测试 {#in-source-testing}
 
-Vitest 还提供了一种方式，可以运行与你的代码实现放在一起的测试，类似 [Rust's 模块测试](https://doc.rust-lang.org/book/ch11-03-test-organization.html#the-tests-module-and-cfgtest).
+Vitest 还提供了一种方式，可以运行与你的代码实现放在一起的测试，类似 [Rust 模块测试](https://doc.rust-lang.org/book/ch11-03-test-organization.html#the-tests-module-and-cfgtest).
 
 这使得测试与实现共享相同的闭包，并且能够在不导出的情况下针对私有状态进行测试。同时，它也使开发更加接近反馈循环。
 
@@ -211,7 +212,7 @@ if (import.meta.vitest) {
 }
 ```
 
-了解更多信息 [源码内联测试](/guide/in-source)
+了解更多信息 [源码内联测试](/guide/in-source) 。
 
 ## 基准测试 <Badge type="warning">实验性</Badge> {#benchmarking}
 

From 939aa8960ad21633296cc25b39e26ca49ce8ae93 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Sat, 15 Nov 2025 23:50:37 +0800
Subject: [PATCH 07/50] !docs: recovery /api/index

---
 api/index.md | 125 +++++++++++++++++++--------------------------------
 1 file changed, 46 insertions(+), 79 deletions(-)

diff --git a/api/index.md b/api/index.md
index fb1ad821..466632cd 100644
--- a/api/index.md
+++ b/api/index.md
@@ -35,7 +35,7 @@ interface TestOptions {
 当测试函数返回一个 promise 时，运行器会等待它解析结束收集异步的结果。如果 promise 被拒绝，测试就会失败。
 
 ::: tip
-在 Jest 中，`TestFunction` 也可以是 `(done: DoneCallback) => void` 类型。如果使用这种形式，测试将在调用 `done` 之前不会结束。也可以使用 `async` 函数来实现相同的效果，请参阅[迁移指南中的回调完成部分](/guide/migration#回调完成)。
+在 Jest 中，`TestFunction` 也可以是 `(done: DoneCallback) => void` 类型。如果使用这种形式，测试将在调用 `done` 之前不会结束。也可以使用 `async` 函数来实现相同的效果，请参阅 [迁移指南中的回调完成部分](/guide/migration.html#done-callback)。
 
 :::
 
@@ -108,7 +108,7 @@ test('heavy test', { skip: true, timeout: 10_000 }, () => {
 
 `test` 定义了一组相关的期望。 它接收测试名称和保存测试期望的函数。
 
-或者，我们可以提供超时（以毫秒为单位）来指定终止前等待的时间。 默认为 5 秒，可以通过 [testTimeout](/config/#testtimeout) 进行全局配置
+或者，我们可以提供超时（以毫秒为单位）来指定终止前等待的时间。 默认为 5 秒，可以通过 [testTimeout](/config/#testtimeout) 进行全局配置。
 
 ```ts
 import { expect, test } from 'vitest'
@@ -123,7 +123,7 @@ test('should work as expected', () => {
 - **类型:** `<T extends Record<string, any>>(fixtures: Fixtures<T>): TestAPI<ExtraContext & T>`
 - **别名:** `it.extend`
 
-使用 `test.extend` 来使用自定义的 fixtures 扩展测试上下文。这将返回一个新的 `test`，它也是可扩展的，因此可以根据需要扩展更多的 fixtures 或覆盖现有的 fixtures。有关更多信息，请参阅[扩展测试上下文](/guide/test-context.html#test-extend)。
+使用 `test.extend` 来使用自定义的 fixtures 扩展测试上下文。这将返回一个新的 `test`，它也是可扩展的，因此可以根据需要扩展更多的 fixtures 或覆盖现有的 fixtures。有关更多信息，请参阅 [扩展测试上下文](/guide/test-context.html#test-extend)。
 
 ```ts
 import { expect, test } from 'vitest'
@@ -176,7 +176,7 @@ test('skipped test', (context) => {
 })
 ```
 
-自 Vitest 3.1 起，如果你无法提前确定是否跳过，可以把条件直接作为第一个参数传给 `skip 方法：
+自 Vitest 3.1 起，如果你无法提前确定是否跳过，可以把条件直接作为第一个参数传给 `skip` 方法：
 
 ```ts
 import { assert, test } from 'vitest'
@@ -206,7 +206,7 @@ test.skipIf(isDev)('prod only test', () => {
 ```
 
 ::: warning
-在将 Vitest 用作[类型检查器](/guide/testing-types)时，不能使用此语法。
+在将 Vitest 用作 [类型检查器](/guide/testing-types) 时，不能使用此语法。
 :::
 
 ### test.runIf
@@ -227,7 +227,7 @@ test.runIf(isDev)('dev only test', () => {
 ```
 
 ::: warning
-在将 Vitest 用作[类型检查器](/guide/testing-types)时，不能使用此语法。
+在将 Vitest 用作 [类型检查器](/guide/testing-types) 时，不能使用此语法。
 :::
 
 ### test.only
@@ -248,7 +248,7 @@ test.only('test', () => {
 })
 ```
 
-有时，只运行某个文件中的 "测试"，而忽略整个 测试套件 中的所有其他测试是非常有用的，因为这些测试会污染输出。
+有时，只运行某个文件中的 "测试"，而忽略整个测试套件中的所有其他测试是非常有用的，因为这些测试会污染输出。
 
 为此，请使用包含相关测试的特定文件运行 `vitest`。
 
@@ -289,7 +289,7 @@ test.only.concurrent(/* ... */) // or test.concurrent.only(/* ... */)
 test.todo.concurrent(/* ... */) // or test.concurrent.todo(/* ... */)
 ```
 
-运行并发测试时，快照和断言必须使用本地[测试上下文](/guide/test-context.md)中的 `expect`，以确保检测到正确的测试。
+运行并发测试时，快照和断言必须使用本地 [测试上下文](/guide/test-context.md) 中的 `expect`，以确保检测到正确的测试。
 
 ```ts
 test.concurrent('test 1', async ({ expect }) => {
@@ -301,12 +301,13 @@ test.concurrent('test 2', async ({ expect }) => {
 ```
 
 ::: warning
-在将 Vitest 用作[类型检查器](/guide/testing-types)时，不能使用此语法。
+在将 Vitest 用作 [类型检查器](/guide/testing-types) 时，不能使用此语法。
 :::
 
 ### test.sequential
 
 - **类型:** `(name: string | Function, fn: TestFunction, timeout?: number) => void`
+- **别名:** `it.sequential`
 
 `test.sequential` 标记一个测试为顺序测试。如果要在 `describe.concurrent` 中或使用 `--sequence.concurrent` 命令选项按顺序运行测试，这一点非常有用。
 
@@ -314,35 +315,19 @@ test.concurrent('test 2', async ({ expect }) => {
 import { describe, test } from 'vitest'
 
 // 使用配置选项 `{ sequence: { concurrent: true } }`
-test('concurrent test 1', async () => {
-  /* ... */
-})
-test('concurrent test 2', async () => {
-  /* ... */
-})
+test('concurrent test 1', async () => { /* ... */ })
+test('concurrent test 2', async () => { /* ... */ })
 
-test.sequential('sequential test 1', async () => {
-  /* ... */
-})
-test.sequential('sequential test 2', async () => {
-  /* ... */
-})
+test.sequential('sequential test 1', async () => { /* ... */ })
+test.sequential('sequential test 2', async () => { /* ... */ })
 
 // 在并发套件中
 describe.concurrent('suite', () => {
-  test('concurrent test 1', async () => {
-    /* ... */
-  })
-  test('concurrent test 2', async () => {
-    /* ... */
-  })
+  test('concurrent test 1', async () => { /* ... */ })
+  test('concurrent test 2', async () => { /* ... */ })
 
-  test.sequential('sequential test 1', async () => {
-    /* ... */
-  })
-  test.sequential('sequential test 2', async () => {
-    /* ... */
-  })
+  test.sequential('sequential test 1', async () => { /* ... */ })
+  test.sequential('sequential test 2', async () => { /* ... */ })
 })
 ```
 
@@ -360,7 +345,6 @@ test.todo('unimplemented test')
 
 ### test.fails
 
-- **类型:** `(name: string | Function, fn: TestFunction, timeout?: number) => void`
 - **别名:** `it.fails`
 
 使用 `test.fails` 明确表示断言将失败。
@@ -377,7 +361,7 @@ test.fails('fail test', async () => {
 ```
 
 ::: warning
-在将 Vitest 用作[类型检查器](/guide/testing-types)时，不能使用此语法。
+在将 Vitest 用作 [类型检查器](/guide/testing-types) 时，不能使用此语法。
 :::
 
 ### test.each
@@ -487,7 +471,7 @@ Vitest 使用 chai `format` 方法处理 `$values`。如果数值太短，可以
 :::
 
 ::: warning
-在将 Vitest 用作[类型检查器](/guide/testing-types)时，不能使用此语法。
+在将 Vitest 用作 [类型检查器](/guide/testing-types) 时，不能使用此语法。
 :::
 
 ### test.for
@@ -504,8 +488,8 @@ test.each([
   [1, 1, 2],
   [1, 2, 3],
   [2, 1, 3],
-])('add(%i, %i) -> %i', (a, b, expected) => {
   // [!code --]
+])('add(%i, %i) -> %i', (a, b, expected) => {
   expect(a + b).toBe(expected)
 })
 
@@ -514,8 +498,8 @@ test.for([
   [1, 1, 2],
   [1, 2, 3],
   [2, 1, 3],
-])('add(%i, %i) -> %i', ([a, b, expected]) => {
   // [!code ++]
+])('add(%i, %i) -> %i', ([a, b, expected]) => {
   expect(a + b).toBe(expected)
 })
 ```
@@ -856,6 +840,7 @@ describe('numberToCurrency', () => {
 ### describe.skip
 
 - **类型:** `(name: string | Function, fn: TestFunction, options?: number | TestOptions) => void`
+- **别名:** `suite.skip`
 
 在套件中使用 `describe.skip` 可避免运行特定的 describe 块。
 
@@ -873,6 +858,7 @@ describe.skip('skipped suite', () => {
 ### describe.skipIf
 
 - **类型:** `(condition: any) => void`
+- **别名:** `suite.skipIf`
 
 在某些情况下，可能会在不同的环境下多次运行套件，其中一些测试套件可能是特定于环境的。可以使用 `describe.skipIf` 来跳过条件为真时的套件，而不是使用 `if` 来封装套件。
 
@@ -893,6 +879,7 @@ describe.skipIf(isDev)('prod only test suite', () => {
 ### describe.runIf
 
 - **类型:** `(condition: any) => void`
+- **别名:** `suite.runIf`
 
 与 [describe.skipIf](#describe-skipif) 相反。
 
@@ -931,11 +918,9 @@ describe('other suite', () => {
 })
 ```
 
-为了做到这一点，请使用包含相关测试的特定文件来运行 `vitest`。
-
 有时，只运行某个文件中的测试套件，而忽略整个测试套件中的所有其他测试是非常有用的，因为这些测试会污染输出。
 
-要做到这一点，请在包含相关测试的特定文件中运行 `vitest`。
+为了做到这一点，请使用包含相关测试的特定文件来运行 `vitest`。
 
 ```
 # vitest interesting.test.ts
@@ -978,7 +963,7 @@ describe.only.concurrent(/* ... */) // 或 describe.concurrent.only(/* ... */)
 describe.todo.concurrent(/* ... */) // 或 describe.concurrent.todo(/* ... */)
 ```
 
-运行并发测试时，快照和断言必须使用本地[测试上下文](/guide/test-context.md)中的 `expect` ，以确保检测到正确的测试。
+运行并发测试时，快照和断言必须使用本地 [测试上下文](/guide/test-context.md) 中的 `expect` ，以确保检测到正确的测试。
 
 ```ts
 describe.concurrent('suite', () => {
@@ -992,12 +977,13 @@ describe.concurrent('suite', () => {
 ```
 
 ::: warning
-在将 Vitest 用作[类型检查器](/guide/testing-types)时，不能使用此语法。
+在将 Vitest 用作 [类型检查器](/guide/testing-types) 时，不能使用此语法。
 :::
 
 ### describe.sequential
 
 - **类型:** `(name: string | Function, fn: TestFunction, options?: number | TestOptions) => void`
+- **别名:** `suite.sequential`
 
 测试套件中的 `describe.sequential` 会将每个测试标记为顺序测试。如果需要在 `describe.concurrent` 中或使用 `--sequence.concurrent` 命令选项按顺序运行测试，这一点非常有用。
 
@@ -1005,20 +991,12 @@ describe.concurrent('suite', () => {
 import { describe, test } from 'vitest'
 
 describe.concurrent('suite', () => {
-  test('concurrent test 1', async () => {
-    /* ... */
-  })
-  test('concurrent test 2', async () => {
-    /* ... */
-  })
+  test('concurrent test 1', async () => { /* ... */ })
+  test('concurrent test 2', async () => { /* ... */ })
 
   describe.sequential('', () => {
-    test('sequential test 1', async () => {
-      /* ... */
-    })
-    test('sequential test 2', async () => {
-      /* ... */
-    })
+    test('sequential test 1', async () => { /* ... */ })
+    test('sequential test 2', async () => { /* ... */ })
   })
 })
 ```
@@ -1026,6 +1004,7 @@ describe.concurrent('suite', () => {
 ### describe.shuffle
 
 - **类型:** `(name: string | Function, fn: TestFunction, options?: number | TestOptions) => void`
+- **别名:** `suite.shuffle`
 
 Vitest 通过 CLI 标志 [`--sequence.shuffle`](/guide/cli) 或配置选项 [`sequence.shuffle`](/config/#sequence-shuffle)，提供了一种以随机顺序运行所有测试的方法，但如果只想让测试套件的一部分以随机顺序运行测试，可以用这个标志来标记它。
 
@@ -1034,48 +1013,35 @@ import { describe, test } from 'vitest'
 
 // 或 `describe('suite', { shuffle: true }, ...)`
 describe.shuffle('suite', () => {
-  test('random test 1', async () => {
-    /* ... */
-  })
-  test('random test 2', async () => {
-    /* ... */
-  })
-  test('random test 3', async () => {
-    /* ... */
-  })
+  test('random test 1', async () => { /* ... */ })
+  test('random test 2', async () => { /* ... */ })
+  test('random test 3', async () => { /* ... */ })
 
   // `shuffle` 是继承的
   describe('still random', () => {
-    test('random 4.1', async () => {
-      /* ... */
-    })
-    test('random 4.2', async () => {
-      /* ... */
-    })
+    test('random 4.1', async () => { /* ... */ })
+    test('random 4.2', async () => { /* ... */ })
   })
 
   // 禁用内部的 shuffle
   describe('not random', { shuffle: false }, () => {
-    test('in order 5.1', async () => {
-      /* ... */
-    })
-    test('in order 5.2', async () => {
-      /* ... */
-    })
+    test('in order 5.1', async () => { /* ... */ })
+    test('in order 5.2', async () => { /* ... */ })
   })
 })
 // 顺序取决于配置中的 `sequence.seed` 选项（默认为 `Date.now()`）
 ```
 
-`.skip`、`.only`和`.todo`适用于随机测试套件。
+`.skip`、 `.only` 和 `.todo` 适用于随机测试套件。
 
 ::: warning
-在将 Vitest 用作[类型检查器](/guide/testing-types)时，不能使用此语法。
+在将 Vitest 用作 [类型检查器](/guide/testing-types) 时，不能使用此语法。
 :::
 
 ### describe.todo
 
 - **类型:** `(name: string | Function) => void`
+- **别名:** `suite.todo`
 
 使用 `describe.todo` 来暂存待以后实施的套件。测试报告中会显示一个条目，这样就能知道还有多少测试需要执行。
 
@@ -1087,6 +1053,7 @@ describe.todo('unimplemented suite')
 ### describe.each
 
 - **类型:** `(cases: ReadonlyArray<T>, ...args: any[]): (name: string | Function, fn: (...args: T[]) => void, options?: number | TestOptions) => void`
+- **别名:** `suite.each`
 
 ::: tip
 虽然 `describe.each` 是为了兼容 Jest 提供的，
@@ -1140,7 +1107,7 @@ describe.each`
 ```
 
 ::: warning
-在将 Vitest 用作[类型检查器](/guide/testing-types)时，不能使用此语法。
+在将 Vitest 用作 [类型检查器](/guide/testing-types) 时，不能使用此语法。
 :::
 
 ### describe.for

From 3c2087b22d21411c97a6a6181ee2e23c44681bec Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Sun, 16 Nov 2025 13:15:18 +0800
Subject: [PATCH 08/50] !docs: recovery /api/mock

---
 .vitepress/config.ts |  2 +-
 api/mock.md          | 55 +++++++-------------------------------------
 2 files changed, 9 insertions(+), 48 deletions(-)

diff --git a/.vitepress/config.ts b/.vitepress/config.ts
index f2ecccc1..980e4042 100644
--- a/.vitepress/config.ts
+++ b/.vitepress/config.ts
@@ -692,7 +692,7 @@ function api(): DefaultTheme.SidebarItem[] {
       link: '/api/',
     },
     {
-      text: 'Mocks',
+      text: 'Mock Functions',
       link: '/api/mock',
     },
     {
diff --git a/api/mock.md b/api/mock.md
index 036d9cea..70f93cec 100644
--- a/api/mock.md
+++ b/api/mock.md
@@ -1,6 +1,6 @@
-# Mocks
+# Mock Functions
 
-用 `vi.fn` 即可创建 mock 函数或类，并全程记录其调用情况；若想监控已存在对象上的某个属性，则改用 `vi.spyOn`。
+我们可以使用 `vi.fn` 方法创建一个 mock 函数来跟踪其执行情况。如果要跟踪已创建对象上的方法，可以使用 `vi.spyOn` 方法：
 
 ```js
 import { vi } from 'vitest'
@@ -18,10 +18,10 @@ market.getApples()
 getApplesSpy.mock.calls.length === 1
 ```
 
-要验证 mock 的行为，请通过 [`expect`](/api/expect) 调用类似 [`toHaveBeenCalled`](/api/expect#tohavebeencalled) 的断言方法；以下 API 参考汇总了所有可用来操控 mock 的属性和方法。
+我们应该在 [`expect`](/api/expect) 上使用 mock 断言（例如 [`toHaveBeenCalled`](/api/expect#tohavebeencalled) ）来断言 mock 结果。在这里我们介绍了用于操作 mock 行为的可用属性和方法。
 
 ::: tip
-The custom function implementation in the types below is marked with a generic `<T>`.
+下列类型中的自定义函数实现通过泛型 `<T>` 标记。
 :::
 
 ## getMockImplementation
@@ -42,7 +42,7 @@ function getMockImplementation(): T | undefined
 function getMockName(): string
 ```
 
-此方法返回由 `.mockName(name)` 为 mock 指定的名称。`vi.fn()` 创建的替身默认返回 `'vi.fn()'`； `vi.spyOn` 生成的 spy 则沿用被监视方法的原始名称。
+使用它来返回使用 `.mockName(name)` 方法分配给 mock 对象的名称。默认情况下，它将返回 `vi.fn()`。
 
 ## mockClear
 
@@ -215,7 +215,7 @@ await asyncMock() // 抛出 Error<'Async error'>
 function mockReset(): Mock<T>
 ```
 
-该方法会先执行与 [`mockClear`](#mockClear) 相同的清理，再重置 mock 的实现，并一并清除所有一次性（once）设定。
+执行与 `mockClear` 相同的操作，并将内部实现设置为空函数（调用时返回 undefined）。这也会重置所有 “once” 实现。它对于将 mock 完全重置为其默认状态很有用。
 
 注意：
 
@@ -378,37 +378,6 @@ fn.mock.calls
 ]
 ```
 
-:::warning 对象按引用存储。
-请注意，Vitest 在 `mock` 状态的所有属性中始终按引用保存对象。一旦你的代码修改了这些属性，诸如 [`.toHaveBeenCalledWith`](/api/expect#tohavebeencalledwith) 之类的断言便可能无法通过：
-
-```ts
-const argument = {
-  value: 0,
-}
-const fn = vi.fn()
-fn(argument) // { value: 0 }
-
-argument.value = 10
-
-expect(fn).toHaveBeenCalledWith({ value: 0 }) // [!code --]
-
-// 相等性检查是针对原始参数进行的，
-// 但是，该参数的属性在调用和断言之间发生了更改。
-expect(fn).toHaveBeenCalledWith({ value: 10 }) // [!code ++]
-```
-
-此时，可先自行克隆该参数：
-
-```ts{6}
-const calledArguments = []
-const fn = vi.fn((arg) => {
-  calledArguments.push(structuredClone(arg))
-})
-
-expect(calledArguments[0]).toEqual({ value: 0 })
-```
-:::
-
 ## mock.lastCall
 
 ```ts
@@ -491,11 +460,6 @@ fn.mock.results
 ## mock.settledResults
 
 ```ts
-interface MockSettledResultIncomplete {
-  type: 'incomplete'
-  value: undefined
-}
-
 interface MockSettledResultFulfilled<T> {
   type: 'fulfilled'
   value: T
@@ -509,16 +473,13 @@ interface MockSettledResultRejected {
 export type MockSettledResult<T>
   = | MockSettledResultFulfilled<T>
     | MockSettledResultRejected
-    | MockSettledResultIncomplete
 
 const settledResults: MockSettledResult<Awaited<ReturnType<T>>>[]
 ```
 
-该数组按顺序记录了函数每次被调用后最终兑现或拒绝的值。
-
-若函数返回的是非 Promise ，实际值会原封不动地保留，但状态仍被标记为 `fulfilled` 或 `rejected`。
+包含函数中 `resolved` 或 `rejected` 的所有值的数组。
 
-在结果出来前，对应的 `settledResult` 类型始终为 `incomplete`。
+如果函数从未 resolved 或 rejected ，则此数组将为空。
 
 ```js
 const fn = vi.fn().mockResolvedValueOnce('result')

From 54ec728c92f14a772d96ec2b1927d9f400fc5eed Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Sun, 16 Nov 2025 21:43:05 +0800
Subject: [PATCH 09/50] !docs: recovery /api/vi

---
 api/vi.md | 346 ++++++++++++------------------------------------------
 1 file changed, 75 insertions(+), 271 deletions(-)

diff --git a/api/vi.md b/api/vi.md
index a2860833..337f5a6e 100644
--- a/api/vi.md
+++ b/api/vi.md
@@ -4,33 +4,20 @@ outline: deep
 
 # Vi
 
-Vitest 通过其 `vi` 辅助工具提供实用功能来帮助你。可以全局访问它（当启用 [globals 配置](/config/#globals) 时），也可以直接从 `vitest` 中导入：
+Vitest 通过 `vi` 工具函数提供实用功能。可以全局访问它（当启用 [globals 配置](/config/#globals) 时），也可以直接从 `vitest` 中导入：
 
 ```js
 import { vi } from 'vitest'
 ```
 
-## 模拟模块 {#mock-modules}
+## Mock Modules
 
 本节介绍在 [模拟模块](/guide/mocking#modules) 时可以使用的 API。请注意，Vitest 不支持模拟使用 `require()` 导入的模块。
 
 ### vi.mock
 
-```ts
-interface MockOptions {
-  spy?: boolean
-}
-
-interface MockFactory<T> {
-  (importOriginal: () => T): unknown
-}
-
-function mock(path: string, factory?: MockOptions | MockFactory<unknown>): void
-function mock<T>(
-  module: Promise<T>,
-  factory?: MockOptions | MockFactory<T>
-): void
-```
+- **类型**: `(path: string, factory?: MockOptions | ((importOriginal: () => unknown) => unknown)) => void`
+- **类型**: `<T>(path: Promise<T>, factory?: MockOptions | ((importOriginal: () => T) => T | Promise<T>)) => void`
 
 用另一个模块替换提供的 `path` 中的所有导入模块。我们可以在路径内使用配置的 Vite 别名。对 `vi.mock` 的调用是悬挂式的，因此在何处调用并不重要。它总是在所有导入之前执行。如果需要在其作用域之外引用某些变量，可以在 [`vi.hoisted`](/api/vi#vi-hoisted)中定义它们，并在 `vi.mock` 中引用它们。
 
@@ -44,6 +31,8 @@ Vitest 不会模拟 [setup file](/config/#setupfiles) 中导入的模块，因
 
 如果定义了 `factory` 函数，所有导入都将返回其结果。Vitest 只调用一次 factory，并缓存所有后续导入的结果，直到 [`vi.unmock`](#vi-unmock) 或 [`vi.doUnmock`](#vi-dounmock) 被调用。
 
+与 `jest` 不同， 该工厂函数是可以异步的。你可以通过 [`vi.importActual`](#vi-importactual) 或传入工厂函数作为首个参数的工具方法，在内部获取原始模块。
+
 我们还可以提供一个具有 `spy` 属性的对象，而不是工厂函数。如果 `spy` 为 `true`，则 Vitest 将照常自动模拟模块，但不会覆盖导出的实现。如果我们只想断言导出的方法已被另一种方法正确调用，这将非常有用。
 
 ```ts
@@ -59,7 +48,6 @@ expect(result).toBe(3)
 expect(calculator).toHaveBeenCalledWith(1, 2)
 expect(calculator).toHaveReturned(3)
 ```
-
 Vitest 还在 `vi.mock` 和 `vi.doMock` 方法中支持 module promise 而非字符串，以获得更好的集成开发环境支持。当文件被移动时，路径会被更新，`importOriginal` 也会自动继承类型。使用此签名还将强制工厂返回类型与原始模块兼容（但每次导出都是可选的）。
 
 ```ts
@@ -119,7 +107,7 @@ vi.mock('./path/to/module.js', () => {
   return {
     default: { myDefaultKey: vi.fn() },
     namedExport: vi.fn(),
-    // ...
+    // etc...
   }
 })
 ```
@@ -143,11 +131,11 @@ vi.mock('./path/to/module.js', () => {
 如果在没有提供工厂或选项的测试文件中调用 `vi.mock` ，它会在 `__mocks__` 文件夹中找到一个文件作为模块使用：
 
 ```ts [increment.test.js]
+import { vi } from 'vitest'
+
 // axios 是 `__mocks__/axios.js` 默认导出项
 import axios from 'axios'
 
-import { vi } from 'vitest'
-
 // increment 是 `src/__mocks__/increment.js` 具名导出
 import { increment } from '../increment.js'
 
@@ -162,20 +150,12 @@ axios.get(`/apples/${increment(1)}`)
 请注意，如果不调用 `vi.mock` ，模块**不会**被自动模拟。要复制 Jest 的自动锁定行为，可以在 [`setupFiles`](/config/#setupfiles) 中为每个所需的模块调用 `vi.mock` 。
 :::
 
-如果没有提供 `__mocks__` 文件夹或未提供工厂函数，Vitest 将导入原始模块并自动模拟其所有导出。有关应用的规则，请参阅[算法](/guide/mocking/modules#automocking-algorithm)。
+如果没有提供 `__mocks__` 文件夹或工厂，Vitest 将导入原始模块并自动模拟其所有输出。有关应用的规则，请参阅 [模块](/mocking.html#automocking-algorithm)。
 
 ### vi.doMock
 
-```ts
-function doMock(
-  path: string,
-  factory?: MockOptions | MockFactory<unknown>
-): void
-function doMock<T>(
-  module: Promise<T>,
-  factory?: MockOptions | MockFactory<T>
-): void
-```
+- **类型**: `(path: string, factory?: MockOptions | ((importOriginal: () => unknown) => unknown)) => void`
+- **类型**: `<T>(path: Promise<T>, factory?: MockOptions | ((importOriginal: () => T) => T | Promise<T>)) => void`
 
 与 [`vi.mock`](#vi-mock) 相同，但它不会被移动到文件顶部，因此我们可以引用全局文件作用域中的变量。模块的下一个 [动态导入](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import) 将被模拟。
 
@@ -224,16 +204,8 @@ test('importing the next module imports mocked one', async () => {
 
 ### vi.mocked
 
-```ts
-function mocked<T>(
-  object: T,
-  deep?: boolean
-): MaybeMockedDeep<T>
-function mocked<T>(
-  object: T,
-  options?: { partial?: boolean, deep?: boolean }
-): MaybePartiallyMockedDeep<T>
-```
+- **类型**: `<T>(obj: T, deep?: boolean) => MaybeMockedDeep<T>`
+- **类型**: `<T>(obj: T, options?: { partial?: boolean; deep?: boolean }) => MaybePartiallyMockedDeep<T>`
 
 TypeScript 的类型助手。只返回传入的对象。
 
@@ -270,9 +242,7 @@ test('mock return value with only partially correct typing', async () => {
 
 ### vi.importActual
 
-```ts
-function importActual<T>(path: string): Promise<T>
-```
+- **类型**: `<T>(path: string) => Promise<T>`
 
 导入模块，绕过模块是否应被模拟的所有检查。如果我们想部分模拟模块，这一点很有用。
 
@@ -286,25 +256,19 @@ vi.mock('./example.js', async () => {
 
 ### vi.importMock
 
-```ts
-function importMock<T>(path: string): Promise<MaybeMockedDeep<T>>
-```
+- **类型**: `<T>(path: string) => Promise<MaybeMockedDeep<T>>`
 
-导入模块并模拟其所有属性（包括嵌套属性）。遵循与 [`vi.mock`](#vi-mock) 相同的规则。有关应用的规则，请参阅[算法](/guide/mocking/modules#automocking-algorithm)。
+导入模块并模拟其所有属性（包括嵌套属性）。遵循与 [`vi.mock`](#vi-mock) 相同的规则。有关应用的规则，请参阅 [模块](/mocking.html#automocking-algorithm)。
 
 ### vi.unmock
 
-```ts
-function unmock(path: string | Promise<Module>): void
-```
+- **类型**: `(path: string | Promise<Module>) => void`
 
 从模拟注册表中删除模块。所有导入调用都将返回原始模块，即使该模块之前已被模拟。该调用会被移动到文件顶端，因此只会解除在 `setupFiles` 中定义的模块。
 
 ### vi.doUnmock
 
-```ts
-function doUnmock(path: string | Promise<Module>): void
-```
+- **类型**: `(path: string | Promise<Module>) => void`
 
 与 [`vi.unmock`](#vi-unmock) 相同，但不会移动到文件顶端。下一次导入模块时，将导入原始模块而非 mock。这不会解除先前导入的模块。
 
@@ -343,9 +307,7 @@ unmockedIncrement(30) === 31
 
 ### vi.resetModules
 
-```ts
-function resetModules(): Vitest
-```
+- **类型**: `() => Vitest`
 
 通过清除所有模块的缓存来重置模块注册表。这样就可以在重新导入模块时对模块进行重新评估。顶层导入无法重新评估。这可能有助于隔离测试之间存在本地状态冲突的模块。
 
@@ -376,10 +338,6 @@ test('module has old state', async () => {
 
 ### vi.dynamicImportSettled
 
-```ts
-function dynamicImportSettled(): Promise<void>
-```
-
 等待加载所有导入模块。如果有同步调用开始导入一个模块，而如果不这样做就无法等待，那么它就很有用。
 
 ```ts
@@ -411,9 +369,7 @@ test('operations are resolved', async () => {
 
 ### vi.fn
 
-```ts
-function fn(fn?: Procedure | Constructable): Mock
-```
+- **类型:** `(fn?: Function) => Mock`
 
 创建函数的监视程序，但也可以不创建监视程序。每次调用函数时，它都会存储调用参数、返回值和实例。此外，我们还可以使用 [methods](/api/mock) 操纵它的行为。
 如果没有给出函数，调用 mock 时将返回 `undefined`。
@@ -433,32 +389,17 @@ expect(res).toBe(5)
 expect(getApples).toHaveNthReturnedWith(2, 5)
 ```
 
-`vi.fn` 同样支持传入 class 作为参数：
-
-```ts
-const Cart = vi.fn(
-  class {
-    get = () => 0
-  }
-)
-
-const cart = new Cart()
-expect(Cart).toHaveBeenCalled()
-```
-
 ### vi.mockObject <Version>3.2.0</Version>
 
-```ts
-function mockObject<T>(value: T): MaybeMockedDeep<T>
-```
+- **Type:** `<T>(value: T) => MaybeMockedDeep<T>`
 
-它与 `vi.mock()` 模拟模块相同，深层模拟给定对象的属性和方法。详见[自动模拟](/guide/mocking.html#automocking-algorithm)。
+它与 `vi.mock()` 模拟模块相同，深层模拟给定对象的属性和方法。详见 [自动模拟](/guide/mocking.html#automocking-algorithm)。
 
 ```ts
 const original = {
   simple: () => 'value',
   nested: {
-    method: () => 'real',
+    method: () => 'real'
   },
   prop: 'foo',
 }
@@ -475,69 +416,30 @@ expect(mocked.simple()).toBe('mocked')
 expect(mocked.nested.method()).toBe('mocked nested')
 ```
 
-就像 `vi.mock()` 一样，可以传递 `{ spy: true }` 作为第二个参数，以保持函数实现：
-
-```ts
-const spied = vi.mockObject(original, { spy: true })
-expect(spied.simple()).toBe('value')
-expect(spied.simple).toHaveBeenCalled()
-expect(spied.simple.mock.results[0]).toEqual({
-  type: 'return',
-  value: 'value',
-})
-```
-
 ### vi.isMockFunction
 
-```ts
-function isMockFunction(fn: unknown): asserts fn is Mock
-```
+- **类型:** `(fn: Function) => boolean`
 
 检查给定参数是否为 mock 函数。如果使用的是 TypeScript ，它还会缩小参数类型的范围。
 
 ### vi.clearAllMocks
 
-```ts
-function clearAllMocks(): Vitest
-```
-
 对所有 spies 调用 [`.mockClear()`](/api/mock#mockclear)。
 这将清除模拟的历史记录，但不影响模拟的实现。
 
 ### vi.resetAllMocks
 
-```ts
-function resetAllMocks(): Vitest
-```
-
 对所有 spies 调用 [`.mockReset()`](/api/mock#mockreset)。
 这将清除模拟的历史记录，并将每个模拟的实现重置为其原始状态。
 
 ### vi.restoreAllMocks
 
-```ts
-function restoreAllMocks(): Vitest
-```
-
-该方法会一次性恢复所有由 [`vi.spyOn`](#vi-spyon) 创建的 spy 的原始实现。
-
-一旦完成还原，即可重新对其进行监视。
-
-::: warning
-该方法同样不会触及 [automocking](/guide/mocking/modules#mocking-a-module) 期间生成的任何 mock。
-
-注意：与 [`mock.mockRestore`](/api/mock#mockrestore) 不同，`vi.restoreAllMocks` 既不会清空调用历史，也不会重置 mock 的实现。
-:::
+对所有 spies 调用 [`.mockRestore()`](/api/mock#mockrestore)。
+这将清除模拟的历史记录，恢复所有原始模拟实现，并恢复被监视对象的原始描述符。
 
 ### vi.spyOn
 
-```ts
-function spyOn<T, K extends keyof T>(
-  object: T,
-  key: K,
-  accessor?: 'get' | 'set'
-): Mock<T[K]>
-```
+- **类型:** `<T, K extends keyof T>(object: T, method: K, accessType?: 'get' | 'set') => MockInstance`
 
 创建与 [`vi.fn()`](#vi-fn) 类似的对象的方法或 getter/setter 的监听(spy) 。它会返回一个 [mock 函数](/api/mock) 。
 
@@ -556,36 +458,6 @@ expect(spy).toHaveBeenCalled()
 expect(spy).toHaveReturnedWith(1)
 ```
 
-若被监视的方法为类定义，则 mock 实现必须使用 `function` 或 `class` 关键字。
-
-```ts {12-14,16-20}
-const cart = {
-  Apples: class Apples {
-    getApples() {
-      return 42
-    }
-  },
-}
-
-const spy = vi
-  .spyOn(cart, 'Apples')
-  .mockImplementation(() => ({ getApples: () => 0 })) // [!code --]
-  // 使用函数关键字
-  .mockImplementation(function () {
-    this.getApples = () => 0
-  })
-  // 使用自定义类
-  .mockImplementation(
-    class MockApples {
-      getApples() {
-        return 0
-      }
-    }
-  )
-```
-
-如果传入箭头函数， mock 被调用时将抛出 [`<anonymous> is not a constructor` 错误](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Not_a_constructor)。
-
 ::: tip
 若运行环境支持 [显式资源管理](https://github.com/tc39/proposal-explicit-resource-management) ，可将 `const` 替换为 `using`。离开当前块级作用域时，系统会自动对被 mock 的函数调用 `mockRestore`，特别适用于已打 spy 的方法。
 
@@ -595,13 +467,12 @@ it('calls console.log', () => {
   debug('message')
   expect(spy).toHaveBeenCalled()
 })
-// console.log 在此处还原
+// console.log is restored here
 ```
-
 :::
 
 ::: tip
-在每个测试后，于 [`afterEach`](/api/#aftereach) 中调用 [`vi.restoreAllMocks`](#vi-restoreallmocks) 或开启配置项 [`test.restoreMocks`](/config/#restoreMocks)，即可将所有方法还原为原始实现。此操作会恢复其 [对象描述符](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty)，除非重新对其进行 spy ，否则无法再次修改方法实现。
+你可以在 [`afterEach`](/api/#aftereach)（或启用 [`test.restoreMocks`](/config/#restoreMocks) ）中调用 [`vi.restoreAllMocks`](#vi-restoreallmocks) ，将所有方法还原为原始实现。这将还原原始的 [object descriptor](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty) ，因此无法更改方法的实现：
 
 ```ts
 const cart = {
@@ -614,7 +485,7 @@ console.log(cart.getApples()) // 10
 vi.restoreAllMocks()
 console.log(cart.getApples()) // 42
 spy.mockReturnValue(10)
-console.log(cart.getApples()) // 仍然为 42!
+console.log(cart.getApples()) // still 42!
 ```
 
 :::
@@ -638,12 +509,7 @@ expect(calculator).toHaveReturned(3)
 
 ### vi.stubEnv {#vi-stubenv}
 
-```ts
-function stubEnv<T extends string>(
-  name: T,
-  value: T extends 'PROD' | 'DEV' | 'SSR' ? boolean : string | undefined
-): Vitest
-```
+- **类型:** `<T extends string>(name: T, value: T extends "PROD" | "DEV" | "SSR" ? boolean : string | undefined) => Vitest`
 
 更改 `process.env` 和 `import.meta.env` 中环境变量的值。我们可以调用 `vi.unstubAllEnvs` 恢复其值。
 
@@ -678,9 +544,7 @@ import.meta.env.MODE = 'test'
 
 ### vi.unstubAllEnvs {#vi-unstuballenvs}
 
-```ts
-function unstubAllEnvs(): Vitest
-```
+- **类型:** `() => Vitest`
 
 恢复通过 `vi.stubEnv` 更改的所有 `import.meta.env` 和 `process.env` 值。首次调用时，Vitest 会记住并保存原始值，直到再次调用 `unstubAllEnvs`。
 
@@ -709,9 +573,7 @@ import.meta.env.NODE_ENV === 'development'
 
 ### vi.stubGlobal
 
-```ts
-function stubGlobal(name: string | number | symbol, value: unknown): Vitest
-```
+- **类型:** `(name: string | number | symbol, value: unknown) => Vitest`
 
 更改全局变量的值。我们可以调用 `vi.unstubAllGlobals` 恢复其原始值。
 
@@ -729,7 +591,7 @@ window.innerWidth === 100
 ```
 
 :::tip
-我们也可以通过简单地将其赋值给 `globalThis` 或 `window`（如果你正在使用 `jsdom` 或 `happy-dom` 环境）来更改该值，但无法使用 `vi.unstubAllGlobals` 恢复原始值：
+我们也可以通过简单地将其赋值给 `globalThis` 或 `window`（如果我们使用的是 `jsdom` 或 `happy-dom` 环境）来更改该值，但无法使用 `vi.unstubAllGlobals` 恢复原始值：
 
 ```ts
 globalThis.innerWidth = 100
@@ -741,11 +603,9 @@ window.innerWidth = 100
 
 ### vi.unstubAllGlobals {#vi-unstuballglobals}
 
-```ts
-function unstubAllGlobals(): Vitest
-```
+- **类型:** `() => Vitest`
 
-恢复 `globalThis` / `global`（和 `window` / `top` / `self` / `parent `，如果我们使用的是 `jsdom` 或 `happy-dom` 环境）上所有被 `vi.stubGlobal` 更改过的全局值。第一次调用时，Vitest 会记住并保存原始值，直到再次调用 `unstubAllGlobals`。
+恢复 `globalThis`/`global`（和 `window`/`top`/`self`/`parent`，如果我们使用的是 `jsdom` 或 `happy-dom` 环境）上所有被 `vi.stubGlobal` 更改过的全局值。第一次调用时，Vitest 会记住并保存原始值，直到再次调用 `unstubAllGlobals`。
 
 ```ts
 import { vi } from 'vitest'
@@ -772,13 +632,11 @@ IntersectionObserver === undefined
 
 ## Fake Timers
 
-本节介绍如何使用 [fake timers](/guide/mocking/timers) 。
+本节介绍如何使用 [模拟计时器](/guide/mocking.html#timers)。
 
 ### vi.advanceTimersByTime
 
-```ts
-function advanceTimersByTime(ms: number): Vitest
-```
+- **类型:** `(ms: number) => Vitest`
 
 该方法将调用每个启动的定时器，直到超过指定的毫秒数或队列为空（以先到者为准）。
 
@@ -795,9 +653,7 @@ vi.advanceTimersByTime(150)
 
 ### vi.advanceTimersByTimeAsync
 
-```ts
-function advanceTimersByTimeAsync(ms: number): Promise<Vitest>
-```
+- **类型:** `(ms: number) => Promise<Vitest>`
 
 该方法将调用每个已启动的定时器，直到超过指定的毫秒数或队列为空（以先到者为准）。这将包括异步设置的计时器。
 
@@ -814,9 +670,7 @@ await vi.advanceTimersByTimeAsync(150)
 
 ### vi.advanceTimersToNextTimer
 
-```ts
-function advanceTimersToNextTimer(): Vitest
-```
+- **类型:** `() => Vitest`
 
 将调用下一个可用的定时器。在每次调用定时器之间进行断言非常有用。我们可以调用它来管理自己的定时器。
 
@@ -831,9 +685,7 @@ vi.advanceTimersToNextTimer() // 输出: 1
 
 ### vi.advanceTimersToNextTimerAsync
 
-```ts
-function advanceTimersToNextTimerAsync(): Promise<Vitest>
-```
+- **类型:** `() => Promise<Vitest>`
 
 如果定时器是异步设置的，则会调用下一个可用的定时器并等待解决。在每次调用定时器之间进行断言非常有用。
 
@@ -848,11 +700,9 @@ await vi.advanceTimersToNextTimerAsync() // log: 2
 await vi.advanceTimersToNextTimerAsync() // log: 3
 ```
 
-### vi.advanceTimersToNextFrame
+### vi.advanceTimersToNextFrame <Version>2.1.0</Version> {#vi-advancetimerstonextframe}
 
-```ts
-function advanceTimersToNextFrame(): Vitest
-```
+- **类型:** `() => Vitest`
 
 与 [`vi.advanceTimersByTime`](https://vitest.dev/api/vi#vi-advancetimersbytime) 类似，但会将计时器推进当前使用 `requestAnimationFrame` 安排的回调执行所需的毫秒数。
 
@@ -870,49 +720,35 @@ expect(frameRendered).toBe(true)
 
 ### vi.getTimerCount
 
-```ts
-function getTimerCount(): number
-```
+- **类型:** `() => number`
 
 获取等待计时器的数量。
 
 ### vi.clearAllTimers
 
-```ts
-function clearAllTimers(): void
-```
-
-立即取消所有已排程的计时器，使其不再执行。
+删除所有计划运行的计时器。这些定时器今后将不再运行。
 
 ### vi.getMockedSystemTime
 
-```ts
-function getMockedSystemTime(): Date | null
-```
+- **类型**: `() => Date | null`
 
 返回模拟的当前日期。如果没有模拟日期，该方法将返回 `null`。
 
 ### vi.getRealSystemTime
 
-```ts
-function getRealSystemTime(): number
-```
+- **类型**: `() => number`
 
 使用 `vi.useFakeTimers` 时，会模拟 `Date.now` 调用。如果需要以毫秒为单位获取实时时间，可以调用此函数。
 
 ### vi.runAllTicks
 
-```ts
-function runAllTicks(): Vitest
-```
+- **类型:** `() => Vitest`
 
 调用由 `process.nextTick` 排在队列中的每个微任务。这也将运行所有自己安排的微任务。
 
 ### vi.runAllTimers
 
-```ts
-function runAllTimers(): Vitest
-```
+- **类型:** `() => Vitest`
 
 该方法将调用每个已经启动的定时器，直到定时器队列为空。这意味着在 `runAllTimers` 期间调用的每个定时器都会被触发。如果时间间隔为无限，则会在尝试 10000 次后触发（可使用 [`fakeTimers.loopLimit`](/config/#faketimers-looplimit) 进行配置）。
 
@@ -935,9 +771,7 @@ vi.runAllTimers()
 
 ### vi.runAllTimersAsync
 
-```ts
-function runAllTimersAsync(): Promise<Vitest>
-```
+- **类型:** `() => Promise<Vitest>`
 
 该方法将异步调用每个已启动的定时器，直到定时器队列为空。这意味着在 `runAllTimersAsync` 期间调用的每个定时器都会被触发，即使是异步定时器。如果我们有一个无限的时间间隔、
 会在尝试 10000 次后抛出（可使用 [`fakeTimers.loopLimit`](/config/#faketimers-looplimit) ）。
@@ -954,9 +788,7 @@ await vi.runAllTimersAsync()
 
 ### vi.runOnlyPendingTimers
 
-```ts
-function runOnlyPendingTimers(): Vitest
-```
+- **类型:** `() => Vitest`
 
 此方法将调用 [`vi.useFakeTimers`](#vii-usefaketimers) 调用后启动的所有计时器。它不会调用在调用期间启动的任何计时器。
 
@@ -971,9 +803,7 @@ vi.runOnlyPendingTimers()
 
 ### vi.runOnlyPendingTimersAsync
 
-```ts
-function runOnlyPendingTimersAsync(): Promise<Vitest>
-```
+- **类型:** `() => Promise<Vitest>`
 
 此方法将异步调用 [`vi.useFakeTimers`](#vi-usefaketimers) 调用后启动的每个定时器，即使是异步定时器。它不会触发任何在调用期间启动的定时器。
 
@@ -1000,13 +830,11 @@ await vi.runOnlyPendingTimersAsync()
 
 ### vi.setSystemTime
 
-```ts
-function setSystemTime(date: string | number | Date): Vitest
-```
+- **类型**: `(date: string | number | Date) => void`
 
 如果启用了伪计时器，此方法将模拟用户更改系统时钟（将影响与日期相关的 API，如 `hrtime` 、`performance.now` 或 `new Date()` ），但不会触发任何计时器。如果未启用假定时器，该方法将仅模拟 `Date.*` 调用。
 
-如果我们需要测试任何依赖于当前日期的内容 -- 例如在代码中调用 [luxon](https://github.com/moment/luxon/) --则非常有用。
+适用于需要测试依赖当前日期的场景，例如代码中的 [Luxon](https://github.com/moment/luxon/) 库调用。
 
 接受与 `Date` 相同的字符串和数字参数。
 
@@ -1023,9 +851,7 @@ vi.useRealTimers()
 
 ### vi.useFakeTimers
 
-```ts
-function useFakeTimers(config?: FakeTimerInstallOpts): Vitest
-```
+- **类型:** `(config?: FakeTimerInstallOpts) => Vitest`
 
 要启用模拟定时器，需要调用此方法。在调用 [`vi.useRealTimers()`](#vi-userealtimers) 之前，它将封装所有对定时器的进一步调用（如 `setTimeout` 、`setInterval` 、`clearTimeout` 、`clearInterval` 、`setImmediate` 、`clearImmediate` 和 `Date`）。
 
@@ -1040,32 +866,23 @@ function useFakeTimers(config?: FakeTimerInstallOpts): Vitest
 
 ### vi.isFakeTimers {#vi-isfaketimers}
 
-```ts
-function isFakeTimers(): boolean
-```
+- **类型:** `() => boolean`
 
-如果启用了假计时器，则返回 `true` 。
+如果启用了模拟计时器，则返回 `true` 。
 
 ### vi.useRealTimers
 
-```ts
-function useRealTimers(): Vitest
-```
+- **类型:** `() => Vitest`
 
 当定时器用完后，我们可以调用此方法将模拟的计时器返回到其原始实现。之前调度的计时器都将被丢弃。
 
-## 辅助函数{#miscellaneous}
+## Miscellaneous
 
 Vitest 提供的一组有用的辅助函数。
 
 ### vi.waitFor {#vi-waitfor}
 
-```ts
-function waitFor<T>(
-  callback: WaitForCallback<T>,
-  options?: number | WaitForOptions
-): Promise<T>
-```
+- **类型:** `<T>(callback: WaitForCallback<T>, options?: number | WaitForOptions) => Promise<T>`
 
 等待回调成功执行。如果回调抛出错误或返回拒绝的承诺，它将继续等待，直到成功或超时。
 
@@ -1126,20 +943,15 @@ test('Element exists in a DOM', async () => {
 })
 ```
 
-一旦通过 `vi.useFakeTimers` 启用假计时器，`vi.waitFor` 将在每次轮询时自动调用 `vi.advanceTimersByTime(interval)` 推进时间。
+如果使用了 `vi.useFakeTimers` , `vi.waitFor` 会在每次检查回调中自动调用 `vi.advanceTimersByTime(interval)` 。
 
-### vi.waitUntil {#vi-waituntil}
+### vi.waitUntil
 
-```ts
-function waitUntil<T>(
-  callback: WaitUntilCallback<T>,
-  options?: number | WaitUntilOptions
-): Promise<T>
-```
+- **类型:** `<T>(callback: WaitUntilCallback<T>, options?: number | WaitUntilOptions) => Promise<T>`
 
-与 `vi.waitFor` 类似，但若回调抛出错误会立即中断并给出报错；若回调返回假值，则持续轮询直至返回真值。适用于“先等某物出现再行动”的场景。
+这与 `vi.waitFor` 类似，但如果回调抛出任何错误，执行将立即中断并收到一条错误信息。如果回调返回虚假值(falsy) ，下一次检查将继续，直到返回真实值(truthy) 。这在需要等待某项内容存在后再执行下一步时非常有用。
 
-下面的示例，我们可以使用 `vi.waitUntil` 等待元素出现在页面上，然后再对该元素进行操作。
+请看下面的示例。我们可以使用 `vi.waitUntil` 等待元素出现在页面上，然后对元素进行操作。
 
 ```ts
 import { expect, test, vi } from 'vitest'
@@ -1149,17 +961,15 @@ test('Element render correctly', async () => {
     timeout: 500, // 默认为 1000
     interval: 20, // 默认为 50
   })
-  expect(element).toBeInstanceOf(HTMLElement)
+
+  // 对元素执行操作
+  expect(element.querySelector('.element-child')).toBeTruthy()
 })
 ```
 
-如果使用了 `vi.useFakeTimers` , `vi.waitFor` 会在每次检查回调中自动调用 `vi.advanceTimersByTime(interval)` 。
-
 ### vi.hoisted {#vi-hoisted}
 
-```ts
-function hoisted<T>(factory: () => T): T
-```
+- **类型**: `<T>(factory: () => T) => T`
 
 ES 模块中的所有静态 `import` 语句都被提升到文件顶部，因此在导入之前定义的任何代码都将在导入评估之后执行。
 
@@ -1187,9 +997,7 @@ import { value } from './some/module.js'
 ```ts
 import { value } from './some/module.js'
 
-vi.hoisted(() => {
-  value
-}) // 抛出一个错误 // [!code warning]
+vi.hoisted(() => { value }) // 抛出一个错误 // [!code warning]
 ```
 
 此代码将产生错误：
@@ -1238,9 +1046,7 @@ const json = await vi.hoisted(async () => {
 
 ### vi.setConfig
 
-```ts
-function setConfig(config: RuntimeOptions): void
-```
+- **类型**: `RuntimeConfig`
 
 更新当前测试文件的配置。此方法只会影响当前测试文件的配置选项：
 
@@ -1253,20 +1059,18 @@ vi.setConfig({
   restoreMocks: true,
   fakeTimers: {
     now: new Date(2021, 11, 19),
-    // 支持完整对象
+    // supports the whole object
   },
   maxConcurrency: 10,
   sequence: {
     hooks: 'stack',
-    // 仅支持 "sequence.hooks"
+    // supports only "sequence.hooks"
   },
 })
 ```
 
 ### vi.resetConfig
 
-```ts
-function resetConfig(): void
-```
+- **类型**: `RuntimeConfig`
 
 如果之前调用过 [`vi.setConfig`](#vi-setconfig) ，则会将配置重置为原始状态。

From 463b30121b0df0367b0013726500ad9788d69cbd Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Sun, 16 Nov 2025 21:49:28 +0800
Subject: [PATCH 10/50] !docs: recovery /api/vi

---
 api/vi.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/api/vi.md b/api/vi.md
index 337f5a6e..fd28be9c 100644
--- a/api/vi.md
+++ b/api/vi.md
@@ -363,7 +363,7 @@ test('operations are resolved', async () => {
 该方法还将在导入解析后等待下一个 `setTimeout` 跟他挂钩，因此所有同步操作都应在解析时完成。
 :::
 
-## 模拟函数和对象
+## 模拟函数和对象 {#mocking-functions-and-objects}
 
 本节介绍如何使用 [method mock](/api/mock) 替换环境变量和全局变量。
 
@@ -1059,12 +1059,12 @@ vi.setConfig({
   restoreMocks: true,
   fakeTimers: {
     now: new Date(2021, 11, 19),
-    // supports the whole object
+    // 支持完整对象
   },
   maxConcurrency: 10,
   sequence: {
     hooks: 'stack',
-    // supports only "sequence.hooks"
+    // 仅支持 "sequence.hooks"
   },
 })
 ```

From 723b7d9b01244f2cd1348190621942af3019d4a6 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Tue, 18 Nov 2025 23:39:45 +0800
Subject: [PATCH 11/50] !docs: recovery /guide/filtering

---
 guide/filtering.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guide/filtering.md b/guide/filtering.md
index e6b9b858..be82a69d 100644
--- a/guide/filtering.md
+++ b/guide/filtering.md
@@ -4,7 +4,7 @@ title: 测试筛选 | 指南
 
 # 测试筛选 {#test-filtering}
 
-用于测试套件(suite)和测试的筛选(filtering)、超时(timeouts)、并发(concurrent)。
+筛选、超时和测试套件的并发。
 
 ## CLI {#cli}
 

From 2ec45b4074a4f3bb2825b41d6d1b564f499b2a80 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Tue, 18 Nov 2025 23:55:46 +0800
Subject: [PATCH 12/50] !docs: recovery /guide/projects

---
 guide/projects.md | 51 ++---------------------------------------------
 1 file changed, 2 insertions(+), 49 deletions(-)

diff --git a/guide/projects.md b/guide/projects.md
index 1c234a04..56086c92 100644
--- a/guide/projects.md
+++ b/guide/projects.md
@@ -30,7 +30,7 @@ export default defineConfig({
 })
 ```
 
-项目配置可以是内联配置、文件或指向项目的 glob 模式。例如，如果你有一个名为 `packages` 的文件夹包含多个项目，可以在根 Vitest 配置中定义一个数组：
+项目配置可以是内联配置、文件或指向项目的 glob 模式。例如，如果你有一个名为 `packages` 的文件夹包含多个项目，可以在 Vitest 配置文件中定义一个数组：
 
 ```ts [vitest.config.ts]
 import { defineConfig } from 'vitest/config'
@@ -42,54 +42,7 @@ export default defineConfig({
 })
 ```
 
-Vitest 会将 `packages` 中的每个文件夹视为独立项目，即使其中没有配置文件。如果 glob 模式匹配到文件，它将验证文件名是否以 `vitest.config`/`vite.config` 开头，或匹配 `(vite|vitest).*.config.*` 模式，以确保它是 Vitest 配置文件。例如，以下配置文件是有效的：
-
-- `vitest.config.ts`
-- `vite.config.js`
-- `vitest.unit.config.ts`
-- `vite.e2e.config.js`
-- `vitest.config.unit.js`
-- `vite.config.e2e.js`
-
-要排除文件夹和文件，你可以使用否定模式：
-
-```ts [vitest.config.ts]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    // 包含 "packages" 所有子文件夹，并排除 "excluded" 文件夹
-    projects: [
-      'packages/*',
-      '!packages/excluded'
-    ],
-  },
-})
-```
-
-如果你有一个嵌套结构，其中某些文件夹需要成为项目，但其他文件夹有自己的子文件夹，你必须使用括号来避免匹配父文件夹：
-
-```ts [vitest.config.ts]
-import { defineConfig } from 'vitest/config'
-
-// 举例来说，像下面这样创建项目：
-// packages/a
-// packages/b
-// packages/business/c
-// packages/business/d
-// 注意："packages/business" 并不是一个项目
-
-export default defineConfig({
-  test: {
-    projects: [
-      // 匹配 "packages" 目录下除 "business" 所有子文件夹
-      'packages/!(business)',
-      // 匹配 "packages/business" 下所有子文件夹
-      'packages/business/*',
-    ],
-  },
-})
-```
+Vitest 会将 `packages` 中的每个文件夹视为独立项目，即使其中没有配置文件。如果该 glob 模式匹配到 _任意文件_，它将被视为 Vitest 配置，即使文件名中没有包含 `vitest` 或文件扩展名不常见。
 
 ::: warning
 Vitest 不会将根目录的 `vitest.config` 文件视为项目，除非在配置中显式指定。因此，根配置只会影响全局选项，如 `reporters` 和 `coverage`。但 Vitest 总会执行根配置文件中指定的某些插件钩子，如 `apply`、`config`、`configResolved` 或 `configureServer`。Vitest 也会使用相同的插件执行全局设置和自定义覆盖提供者。

From 763a739c0f1c95fef6415db4155123fb295939bc Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Wed, 19 Nov 2025 00:35:40 +0800
Subject: [PATCH 13/50] !docs: recovery /guide/snapshot

---
 guide/snapshot.md | 49 ++++++++++++++++++++++++++---------------------
 1 file changed, 27 insertions(+), 22 deletions(-)

diff --git a/guide/snapshot.md b/guide/snapshot.md
index eee9cfff..576e4f16 100644
--- a/guide/snapshot.md
+++ b/guide/snapshot.md
@@ -4,10 +4,10 @@ title: 测试快照 | 指南
 
 # 测试快照 {#snapshot}
 
-当你希望确保函数的输出不会意外更改时，快照测试是一个非常有用的工具。
-
 <CourseLink href="https://vueschool.io/lessons/snapshots-in-vitest?friend=vueuse">通过 Vue School 的视频学习快照</CourseLink>
 
+当你希望确保函数的输出不会意外更改时，快照测试是一个非常有用的工具。
+
 使用快照时，Vitest 将获取给定值的快照，将其比较时将参考存储在测试旁边的快照文件。如果两个快照不匹配，则测试将失败：要么更改是意外的，要么参考快照需要更新到测试结果的新版本。
 
 ## 使用快照 {#use-snapshots}
@@ -39,7 +39,7 @@ exports['toUpperCase 1'] = '"FOOBAR"'
 在异步并发测试中使用快照时，由于 JavaScript 的限制，你需要使用 [测试环境](/guide/test-context) 中的 `expect` 来确保检测到正确的测试。
 :::
 
-如同前文，你可以使用 [`toMatchInlineSnapshot()`](/api/#tomatchinlinesnapshot) 将内联快照存储在测试文件中。
+同样，你可以使用 [`toMatchInlineSnapshot()`](/api/#tomatchinlinesnapshot) 将内联快照存储在测试文件中。
 
 ```ts
 import { expect, it } from 'vitest'
@@ -63,12 +63,12 @@ it('toUpperCase', () => {
 
 这允许你直接查看期望输出，而无需跨不同的文件跳转。
 
-## 更新快照 {#updating-snapshots}
-
 ::: warning
-在异步并发测试中使用快照时，由于 JavaScript 的限制，你需要使用 [测试环境](/guide/test-context) 中的 `expect` 来确保检测到正确的测试。
+在异步并发测试中使用快照时，必须使用本地的 [Test Context](/guide/test-context) 中的 `expect`  方法，以确保正确检测到对应的测试。
 :::
 
+## 更新快照 {#updating-snapshots}
+
 当接收到的值与快照不匹配时，测试将失败，并显示它们之间的差异。当需要更改快照时，你可能希望从当前状态更新快照。
 
 在监听(watch)模式下, 你可以在终端中键入 `u` 键直接更新失败的快照。
@@ -81,7 +81,7 @@ vitest -u
 
 ## 文件快照 {#file-snapshots}
 
-调用 `toMatchSnapshot()` 时，我们将所有快照存储在格式化的快照文件中。这意味着我们需要转义快照字符串中的一些字符（即双引号 `"` 和反引号 `\``）。同时，你可能会丢失快照内容的语法突出显示（如果它们是某种语言）。
+调用 `toMatchSnapshot()` 时，我们将所有快照存储在格式化的快照文件中。这意味着我们需要转义快照字符串中的一些字符（即双引号 `"` 和反引号 `` ` ``）。同时，你可能会丢失快照内容的语法突出显示（如果它们是某种语言）。
 
 为了改善这种情况，我们引入 [`toMatchFileSnapshot()`](/api/expect#tomatchfilesnapshot) 以在文件中显式快照。这允许你为快照文件分配任何文件扩展名，并使它们更具可读性。
 
@@ -96,33 +96,38 @@ it('render basic', async () => {
 
 它将与 `./test/basic.output.html` 的内容进行比较。并且可以用 `--update` 标志写回。
 
-## 图像快照 {#visual-snapshots}
+## 图像快照 {#image-snapshots}
 
-对于 UI 组件和页面的视觉回归测试，Vitest 通过[浏览器模式](/guide/browser/)提供了内置支持，使用 [`toMatchScreenshot()`](/guide/browser/assertion-api#tomatchscreenshot-experimental) 断言：
+快照图像也可以使用 [`jest-image-snapshot`](https://github.com/americanexpress/jest-image-snapshot)。
 
-```ts
-import { expect, test } from 'vitest'
-import { page } from 'vitest/browser'
+```bash
+npm i -D jest-image-snapshot
+```
 
-test('button looks correct', async () => {
-  const button = page.getByRole('button')
-  await expect(button).toMatchScreenshot('primary-button')
+```ts
+test('image snapshot', () => {
+  expect(readFileSync('./test/stubs/input-image.png'))
+    .toMatchImageSnapshot()
 })
 ```
 
-它会捕获屏幕截图并与参考图像进行比较，以检测意外的视觉变化。在[视觉回归测试指南](/guide/browser/visual-regression-testing)中了解更多内容。
-
 ## 自定义序列化程序 {#custom-serializer}
 
-你可以添加自己的逻辑来修改快照的序列化方式。像 Jest 一样，Vitest 为内置的 JavaScript 类型、HTML 元素、ImmutableJS 和 React 元素提供了默认的序列化程序。
+你可以添加自己的逻辑来修改快照的序列化方式。像 Jest 一样，Vitest 默认有内置的 JavaScript 类型、HTML 元素、ImmutableJS 和 React 元素提供了默认的序列化程序。
 
 可以使用 [`expect.addSnapshotSerializer`](/api/expect#expect-addsnapshotserializer) 添加自定义序列器。
 
 ```ts
 expect.addSnapshotSerializer({
   serialize(val, config, indentation, depth, refs, printer) {
-    // `printer` is a function that serializes a value using existing plugins.
-    return `Pretty foo: ${printer(val.foo, config, indentation, depth, refs)}`
+    // `printer` 是一个通过现有插件对值进行序列化的函数。
+    return `Pretty foo: ${printer(
+      val.foo,
+      config,
+      indentation,
+      depth,
+      refs
+    )}`
   },
   test(val) {
     return val && Object.prototype.hasOwnProperty.call(val, 'foo')
@@ -130,7 +135,7 @@ expect.addSnapshotSerializer({
 })
 ```
 
-我们还支持 [snapshotSerializers](/config/#snapshotserializers) 选项来隐式添加自定义序列化器。
+我们还支持 [snapshotSerializers](/config/#snapshotserializers) 选项，可以隐式添加自定义序列化器。
 
 ```ts [path/to/custom-serializer.ts]
 import { SnapshotSerializer } from 'vitest'
@@ -156,7 +161,7 @@ export default defineConfig({
 })
 ```
 
-如下所示的测试添加后：
+添加类似的测试后：
 
 ```ts
 test('foo snapshot test', () => {

From 0c652230120b936facd5aa5e11630d7602157ff2 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Wed, 19 Nov 2025 01:00:46 +0800
Subject: [PATCH 14/50] !docs: recovery /guide/coverage

---
 guide/coverage.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/guide/coverage.md b/guide/coverage.md
index 47ab5c5d..8f4597aa 100644
--- a/guide/coverage.md
+++ b/guide/coverage.md
@@ -49,7 +49,7 @@ npm i -D @vitest/coverage-istanbul
 这让用户在享受 V8 覆盖率高速执行的同时，也能获得 Istanbul 覆盖率的高准确度。
 :::
 
-Vitest 默认采用 'v8' 作为覆盖率提供器。
+Vitest 默认采用 `v8` 作为覆盖率提供器。
 此提供器依赖于基于 [V8 引擎](https://v8.dev/) 的 JavaScript 运行环境，比如 NodeJS、Deno，或者 Google Chrome 等 Chromium 内核的浏览器。
 
 覆盖率收集是在程序运行时完成的，通过 [`node:inspector`](https://nodejs.org/api/inspector.html) 模块以及浏览器中的 [Chrome DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/tot/Profiler/) 协议 与 V8 交互即可实现。这样，用户的源码可以直接被执行，而不需要事先进行插桩处理。
@@ -265,7 +265,7 @@ export default CustomCoverageProviderModule
 
 请参阅类型定义查看有关详细信息。
 
-## 更改默认覆盖文件夹位置 {#changing-the-default-coverage-folder-location}
+## 更改默认覆盖率报告文件夹位置 {#changing-the-default-coverage-folder-location}
 
 运行覆盖率报告时，会在项目的根目录中创建一个 `coverage` 文件夹。 如果你想将它移动到不同的目录，请使用 `vite.config.js` 文件中的 `test.coverage.reportsDirectory` 属性。
 
@@ -311,13 +311,13 @@ if (condition) {
 
 ## 覆盖率性能 {#coverage-performance}
 
-如果你的项目中代码覆盖率生成较慢，请参阅[性能测试分析 | 代码覆盖率](/guide/profiling-test-performance.html#code-coverage)。
+如果你的项目中代码覆盖率生成较慢，请参阅 [性能测试分析 | 代码覆盖率](/guide/profiling-test-performance.html#code-coverage)。
 
-## Vitest UI {#vitest-ui}
+## UI 模式 {#vitest-ui}
 
-我们可以在 [Vitest UI](/guide/ui) 中查看你的覆盖率报告。
+我们可以在 [UI 模式](/guide/ui) 中查看你的覆盖率报告。
 
-Vitest UI 会在以下情况下启用覆盖率报告：
+UI 模式 会在以下情况下启用覆盖率报告：
 
 - 显式启用覆盖率报告：在配置文件中设置 `coverage.enabled=true` ，或运行 Vitest 时添加 `--coverage.enabled=true` 标志。
 - 添加 HTML 报告器：将 `html` 添加到 `coverage.reporter` 列表中，我们还可以启用 `subdir` 选项，将覆盖率报告放在子目录中。

From dae59a29ddff77d1148ee2ddae0cfac64b004341 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Wed, 19 Nov 2025 01:05:40 +0800
Subject: [PATCH 15/50] !docs: recovery /guide/ui

---
 guide/ui.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guide/ui.md b/guide/ui.md
index ff2552f8..3936397a 100644
--- a/guide/ui.md
+++ b/guide/ui.md
@@ -37,7 +37,7 @@ export default defineConfig({
 })
 ```
 
-你可以在 Vitest UI 中查看覆盖率报告：查看 [Vitest UI 覆盖率](/guide/coverage#vitest-ui) 了解更多详情。
+你可以在 Vitest UI 中查看覆盖率报告：查看 [覆盖率 | UI 模式](/guide/coverage#vitest-ui) 了解更多详情。
 
 ::: warning
 如果你仍想在终端中实时查看测试的运行情况，请不要忘记将 `default` 报告器添加到 `reporters` 选项：`['default', 'html']`。

From bc56adedc17421d6020e90832f9abc51bb8de0ff Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Wed, 19 Nov 2025 02:17:02 +0800
Subject: [PATCH 16/50] !docs: recovery /guide/cli

---
 .vitepress/config.ts                |   2 +-
 .vitepress/scripts/cli-generator.ts |   2 +-
 guide/browser/config.md             |  14 +-
 guide/cli-generated.md              | 552 ++++++++++++++--------------
 guide/cli.md                        |   4 +-
 5 files changed, 294 insertions(+), 280 deletions(-)

diff --git a/.vitepress/config.ts b/.vitepress/config.ts
index 980e4042..d5e07c8a 100644
--- a/.vitepress/config.ts
+++ b/.vitepress/config.ts
@@ -622,7 +622,7 @@ function guide(): DefaultTheme.SidebarItem[] {
       link: '/guide/testing-types',
     },
     {
-      text: 'UI模式',
+      text: 'UI 模式',
       link: '/guide/ui',
     },
     {
diff --git a/.vitepress/scripts/cli-generator.ts b/.vitepress/scripts/cli-generator.ts
index bea3ade8..642b9aba 100644
--- a/.vitepress/scripts/cli-generator.ts
+++ b/.vitepress/scripts/cli-generator.ts
@@ -77,7 +77,7 @@ const template = options.map((option) => {
   const title = option.title
   const cli = option.cli
   const config = skipConfig.has(title) ? '' : `[${title}](${title.includes('browser.') ? '/guide/browser/config' : '/config/'}#${title.toLowerCase().replace(/\./g, '-')})`
-  return `### ${title}\n\n- **CLI:** ${cli}\n${config ? `- **Config:** ${config}\n` : ''}\n${option.description}\n`
+  return `### ${title}\n\n- **命令行终端:** ${cli}\n${config ? `- **配置:** ${config}\n` : ''}\n${option.description}\n`
 }).join('\n')
 
 writeFileSync(cliTablePath, template, 'utf-8')
diff --git a/guide/browser/config.md b/guide/browser/config.md
index f5830437..381e8275 100644
--- a/guide/browser/config.md
+++ b/guide/browser/config.md
@@ -40,7 +40,7 @@ export default defineConfig({
 
 - **类型:** `boolean`
 - **默认值:** `false`
-- **CLI:** `--browser`, `--browser.enabled=false`
+- **命令行终端:** `--browser`, `--browser.enabled=false`
 
 默认情况下在浏览器中运行所有测试。请注意，`--browser` 仅在我们至少有一个 [`browser.instances`](#browser-instances) 项时有效。
 
@@ -95,7 +95,7 @@ export default defineConfig({
 
 - **类型:** `boolean`
 - **默认值:** `process.env.CI`
-- **CLI:** `--browser.headless`, `--browser.headless=false`
+- **命令行终端:** `--browser.headless`, `--browser.headless=false`
 
 在 `headless` 模式下运行浏览器。如果我们在 CI 中运行 Vitest，则默认启用此模式。
 
@@ -103,7 +103,7 @@ export default defineConfig({
 
 - **类型:** `boolean`
 - **默认值:** `true`
-- **CLI:** `--browser.isolate`, `--browser.isolate=false`
+- **命令行终端:** `--browser.isolate`, `--browser.isolate=false`
 
 在单独的 iframe 中运行每个测试。
 
@@ -117,7 +117,7 @@ HTML 入口点的路径。可以是相对于项目根目录的路径。此文件
 
 - **类型:** `number | { port?, strictPort?, host? }`
 - **默认值:** `63315`
-- **CLI:** `--browser.api=63315`, `--browser.api.port=1234, --browser.api.host=example.com`
+- **命令行终端:** `--browser.api=63315`, `--browser.api.port=1234, --browser.api.host=example.com`
 
 配置为浏览器提供代码的 Vite 服务器的选项。不影响 [`test.api`](#api) 选项。默认情况下，Vitest 分配端口 `63315` 以避免与开发服务器冲突，允许我们同时运行两者。
 
@@ -125,7 +125,7 @@ HTML 入口点的路径。可以是相对于项目根目录的路径。此文件
 
 - **类型:** `BrowserProviderOption`
 - **默认值:** `'preview'`
-- **CLI:** `--browser.provider=playwright`
+- **命令行终端:** `--browser.provider=playwright`
 
 提供者工厂的返回值。你可以从 `@vitest/browser-<provider-name>` 导入工厂函数，或者创建自己的提供者：
 
@@ -206,7 +206,7 @@ export interface BrowserProvider {
 
 - **类型:** `boolean`
 - **默认值:** `!isCI`
-- **CLI:** `--browser.ui=false`
+- **命令行终端:** `--browser.ui=false`
 
 是否应将 Vitest UI 注入页面。默认情况下，在开发期间注入 UI iframe。
 
@@ -303,7 +303,7 @@ export interface BrowserScript {
 ## browser.trace
 
 - **类型：** `'on' | 'off' | 'on-first-retry' | 'on-all-retries' | 'retain-on-failure' | object`
-- **CLI:** `--browser.trace=on`, `--browser.trace=retain-on-failure`
+- **命令行终端:** `--browser.trace=on`, `--browser.trace=retain-on-failure`
 - **Default:** `'off'`
 
 Capture a trace of your browser test runs. You can preview traces with [Playwright Trace Viewer](https://trace.playwright.dev/).
diff --git a/guide/cli-generated.md b/guide/cli-generated.md
index 9ca5fc3c..4cb93af6 100644
--- a/guide/cli-generated.md
+++ b/guide/cli-generated.md
@@ -1,904 +1,918 @@
 ### root
 
-- **CLI:** `-r, --root <path>`
-- **Config:** [root](/config/#root)
+- **命令行终端:** `-r, --root <path>`
+- **配置:** [root](/config/#root)
 
 根路径
 
 ### config
 
-- **CLI:** `-c, --config <path>`
+- **命令行终端:** `-c, --config <path>`
 
 配置文件的路径
 
 ### update
 
-- **CLI:** `-u, --update`
-- **Config:** [update](/config/#update)
+- **命令行终端:** `-u, --update`
+- **配置:** [update](/config/#update)
 
 更新快照
 
 ### watch
 
-- **CLI:** `-w, --watch`
-- **Config:** [watch](/config/#watch)
+- **命令行终端:** `-w, --watch`
+- **配置:** [watch](/config/#watch)
 
 启用观察模式
 
 ### testNamePattern
 
-- **CLI:** `-t, --testNamePattern <pattern>`
-- **Config:** [testNamePattern](/config/#testnamepattern)
+- **命令行终端:** `-t, --testNamePattern <pattern>`
+- **配置:** [testNamePattern](/config/#testnamepattern)
 
 使用符合指定 regexp 模式的运行测试
 
 ### dir
 
-- **CLI:** `--dir <path>`
-- **Config:** [dir](/config/#dir)
+- **命令行终端:** `--dir <path>`
+- **配置:** [dir](/config/#dir)
 
 扫描测试文件的基本目录
 
 ### ui
 
-- **CLI:** `--ui`
-- **Config:** [ui](/config/#ui)
+- **命令行终端:** `--ui`
+- **配置:** [ui](/config/#ui)
 
-启用UI
+启用 UI 模式
 
 ### open
 
-- **CLI:** `--open`
-- **Config:** [open](/config/#open)
+- **命令行终端:** `--open`
+- **配置:** [open](/config/#open)
 
 自动打开用户界面（默认值：`!process.env.CI`）。
 
 ### api.port
 
-- **CLI:** `--api.port [port]`
+- **命令行终端:** `--api.port [port]`
 
 指定服务器端口。注意，如果端口已被使用，Vite 会自动尝试下一个可用端口，因此这可能不是服务器最终监听的实际端口。如果为 `true`，将设置为`51204`
 
 ### api.host
 
-- **CLI:** `--api.host [host]`
+- **命令行终端:** `--api.host [host]`
 
 指定服务器应该监听哪些 IP 地址。设为 `0.0.0.0` 或 `true` 则监听所有地址，包括局域网地址和公共地址
 
 ### api.strictPort
 
-- **CLI:** `--api.strictPort`
+- **命令行终端:** `--api.strictPort`
 
 设置为 true 时，如果端口已被使用，则退出，而不是自动尝试下一个可用端口
 
 ### silent
 
-- **CLI:** `--silent [value]`
-- **Config:** [silent](/config/#silent)
+- **命令行终端:** `--silent [value]`
+- **配置:** [silent](/config/#silent)
 
 测试的静默控制台输出。使用 `'passed-only'` 仅查看失败测试的日志。
 
 ### hideSkippedTests
 
-- **CLI:** `--hideSkippedTests`
+- **命令行终端:** `--hideSkippedTests`
 
 隐藏跳过测试的日志
 
 ### reporters
 
-- **CLI:** `--reporter <name>`
-- **Config:** [reporters](/config/#reporters)
+- **命令行终端:** `--reporter <name>`
+- **配置:** [reporters](/config/#reporters)
 
 指定报告器（default、blob、verbose、dot、json、tap、tap-flat、junit、tree、hanging-process、github-actions）
 
 ### outputFile
 
-- **CLI:** `--outputFile <filename/-s>`
-- **Config:** [outputFile](/config/#outputfile)
+- **命令行终端:** `--outputFile <filename/-s>`
+- **配置:** [outputFile](/config/#outputfile)
 
-如果还指定了支持报告程序，则将测试结果写入文件，使用 cac 的点符号表示多个报告程序的单个输出结果 (比如: --outputFile.tap=./tap.txt)
+如果还指定了支持报告程序，则将测试结果写入文件，使用 cac 的点符号表示多个报告程序的单个输出结果 (比如: `--outputFile.tap=./tap.txt`)
+
+### coverage.all
+
+- **命令行终端:** `--coverage.all`
+- **配置:** [coverage.all](/config/#coverage-all)
+
+是否将所有文件，包括未测试的文件，都纳入报告中。
 
 ### coverage.provider
 
-- **CLI:** `--coverage.provider <name>`
-- **Config:** [coverage.provider](/config/#coverage-provider)
+- **命令行终端:** `--coverage.provider <name>`
+- **配置:** [coverage.provider](/config/#coverage-provider)
 
 选择覆盖范围采集工具， 可用值为: "v8", "istanbul" and "custom"
 
 ### coverage.enabled
 
-- **CLI:** `--coverage.enabled`
-- **Config:** [coverage.enabled](/config/#coverage-enabled)
+- **命令行终端:** `--coverage.enabled`
+- **配置:** [coverage.enabled](/config/#coverage-enabled)
 
 启用覆盖范围收集。可使用 `--coverage` CLI 选项覆盖（默认值：`false`）。
 
 ### coverage.include
 
-- **CLI:** `--coverage.include <pattern>`
-- **Config:** [coverage.include](/config/#coverage-include)
+- **命令行终端:** `--coverage.include <pattern>`
+- **配置:** [coverage.include](/config/#coverage-include)
 
-作为通配符模式包含在覆盖率中的文件。在使用多个模式时可以指定多次。默认情况下，只包含被测试覆盖的文件。
+覆盖范围中要包含的文件。使用多个扩展名时，可指定多次（默认值：`**`）。
 
 ### coverage.exclude
 
-- **CLI:** `--coverage.exclude <pattern>`
-- **Config:** [coverage.exclude](/config/#coverage-exclude)
+- **命令行终端:** `--coverage.exclude <pattern>`
+- **配置:** [coverage.exclude](/config/#coverage-exclude)
+
+覆盖范围中要排除的文件。使用多个扩展名时，可指定多次（默认情况下： 访问 [`coverage.exclude`](https://vitest.dev/config/#coverage-exclude)
+
+### coverage.extension
 
-覆盖范围中要排除的文件。使用多个扩展名时，可指定多次。
+- **命令行终端:** `--coverage.extension <extension>`
+- **配置:** [coverage.extension](/config/#coverage-extension)
+
+包含在覆盖范围内的扩展名。使用多个扩展名时，可指定多次 (默认值: `[".js", ".cjs", ".mjs", ".ts", ".mts", ".tsx", ".jsx", ".vue", ".svelte"]`)
 
 ### coverage.clean
 
-- **CLI:** `--coverage.clean`
-- **Config:** [coverage.clean](/config/#coverage-clean)
+- **命令行终端:** `--coverage.clean`
+- **配置:** [coverage.clean](/config/#coverage-clean)
 
 运行测试前清除覆盖结果（默认值：true）
 
 ### coverage.cleanOnRerun
 
-- **CLI:** `--coverage.cleanOnRerun`
-- **Config:** [coverage.cleanOnRerun](/config/#coverage-cleanonrerun)
+- **命令行终端:** `--coverage.cleanOnRerun`
+- **配置:** [coverage.cleanOnRerun](/config/#coverage-cleanonrerun)
 
 重新运行监视时清理覆盖率报告（默认值：true）
 
 ### coverage.reportsDirectory
 
-- **CLI:** `--coverage.reportsDirectory <path>`
-- **Config:** [coverage.reportsDirectory](/config/#coverage-reportsdirectory)
+- **命令行终端:** `--coverage.reportsDirectory <path>`
+- **配置:** [coverage.reportsDirectory](/config/#coverage-reportsdirectory)
 
 将覆盖率报告写入的目录（默认值： ./coverage）
 
 ### coverage.reporter
 
-- **CLI:** `--coverage.reporter <name>`
-- **Config:** [coverage.reporter](/config/#coverage-reporter)
+- **命令行终端:** `--coverage.reporter <name>`
+- **配置:** [coverage.reporter](/config/#coverage-reporter)
 
 使用的报告。更多信息请访问 [`coverage.reporter`](https://vitest.dev/config/#coverage-reporter)。 (默认值: `["text", "html", "clover", "json"]`)
 
 ### coverage.reportOnFailure
 
-- **CLI:** `--coverage.reportOnFailure`
-- **Config:** [coverage.reportOnFailure](/config/#coverage-reportonfailure)
+- **命令行终端:** `--coverage.reportOnFailure`
+- **配置:** [coverage.reportOnFailure](/config/#coverage-reportonfailure)
 
 即使测试失败也能生成覆盖率报告 (默认值: `false`)
 
 ### coverage.allowExternal
 
-- **CLI:** `--coverage.allowExternal`
-- **Config:** [coverage.allowExternal](/config/#coverage-allowexternal)
+- **命令行终端:** `--coverage.allowExternal`
+- **配置:** [coverage.allowExternal](/config/#coverage-allowexternal)
 
 收集项目根目录外文件的覆盖范围（默认值：`false`）
 
 ### coverage.skipFull
 
-- **CLI:** `--coverage.skipFull`
-- **Config:** [coverage.skipFull](/config/#coverage-skipfull)
+- **命令行终端:** `--coverage.skipFull`
+- **配置:** [coverage.skipFull](/config/#coverage-skipfull)
 
  不显示语句、分支和函数覆盖率为 100% 的文件（默认值：`false`）
 
 ### coverage.thresholds.100
 
-- **CLI:** `--coverage.thresholds.100`
-- **Config:** [coverage.thresholds.100](/config/#coverage-thresholds-100)
+- **命令行终端:** `--coverage.thresholds.100`
+- **配置:** [coverage.thresholds.100](/config/#coverage-thresholds-100)
 
 将所有覆盖率阈值设置为 100 的快捷方式（默认值：`false`）
 
 ### coverage.thresholds.perFile
 
-- **CLI:** `--coverage.thresholds.perFile`
-- **Config:** [coverage.thresholds.perFile](/config/#coverage-thresholds-perfile)
+- **命令行终端:** `--coverage.thresholds.perFile`
+- **配置:** [coverage.thresholds.perFile](/config/#coverage-thresholds-perfile)
 
-查每个文件的阈值。 `--coverage.thresholds.lines`, `--coverage.thresholds.functions`, `--coverage.thresholds.branches`, `--coverage.thresholds.statements` 为实际阈值（默认值：`false`）
+检查每个文件的阈值。 `--coverage.thresholds.lines`, `--coverage.thresholds.functions`, `--coverage.thresholds.branches`, `--coverage.thresholds.statements` 为实际阈值（默认值：`false`）
 
 ### coverage.thresholds.autoUpdate
 
-- **CLI:** `--coverage.thresholds.autoUpdate <boolean|function>`
-- **Config:** [coverage.thresholds.autoUpdate](/config/#coverage-thresholds-autoupdate)
+- **命令行终端:** `--coverage.thresholds.autoUpdate <boolean|function>`
+- **配置:** [coverage.thresholds.autoUpdate](/config/#coverage-thresholds-autoupdate)
 
-更新阈值： 当当前覆盖率高于配置的阈值时，将 "lines"、"functions"、"branches"和 "statements"更新到配置文件（默认值：`false`）
+更新阈值： 当前覆盖率高于配置的阈值时，将 "lines"、"functions"、"branches"和 "statements"更新到配置文件（默认值：`false`）
 
 ### coverage.thresholds.lines
 
-- **CLI:** `--coverage.thresholds.lines <number>`
+- **命令行终端:** `--coverage.thresholds.lines <number>`
 
 针对代码行的覆盖度阈值设定，请访问 [istanbuljs](https://github.com/istanbuljs/nyc#coverage-thresholds) 了解更多信息。此选项不适用于自定义 providers
 
 ### coverage.thresholds.functions
 
-- **CLI:** `--coverage.thresholds.functions <number>`
+- **命令行终端:** `--coverage.thresholds.functions <number>`
 
-针对函数的覆盖度阈值设定，请访问 [istanbuljs](https://github.com/istanbuljs/nyc#coverage-thresholds) 了解更多信息。 此选项不适用于自定义 providers
+针对函数的覆盖度阈值设定，请访问 [istanbuljs](https://github.com/istanbuljs/nyc#coverage-thresholds) 了解更多信息。此选项不适用于自定义 providers
 
 ### coverage.thresholds.branches
 
-- **CLI:** `--coverage.thresholds.branches <number>`
+- **命令行终端:** `--coverage.thresholds.branches <number>`
 
-针对 branches 的覆盖度阈值设定，请访问 [istanbuljs](https://github.com/istanbuljs/nyc#coverage-thresholds) 了解更多信息。 此选项不适用于自定义 providers
+针对 branches 的覆盖度阈值设定，请访问 [istanbuljs](https://github.com/istanbuljs/nyc#coverage-thresholds) 了解更多信息。此选项不适用于自定义 providers
 
 ### coverage.thresholds.statements
 
-- **CLI:** `--coverage.thresholds.statements <number>`
+- **命令行终端:** `--coverage.thresholds.statements <number>`
 
-针对 statements 的覆盖度阈值设定，请访问 [istanbuljs](https://github.com/istanbuljs/nyc#coverage-thresholds) 了解更多信息。 此选项不适用于自定义 providers
+针对 statements 的覆盖度阈值设定，请访问 [istanbuljs](https://github.com/istanbuljs/nyc#coverage-thresholds) 了解更多信息。此选项不适用于自定义 providers
 
 ### coverage.ignoreClassMethods
 
-- **CLI:** `--coverage.ignoreClassMethods <name>`
-- **Config:** [coverage.ignoreClassMethods](/config/#coverage-ignoreclassmethods)
+- **命令行终端:** `--coverage.ignoreClassMethods <name>`
+- **配置:** [coverage.ignoreClassMethods](/config/#coverage-ignoreclassmethods)
 
 覆盖时要忽略的类方法名称数组。更多信息请访问 [istanbuljs](https://github.com/istanbuljs/nyc#ignoring-methods) 。该选项仅适用于 istanbul providers（默认值：`[]`）。
 
 ### coverage.processingConcurrency
 
-- **CLI:** `--coverage.processingConcurrency <number>`
-- **Config:** [coverage.processingConcurrency](/config/#coverage-processingconcurrency)
+- **命令行终端:** `--coverage.processingConcurrency <number>`
+- **配置:** [coverage.processingConcurrency](/config/#coverage-processingconcurrency)
 
 处理覆盖率结果时使用的并发限制。 （默认最小值介于 20 和 CPU 数量之间）
 
 ### coverage.customProviderModule
 
-- **CLI:** `--coverage.customProviderModule <path>`
-- **Config:** [coverage.customProviderModule](/config/#coverage-customprovidermodule)
+- **命令行终端:** `--coverage.customProviderModule <path>`
+- **配置:** [coverage.customProviderModule](/config/#coverage-customprovidermodule)
 
-指定自定义覆盖范围提供程序模块的模块名称或路径。 请访问[自定义 providers 覆盖范围](https://vitest.dev/guide/coverage#custom-coverage-provider) 了解更多信息。 此选项仅适用于自定义 providers
+指定自定义覆盖范围提供程序模块的模块名称或路径。 请访问 [自定义 providers 覆盖范围](/guide/coverage#custom-coverage-provider) 了解更多信息。此选项仅适用于自定义 providers
 
 ### coverage.watermarks.statements
 
-- **CLI:** `--coverage.watermarks.statements <watermarks>`
+- **命令行终端:** `--coverage.watermarks.statements <watermarks>`
 
 High and low watermarks for statements in the format of `<high>,<low>`
 
 ### coverage.watermarks.lines
 
-- **CLI:** `--coverage.watermarks.lines <watermarks>`
+- **命令行终端:** `--coverage.watermarks.lines <watermarks>`
 
 High and low watermarks for lines in the format of `<high>,<low>`
 
 ### coverage.watermarks.branches
 
-- **CLI:** `--coverage.watermarks.branches <watermarks>`
+- **命令行终端:** `--coverage.watermarks.branches <watermarks>`
 
 High and low watermarks for branches in the format of `<high>,<low>`
 
 ### coverage.watermarks.functions
 
-- **CLI:** `--coverage.watermarks.functions <watermarks>`
+- **命令行终端:** `--coverage.watermarks.functions <watermarks>`
 
 High and low watermarks for functions in the format of `<high>,<low>`
 
 ### mode
 
-- **CLI:** `--mode <name>`
-- **Config:** [mode](/config/#mode)
+- **命令行终端:** `--mode <name>`
+- **配置:** [mode](/config/#mode)
 
 覆盖 Vite 模式 (默认值: `test` 或 `benchmark`)
 
+### workspace
+
+- **命令行终端:** `--workspace <path>`
+- **配置:** [workspace](/config/#workspace)
+
+（已废弃）工作区配置文件的路径
+
 ### isolate
 
-- **CLI:** `--isolate`
-- **Config:** [isolate](/config/#isolate)
+- **命令行终端:** `--isolate`
+- **配置:** [isolate](/config/#isolate)
 
 隔离运行每个测试文件。要禁用隔离, 使用 `--no-isolate` (默认值: `true`)
 
 ### globals
 
-- **CLI:** `--globals`
-- **Config:** [globals](/config/#globals)
+- **命令行终端:** `--globals`
+- **配置:** [globals](/config/#globals)
 
 全局注入
 
 ### dom
 
-- **CLI:** `--dom`
+- **命令行终端:** `--dom`
 
 使用 happy-dom 模拟浏览器 API
 
 ### browser.enabled
 
-- **CLI:** `--browser.enabled`
-- **Config:** [browser.enabled](/guide/browser/config#browser-enabled)
+- **命令行终端:** `--browser.enabled`
+- **配置:** [browser.enabled](/guide/browser/config#browser-enabled)
 
 在浏览器中运行测试。 相当于 `--browser.enabled` (默认值: `false`)
 
 ### browser.name
 
-- **CLI:** `--browser.name <name>`
-- **Config:** [browser.name](/guide/browser/config#browser-name)
+- **命令行终端:** `--browser.name <name>`
+- **配置:** [browser.name](/guide/browser/config#browser-name)
 
 在特定浏览器中运行所有测试。某些浏览器仅适用于特定提供商（请参阅 `--browser.provider` ）。访问 [`browser.name`](https://vitest.dev/guide/browser/config/#browser-name) 了解更多信息
 
 ### browser.headless
 
-- **CLI:** `--browser.headless`
-- **Config:** [browser.headless](/guide/browser/config#browser-headless)
+- **命令行终端:** `--browser.headless`
+- **配置:** [browser.headless](/guide/browser/config#browser-headless)
 
 在无头模式下运行浏览器（即不打开图形用户界面）。如果在 CI 中运行 Vitest，默认情况下将启用无头模式 (默认值: `process.env.CI`)
 
 ### browser.api.port
 
-- **CLI:** `--browser.api.port [port]`
-- **Config:** [browser.api.port](/guide/browser/config#browser-api-port)
+- **命令行终端:** `--browser.api.port [port]`
+- **配置:** [browser.api.port](/guide/browser/config#browser-api-port)
 
 指定服务器端口。注意，如果端口已被使用，Vite 会自动尝试下一个可用端口，因此这可能不是服务器最终监听的实际端口。如果为 `true`，将设置为 `63315`
 
 ### browser.api.host
 
-- **CLI:** `--browser.api.host [host]`
-- **Config:** [browser.api.host](/guide/browser/config#browser-api-host)
+- **命令行终端:** `--browser.api.host [host]`
+- **配置:** [browser.api.host](/guide/browser/config#browser-api-host)
 
 指定服务器应该监听哪些 IP 地址。设为 `0.0.0.0` 或 `true` 则监听所有地址，包括局域网地址和公共地址
 
 ### browser.api.strictPort
 
-- **CLI:** `--browser.api.strictPort`
-- **Config:** [browser.api.strictPort](/guide/browser/config#browser-api-strictport)
+- **命令行终端:** `--browser.api.strictPort`
+- **配置:** [browser.api.strictPort](/guide/browser/config#browser-api-strictport)
 
 设置为 true 时，如果端口已被使用，则退出，而不是自动尝试下一个可用端口
 
 ### browser.provider
 
-- **CLI:** `--browser.provider <name>`
-- **Config:** [browser.provider](/guide/browser/config#browser-provider)
+- **命令行终端:** `--browser.provider <name>`
+- **配置:** [browser.provider](/guide/browser/config#browser-provider)
 
-指定执行浏览器测试时所使用的提供程序。部分浏览器仅在特定的提供程序下可用。可选值有 "webdriverio"、"playwright"、"preview"，也可以填写自定义提供程序的路径。更多信息请查看 [`browser.provider`](https://vitest.dev/guide/browser/config.html#browser-provider)（默认值为 "preview"）。
+指定执行浏览器测试时所使用的提供程序。部分浏览器仅在特定的提供程序下可用。可选值有 "webdriverio"、"playwright"、"preview"，也可以填写自定义提供程序的路径。更多信息请查看 [`browser.provider`](https://vitest.dev/guide/browser/config.html#browser-provider)（默认值为 "preview"）
+
+### browser.providerOptions
+
+- **命令行终端:** `--browser.providerOptions <options>`
+- **配置:** [browser.providerOptions](/guide/browser/config#browser-provideroptions)
+
+传递给浏览器提供程序的选项。更多信息请访问 [`browser.providerOptions`](https://vitest.dev/config/#browser-provideroptions)
 
 ### browser.isolate
 
-- **CLI:** `--browser.isolate`
-- **Config:** [browser.isolate](/guide/browser/config#browser-isolate)
+- **命令行终端:** `--browser.isolate`
+- **配置:** [browser.isolate](/guide/browser/config#browser-isolate)
 
 隔离运行每个浏览器测试文件。要禁用隔离请使用 `--browser.isolate=false` (默认值: `true`)
 
 ### browser.ui
 
-- **CLI:** `--browser.ui`
-- **Config:** [browser.ui](/guide/browser/config#browser-ui)
+- **命令行终端:** `--browser.ui`
+- **配置:** [browser.ui](/guide/browser/config#browser-ui)
 
-运行测试时显示 Vitest UI(默认值: `!process.env.CI`)
+运行测试时显示 Vitest UI (默认值: `!process.env.CI`)
 
 ### browser.fileParallelism
 
-- **CLI:** `--browser.fileParallelism`
-- **Config:** [browser.fileParallelism](/guide/browser/config#browser-fileparallelism)
+- **命令行终端:** `--browser.fileParallelism`
+- **配置:** [browser.fileParallelism](/guide/browser/config#browser-fileparallelism)
 
-浏览器测试文件是否应并行运行。使用 `--browser.fileParallelism=false` 可禁用 (默认值: `true`)
+浏览器测试文件是否应并行运行。使用 `--browser.fileParallelism=false` 进行禁用 (默认值: `true`)
 
 ### browser.connectTimeout
 
-- **CLI:** `--browser.connectTimeout <timeout>`
-- **Config:** [browser.connectTimeout](/guide/browser/config#browser-connecttimeout)
-
-If connection to the browser takes longer, the test suite will fail (default: `60_000`)
-
-### browser.trackUnhandledErrors
-
-- **CLI:** `--browser.trackUnhandledErrors`
-- **Config:** [browser.trackUnhandledErrors](/guide/browser/config#browser-trackunhandlederrors)
-
-控制 Vitest 是否捕获未捕获的异常以便报告（默认：`true`）。
-
-### browser.trace
-
-- **CLI:** `--browser.trace <mode>`
-- **Config:** [browser.trace](/guide/browser/config#browser-trace)
+- **命令行终端:** `--browser.connectTimeout <timeout>`
+- **配置:** [browser.connectTimeout](/guide/browser/config#browser-connecttimeout)
 
-Enable trace view mode. Supported: "on", "off", "on-first-retry", "on-all-retries", "retain-on-failure".
+如果连接浏览器时间超时，测试套件将失败 (默认值: `60_000`)
 
 ### pool
 
-- **CLI:** `--pool <pool>`
-- **Config:** [pool](/config/#pool)
+- **命令行终端:** `--pool <pool>`
+- **配置:** [pool](/config/#pool)
 
 如果未在浏览器中运行，则指定 pool (默认值: `threads`)
 
 ### poolOptions.threads.isolate
 
-- **CLI:** `--poolOptions.threads.isolate`
-- **Config:** [poolOptions.threads.isolate](/config/#pooloptions-threads-isolate)
+- **命令行终端:** `--poolOptions.threads.isolate`
+- **配置:** [poolOptions.threads.isolate](/config/#pooloptions-threads-isolate)
 
 在线程池中隔离测试 (默认值: `true`)
 
 ### poolOptions.threads.singleThread
 
-- **CLI:** `--poolOptions.threads.singleThread`
-- **Config:** [poolOptions.threads.singleThread](/config/#pooloptions-threads-singlethread)
+- **命令行终端:** `--poolOptions.threads.singleThread`
+- **配置:** [poolOptions.threads.singleThread](/config/#pooloptions-threads-singlethread)
 
 在单线程内运行测试 (默认值: `false`)
 
 ### poolOptions.threads.maxThreads
 
-- **CLI:** `--poolOptions.threads.maxThreads <workers>`
-- **Config:** [poolOptions.threads.maxThreads](/config/#pooloptions-threads-maxthreads)
+- **命令行终端:** `--poolOptions.threads.maxThreads <workers>`
+- **配置:** [poolOptions.threads.maxThreads](/config/#pooloptions-threads-maxthreads)
 
 运行测试的最大线程数或百分比
 
 ### poolOptions.threads.useAtomics
 
-- **CLI:** `--poolOptions.threads.useAtomics`
-- **Config:** [poolOptions.threads.useAtomics](/config/#pooloptions-threads-useatomics)
+- **命令行终端:** `--poolOptions.threads.useAtomics`
+- **配置:** [poolOptions.threads.useAtomics](/config/#pooloptions-threads-useatomics)
 
 使用 Atomics 同步线程。这在某些情况下可以提高性能，但在较旧的 Node 版本中可能会导致 segfault。 (默认值: `false`)
 
 ### poolOptions.vmThreads.isolate
 
-- **CLI:** `--poolOptions.vmThreads.isolate`
-- **Config:** [poolOptions.vmThreads.isolate](/config/#pooloptions-vmthreads-isolate)
+- **命令行终端:** `--poolOptions.vmThreads.isolate`
+- **配置:** [poolOptions.vmThreads.isolate](/config/#pooloptions-vmthreads-isolate)
 
 在线程池中隔离测试 (默认值: `true`)
 
 ### poolOptions.vmThreads.singleThread
 
-- **CLI:** `--poolOptions.vmThreads.singleThread`
-- **Config:** [poolOptions.vmThreads.singleThread](/config/#pooloptions-vmthreads-singlethread)
+- **命令行终端:** `--poolOptions.vmThreads.singleThread`
+- **配置:** [poolOptions.vmThreads.singleThread](/config/#pooloptions-vmthreads-singlethread)
 
 在单线程内运行测试（默认值：`false`）
 
 ### poolOptions.vmThreads.maxThreads
 
-- **CLI:** `--poolOptions.vmThreads.maxThreads <workers>`
-- **Config:** [poolOptions.vmThreads.maxThreads](/config/#pooloptions-vmthreads-maxthreads)
+- **命令行终端:** `--poolOptions.vmThreads.maxThreads <workers>`
+- **配置:** [poolOptions.vmThreads.maxThreads](/config/#pooloptions-vmthreads-maxthreads)
 
  运行测试的最大线程数或百分比
 
 ### poolOptions.vmThreads.useAtomics
 
-- **CLI:** `--poolOptions.vmThreads.useAtomics`
-- **Config:** [poolOptions.vmThreads.useAtomics](/config/#pooloptions-vmthreads-useatomics)
+- **命令行终端:** `--poolOptions.vmThreads.useAtomics`
+- **配置:** [poolOptions.vmThreads.useAtomics](/config/#pooloptions-vmthreads-useatomics)
 
 使用 Atomics 同步线程。这在某些情况下可以提高性能，但在较旧的 Node 版本中可能会导致 segfault。 (默认值: `false`)
 
 ### poolOptions.vmThreads.memoryLimit
 
-- **CLI:** `--poolOptions.vmThreads.memoryLimit <limit>`
-- **Config:** [poolOptions.vmThreads.memoryLimit](/config/#pooloptions-vmthreads-memorylimit)
+- **命令行终端:** `--poolOptions.vmThreads.memoryLimit <limit>`
+- **配置:** [poolOptions.vmThreads.memoryLimit](/config/#pooloptions-vmthreads-memorylimit)
 
 虚拟机线程池的内存限制。如果发现内存泄漏，请尝试调整该值。
 
 ### poolOptions.forks.isolate
 
-- **CLI:** `--poolOptions.forks.isolate`
-- **Config:** [poolOptions.forks.isolate](/config/#pooloptions-forks-isolate)
+- **命令行终端:** `--poolOptions.forks.isolate`
+- **配置:** [poolOptions.forks.isolate](/config/#pooloptions-forks-isolate)
 
 在 forks pool 中隔离测试 (默认值: `true`)
 
 ### poolOptions.forks.singleFork
 
-- **CLI:** `--poolOptions.forks.singleFork`
-- **Config:** [poolOptions.forks.singleFork](/config/#pooloptions-forks-singlefork)
+- **命令行终端:** `--poolOptions.forks.singleFork`
+- **配置:** [poolOptions.forks.singleFork](/config/#pooloptions-forks-singlefork)
 
 单个子进程内运行测试 (default: `false`)
 
 ### poolOptions.forks.maxForks
 
-- **CLI:** `--poolOptions.forks.maxForks <workers>`
-- **Config:** [poolOptions.forks.maxForks](/config/#pooloptions-forks-maxforks)
+- **命令行终端:** `--poolOptions.forks.maxForks <workers>`
+- **配置:** [poolOptions.forks.maxForks](/config/#pooloptions-forks-maxforks)
 
 运行测试的最大进程数
 
 ### poolOptions.vmForks.isolate
 
-- **CLI:** `--poolOptions.vmForks.isolate`
-- **Config:** [poolOptions.vmForks.isolate](/config/#pooloptions-vmforks-isolate)
+- **命令行终端:** `--poolOptions.vmForks.isolate`
+- **配置:** [poolOptions.vmForks.isolate](/config/#pooloptions-vmforks-isolate)
 
 在 forks pool 中隔离测试 (default: `true`)
 
 ### poolOptions.vmForks.singleFork
 
-- **CLI:** `--poolOptions.vmForks.singleFork`
-- **Config:** [poolOptions.vmForks.singleFork](/config/#pooloptions-vmforks-singlefork)
+- **命令行终端:** `--poolOptions.vmForks.singleFork`
+- **配置:** [poolOptions.vmForks.singleFork](/config/#pooloptions-vmforks-singlefork)
 
 在单个子进程内运行测试 (default: `false`)
 
 ### poolOptions.vmForks.maxForks
 
-- **CLI:** `--poolOptions.vmForks.maxForks <workers>`
-- **Config:** [poolOptions.vmForks.maxForks](/config/#pooloptions-vmforks-maxforks)
+- **命令行终端:** `--poolOptions.vmForks.maxForks <workers>`
+- **配置:** [poolOptions.vmForks.maxForks](/config/#pooloptions-vmforks-maxforks)
 
 运行测试的最大进程数
 
 ### poolOptions.vmForks.memoryLimit
 
-- **CLI:** `--poolOptions.vmForks.memoryLimit <limit>`
-- **Config:** [poolOptions.vmForks.memoryLimit](/config/#pooloptions-vmforks-memorylimit)
+- **命令行终端:** `--poolOptions.vmForks.memoryLimit <limit>`
+- **配置:** [poolOptions.vmForks.memoryLimit](/config/#pooloptions-vmforks-memorylimit)
 
 VM forks pool 的内存限制。如果你观察到内存泄漏问题，可以尝试调整这个值。
 
 ### fileParallelism
 
-- **CLI:** `--fileParallelism`
-- **Config:** [fileParallelism](/config/#fileparallelism)
+- **命令行终端:** `--fileParallelism`
+- **配置:** [fileParallelism](/config/#fileparallelism)
 
 是否所有测试文件都应并行运行. 使用 `--no-file-parallelism` 去禁用 (默认值: `true`)
 
 ### maxWorkers
 
-- **CLI:** `--maxWorkers <workers>`
-- **Config:** [maxWorkers](/config/#maxworkers)
+- **命令行终端:** `--maxWorkers <workers>`
+- **配置:** [maxWorkers](/config/#maxworkers)
 
 同时并发执行测试任务的最大线程数或百分比
 
 ### environment
 
-- **CLI:** `--environment <name>`
-- **Config:** [environment](/config/#environment)
+- **命令行终端:** `--environment <name>`
+- **配置:** [environment](/config/#environment)
 
 如果不在浏览器中运行，则指定运行环境 (默认值: `node`)
 
 ### passWithNoTests
 
-- **CLI:** `--passWithNoTests`
-- **Config:** [passWithNoTests](/config/#passwithnotests)
+- **命令行终端:** `--passWithNoTests`
+- **配置:** [passWithNoTests](/config/#passwithnotests)
 
 未发现测试时通过
 
 ### logHeapUsage
 
-- **CLI:** `--logHeapUsage`
-- **Config:** [logHeapUsage](/config/#logheapusage)
+- **命令行终端:** `--logHeapUsage`
+- **配置:** [logHeapUsage](/config/#logheapusage)
 
 在节点中运行时，显示每个测试的堆大小
 
 ### allowOnly
 
-- **CLI:** `--allowOnly`
-- **Config:** [allowOnly](/config/#allowonly)
+- **命令行终端:** `--allowOnly`
+- **配置:** [allowOnly](/config/#allowonly)
 
 允许执行那些被标记为"only"的测试用例或测试套件 (默认值: `!process.env.CI`)
 
 ### dangerouslyIgnoreUnhandledErrors
 
-- **CLI:** `--dangerouslyIgnoreUnhandledErrors`
-- **Config:** [dangerouslyIgnoreUnhandledErrors](/config/#dangerouslyignoreunhandlederrors)
+- **命令行终端:** `--dangerouslyIgnoreUnhandledErrors`
+- **配置:** [dangerouslyIgnoreUnhandledErrors](/config/#dangerouslyignoreunhandlederrors)
 
 忽略任何未处理的错误
 
 ### sequence.shuffle.files
 
-- **CLI:** `--sequence.shuffle.files`
-- **Config:** [sequence.shuffle.files](/config/#sequence-shuffle-files)
+- **命令行终端:** `--sequence.shuffle.files`
+- **配置:** [sequence.shuffle.files](/config/#sequence-shuffle-files)
 
 以随机顺序运行文件。如果启用此选项，长时间运行的测试将不会提前开始。 (默认值: `false`)
 
 ### sequence.shuffle.tests
 
-- **CLI:** `--sequence.shuffle.tests`
-- **Config:** [sequence.shuffle.tests](/config/#sequence-shuffle-tests)
+- **命令行终端:** `--sequence.shuffle.tests`
+- **配置:** [sequence.shuffle.tests](/config/#sequence-shuffle-tests)
 
 以随机方式运行测试（默认值：`false`）
 
 ### sequence.concurrent
 
-- **CLI:** `--sequence.concurrent`
-- **Config:** [sequence.concurrent](/config/#sequence-concurrent)
+- **命令行终端:** `--sequence.concurrent`
+- **配置:** [sequence.concurrent](/config/#sequence-concurrent)
 
 使测试并行运行（默认值：`false`）
 
 ### sequence.seed
 
-- **CLI:** `--sequence.seed <seed>`
-- **Config:** [sequence.seed](/config/#sequence-seed)
+- **命令行终端:** `--sequence.seed <seed>`
+- **配置:** [sequence.seed](/config/#sequence-seed)
 
 设置随机化种子。如果 --sequence.shuffle（随机序列）是`false`，则此选项无效。 t 通过 ["Random Seed" page](https://en.wikipedia.org/wiki/Random_seed) 查看更多信息
 
 ### sequence.hooks
 
-- **CLI:** `--sequence.hooks <order>`
-- **Config:** [sequence.hooks](/config/#sequence-hooks)
+- **命令行终端:** `--sequence.hooks <order>`
+- **配置:** [sequence.hooks](/config/#sequence-hooks)
 
 更改钩子的执行顺序。 可接受的值有: "stack", "list" and "parallel". 通过 [`sequence.hooks`](https://vitest.dev/config/#sequence-hooks) 查看更多信息 (默认值: `"parallel"`)
 
 ### sequence.setupFiles
 
-- **CLI:** `--sequence.setupFiles <order>`
-- **Config:** [sequence.setupFiles](/config/#sequence-setupfiles)
+- **命令行终端:** `--sequence.setupFiles <order>`
+- **配置:** [sequence.setupFiles](/config/#sequence-setupfiles)
 
  更改设置文件的执行顺序。可接受的值有 "list" 和 "parallel"。如果设置为"list"，将按照定义的顺序运行设置文件。如果设置为 "parallel"，将并行运行设置文件（默认值：`"parallel"`）。
 
 ### inspect
 
-- **CLI:** `--inspect [[host:]port]`
-- **Config:** [inspect](/config/#inspect)
+- **命令行终端:** `--inspect [[host:]port]`
+- **配置:** [inspect](/config/#inspect)
 
 启用 Node.js 检查器（默认值：`127.0.0.1:9229`）
 
 ### inspectBrk
 
-- **CLI:** `--inspectBrk [[host:]port]`
-- **Config:** [inspectBrk](/config/#inspectbrk)
+- **命令行终端:** `--inspectBrk [[host:]port]`
+- **配置:** [inspectBrk](/config/#inspectbrk)
 
 启用 Node.js 检查器并在测试开始前中断
 
 ### testTimeout
 
-- **CLI:** `--testTimeout <timeout>`
-- **Config:** [testTimeout](/config/#testtimeout)
+- **命令行终端:** `--testTimeout <timeout>`
+- **配置:** [testTimeout](/config/#testtimeout)
 
 测试的默认超时（毫秒）（默认值：`5000`）。使用 `0` 完全禁用超时。
 
 ### hookTimeout
 
-- **CLI:** `--hookTimeout <timeout>`
-- **Config:** [hookTimeout](/config/#hooktimeout)
+- **命令行终端:** `--hookTimeout <timeout>`
+- **配置:** [hookTimeout](/config/#hooktimeout)
 
 默认钩子超时（以毫秒为单位）（默认值：`10000`）。使用 `0` 完全禁用超时。
 
 ### bail
 
-- **CLI:** `--bail <number>`
-- **Config:** [bail](/config/#bail)
+- **命令行终端:** `--bail <number>`
+- **配置:** [bail](/config/#bail)
 
 当指定数量的测试失败时停止测试执行（默认值：`0`）
 
 ### retry
 
-- **CLI:** `--retry <times>`
-- **Config:** [retry](/config/#retry)
+- **命令行终端:** `--retry <times>`
+- **配置:** [retry](/config/#retry)
 
 如果测试失败，重试特定次数（默认值： `0`）。
 
 ### diff.aAnnotation
 
-- **CLI:** `--diff.aAnnotation <annotation>`
-- **Config:** [diff.aAnnotation](/config/#diff-aannotation)
+- **命令行终端:** `--diff.aAnnotation <annotation>`
+- **配置:** [diff.aAnnotation](/config/#diff-aannotation)
 
 Annotation for expected lines (default: `Expected`)
 
 ### diff.aIndicator
 
-- **CLI:** `--diff.aIndicator <indicator>`
-- **Config:** [diff.aIndicator](/config/#diff-aindicator)
+- **命令行终端:** `--diff.aIndicator <indicator>`
+- **配置:** [diff.aIndicator](/config/#diff-aindicator)
 
 Indicator for expected lines (default: `-`)
 
 ### diff.bAnnotation
 
-- **CLI:** `--diff.bAnnotation <annotation>`
-- **Config:** [diff.bAnnotation](/config/#diff-bannotation)
+- **命令行终端:** `--diff.bAnnotation <annotation>`
+- **配置:** [diff.bAnnotation](/config/#diff-bannotation)
 
 Annotation for received lines (default: `Received`)
 
 ### diff.bIndicator
 
-- **CLI:** `--diff.bIndicator <indicator>`
-- **Config:** [diff.bIndicator](/config/#diff-bindicator)
+- **命令行终端:** `--diff.bIndicator <indicator>`
+- **配置:** [diff.bIndicator](/config/#diff-bindicator)
 
 Indicator for received lines (default: `+`)
 
 ### diff.commonIndicator
 
-- **CLI:** `--diff.commonIndicator <indicator>`
-- **Config:** [diff.commonIndicator](/config/#diff-commonindicator)
+- **命令行终端:** `--diff.commonIndicator <indicator>`
+- **配置:** [diff.commonIndicator](/config/#diff-commonindicator)
 
 Indicator for common lines (default: ` `)
 
 ### diff.contextLines
 
-- **CLI:** `--diff.contextLines <lines>`
-- **Config:** [diff.contextLines](/config/#diff-contextlines)
+- **命令行终端:** `--diff.contextLines <lines>`
+- **配置:** [diff.contextLines](/config/#diff-contextlines)
 
 Number of lines of context to show around each change (default: `5`)
 
 ### diff.emptyFirstOrLastLinePlaceholder
 
-- **CLI:** `--diff.emptyFirstOrLastLinePlaceholder <placeholder>`
-- **Config:** [diff.emptyFirstOrLastLinePlaceholder](/config/#diff-emptyfirstorlastlineplaceholder)
+- **命令行终端:** `--diff.emptyFirstOrLastLinePlaceholder <placeholder>`
+- **配置:** [diff.emptyFirstOrLastLinePlaceholder](/config/#diff-emptyfirstorlastlineplaceholder)
 
 Placeholder for an empty first or last line (default: `""`)
 
 ### diff.expand
 
-- **CLI:** `--diff.expand`
-- **Config:** [diff.expand](/config/#diff-expand)
+- **命令行终端:** `--diff.expand`
+- **配置:** [diff.expand](/config/#diff-expand)
 
 Expand all common lines (default: `true`)
 
 ### diff.includeChangeCounts
 
-- **CLI:** `--diff.includeChangeCounts`
-- **Config:** [diff.includeChangeCounts](/config/#diff-includechangecounts)
+- **命令行终端:** `--diff.includeChangeCounts`
+- **配置:** [diff.includeChangeCounts](/config/#diff-includechangecounts)
 
 Include comparison counts in diff output (default: `false`)
 
 ### diff.omitAnnotationLines
 
-- **CLI:** `--diff.omitAnnotationLines`
-- **Config:** [diff.omitAnnotationLines](/config/#diff-omitannotationlines)
+- **命令行终端:** `--diff.omitAnnotationLines`
+- **配置:** [diff.omitAnnotationLines](/config/#diff-omitannotationlines)
 
 Omit annotation lines from the output (default: `false`)
 
 ### diff.printBasicPrototype
 
-- **CLI:** `--diff.printBasicPrototype`
-- **Config:** [diff.printBasicPrototype](/config/#diff-printbasicprototype)
+- **命令行终端:** `--diff.printBasicPrototype`
+- **配置:** [diff.printBasicPrototype](/config/#diff-printbasicprototype)
 
 Print basic prototype Object and Array (default: `true`)
 
 ### diff.maxDepth
 
-- **CLI:** `--diff.maxDepth <maxDepth>`
-- **Config:** [diff.maxDepth](/config/#diff-maxdepth)
+- **命令行终端:** `--diff.maxDepth <maxDepth>`
+- **配置:** [diff.maxDepth](/config/#diff-maxdepth)
 
 Limit the depth to recurse when printing nested objects (default: `20`)
 
 ### diff.truncateThreshold
 
-- **CLI:** `--diff.truncateThreshold <threshold>`
-- **Config:** [diff.truncateThreshold](/config/#diff-truncatethreshold)
+- **命令行终端:** `--diff.truncateThreshold <threshold>`
+- **配置:** [diff.truncateThreshold](/config/#diff-truncatethreshold)
 
 Number of lines to show before and after each change (default: `0`)
 
 ### diff.truncateAnnotation
 
-- **CLI:** `--diff.truncateAnnotation <annotation>`
-- **Config:** [diff.truncateAnnotation](/config/#diff-truncateannotation)
+- **命令行终端:** `--diff.truncateAnnotation <annotation>`
+- **配置:** [diff.truncateAnnotation](/config/#diff-truncateannotation)
 
 Annotation for truncated lines (default: `... Diff result is truncated`)
 
 ### exclude
 
-- **CLI:** `--exclude <glob>`
-- **Config:** [exclude](/config/#exclude)
+- **命令行终端:** `--exclude <glob>`
+- **配置:** [exclude](/config/#exclude)
 
 测试中排除的其他文件路径匹配模式
 
 ### expandSnapshotDiff
 
-- **CLI:** `--expandSnapshotDiff`
-- **Config:** [expandSnapshotDiff](/config/#expandsnapshotdiff)
+- **命令行终端:** `--expandSnapshotDiff`
+- **配置:** [expandSnapshotDiff](/config/#expandsnapshotdiff)
 
 快照失败时显示完整差异
 
 ### disableConsoleIntercept
 
-- **CLI:** `--disableConsoleIntercept`
-- **Config:** [disableConsoleIntercept](/config/#disableconsoleintercept)
+- **命令行终端:** `--disableConsoleIntercept`
+- **配置:** [disableConsoleIntercept](/config/#disableconsoleintercept)
 
 禁用自动拦截控制台日志（默认值：`false`）
 
 ### typecheck.enabled
 
-- **CLI:** `--typecheck.enabled`
-- **Config:** [typecheck.enabled](/config/#typecheck-enabled)
+- **命令行终端:** `--typecheck.enabled`
+- **配置:** [typecheck.enabled](/config/#typecheck-enabled)
 
 在测试的同时启用类型检查（默认值：`false`）
 
 ### typecheck.only
 
-- **CLI:** `--typecheck.only`
-- **Config:** [typecheck.only](/config/#typecheck-only)
+- **命令行终端:** `--typecheck.only`
+- **配置:** [typecheck.only](/config/#typecheck-only)
 
 仅运行类型检查测试。这将自动启用类型检查（默认值：`false`）
 
 ### typecheck.checker
 
-- **CLI:** `--typecheck.checker <name>`
-- **Config:** [typecheck.checker](/config/#typecheck-checker)
+- **命令行终端:** `--typecheck.checker <name>`
+- **配置:** [typecheck.checker](/config/#typecheck-checker)
 
 指定要使用的类型检查器。可用值为 "tsc"和 "vue-tsc "以及一个可执行文件的路径（默认值：`tsc`）
 
 ### typecheck.allowJs
 
-- **CLI:** `--typecheck.allowJs`
-- **Config:** [typecheck.allowJs](/config/#typecheck-allowjs)
+- **命令行终端:** `--typecheck.allowJs`
+- **配置:** [typecheck.allowJs](/config/#typecheck-allowjs)
 
 允许对 JavaScript 文件进行类型检查。默认值取自 tsconfig.json
 
 ### typecheck.ignoreSourceErrors
 
-- **CLI:** `--typecheck.ignoreSourceErrors`
-- **Config:** [typecheck.ignoreSourceErrors](/config/#typecheck-ignoresourceerrors)
+- **命令行终端:** `--typecheck.ignoreSourceErrors`
+- **配置:** [typecheck.ignoreSourceErrors](/config/#typecheck-ignoresourceerrors)
 
 忽略源文件中的类型错误
 
 ### typecheck.tsconfig
 
-- **CLI:** `--typecheck.tsconfig <path>`
-- **Config:** [typecheck.tsconfig](/config/#typecheck-tsconfig)
+- **命令行终端:** `--typecheck.tsconfig <path>`
+- **配置:** [typecheck.tsconfig](/config/#typecheck-tsconfig)
 
 自定义 tsconfig 文件的路径
 
 ### typecheck.spawnTimeout
 
-- **CLI:** `--typecheck.spawnTimeout <time>`
-- **Config:** [typecheck.spawnTimeout](/config/#typecheck-spawntimeout)
+- **命令行终端:** `--typecheck.spawnTimeout <time>`
+- **配置:** [typecheck.spawnTimeout](/config/#typecheck-spawntimeout)
 
 Minimum time in milliseconds it takes to spawn the typechecker
 
 ### project
 
-- **CLI:** `--project <name>`
-- **Config:** [project](/config/#project)
+- **命令行终端:** `--project <name>`
+- **配置:** [project](/config/#project)
 
 如果我们正在使用 Vitest 的工作区功能，这是要运行的项目名称。这个参数可以重复以指定多个项目：`--project=1 --project=2`。我们还可以使用通配符来过滤项目，例如 `--project=packages*`，以及使用 `--project=!pattern` 来排除项目。
 
 ### slowTestThreshold
 
-- **CLI:** `--slowTestThreshold <threshold>`
-- **Config:** [slowTestThreshold](/config/#slowtestthreshold)
+- **命令行终端:** `--slowTestThreshold <threshold>`
+- **配置:** [slowTestThreshold](/config/#slowtestthreshold)
 
 测试速度慢的阈值（以毫秒为单位）（默认值：`300`）
 
 ### teardownTimeout
 
-- **CLI:** `--teardownTimeout <timeout>`
-- **Config:** [teardownTimeout](/config/#teardowntimeout)
+- **命令行终端:** `--teardownTimeout <timeout>`
+- **配置:** [teardownTimeout](/config/#teardowntimeout)
 
 拆卸函数的默认超时（以毫秒为单位）（默认值：`10000`）
 
 ### maxConcurrency
 
-- **CLI:** `--maxConcurrency <number>`
-- **Config:** [maxConcurrency](/config/#maxconcurrency)
+- **命令行终端:** `--maxConcurrency <number>`
+- **配置:** [maxConcurrency](/config/#maxconcurrency)
 
 套件中并发测试的最大次数（默认值：`5`）
 
 ### expect.requireAssertions
 
-- **CLI:** `--expect.requireAssertions`
-- **Config:** [expect.requireAssertions](/config/#expect-requireassertions)
+- **命令行终端:** `--expect.requireAssertions`
+- **配置:** [expect.requireAssertions](/config/#expect-requireassertions)
 
 要求所有测试至少有一个断言
 
 ### expect.poll.interval
 
-- **CLI:** `--expect.poll.interval <interval>`
-- **Config:** [expect.poll.interval](/config/#expect-poll-interval)
+- **命令行终端:** `--expect.poll.interval <interval>`
+- **配置:** [expect.poll.interval](/config/#expect-poll-interval)
 
 断言的轮询间隔 `expect.poll()` (默认值: `50`)
 
 ### expect.poll.timeout
 
-- **CLI:** `--expect.poll.timeout <timeout>`
-- **Config:** [expect.poll.timeout](/config/#expect-poll-timeout)
+- **命令行终端:** `--expect.poll.timeout <timeout>`
+- **配置:** [expect.poll.timeout](/config/#expect-poll-timeout)
 
 断言的轮询超时（以毫秒为单位） `expect.poll()` (默认值: `1000`)
 
 ### printConsoleTrace
 
-- **CLI:** `--printConsoleTrace`
-- **Config:** [printConsoleTrace](/config/#printconsoletrace)
+- **命令行终端:** `--printConsoleTrace`
+- **配置:** [printConsoleTrace](/config/#printconsoletrace)
 
  始终打印控制台堆栈跟踪
 
 ### includeTaskLocation
 
-- **CLI:** `--includeTaskLocation`
-- **Config:** [includeTaskLocation](/config/#includetasklocation)
+- **命令行终端:** `--includeTaskLocation`
+- **配置:** [includeTaskLocation](/config/#includetasklocation)
 
 Collect test and suite locations in the `location` property
 
 ### attachmentsDir
 
-- **CLI:** `--attachmentsDir <dir>`
-- **Config:** [attachmentsDir](/config/#attachmentsdir)
+- **命令行终端:** `--attachmentsDir <dir>`
+- **配置:** [attachmentsDir](/config/#attachmentsdir)
 
 The directory where attachments from `context.annotate` are stored in (default: `.vitest-attachments`)
 
 ### run
 
-- **CLI:** `--run`
+- **命令行终端:** `--run`
 
 禁用 watch 模式
 
 ### color
 
-- **CLI:** `--no-color`
+- **命令行终端:** `--no-color`
 
 删除控制台输出中的颜色
 
 ### clearScreen
 
-- **CLI:** `--clearScreen`
+- **命令行终端:** `--clearScreen`
 
  watch 模式下重新运行测试时清除终端屏幕（默认值：`true`）。
 
 ### configLoader
 
-- **CLI:** `--configLoader <loader>`
+- **命令行终端:** `--configLoader <loader>`
 
 Use `bundle` to bundle the config with esbuild or `runner` (experimental) to process it on the fly. This is only available in vite version 6.1.0 and above. (default: `bundle`)
 
 ### standalone
 
-- **CLI:** `--standalone`
+- **命令行终端:** `--standalone`
 
 启动 Vitest 但不运行测试。只有在文件发生变化时才会运行测试。当通过 CLI 传递了文件过滤器时，此选项将被忽略。（默认值：`false`）
diff --git a/guide/cli.md b/guide/cli.md
index 488b53f8..34035652 100644
--- a/guide/cli.md
+++ b/guide/cli.md
@@ -79,11 +79,11 @@ export default {
 
 ### `vitest bench`
 
-仅运行 [benchmark](/guide/features.html#benchmarking) 测试，用于比较性能结果。
+仅运行 [基准](/guide/features.html#benchmarking) 测试，用于比较性能结果。
 
 ### `vitest init`
 
-`vitest-init<name>` 可以用于设置项目配置。目前，它只支持 [`browser`](/guide/browser/) 值：
+`vitest init <name>` 可以用于设置项目配置。目前，它只支持 [`browser`](/guide/browser/) 值：
 
 ```bash
 vitest init browser

From 9ffed01f7eda263f5b07dbd0618d7fb2e04c1cd0 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Sun, 23 Nov 2025 21:14:54 +0800
Subject: [PATCH 17/50] !docs: recovery /guide/mocking

---
 guide/mocking.md | 752 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 740 insertions(+), 12 deletions(-)

diff --git a/guide/mocking.md b/guide/mocking.md
index e8623d84..ce570a50 100644
--- a/guide/mocking.md
+++ b/guide/mocking.md
@@ -1,6 +1,5 @@
 ---
 title: 模拟对象 | 指南
-outline: false
 ---
 
 # 模拟对象 {#mocking}
@@ -11,23 +10,752 @@ outline: false
 不要忘记在每次测试运行前后清除或恢复模拟对象，以撤消运行测试时模拟对象状态的更改！有关更多信息，请参阅 [`mockReset`](/api/mock.html#mockreset) 文档。
 :::
 
-如果你不熟悉 `vi.fn`、`vi.mock` 或 `vi.spyOn` 方法，请先查看[API部分](/api/vi)。
+如果你不熟悉 `vi.fn`、`vi.mock` 或 `vi.spyOn` 方法，请先查看 [API部分](/api/vi)。
 
-Vitest 提供了有关模拟的全部指南：
+## 日期 {#dates}
 
-- [模拟类](/guide/mocking/classes.md)
-- [模拟日期](/guide/mocking/dates.md)
-- [模拟文件系统](/guide/mocking/file-system.md)
-- [模拟函数](/guide/mocking/functions.md)
-- [模拟全局对象](/guide/mocking/globals.md)
-- [模拟模块](/guide/mocking/modules.md)
-- [模拟请求](/guide/mocking/requests.md)
-- [模拟计时器](/guide/mocking/timers.md)
+有些时候，你可能需要控制日期来确保测试时的一致性。Vitest 使用了 [`@sinonjs/fake-timers`](https://github.com/sinonjs/fake-timers) 库来操作计时器以及系统日期。可以在 [此处](/api/vi#vi-setsystemtime) 找到有关特定 API 的更多详细信息。
 
-为了更简单快捷地开始使用模拟，你可以查看下面的备忘单。
+### 示例 {#example}
+
+```js
+import { afterEach, beforeEach, describe, expect, it, vi } from 'vitest'
+
+const businessHours = [9, 17]
+
+function purchase() {
+  const currentHour = new Date().getHours()
+  const [open, close] = businessHours
+
+  if (currentHour > open && currentHour < close) {
+    return { message: 'Success' }
+  }
+
+  return { message: 'Error' }
+}
+
+describe('purchasing flow', () => {
+  beforeEach(() => {
+    // 告诉 vitest 我们使用模拟时间
+    vi.useFakeTimers()
+  })
+
+  afterEach(() => {
+    // 每次测试运行后恢复日期
+    vi.useRealTimers()
+  })
+
+  it('allows purchases within business hours', () => {
+    // 将时间设置在工作时间之内
+    const date = new Date(2000, 1, 1, 13)
+    vi.setSystemTime(date)
+
+    // 访问 Date.now() 将生成上面设置的日期
+    expect(purchase()).toEqual({ message: 'Success' })
+  })
+
+  it('disallows purchases outside of business hours', () => {
+    // 将时间设置在工作时间之外
+    const date = new Date(2000, 1, 1, 19)
+    vi.setSystemTime(date)
+
+    // 访问 Date.now() 将生成上面设置的日期
+    expect(purchase()).toEqual({ message: 'Error' })
+  })
+})
+```
+
+## 函数 {#functions}
+
+函数的模拟可以分为两个不同的类别：_对象监听(spying) 和 对象模拟_。
+
+有时你可能只需要验证是否调用了特定函数（以及可能传递了哪些参数）。在这种情况下，我们就需要使用一个对象监听，可以直接使用 `vi.spyOn()` ([在此处阅读更多信息](/api/vi#vi-spyon))。
+
+然而，对象监听只能帮助你 **监听** 函数，他们无法改变这些函数的实现。如果我们需要创建一个函数的假（或模拟）版本，可以使用它 `vi.fn()` ([在此处阅读更多信息](/api/vi#vi-fn))。
+
+我们使用 [Tinyspy](https://github.com/tinylibs/tinyspy) 作为模拟函数的基础，同时也有一套自己的封装来使其与 `Jest` 兼容。`vi.fn()` 和 `vi.spyOn()` 共享相同的方法，但是只有 `vi.fn()` 的返回结果是可调用的。
+
+### 示例 {#example-1}
+
+```js
+import { afterEach, describe, expect, it, vi } from 'vitest'
+
+const messages = {
+  items: [
+    { message: 'Simple test message', from: 'Testman' },
+    // ...
+  ],
+  getLatest, // 如果支持也可以是一个 `getter 或 setter`
+}
+
+function getLatest(index = messages.items.length - 1) {
+  return messages.items[index]
+}
+
+describe('reading messages', () => {
+  afterEach(() => {
+    vi.restoreAllMocks()
+  })
+
+  it('should get the latest message with a spy', () => {
+    const spy = vi.spyOn(messages, 'getLatest')
+    expect(spy.getMockName()).toEqual('getLatest')
+
+    expect(messages.getLatest()).toEqual(
+      messages.items[messages.items.length - 1]
+    )
+
+    expect(spy).toHaveBeenCalledTimes(1)
+
+    spy.mockImplementationOnce(() => 'access-restricted')
+    expect(messages.getLatest()).toEqual('access-restricted')
+
+    expect(spy).toHaveBeenCalledTimes(2)
+  })
+
+  it('should get with a mock', () => {
+    const mock = vi.fn().mockImplementation(getLatest)
+
+    expect(mock()).toEqual(messages.items[messages.items.length - 1])
+    expect(mock).toHaveBeenCalledTimes(1)
+
+    mock.mockImplementationOnce(() => 'access-restricted')
+    expect(mock()).toEqual('access-restricted')
+
+    expect(mock).toHaveBeenCalledTimes(2)
+
+    expect(mock()).toEqual(messages.items[messages.items.length - 1])
+    expect(mock).toHaveBeenCalledTimes(3)
+  })
+})
+```
+
+### 了解更多 {#more}
+
+- [Jest's Mock Functions](https://jestjs.io/docs/mock-function-api)
+
+## 全局 (Globals) {#globals}
+
+你可以通过使用 [`vi.stubGlobal`](/api/vi#stubglobal) 来模拟 `jsdom` 或 `node` 中不存在的全局变量。它将把全局变量的值放入 `globalThis` 对象。
+
+```ts
+import { vi } from 'vitest'
+
+const IntersectionObserverMock = vi.fn(() => ({
+  disconnect: vi.fn(),
+  observe: vi.fn(),
+  takeRecords: vi.fn(),
+  unobserve: vi.fn(),
+}))
+
+vi.stubGlobal('IntersectionObserver', IntersectionObserverMock)
+
+// 现在你可以通过 `IntersectionObserver` 或 `window.IntersectionObserver` 访问
+```
+
+## 模块 {#modules}
+
+模拟模块监听在其他代码中调用的第三方库，允许你测试参数、输出甚至重新声明其实现。
+
+参见 [`vi.mock()` API 部分](/api/vi#vi-mock) 以获得更深入详细 API 描述。
+
+### 自动模拟算法 {#automocking-algorithm}
+
+如果你的代码导入了模拟模块，并且没有任何与此模块相关联的 `__mocks__` 文件或 `factory`，Vitest 将通过调用模块并模拟每个导出来的模拟模块本身。
+
+以下原则适用
+
+- 所有的数组将被清空
+- 所有的基础类型和集合将保持不变
+- 所有的对象都将被深度克隆
+- 类的所有实例及其原型都将被深度克隆
+
+### 虚拟模块 {#virtual-modules}
+
+Vitest 支持模拟 Vite [虚拟模块](https://cn.vitejs.dev/guide/api-plugin#virtual-modules-convention)。它的工作方式与 Jest 中处理虚拟模块的方式不同。我们不需要将 `virtual: true` 传递给 `vi.mock` 函数，而是需要告诉 Vite 模块存在，否则它将在解析过程中失败。有几种方法可以做到这一点：
+
+1. 提供别名
+
+```ts [vitest.config.js]
+import { resolve } from 'node:path'
+import { defineConfig } from 'vitest/config'
+export default defineConfig({
+  test: {
+    alias: {
+      '$app/forms': resolve('./mocks/forms.js'),
+    },
+  },
+})
+```
+
+2. 提供解析虚拟模块的插件
+
+```ts [vitest.config.js]
+import { defineConfig } from 'vitest/config'
+export default defineConfig({
+  plugins: [
+    {
+      name: 'virtual-modules',
+      resolveId(id) {
+        if (id === '$app/forms') {
+          return 'virtual:$app/forms'
+        }
+      },
+    },
+  ],
+})
+```
+
+第二种方法的好处是可以动态创建不同的虚拟入口点。如果将多个虚拟模块重定向到一个文件中，那么所有这些模块都将受到 `vi.mock` 的影响，因此请确保使用唯一的标识符。
+
+### 模拟 Pitfalls {#mocking-pitfalls}
+
+请注意，对在同一文件的其他方法中调用的方法的模拟调用是不可能的。例如以下代码：
+
+```ts [foobar.js]
+export function foo() {
+  return 'foo'
+}
+
+export function foobar() {
+  return `${foo()}bar`
+}
+```
+
+不可能从外部模拟 `foo` 方法，因为它是直接引用的。因此，此代码对 `foobar` 内部的 `foo` 调用没有影响（但会影响其他模块中的 `foo` 调用）：
+
+```ts [foobar.test.ts]
+import { vi } from 'vitest'
+import * as mod from './foobar.js'
+
+// 这只会影响在原始模块之外的 "foo"
+vi.spyOn(mod, 'foo')
+vi.mock('./foobar.js', async (importOriginal) => {
+  return {
+    ...(await importOriginal<typeof import('./foobar.js')>()),
+    // 这只会影响在原始模块之外的 "foo"
+    foo: () => 'mocked',
+  }
+})
+```
+
+你可以通过直接向 `foobar` 方法提供实现来确认这种行为：
+
+```ts [foobar.test.js]
+import * as mod from './foobar.js'
+
+vi.spyOn(mod, 'foo')
+
+// 导出的 foo  引用模拟的方法
+mod.foobar(mod.foo)
+```
+
+```ts [foobar.js]
+export function foo() {
+  return 'foo'
+}
+
+export function foobar(injectedFoo) {
+  return injectedFoo === foo // false
+}
+```
+
+这就是预期行为。当以这种方式包含 mock 时，这通常是不良代码的标志。考虑将代码重构为多个文件，或者使用[依赖项注入](https://en.wikipedia.org/wiki/dependency_injection)等技术来改进应用体系结构。
+
+### 示例 {#example-2}
+
+```js
+import { Client } from 'pg'
+import { afterEach, beforeEach, describe, expect, it, vi } from 'vitest'
+import { failure, success } from './handlers.js'
+
+// 原始实现
+export async function getTodos(event, context) {
+  const client = new Client({
+    // ...其他选项参数
+  })
+
+  await client.connect()
+
+  try {
+    const result = await client.query('SELECT * FROM todos;')
+
+    client.end()
+
+    return success({
+      message: `${result.rowCount} item(s) returned`,
+      data: result.rows,
+      status: true,
+    })
+  }
+  catch (e) {
+    console.error(e.stack)
+
+    client.end()
+
+    return failure({ message: e, status: false })
+  }
+}
+
+vi.mock('pg', () => {
+  const Client = vi.fn()
+  Client.prototype.connect = vi.fn()
+  Client.prototype.query = vi.fn()
+  Client.prototype.end = vi.fn()
+
+  return { Client }
+})
+
+vi.mock('./handlers.js', () => {
+  return {
+    success: vi.fn(),
+    failure: vi.fn(),
+  }
+})
+
+describe('get a list of todo items', () => {
+  let client
+
+  beforeEach(() => {
+    client = new Client()
+  })
+
+  afterEach(() => {
+    vi.clearAllMocks()
+  })
+
+  it('should return items successfully', async () => {
+    client.query.mockResolvedValueOnce({ rows: [], rowCount: 0 })
+
+    await getTodos()
+
+    expect(client.connect).toBeCalledTimes(1)
+    expect(client.query).toBeCalledWith('SELECT * FROM todos;')
+    expect(client.end).toBeCalledTimes(1)
+
+    expect(success).toBeCalledWith({
+      message: '0 item(s) returned',
+      data: [],
+      status: true,
+    })
+  })
+
+  it('should throw an error', async () => {
+    const mError = new Error('Unable to retrieve rows')
+    client.query.mockRejectedValueOnce(mError)
+
+    await getTodos()
+
+    expect(client.connect).toBeCalledTimes(1)
+    expect(client.query).toBeCalledWith('SELECT * FROM todos;')
+    expect(client.end).toBeCalledTimes(1)
+    expect(failure).toBeCalledWith({ message: mError, status: false })
+  })
+})
+```
+
+## 文件系统 {#file-system}
+
+文件系统模拟文件系统可确保测试不依赖于实际文件系统，从而使测试更可靠、更可预测。这种隔离有助于避免先前测试的副作用。它允许测试可能难以或无法用实际文件系统复制的错误条件和边缘情况，如权限问题、磁盘满的情况或读/写错误。
+
+Vitest 并不提供任何文件系统模拟 API。您可以使用 `vi.mock` 手动模拟 `fs` 模块，但这很难维护。相反，我们建议使用 [`memfs`](https://www.npmjs.com/package/memfs) 来为你做这件事。`memfs` 创建了一个内存文件系统，可以在不接触实际磁盘的情况下模拟文件系统操作。这种方法既快速又安全，可以避免对真实文件系统产生任何潜在的副作用。
+
+### 示例 {#example-3}
+
+要自动将每个 `fs` 调用重定向到 `memfs`，可以在项目根目录下创建 `__mocks__/fs.cjs` 和 `__mocks__/fs/promises.cjs` 文件：
+
+::: code-group
+```ts [__mocks__/fs.cjs]
+// 也可以使用 import，但这样
+// 每个导出都需要显式定义
+
+const { fs } = require('memfs')
+module.exports = fs
+```
+
+```ts [__mocks__/fs/promises.cjs]
+// 也可以使用 import，但这样
+// 每个导出都需要显式定义
+
+const { fs } = require('memfs')
+module.exports = fs.promises
+```
+:::
+
+```ts [read-hello-world.js]
+import { readFileSync } from 'node:fs'
+
+export function readHelloWorld(path) {
+  return readFileSync(path, 'utf-8')
+}
+```
+
+```ts [hello-world.test.js]
+import { fs, vol } from 'memfs'
+import { beforeEach, expect, it, vi } from 'vitest'
+import { readHelloWorld } from './read-hello-world.js'
+
+// 告诉 Vitest 使用 __mocks__ 文件夹中的 fs 模拟模块
+// 如果始终需要模拟 fs，可以在 setup 文件中进行此配置
+vi.mock('node:fs')
+vi.mock('node:fs/promises')
+
+beforeEach(() => {
+  // 重置内存中 fs 的状态
+  vol.reset()
+})
+
+it('should return correct text', () => {
+  const path = '/hello-world.txt'
+  fs.writeFileSync(path, 'hello world')
+
+  const text = readHelloWorld(path)
+  expect(text).toBe('hello world')
+})
+
+it('can return a value multiple times', () => {
+  // 你可以使用 vol.fromJSON 来定义多个文件
+  vol.fromJSON(
+    {
+      './dir1/hw.txt': 'hello dir1',
+      './dir2/hw.txt': 'hello dir2',
+    },
+    // 默认当前目录
+    '/tmp',
+  )
+
+  expect(readHelloWorld('/tmp/dir1/hw.txt')).toBe('hello dir1')
+  expect(readHelloWorld('/tmp/dir2/hw.txt')).toBe('hello dir2')
+})
+```
+
+## 请求 {#requests}
+
+因为 Vitest 运行在 Node 环境中，所以模拟网络请求是一件非常棘手的事情；由于没有办法使用 Web API，因此我们需要一些可以为我们模拟网络行为的包。推荐使用 [Mock Service Worker](https://mswjs.io/) 来进行这个操作。它可以模拟 `http`、`WebSocket` 和 `GraphQL` 网络请求，并且与框架无关。
+
+Mock Service Worker (MSW) 的工作原理是拦截测试请求，让我们可以在不更改任何应用代码的情况下使用它。在浏览器中，它使用 [Service Worker API](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API) 。在 Node.js 和 Vitest 中，它使用 [`@mswjs/interceptors`](https://github.com/mswjs/interceptors) 库。要了解有关 MSW 的更多信息，请阅读他们的 [介绍部分](https://mswjs.io/docs/) 。
+
+### 配置 {#configuration}
+
+你可以像下面一样，将配置添加到 [setup file](/config/#setupfiles) 中
+
+::: code-group
+
+```js [HTTP Setup]
+import { http, HttpResponse } from 'msw'
+import { setupServer } from 'msw/node'
+import { afterAll, afterEach, beforeAll } from 'vitest'
+
+const posts = [
+  {
+    userId: 1,
+    id: 1,
+    title: 'first post title',
+    body: 'first post body',
+  },
+  // ...
+]
+
+export const restHandlers = [
+  http.get('https://rest-endpoint.example/path/to/posts', () => {
+    return HttpResponse.json(posts)
+  }),
+]
+
+const server = setupServer(...restHandlers)
+
+// 在所有测试之前启动服务器
+beforeAll(() => server.listen({ onUnhandledRequest: 'error' }))
+
+// 所有测试完成后关闭服务器
+afterAll(() => server.close())
+
+// 在每个测试后重置处理程序以实现测试隔离
+afterEach(() => server.resetHandlers())
+```
+
+```js [GraphQL Setup]
+import { graphql, HttpResponse } from 'msw'
+import { setupServer } from 'msw/node'
+import { afterAll, afterEach, beforeAll } from 'vitest'
+
+const posts = [
+  {
+    userId: 1,
+    id: 1,
+    title: 'first post title',
+    body: 'first post body',
+  },
+  // ...
+]
+
+const graphqlHandlers = [
+  graphql.query('ListPosts', () => {
+    return HttpResponse.json({
+      data: { posts },
+    })
+  }),
+]
+
+const server = setupServer(...graphqlHandlers)
+
+// 在所有测试之前启动服务器
+beforeAll(() => server.listen({ onUnhandledRequest: 'error' }))
+
+// 所有测试完成后关闭服务器
+afterAll(() => server.close())
+
+// 在每个测试后重置处理程序以实现测试隔离
+afterEach(() => server.resetHandlers())
+```
+
+```js [WebSocket Setup]
+import { ws } from 'msw'
+import { setupServer } from 'msw/node'
+import { afterAll, afterEach, beforeAll } from 'vitest'
+
+const chat = ws.link('wss://chat.example.com')
+
+const wsHandlers = [
+  chat.addEventListener('connection', ({ client }) => {
+    client.addEventListener('message', (event) => {
+      console.log('Received message from client:', event.data)
+      // Echo the received message back to the client
+      client.send(`Server received: ${event.data}`)
+    })
+  }),
+]
+
+const server = setupServer(...wsHandlers)
+
+// 在所有测试之前启动服务器
+beforeAll(() => server.listen({ onUnhandledRequest: 'error' }))
+
+// 所有测试完成后关闭服务器
+afterAll(() => server.close())
+
+// 在每个测试后重置处理程序以实现测试隔离
+afterEach(() => server.resetHandlers())
+```
+:::
+
+> 将 server 配置为 `onUnhandledRequest: 'error'` 可确保在遇到没有对应请求处理程序的请求时抛出错误。
+
+### 了解更多 {#more-1}
+
+MSW 能做的还有很多。你可以访问 cookie 和查询参数、定义模拟错误响应等等！要查看你可以使用 MSW 做什么，请阅读 [他们的文档](https://mswjs.io/docs)。
+
+## 计时器 {#timers}
+
+每当测试代码涉及到 timeout 或者 interval 时，并不是让我们的测试程序进行等待或者超时。我们也可以通过模拟对 `setTimeout` 和 `setInterval` 的调用来使用 "fake" 计时器来加速测试。
+
+有关更深入的详细 API 描述，参阅 [`vi.usefaketimers` API 部分](/api/vi#vi-usefaketimers)。
+
+### 示例 {#example-4}
+
+```js
+import { afterEach, beforeEach, describe, expect, it, vi } from 'vitest'
+
+function executeAfterTwoHours(func) {
+  setTimeout(func, 1000 * 60 * 60 * 2) // 2小时
+}
+
+function executeEveryMinute(func) {
+  setInterval(func, 1000 * 60) // 1分钟
+}
+
+const mock = vi.fn(() => console.log('executed'))
+
+describe('delayed execution', () => {
+  beforeEach(() => {
+    vi.useFakeTimers()
+  })
+  afterEach(() => {
+    vi.restoreAllMocks()
+  })
+  it('should execute the function', () => {
+    executeAfterTwoHours(mock)
+    vi.runAllTimers()
+    expect(mock).toHaveBeenCalledTimes(1)
+  })
+  it('should not execute the function', () => {
+    executeAfterTwoHours(mock)
+    // 前进2毫秒并不会触发方法
+    vi.advanceTimersByTime(2)
+    expect(mock).not.toHaveBeenCalled()
+  })
+  it('should execute every minute', () => {
+    executeEveryMinute(mock)
+    vi.advanceTimersToNextTimer()
+    expect(mock).toHaveBeenCalledTimes(1)
+    vi.advanceTimersToNextTimer()
+    expect(mock).toHaveBeenCalledTimes(2)
+  })
+})
+```
+
+## 模拟类 {#classes}
+
+你只需调用一次 `vi.fn` 就能模拟整个类，因为所有的类本质也都是函数，所以这种方法可以直接使用。需要注意的是，目前 Vitest 并不支持 `new` 关键字，因此在函数的主体中，`new.target` 总是 `undefined`。
+
+```ts
+class Dog {
+  name: string
+
+  constructor(name: string) {
+    this.name = name
+  }
+
+  static getType(): string {
+    return 'animal'
+  }
+
+  greet = (): string => {
+    return `Hi! My name is ${this.name}!`
+  }
+
+  speak(): string {
+    return 'bark!'
+  }
+
+  isHungry() {}
+  feed() {}
+}
+```
+
+我们可以使用 ES5 函数重新创建这个类：
+
+```ts
+const Dog = vi.fn(function (name) {
+  this.name = name
+  // 在构造函数中模拟示例包房，每个示例都会有自己模拟函数 (spy)
+  this.greet = vi.fn(() => `Hi! My name is ${this.name}!`)
+})
+
+// 注意静态方法是直接在函数上模拟的，
+// 并不在每个类的实例上
+Dog.getType = vi.fn(() => 'mocked animal')
+
+// 在每个类的实例上模拟 "speak" 和 "feed" 方法
+// 所有 `new Dog()` 实例都会继承并共享这些模拟函数 (spy)
+Dog.prototype.speak = vi.fn(() => 'loud bark!')
+Dog.prototype.feed = vi.fn()
+```
+
+::: warning
+如果构造函数返回一个非原始值，该值将成为 new 表达式的结果。在这种情况下，`[[Prototype]]` 可能无法正确绑定：
+
+```ts
+const CorrectDogClass = vi.fn(function (name) {
+  this.name = name
+})
+
+const IncorrectDogClass = vi.fn(name => ({
+  name
+}))
+
+const Marti = new CorrectDogClass('Marti')
+const Newt = new IncorrectDogClass('Newt')
+
+Marti instanceof CorrectDogClass // ✅ true
+Newt instanceof IncorrectDogClass // ❌ false!
+```
+:::
+
+::: tip 何时使用?
+一般来说，如果类是从另一个模块重新导出的，你会在模块工厂内重新创建这样的类：
+
+```ts
+import { Dog } from './dog.js'
+
+vi.mock(import('./dog.js'), () => {
+  const Dog = vi.fn()
+  Dog.prototype.feed = vi.fn()
+  // 一些其他的模拟...
+  return { Dog }
+})
+```
+
+该方法也可用于将一个类的实例传递给接受相同接口的函数：
+
+```ts [src/feed.ts]
+function feed(dog: Dog) {
+  // ...
+}
+```
+```ts [tests/dog.test.ts]
+import { expect, test, vi } from 'vitest'
+import { feed } from '../src/feed.js'
+
+const Dog = vi.fn()
+Dog.prototype.feed = vi.fn()
+
+test('can feed dogs', () => {
+  const dogMax = new Dog('Max')
+
+  feed(dogMax)
+
+  expect(dogMax.feed).toHaveBeenCalled()
+  expect(dogMax.isHungry()).toBe(false)
+})
+```
+:::
+
+现在，当我们创建一个新的 `Dog` 类实例时，它的 `speak` 方法（与 `feed` 并列）已经被模拟：
+
+```ts
+const Cooper = new Dog('Cooper')
+Cooper.speak() // loud bark!
+Cooper.greet() // Hi! My name is Cooper!
+
+// 你可以使用内置断言来检查调用的有效性
+expect(Cooper.speak).toHaveBeenCalled()
+expect(Cooper.greet).toHaveBeenCalled()
+
+const Max = new Dog('Max')
+
+// 如果你直接赋值方法，这些方法在实例之间不会共享
+expect(Max.speak).toHaveBeenCalled()
+expect(Max.greet).not.toHaveBeenCalled()
+```
+
+我们可以为特定实例重新分配返回值：
+
+```ts
+const dog = new Dog('Cooper')
+
+// "vi.mocked" 是一个类型辅助工具，因为
+// TypeScript 不知道 Dog 是一个被模拟的类，
+// 它将任何函数包装在 Mock<T> 类型中
+// 而不会验证该函数是否为模拟函数
+vi.mocked(dog.speak).mockReturnValue('woof woof')
+
+dog.speak() // woof woof
+```
+
+要模拟属性，我们可以使用 `vi.spyOn(dog, 'name', 'get')` 方法。这样就可以在被模拟的属性上使用 spy 断言：
+
+```ts
+const dog = new Dog('Cooper')
+
+const nameSpy = vi.spyOn(dog, 'name', 'get').mockReturnValue('Max')
+
+expect(dog.name).toBe('Max')
+expect(nameSpy).toHaveBeenCalledTimes(1)
+```
+
+::: tip
+你也可以使用相同的方法来监视 getter 和 setter。
+:::
 
 ## 速查表 {#cheat-sheet}
 
+::: info 提示
+下列示例中的 `vi` 是直接从 `vitest` 导入的。如果在你的 [配置文件](/config/) 中将 `globals` 设置为 `true`，则可以全局使用它。
+:::
+
+我想……
+
 ### 模拟导出变量 {#mock-exported-variables}
 ```js [example.js]
 export const getter = 'variable'

From 8239279eb1d31f0fabc00c45462d8ddecc8459e8 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 24 Nov 2025 00:02:17 +0800
Subject: [PATCH 18/50] !docs: remove extra files

---
 .vitepress/config.ts         |  37 +--
 guide/mocking/classes.md     | 158 ------------
 guide/mocking/dates.md       |  52 ----
 guide/mocking/file-system.md |  76 ------
 guide/mocking/functions.md   |  61 -----
 guide/mocking/globals.md     |  20 --
 guide/mocking/modules.md     | 479 -----------------------------------
 guide/mocking/requests.md    | 114 ---------
 guide/mocking/timers.md      |  48 ----
 9 files changed, 1 insertion(+), 1044 deletions(-)
 delete mode 100644 guide/mocking/classes.md
 delete mode 100644 guide/mocking/dates.md
 delete mode 100644 guide/mocking/file-system.md
 delete mode 100644 guide/mocking/functions.md
 delete mode 100644 guide/mocking/globals.md
 delete mode 100644 guide/mocking/modules.md
 delete mode 100644 guide/mocking/requests.md
 delete mode 100644 guide/mocking/timers.md

diff --git a/.vitepress/config.ts b/.vitepress/config.ts
index d5e07c8a..099c2ca4 100644
--- a/.vitepress/config.ts
+++ b/.vitepress/config.ts
@@ -575,43 +575,8 @@ function guide(): DefaultTheme.SidebarItem[] {
       link: '/guide/snapshot',
     },
     {
-      text: '模拟对象',
+      text: '模拟',
       link: '/guide/mocking',
-      collapsed: true,
-      items: [
-        {
-          text: '模拟日期',
-          link: '/guide/mocking/dates',
-        },
-        {
-          text: '模拟函数',
-          link: '/guide/mocking/functions',
-        },
-        {
-          text: '模拟全局对象',
-          link: '/guide/mocking/globals',
-        },
-        {
-          text: '模拟模块',
-          link: '/guide/mocking/modules',
-        },
-        {
-          text: '模拟文件系统',
-          link: '/guide/mocking/file-system',
-        },
-        {
-          text: '模拟请求',
-          link: '/guide/mocking/requests',
-        },
-        {
-          text: '模拟计时器',
-          link: '/guide/mocking/timers',
-        },
-        {
-          text: '模拟类',
-          link: '/guide/mocking/classes',
-        },
-      ],
     },
     {
       text: '并行执行',
diff --git a/guide/mocking/classes.md b/guide/mocking/classes.md
deleted file mode 100644
index ffc08a48..00000000
--- a/guide/mocking/classes.md
+++ /dev/null
@@ -1,158 +0,0 @@
-# 模拟类 {#mocking-classes}
-
-你可以通过一次 [`vi.fn`](/api/vi#fn) 调用来模拟整个类。
-
-```ts
-class Dog {
-  name: string
-
-  constructor(name: string) {
-    this.name = name
-  }
-
-  static getType(): string {
-    return 'animal'
-  }
-
-  greet = (): string => {
-    return `Hi! My name is ${this.name}!`
-  }
-
-  speak(): string {
-    return 'bark!'
-  }
-
-  isHungry() {}
-  feed() {}
-}
-```
-
-我们可以使用 `vi.fn`（或 `vi.spyOn().mockImplementation()`）来重新创建这个类：
-
-```ts
-const Dog = vi.fn(class {
-  static getType = vi.fn(() => 'mocked animal')
-
-  constructor(name) {
-    this.name = name
-  }
-
-  greet = vi.fn(() => `Hi! My name is ${this.name}!`)
-  speak = vi.fn(() => 'loud bark!')
-  feed = vi.fn()
-})
-```
-
-::: warning
-如果构造函数返回一个非原始值，那么该值将成为 new 表达式的结果。在这种情况下，`[[Prototype]]` 可能无法正确绑定：
-
-```ts
-const CorrectDogClass = vi.fn(function (name) {
-  this.name = name
-})
-
-const IncorrectDogClass = vi.fn(name => ({
-  name
-}))
-
-const Marti = new CorrectDogClass('Marti')
-const Newt = new IncorrectDogClass('Newt')
-
-Marti instanceof CorrectDogClass // ✅ true
-Newt instanceof IncorrectDogClass // ❌ false!
-```
-
-如果你正在模拟类，建议优先使用类语法而不是函数语法。
-:::
-
-::: tip 何时使用？
-一般来说，如果类是从另一个模块重新导出的，你会在模块工厂内部重新创建这样的类：
-
-```ts
-import { Dog } from './dog.js'
-
-vi.mock(import('./dog.js'), () => {
-  const Dog = vi.fn(class {
-    feed = vi.fn()
-    // ... other mocks
-  })
-  return { Dog }
-})
-```
-
-这种方法也可以用于将类的实例传递给接受相同接口的函数：
-
-```ts [src/feed.ts]
-function feed(dog: Dog) {
-  // ...
-}
-```
-```ts [tests/dog.test.ts]
-import { expect, test, vi } from 'vitest'
-import { feed } from '../src/feed.js'
-
-const Dog = vi.fn(class {
-  feed = vi.fn()
-})
-
-test('can feed dogs', () => {
-  const dogMax = new Dog('Max')
-
-  feed(dogMax)
-
-  expect(dogMax.feed).toHaveBeenCalled()
-  expect(dogMax.isHungry()).toBe(false)
-})
-```
-:::
-
-现在，当我们创建 `Dog` 类的新实例时，它的 `speak` 方法（以及 `feed` 和 `greet` 方法）已经被模拟了：
-
-```ts
-const Cooper = new Dog('Cooper')
-Cooper.speak() // loud bark!
-Cooper.greet() // Hi! My name is Cooper!
-
-// 你可以使用内置断言来检查调用的有效性
-expect(Cooper.speak).toHaveBeenCalled()
-expect(Cooper.greet).toHaveBeenCalled()
-
-const Max = new Dog('Max')
-
-// 如果你直接赋值方法，这些方法在实例之间不会共享
-expect(Max.speak).not.toHaveBeenCalled()
-expect(Max.greet).not.toHaveBeenCalled()
-```
-
-我们可以为特定实例重新分配返回值：
-
-```ts
-const dog = new Dog('Cooper')
-
-// "vi.mocked" 是一个类型辅助工具，因为
-// TypeScript 不知道 Dog 是一个被模拟的类，
-// 它将任何函数包装在 Mock<T> 类型中
-// 而不会验证该函数是否为模拟函数
-vi.mocked(dog.speak).mockReturnValue('woof woof')
-
-dog.speak() // woof woof
-```
-
-要模拟属性，我们可以使用 `vi.spyOn(dog, 'name', 'get')` 方法。这样就可以在模拟属性上使用间谍断言：
-
-```ts
-const dog = new Dog('Cooper')
-
-const nameSpy = vi.spyOn(dog, 'name', 'get').mockReturnValue('Max')
-
-expect(dog.name).toBe('Max')
-expect(nameSpy).toHaveBeenCalledTimes(1)
-```
-
-::: tip
-你也可以使用相同的方法来监视 getter 和 setter。
-:::
-
-::: danger
-在 Vitest 4 中引入了使用 `vi.fn()` 模拟类的功能。在此之前，你必须直接使用 `function` 和 `prototype` 继承。参见 [v3 指南](https://v3.vitest.dev/guide/mocking.html#classes)。
-:::
diff --git a/guide/mocking/dates.md b/guide/mocking/dates.md
deleted file mode 100644
index 32d9707d..00000000
--- a/guide/mocking/dates.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# 模拟日期 {#mocking-dates}
-
-有时你需要控制日期以确保测试时的一致性。Vitest 使用 [`@sinonjs/fake-timers`](https://github.com/sinonjs/fake-timers) 包来操作计时器和系统日期。你可以在[这里](/api/vi#vi-setsystemtime)找到有关特定 API 的详细信息。
-
-## 示例 {#example}
-
-```js
-import { afterEach, beforeEach, describe, expect, it, vi } from 'vitest'
-
-const businessHours = [9, 17]
-
-function purchase() {
-  const currentHour = new Date().getHours()
-  const [open, close] = businessHours
-
-  if (currentHour > open && currentHour < close) {
-    return { message: 'Success' }
-  }
-
-  return { message: 'Error' }
-}
-
-describe('purchasing flow', () => {
-  beforeEach(() => {
-    // 告诉 vitest 我们使用模拟时间
-    vi.useFakeTimers()
-  })
-
-  afterEach(() => {
-    // 在每次测试运行后恢复日期
-    vi.useRealTimers()
-  })
-
-  it('allows purchases within business hours', () => {
-    // 设置在营业时间内的小时数
-    const date = new Date(2000, 1, 1, 13)
-    vi.setSystemTime(date)
-
-    // 访问 `Date.now()` 将会返回上面设置的日期
-    expect(purchase()).toEqual({ message: 'Success' })
-  })
-
-  it('disallows purchases outside of business hours', () => {
-    // 设置在营业时间外的小时数
-    const date = new Date(2000, 1, 1, 19)
-    vi.setSystemTime(date)
-
-    // 访问 `Date.now()` 将会返回上面设置的日期
-    expect(purchase()).toEqual({ message: 'Error' })
-  })
-})
-```
diff --git a/guide/mocking/file-system.md b/guide/mocking/file-system.md
deleted file mode 100644
index ce775f80..00000000
--- a/guide/mocking/file-system.md
+++ /dev/null
@@ -1,76 +0,0 @@
-# 模拟文件系统 {#mocking-the-file-system}
-
-模拟文件系统可以确保测试不依赖于实际的文件系统，从而使测试更加可靠和可预测。这种隔离有助于避免之前测试产生的副作用。它允许测试错误条件和边缘情况，而这些情况在实际文件系统中可能难以或无法复制，例如权限问题、磁盘满场景或读写错误。
-
-Vitest 没有开箱即用地提供任何文件系统模拟 API。你可以使用 `vi.mock` 手动模拟 `fs` 模块，但这很难维护。相反，我们推荐使用 [`memfs`](https://www.npmjs.com/package/memfs) 来为你完成这项工作。`memfs` 创建一个内存中的文件系统，它模拟文件系统操作而不触及实际磁盘。这种方法快速且安全，避免了对真实文件系统的任何潜在副作用。
-
-## 示例 {#example}
-
-为了自动将每个 `fs` 调用重定向到 `memfs`，你可以在项目的根目录下创建 `__mocks__/fs.cjs` 和 `__mocks__/fs/promises.cjs` 文件：
-
-::: code-group
-```ts [__mocks__/fs.cjs]
-// 我们可以使用 `import`，但是那样的话
-// 每个导出都需要明确定义
-
-const { fs } = require('memfs')
-
-module.exports = fs
-```
-
-```ts [__mocks__/fs/promises.cjs]
-// 我们可以使用 `import`，但是那样的话
-// 每个导出都需要明确定义
-
-const { fs } = require('memfs')
-
-module.exports = fs.promises
-```
-:::
-
-```ts [read-hello-world.js]
-import { readFileSync } from 'node:fs'
-
-export function readHelloWorld(path) {
-  return readFileSync(path, 'utf-8')
-}
-```
-
-```ts [hello-world.test.js]
-import { fs, vol } from 'memfs'
-import { beforeEach, expect, it, vi } from 'vitest'
-import { readHelloWorld } from './read-hello-world.js'
-
-// tell vitest to use fs mock from __mocks__ folder
-// this can be done in a setup file if fs should always be mocked
-vi.mock('node:fs')
-vi.mock('node:fs/promises')
-
-beforeEach(() => {
-  // reset the state of in-memory fs
-  vol.reset()
-})
-
-it('should return correct text', () => {
-  const path = '/hello-world.txt'
-  fs.writeFileSync(path, 'hello world')
-
-  const text = readHelloWorld(path)
-  expect(text).toBe('hello world')
-})
-
-it('can return a value multiple times', () => {
-  // you can use vol.fromJSON to define several files
-  vol.fromJSON(
-    {
-      './dir1/hw.txt': 'hello dir1',
-      './dir2/hw.txt': 'hello dir2',
-    },
-    // default cwd
-    '/tmp',
-  )
-
-  expect(readHelloWorld('/tmp/dir1/hw.txt')).toBe('hello dir1')
-  expect(readHelloWorld('/tmp/dir2/hw.txt')).toBe('hello dir2')
-})
-```
diff --git a/guide/mocking/functions.md b/guide/mocking/functions.md
deleted file mode 100644
index 55d5a741..00000000
--- a/guide/mocking/functions.md
+++ /dev/null
@@ -1,61 +0,0 @@
-# Mocking Functions
-
-模拟函数可以分为两个不同的类别：监视(spying)和模拟(mocking)。
-
-如果你需要观察对象上方法的行为，你可以使用 [`vi.spyOn()`](/api/vi#vi-spyon) 来创建一个间谍，用于跟踪对该方法的调用。
-
-如果你需要传递自定义函数实现作为参数或创建新的模拟实体，你可以使用 [`vi.fn()`](/api/vi#vi-fn) 来创建一个模拟函数。
-
-`vi.spyOn` 和 `vi.fn` 都共享相同的方法。
-
-## Example
-
-```js
-import { afterEach, describe, expect, it, vi } from 'vitest'
-
-const messages = {
-  items: [
-    { message: 'Simple test message', from: 'Testman' },
-    // ...
-  ],
-  addItem(item) {
-    messages.items.push(item)
-    messages.callbacks.forEach(callback => callback(item))
-  },
-  onItem(callback) {
-    messages.callbacks.push(callback)
-  },
-  getLatest, // can also be a `getter or setter if supported`
-}
-
-function getLatest(index = messages.items.length - 1) {
-  return messages.items[index]
-}
-
-it('should get the latest message with a spy', () => {
-  const spy = vi.spyOn(messages, 'getLatest')
-  expect(spy.getMockName()).toEqual('getLatest')
-
-  expect(messages.getLatest()).toEqual(
-    messages.items[messages.items.length - 1],
-  )
-
-  expect(spy).toHaveBeenCalledTimes(1)
-
-  spy.mockImplementationOnce(() => 'access-restricted')
-  expect(messages.getLatest()).toEqual('access-restricted')
-
-  expect(spy).toHaveBeenCalledTimes(2)
-})
-
-it('passing down the mock', () => {
-  const callback = vi.fn()
-  messages.onItem(callback)
-
-  messages.addItem({ message: 'Another test message', from: 'Testman' })
-  expect(callback).toHaveBeenCalledWith({
-    message: 'Another test message',
-    from: 'Testman',
-  })
-})
-```
diff --git a/guide/mocking/globals.md b/guide/mocking/globals.md
deleted file mode 100644
index d354c5f2..00000000
--- a/guide/mocking/globals.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# 模拟全局对象 {#mocking-globals}
-
-你可以使用 [`vi.stubGlobal`](/api/vi#vi-stubglobal) 助手来模拟 `jsdom` 或 `node` 中不存在的全局变量。它会将全局变量的值放入 `globalThis` 对象中。
-
-默认情况下，Vitest 不会重置这些全局变量，但你可以在配置中开启 [`unstubGlobals`](/config/#unstubglobals) 选项，以便在每次测试后恢复原始值，或者手动调用 [`vi.unstubAllGlobals()`](/api/vi#vi-unstuballglobals)。
-
-```ts
-import { vi } from 'vitest'
-
-const IntersectionObserverMock = vi.fn(() => ({
-  disconnect: vi.fn(),
-  observe: vi.fn(),
-  takeRecords: vi.fn(),
-  unobserve: vi.fn(),
-}))
-
-vi.stubGlobal('IntersectionObserver', IntersectionObserverMock)
-
-// 现在你可以通过 `IntersectionObserver` 或 `window.IntersectionObserver` 来访问它
-```
diff --git a/guide/mocking/modules.md b/guide/mocking/modules.md
deleted file mode 100644
index 2220a13f..00000000
--- a/guide/mocking/modules.md
+++ /dev/null
@@ -1,479 +0,0 @@
-# 模拟模块 {#mocking-modules}
-
-## 模块的定义 {#defining-a-module}
-
-在进行模块模拟之前，先要明确“模块”的含义。在 Vitest 中，模块指的是一个导出内容的文件。
-通过 [插件](https://vite.dev/guide/api-plugin.html)，几乎任何文件都可以转换为 JavaScript 模块。
-
-“模块对象”是一个命名空间对象，内部动态引用模块导出的标识符。
-换句话说，它就是一个包含已导出方法与属性的对象。
-
-例如，`example.js` 就是一个模块，它导出了 `method` 和 `variable`：
-
-```js [example.js]
-export function answer() {
-  // ...
-  return 42
-}
-
-export const variable = 'example'
-```
-
-这里的 `exampleObject` 指的就是一个模块对象：
-
-```js [example.test.js]
-import * as exampleObject from './example.js'
-```
-
-即便是通过具名导入（ named imports ）来引入 `example`, `exampleObject` 依然会存在。
-
-```js [example.test.js]
-import { answer, variable } from './example.js'
-```
-
-`exampleObject` 只能在 `example` 模块之外被引用，例如在测试代码中使用。
-
-## 模拟模块 {#mocking-a-module}
-
-在讲解实现方式之前，先明确几个相关概念：
-
-- **Mocked module （模拟模块）**：原模块被完全替换成另一个模块；
-- **Spied module （监听模块）**：属于模拟模块的一种，但其导出方法依然保留原始实现，同时可跟踪调用情况；
-- **Mocked export （模拟导出）**：模块中被替换的某个导出，其调用记录可被跟踪；
-- **Spied export （监听导出）**：一种模拟导出形式，带有调用跟踪能力。
-
-要完全替换一个模块，可以使用 [`vi.mock` API](/api/vi#vi-mock)。
-在调用 `vi.mock` 时，通过传入一个工厂函数作为第二个参数，该函数返回的新模块将动态替代原模块。
-
-```ts
-import { vi } from 'vitest'
-
-// The ./example.js module will be replaced with
-// the result of a factory function, and the
-// original ./example.js module will never be called
-vi.mock(import('./example.js'), () => {
-  return {
-    answer() {
-      // ...
-      return 42
-    },
-    variable: 'mock',
-  }
-})
-```
-
-::: tip
-请注意，你可以在 [setup 文件](/config/#setupfiles) 中调用 `vi.mock` ，
-这样模块的模拟就会在所有测试文件中自动生效，无需在每个文件中重复声明。
-:::
-
-::: tip
-注意这里使用了动态导入语法：`import('./example.ts')`。
-Vitest 会在代码真正执行前将其移除，但这种写法可以让 TypeScript 正确验证导入路径的字符串，并在你的 IDE 或 CLI 中为 `importOriginal` 方法提供完整的类型提示和检查功能。
-:::
-
-如果我么的代码试图访问一个不在工厂函数返回对象中的方法， Vitest 会抛出错误，并附带清晰的提示信息。
-需要注意，`answer` 在这里并未被 mock ，因此它的调用无法被追踪。
-若要让它支持调用跟踪，应使用 `vi.fn()` 进行包装。
-
-```ts
-import { vi } from 'vitest'
-
-vi.mock(import('./example.js'), () => {
-  return {
-    answer: vi.fn(),
-    variable: 'mock',
-  }
-})
-```
-
-这个工厂方法会接收一个 `importOriginal` 函数，该函数用于执行原始模块代码，并返回对应的模块对象。
-
-```ts
-import { expect, vi } from 'vitest'
-import { answer } from './example.js'
-
-vi.mock(import('./example.js'), async (importOriginal) => {
-  const originalModule = await importOriginal()
-  return {
-    answer: vi.fn(originalModule.answer),
-    variable: 'mock',
-  }
-})
-
-expect(answer()).toBe(42)
-
-expect(answer).toHaveBeenCalled()
-expect(answer).toHaveReturned(42)
-```
-
-::: warning
-请注意，`importOriginal` 是异步函数，调用时需要使用 `await` 进行等待。
-:::
-
-在上例中，我们将原始的 `answer` 传递给 `vi.fn()`，这样既可以保留其原始实现的调用，又能对调用进行跟踪。
-
-如果需要使用 `importOriginal`，可以考虑使用另一个 API —— `vi.spyOn` —— 来直接监听模块的某个导出方法。
-这种方式无需替换整个模块，而是仅对目标方法进行监听。
-
-要实现这一点，需要将模块以命名空间对象的形式导入。
-
-```ts
-import { expect, vi } from 'vitest'
-import * as exampleObject from './example.js'
-
-const spy = vi.spyOn(exampleObject, 'answer').mockReturnValue(0)
-
-expect(exampleObject.answer()).toBe(0)
-expect(exampleObject.answer).toHaveBeenCalled()
-```
-
-::: danger Browser Mode Support
-这种方式在 [浏览器模式](/guide/browser/) 下无法使用，因为浏览器会依赖原生的 ESM 机制来加载模块，
-而模块的命名空间对象是密封的（sealed），无法被重新配置。
-
-为绕过这一限制，Vitest 在 `vi.mock('./example.js')` 中提供了 `{ spy: true }` 选项。
-启用该选项后，Vitest 会自动为模块中的每个导出设置监听（spy），而不会用虚假的实现去替换它们。
-
-```ts
-import { vi } from 'vitest'
-import * as exampleObject from './example.js'
-
-vi.mock('./example.js', { spy: true })
-
-vi.mocked(exampleObject.answer).mockReturnValue(0)
-```
-:::
-
-::: warning
-在使用 `vi.spyOn` 的文件中，只需将目标模块以命名空间对象的形式导入即可。
-如果 `answer` 方法是在其他文件中通过具名导入的方式被引用并调用的，只要该调用发生在 `vi.spyOn` 执行之后，
-Vitest 依然能够准确追踪它的调用记录。
-
-```ts [source.js]
-import { answer } from './example.js'
-
-export function question() {
-  if (answer() === 42) {
-    return 'Ultimate Question of Life, the Universe, and Everything'
-  }
-
-  return 'Unknown Question'
-}
-```
-:::
-
-请注意，`vi.spyOn` 只能追踪在其监听启动之后发生的调用。
-如果某个函数是在模块导入时（顶层执行）就被调用，或者在监听启动之前就已执行过，`vi.spyOn` 将无法记录这些调用。
-
-若想在模块被导入前自动对其进行模拟，可以调用 `vi.mock` 并传入对应的模块路径：
-
-```ts
-import { vi } from 'vitest'
-
-vi.mock(import('./example.js'))
-```
-
-如果文件 `./__mocks__/example.js` 存在， Vitest 会优先加载该文件来替代原模块。
-若不存在该文件， Vitest 会加载原模块，并递归替换其中的所有内容，规则如下：
-
-{#automocking-algorithm}
-
-- 所有数组将被替换为空数组
-- 所有原始类型保持不变
-- 所有 getter 将返回 `undefined`
-- 所有方法将返回 `undefined`
-- 所有对象将被深度克隆
-- 所有类的实例及其原型将被克隆
-
-如需禁用该默认行为，可以在调用时将 `{ spy: true }` 作为第二个参数传入，例如：
-
-```ts
-import { vi } from 'vitest'
-
-vi.mock(import('./example.js'), { spy: true })
-```
-
-在这种模式下，方法不会返回 `undefined`，而是会继续调用原始实现，但你依然能够记录并追踪这些方法的调用情况。
-
-```ts
-import { expect, vi } from 'vitest'
-import { answer } from './example.js'
-
-vi.mock(import('./example.js'), { spy: true })
-
-// calls the original implementation
-expect(answer()).toBe(42)
-// vitest can still track the invocations
-expect(answer).toHaveBeenCalled()
-```
-
-被模拟（ mocked ）的模块有一个很实用的特性——实例与其原型之间可以共享状态。
-来看下面这个示例模块：
-
-```ts [answer.js]
-export class Answer {
-  constructor(value) {
-    this._value = value
-  }
-
-  value() {
-    return this._value
-  }
-}
-```
-
-对该模块进行 mock 后，即便无法直接访问类的实例，也能记录并追踪 `.value()` 方法的每一次调用。
-
-```ts [answer.test.js]
-import { expect, test, vi } from 'vitest'
-import { Answer } from './answer.js'
-
-vi.mock(import('./answer.js'), { spy: true })
-
-test('instance inherits the state', () => {
-  // these invocations could be private inside another function
-  // that you don't have access to in your test
-  const answer1 = new Answer(42)
-  const answer2 = new Answer(0)
-
-  expect(answer1.value()).toBe(42)
-  expect(answer1.value).toHaveBeenCalled()
-  // note that different instances have their own states
-  expect(answer2.value).not.toHaveBeenCalled()
-
-  expect(answer2.value()).toBe(0)
-
-  // but the prototype state accumulates all calls
-  expect(Answer.prototype.value).toHaveBeenCalledTimes(2)
-  expect(Answer.prototype.value).toHaveReturned(42)
-  expect(Answer.prototype.value).toHaveReturned(0)
-})
-```
-
-这种技巧在需要跟踪那些从未对外暴露的实例方法调用时尤其有用。
-
-## 模拟不存在的模块 {#mocking-non-existing-module}
-
-Vitest 支持对“虚拟模块”进行模拟（mock）。
-这类模块并不存在于文件系统中，但代码中依然会导入它们。
-这种情况常见于开发环境与生产环境不一致的场景，例如在单元测试中模拟 `vscode` API。
-
-默认情况下，如果 Vitest 无法找到导入模块的源文件，它会在代码转换阶段报错。
-为避免这种情况，需要在配置文件中进行声明。
-
-你可以选择：
-
-- 始终将该导入重定向到某个真实文件；
-- 或仅告知 Vite 忽略它，再通过 `vi.mock` 工厂函数来定义模块的导出。
-
-若要进行导入重定向，可以使用 [`test.alias`](/config/#alias) 配置选项：
-
-```ts [vitest.config.ts]
-import { resolve } from 'node:path'
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    alias: {
-      vscode: resolve(import.meta.dirname, './mock/vscode.js'),
-    },
-  },
-})
-```
-
-若要将某个模块标记为“始终可解析”，可以在插件的 `resolveId` 钩子中返回与传入值相同的字符串。
-
-```ts [vitest.config.ts]
-import { resolve } from 'node:path'
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  plugins: [
-    {
-      name: 'virtual-vscode',
-      resolveId(id) {
-        if (id === 'vscode') {
-          return 'vscode'
-        }
-      }
-    }
-  ]
-})
-```
-
-现在，你可以在测试中照常使用 `vi.mock` 来模拟该模块了。
-
-```ts
-import { vi } from 'vitest'
-
-vi.mock(import('vscode'), () => {
-  return {
-    window: {
-      createOutputChannel: vi.fn(),
-    }
-  }
-})
-```
-
-## 工作原理 {#how-it-works}
-
-Vitest 会根据运行环境的不同，采用不同的模块模拟机制，但它们的共同点是都使用了插件转换器（ plugin transformer ）。
-
-当 Vitest 发现某个文件中包含 `vi.mock` 调用时，会执行两步处理：
-1. 将所有静态导入（ static import ）语句改写为动态导入（ dynamic import ）
-2. 将 `vi.mock` 调用移动到文件顶部。
-
-这样一来，Vitest 就能在模块被导入前完成 Mock 的注册，同时依然遵守 ESM 对“导入提升（ hoisted imports ）”的语法规则。
-
-::: code-group
-```ts [example.js]
-import { answer } from './answer.js'
-
-vi.mock(import('./answer.js'))
-
-console.log(answer)
-```
-```ts [example.transformed.js]
-vi.mock('./answer.js')
-
-const __vitest_module_0__ = await __handle_mock__(
-  () => import('./answer.js')
-)
-// to keep the live binding, we have to access
-// the export on the module namespace
-console.log(__vitest_module_0__.answer())
-```
-:::
-
-`__handle_mock__` 这个包装器的唯一作用，是确保在模块导入开始之前就完成 Mock 的解析；
-它不会对模块内容做任何修改。
-
-Vitest 所使用的模块模拟插件，
-可以在 [`@vitest/mocker` 包](https://github.com/vitest-dev/vitest/tree/main/packages/mocker) 中找到。
-
-### JSDOM, happy-dom, Node {#jsdom-happy-dom-node}
-
-当你在模拟（ emulated ）环境中运行测试时， Vitest 会创建一个可执行 Vite 转译代码的 [module runner](https://vite.dev/guide/api-environment-runtimes.html#modulerunner)。
-
-这个 module runner 的设计，使得 Vitest 能够在模块执行阶段进行拦截，并在已注册 mock 的情况下用它替换原模块。
-
-换句话说， Vitest 会在一个“ 类 ESM ”环境中运行测试代码，但并不直接依赖原生 ESM 机制。
-这使得测试运行器能够打破 ES Modules 的不可变性规则，让你可以在看似 ES Module 的模块上调用 `vi.spyOn`。
-
-### 浏览器模式 {#browser-mode}
-
-在浏览器模式（ Browser Mode ）中，
-Vitest 依赖原生 ESM ，这意味着无法像在 Node 环境中那样直接替换模块。
-
-因此，当模块被 mock 时，
-Vitest 会通过拦截网络请求来替换模块代码：
-- 在 Playwright 环境下，使用 `page.route` 进行拦截；
-- 在 `preview` 或 `webdriverio` 场景下，使用 Vite 插件 API 进行拦截。
-
-拦截后，
-Vitest 会返回经过转换的代码。
-
-例如，当模块是自动 mock （ automocked ）时，
-Vitest 会解析模块的静态导出，并生成一个占位模块（ placeholder module ）来替代原模块。
-
-::: code-group
-```ts [answer.js]
-export function answer() {
-  return 42
-}
-```
-```ts [answer.transformed.js]
-function answer() {
-  return 42
-}
-
-const __private_module__ = {
-  [Symbol.toStringTag]: 'Module',
-  answer: vi.fn(answer),
-}
-
-export const answer = __private_module__.answer
-```
-:::
-
-为了简洁，示例代码有所精简，但核心原理不变。
-
-我们可以在模块中注入一个 `__private_module__` 变量，用于存放被 mock 的值：
-- 如果用户在调用 `vi.mock` 时传入 `{ spy: true }`，则保留原始实现并传递它；
-- 否则，就用一个简单的 `vi.fn()` 来创建 mock 函数。
-
-当用户定义了自定义的 mock 工厂时，注入逻辑会更复杂，但仍然可以实现。
-具体流程是：当浏览器请求被 mock 的文件时，
-Vitest 会先在浏览器端解析工厂函数，并将对应的键（ keys ）传回服务器；
-服务器再利用这些键生成一个占位模块（ placeholder module ）。
-
-```ts
-const resolvedFactoryKeys = await resolveBrowserFactory(url)
-const mockedModule = `
-const __private_module__ = getFactoryReturnValue(${url})
-${resolvedFactoryKeys.map(key => `export const ${key} = __private_module__["${key}"]`).join('\n')}
-`
-```
-
-该模块此时已经可以回传并在浏览器中加载。
-在运行测试时，你可以通过浏览器的开发者工具（ DevTools ）来查看它的代码。
-
-## 模块模拟的常见陷阱 {#mocking-modules-pitfalls}
-
-需要注意的是，如果一个方法是在同一文件内由另一个方法调用的，那么它无法通过外部进行 mock。
-例如，以下代码中就存在这种情况：
-
-```ts [foobar.js]
-export function foo() {
-  return 'foo'
-}
-
-export function foobar() {
-  return `${foo()}bar`
-}
-```
-
-`foo` 方法在 `foobar` 函数内部是直接引用的，因此无法通过外部 mock 覆盖。
-这意味着，该 mock 对 `foobar` 内部的 `foo` 调用不会产生任何作用，但会影响其他模块中对 `foo` 的调用。
-
-```ts [foobar.test.ts]
-import { vi } from 'vitest'
-import * as mod from './foobar.js'
-
-// this will only affect "foo" outside of the original module
-vi.spyOn(mod, 'foo')
-vi.mock(import('./foobar.js'), async (importOriginal) => {
-  return {
-    ...await importOriginal(),
-    // this will only affect "foo" outside of the original module
-    foo: () => 'mocked'
-  }
-})
-```
-
-你可以直接替换 `foobar` 方法的实现，从而验证这一行为。
-
-```ts [foobar.test.js]
-import * as mod from './foobar.js'
-
-vi.spyOn(mod, 'foo')
-
-// exported foo references mocked method
-mod.foobar(mod.foo)
-```
-
-```ts [foobar.js]
-export function foo() {
-  return 'foo'
-}
-
-export function foobar(injectedFoo) {
-  return injectedFoo === foo // false
-}
-```
-
-这是预期的行为，我们不会为此提供变通方案。
-建议将代码拆分为多个文件，或采用 [依赖注入](https://en.wikipedia.org/wiki/Dependency_injection) 等架构设计手段来优化。
-
-我们认为，让应用程序具备良好的可测试性，并不是测试运行器的职责，而是应用架构设计应承担的责任。
diff --git a/guide/mocking/requests.md b/guide/mocking/requests.md
deleted file mode 100644
index 83693084..00000000
--- a/guide/mocking/requests.md
+++ /dev/null
@@ -1,114 +0,0 @@
-# 模拟请求 {#mocking-requests}
-
-由于 Vitest 运行在 Node 环境中，模拟网络请求很棘手；Web API 不可用，所以我们需要一些能够模拟网络行为的工具。我们推荐使用 [Mock Service Worker](https://mswjs.io/) 来实现这一点。它允许你模拟 `http`、`WebSocket` 和 `GraphQL` 网络请求，并且与框架无关。
-
-Mock Service Worker (MSW) 通过拦截你的测试发出的请求来工作，允许你在不更改任何应用程序代码的情况下使用它。在浏览器中，这使用 [Service Worker API](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API)。在 Node.js 和 Vitest 中，它使用 [`@mswjs/interceptors`](https://github.com/mswjs/interceptors) 库。要了解更多关于 MSW 的信息，请阅读他们的[介绍](https://mswjs.io/docs/)。
-
-## 配置 {#configuration}
-
-你可以像下面这样在你的 [setup 文件](/config/#setupfiles) 中使用它：
-
-::: code-group
-
-```js [HTTP Setup]
-import { http, HttpResponse } from 'msw'
-import { setupServer } from 'msw/node'
-import { afterAll, afterEach, beforeAll } from 'vitest'
-
-const posts = [
-  {
-    userId: 1,
-    id: 1,
-    title: 'first post title',
-    body: 'first post body',
-  },
-  // ...
-]
-
-export const restHandlers = [
-  http.get('https://rest-endpoint.example/path/to/posts', () => {
-    return HttpResponse.json(posts)
-  }),
-]
-
-const server = setupServer(...restHandlers)
-
-// 在所有测试开始前启动服务器
-beforeAll(() => server.listen({ onUnhandledRequest: 'error' }))
-
-// 在所有测试结束后关闭服务器
-afterAll(() => server.close())
-
-// 在每次测试后重置处理器以实现测试隔离
-afterEach(() => server.resetHandlers())
-```
-
-```js [GraphQL Setup]
-import { graphql, HttpResponse } from 'msw'
-import { setupServer } from 'msw/node'
-import { afterAll, afterEach, beforeAll } from 'vitest'
-
-const posts = [
-  {
-    userId: 1,
-    id: 1,
-    title: 'first post title',
-    body: 'first post body',
-  },
-  // ...
-]
-
-const graphqlHandlers = [
-  graphql.query('ListPosts', () => {
-    return HttpResponse.json({
-      data: { posts },
-    })
-  }),
-]
-
-const server = setupServer(...graphqlHandlers)
-
-// 在所有测试开始前启动服务器
-beforeAll(() => server.listen({ onUnhandledRequest: 'error' }))
-
-// 在所有测试结束后关闭服务器
-afterAll(() => server.close())
-
-// 在每次测试后重置处理器以实现测试隔离
-afterEach(() => server.resetHandlers())
-```
-
-```js [WebSocket Setup]
-import { ws } from 'msw'
-import { setupServer } from 'msw/node'
-import { afterAll, afterEach, beforeAll } from 'vitest'
-
-const chat = ws.link('wss://chat.example.com')
-
-const wsHandlers = [
-  chat.addEventListener('connection', ({ client }) => {
-    client.addEventListener('message', (event) => {
-      console.log('Received message from client:', event.data)
-      // 将接收到的消息回显给客户端
-      client.send(`Server received: ${event.data}`)
-    })
-  }),
-]
-
-const server = setupServer(...wsHandlers)
-
-// 在所有测试开始前启动服务器
-beforeAll(() => server.listen({ onUnhandledRequest: 'error' }))
-
-// 在所有测试结束后关闭服务器
-afterAll(() => server.close())
-
-// 在每次测试后重置处理器以实现测试隔离
-afterEach(() => server.resetHandlers())
-```
-:::
-
-> 配置服务器时设置 `onUnhandledRequest: 'error'` 可以确保当存在没有对应请求处理器的请求时抛出错误。
-
-## 更多信息 {#more}
-MSW 的功能远不止这些。你可以访问 cookie 和查询参数，定义模拟错误响应，以及更多其他功能！要了解 MSW 的所有功能，请阅读[它们的文档](https://mswjs.io/docs)。
diff --git a/guide/mocking/timers.md b/guide/mocking/timers.md
deleted file mode 100644
index 4d820a10..00000000
--- a/guide/mocking/timers.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# 模拟计时器 {#timers}
-
-当我们测试涉及超时或间隔的代码时，我们可以使用"伪造"计时器来加速测试，而不是让测试等待超时。这些伪造计时器可以模拟对 `setTimeout` 和 `setInterval` 的调用。
-
-有关更详细的 API 描述，请参见 [`vi.useFakeTimers` API 部分](/api/vi#vi-usefaketimers)。
-
-## 示例 {#example}
-
-```js
-import { afterEach, beforeEach, describe, expect, it, vi } from 'vitest'
-
-function executeAfterTwoHours(func) {
-  setTimeout(func, 1000 * 60 * 60 * 2) // 2 hours
-}
-
-function executeEveryMinute(func) {
-  setInterval(func, 1000 * 60) // 1 minute
-}
-
-const mock = vi.fn(() => console.log('executed'))
-
-describe('delayed execution', () => {
-  beforeEach(() => {
-    vi.useFakeTimers()
-  })
-  afterEach(() => {
-    vi.restoreAllMocks()
-  })
-  it('should execute the function', () => {
-    executeAfterTwoHours(mock)
-    vi.runAllTimers()
-    expect(mock).toHaveBeenCalledTimes(1)
-  })
-  it('should not execute the function', () => {
-    executeAfterTwoHours(mock)
-    // 前进2毫秒不会触发该函数
-    vi.advanceTimersByTime(2)
-    expect(mock).not.toHaveBeenCalled()
-  })
-  it('should execute every minute', () => {
-    executeEveryMinute(mock)
-    vi.advanceTimersToNextTimer()
-    expect(mock).toHaveBeenCalledTimes(1)
-    vi.advanceTimersToNextTimer()
-    expect(mock).toHaveBeenCalledTimes(2)
-  })
-})
-```

From e3913c46379d1ed59bdfa296d37a3c962a0fc885 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 24 Nov 2025 00:12:14 +0800
Subject: [PATCH 19/50] !docs: recovery /guide/parallelism

---
 .vitepress/config.ts | 2 +-
 guide/parallelism.md | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/.vitepress/config.ts b/.vitepress/config.ts
index 099c2ca4..04c9f595 100644
--- a/.vitepress/config.ts
+++ b/.vitepress/config.ts
@@ -579,7 +579,7 @@ function guide(): DefaultTheme.SidebarItem[] {
       link: '/guide/mocking',
     },
     {
-      text: '并行执行',
+      text: '并行性',
       link: '/guide/parallelism',
     },
     {
diff --git a/guide/parallelism.md b/guide/parallelism.md
index 826d6f8d..814db2fc 100644
--- a/guide/parallelism.md
+++ b/guide/parallelism.md
@@ -7,7 +7,7 @@ outline: deep
 
 ## 文件级并行 {#file-parallelism}
 
-Vitest 默认会并行执行 _测试文件_ 。具体使用哪种并行机制取决于配置的 `pool` 类型：
+默认情况下，Vitest 会并行运行 _测试文件_。根据指定的 `pool`，Vitest 会采用不同的并行化机制：
 
 - `forks`（默认）和 `vmForks` 会在不同的 [child processes](https://nodejs.org/api/child_process.html) 中执行测试
 - `threads` 和 `vmThreads` 则会在不同的 [worker threads](https://nodejs.org/api/worker_threads.html) 中运行
@@ -16,7 +16,7 @@ Vitest 默认会并行执行 _测试文件_ 。具体使用哪种并行机制取
 
 如果项目包含大量测试文件，通常并行执行会大幅提升速度。但具体效果还要看项目本身、运行环境以及是否启用了 [隔离](/config/#isolate)。若需要关闭文件级并行化，可以将 [`fileParallelism`](/config/#fileparallelism) 设为 `false` 。更多性能优化技巧，请参考 [性能指南](/guide/improving-performance) 。
 
-## 测试用例并行 {#test-parallelism}
+## 测试级并行 {#test-parallelism}
 
 与 _测试文件_ 不同， Vitest 在同一个文件中会顺序执行 _测试用例_ 。也就是说，同一个文件里的测试会按定义顺序一个接一个地执行。
 

From 2bc5fbc237df21b2b94422f035709bab61f8b14e Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 24 Nov 2025 00:29:27 +0800
Subject: [PATCH 20/50] !docs: recovery /guide/testing-types

---
 guide/testing-types.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/guide/testing-types.md b/guide/testing-types.md
index 26fc4bc3..0c4736ed 100644
--- a/guide/testing-types.md
+++ b/guide/testing-types.md
@@ -4,9 +4,9 @@ title: 类型测试 | 指南
 
 # 类型测试 {#testing-types}
 
-::: tip Sample Project
+::: tip 示例项目
 
-[GitHub](https://github.com/vitest-dev/vitest/tree/main/examples/typecheck) - [Play Online](https://stackblitz.com/fork/github/vitest-dev/vitest/tree/main/examples/typecheck?initialPath=__vitest__/)
+[GitHub](https://github.com/vitest-dev/vitest/tree/main/examples/typecheck) - [在线演示](https://stackblitz.com/fork/github/vitest-dev/vitest/tree/main/examples/typecheck?initialPath=__vitest__/)
 
 :::
 
@@ -14,7 +14,7 @@ Vitest 允许你使用 `expectTypeOf` 或 `assertType` 语法为你的类型编
 
 在这里，Vitest 调用 `tsc` 或 `vue-tsc`，具体取决于你的配置，并解析结果。如果发现任何类型错误，Vitest 还会在你的源代码中打印出类型错误。你可以使用 [`typecheck.ignoreSourceErrors`](/config/#typecheck-ignoresourceerrors) 配置选项禁用它。
 
-请记住，Vitest 不会运行这些文件，编译器只会对它们进行静态分析。也就是说，如果您使用动态名称或 `test.each` 或 `test.for`，测试名称将不会被评估 - 它将原样显示。
+请记住，Vitest 不会运行这些文件，编译器只会对它们进行静态分析。也就是说，如果您使用动态名称或 `test.each` 或 `test.for`，测试名称将不会被评估，它将原样显示。
 
 ::: warning
 在 Vitest 2.1 之前，您的 `typecheck.include` 覆盖了 `include` 模式，因此您的运行时测试并没有实际运行；它们只是被类型检查。
@@ -39,7 +39,7 @@ test('my types work properly', () => {
 
 在测试文件中触发的任何类型错误都将被视为测试错误，因此你可以使用任何类型技巧来测试项目中的类型。
 
-你可以在 [API 部分](/api/#expecttypeof) 中查看可能的匹配器列表。
+你可以在 [API 部分](/api/#expecttypeof) 中查看所有可用的匹配器列表。
 
 ## 读取错误 {#reading-errors}
 
@@ -61,7 +61,7 @@ test/test.ts:999:999 - error TS2344: Type '{ a: string; }' does not satisfy the
 999 expectTypeOf({a: 1}).toEqualTypeOf<{a: string}>()
 ```
 
-请注意，报告的类型约束是一个可读性强的消息，指定了"期望"和"实际"类型。不要字面上解读句子 `Types of property 'a' are incompatible // Type 'string' is not assignable to type "Expected: string, Actual: number"` ，而是看属性名（`'a'`）和消息内容：`Expected: string, Actual: number`。这将告诉你出了什么问题，在大多数情况下。当然，对于非常复杂的类型，调试可能需要更多的努力，并且可能需要一些试验。如果错误消息实际上是误导性的，请[提出问题](https://github.com/mmkal/expect-type)。
+请注意，报告的类型约束是一个可读性强的消息，指定了"期望"和"实际"类型。不要字面上解读句子 `Types of property 'a' are incompatible // Type 'string' is not assignable to type "Expected: string, Actual: number"` ，而是看属性名（`'a'`）和消息内容：`Expected: string, Actual: number`。这将告诉你出了什么问题，在大多数情况下。当然，对于非常复杂的类型，调试可能需要更多的努力，并且可能需要一些试验。如果错误消息实际上是误导性的，请 [提出问题](https://github.com/mmkal/expect-type)。
 
 对于像 `expectTypeOf(1).toBeString()` 这样的断言，`toBe...` 方法（如 `toBeString`、`toBeNumber`、`toBeVoid` 等）在被测试的 `Actual` 类型不匹配时会解析为一个不可调用的类型。例如，失败的断言可能会显示如下内容：
 
@@ -73,7 +73,7 @@ test/test.ts:999:999 - error TS2349: This expression is not callable.
                     ~~~~~~~~~~
 ```
 
-这部分的`This expression is not callable`并没有太大的帮助 - 有意义的错误在下一行，`Type 'ExpectString<number> has no call signatures`。这基本上意味着你传递了一个数字，但断言它应该是一个字符串。
+这部分的 `This expression is not callable` 并没有太大的帮助，有意义的错误在下一行，`Type 'ExpectString<number> has no call signatures`。这基本上意味着你传递了一个数字，但断言它应该是一个字符串。
 
 如果 TypeScript 添加了对 ["throw" 类型](https://github.com/microsoft/TypeScript/pull/40468) 的支持，这些错误消息将会显著改进。在那之前，它们需要一定程度的仔细观察。
 

From 076b1e7136253d91429552e60ea712967d655784 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 24 Nov 2025 00:36:23 +0800
Subject: [PATCH 21/50] !docs: recovery /guide/in-source

---
 guide/in-source.md | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/guide/in-source.md b/guide/in-source.md
index 46e04772..4194766b 100644
--- a/guide/in-source.md
+++ b/guide/in-source.md
@@ -4,20 +4,20 @@ title: 源码内联测试 | 指南
 
 # 源码内联测试 {#in-source-testing}
 
-Vitest 还提供了一种方式，可以运行与你的代码实现放在一起的测试，就像是 [Rust 语言的模块测试一样](https://doc.rust-lang.org/book/ch11-03-test-organization.html#the-tests-module-and-cfgtest)。
+Vitest 还提供了一种在源代码中与实现一起运行测试的方式，就像是 [类似于 Rust 语言的模块测试](https://doc.rust-lang.org/book/ch11-03-test-organization.html#the-tests-module-and-cfgtest)。
 
 这允许测试与实现共享相同的闭包，并且能够在不导出的情况下针对私有状态进行测试。同时，它也使开发更加接近反馈循环。
 
-## 指引 {#setup}
-
 ::: warning
-本指南介绍如何在源代码中编写测试。如果需要在单独的测试文件中编写测试，请参阅["编写测试"指南](/guide/#writing-tests)。
+本指南介绍如何在源代码中编写测试。如果需要在单独的测试文件中编写测试，请参阅 ["编写测试" 指南](/guide/#writing-tests)。
 :::
 
+## 指引 {#setup}
+
 首先，在 `if (import.meta.vitest)` 代码块内写一些测试代码并放在文件的末尾，例如:
 
 ```ts [src/index.ts]
-// the implementation
+// 具体实现
 export function add(...args: number[]) {
   return args.reduce((a, b) => a + b, 0)
 }
@@ -82,11 +82,11 @@ export default defineBuildConfig({
     // [!code ++]
     'import.meta.vitest': 'undefined', // [!code ++]
   }, // [!code ++]
-  // other options
+  // 其他选项
 })
 ```
 
-了解更多: [unbuild](https://github.com/unjs/unbuild)
+了解更多：[unbuild](https://github.com/unjs/unbuild)
 :::
 
 ::: details Rollup
@@ -100,7 +100,7 @@ export default {
       'import.meta.vitest': 'undefined', // [!code ++]
     }), // [!code ++]
   ],
-  // other options
+  // 其他选项
 }
 ```
 

From edfe8d7d7b2daf0b91fe04526e84c6f47a006fb7 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 24 Nov 2025 00:47:52 +0800
Subject: [PATCH 22/50] !docs: recovery /guide/test-context

---
 guide/test-context.md | 59 ++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 55 insertions(+), 4 deletions(-)

diff --git a/guide/test-context.md b/guide/test-context.md
index ed4a42ff..8b1703f3 100644
--- a/guide/test-context.md
+++ b/guide/test-context.md
@@ -191,7 +191,7 @@ export const test = todosTest.extend({
 })
 ```
 
-#### 固定装置初始化 {#fixture-initialization}
+#### 初始化固定装置 {#fixture-initialization}
 
 Vitest 运行器将智能地初始化你的固定装置并根据使用情况将它们注入到测试上下文中。
 
@@ -255,7 +255,7 @@ test('works correctly')
 
 #### 默认的装置 {#default-fixture}
 
-从 Vitest 3 开始，你可以在不同的[项目](/guide/projects)中提供不同的值。要启用此功能，请在选项中传递 `{ injected: true }`。如果在[项目配置](/config/#provide)中未指定该键，则将使用默认值。
+从 Vitest 3 开始，你可以在不同的 [项目](/guide/projects) 中提供不同的值。要启用此功能，请在选项中传递 `{ injected: true }`。如果在 [项目配置](/config/#provide) 中未指定该键，则将使用默认值。
 
 :::code-group
 ```ts [fixtures.test.ts]
@@ -373,7 +373,7 @@ describe('another type of schema', () => {
 })
 ```
 
-#### 作用域上下文 <Version>3.2.0</Version>
+#### 作用域上下文 <Version>3.2.0</Version> {#per-scope-context-3-2-0}
 
 你可以定义每个文件或每个工作线程只初始化一次的上下文。它的初始化方式与带对象参数的常规夹具相同：
 
@@ -392,7 +392,7 @@ export const test = baseTest.extend({
 })
 ```
 
-该值在任何测试第一次访问它时初始化，除非夹具选项设置了 `auto: true` - 在这种情况下，该值在任何测试运行之前就已初始化。
+该值在任何测试第一次访问它时初始化，除非夹具选项设置了 `auto: true`， 在这种情况下，该值在任何测试运行之前就已初始化。
 
 ```ts
 const test = baseTest.extend({
@@ -478,3 +478,54 @@ test.afterEach(({ todos }) => {
   console.log(todos)
 })
 ```
+
+### `beforeEach` and `afterEach`
+
+::: danger 弃用
+这种扩展上下文的方法已不再推荐使用，并且在你使用 `test.extend` 扩展 `test` 时，它将无法生效。
+:::
+
+每个测试用例都有独立的上下文，你可以在 `beforeEach` 和 `afterEach` 钩子里对其进行访问或扩展。
+
+```ts
+import { beforeEach, it } from 'vitest'
+
+beforeEach(async (context) => {
+  // 扩展上下文
+  context.foo = 'bar'
+})
+
+it('should work', ({ foo }) => {
+  console.log(foo) // 'bar'
+})
+```
+
+#### TypeScript
+
+如果你想为自定义的上下文属性提供类型支持，可以通过扩展 `TestContext` 类型来实现：
+
+```ts
+declare module 'vitest' {
+  export interface TestContext {
+    foo?: string
+  }
+}
+```
+
+如果你只想为特定的 `beforeEach`、`afterEach`、`it` 或 `test` hooks 提供属性类型，则可以将类型作为泛型(generic)传递。
+
+```ts
+interface LocalTestContext {
+  foo: string
+}
+
+beforeEach<LocalTestContext>(async (context) => {
+  // 上下文的类型是 'TestContext & LocalTestContext'
+  context.foo = 'bar'
+})
+
+it<LocalTestContext>('should work', ({ foo }) => {
+  // foo 的类型是 'string'
+  console.log(foo) // 'bar'
+})
+```

From 99661d40326dbc446b6fe4029d8e96a15a776daa Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 24 Nov 2025 01:19:06 +0800
Subject: [PATCH 23/50] !docs: recovery /guide/test-annotations

---
 .vitepress/config.ts      |  4 ++++
 guide/test-annotations.md | 24 ++++++++++++------------
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/.vitepress/config.ts b/.vitepress/config.ts
index 04c9f595..6dac9959 100644
--- a/.vitepress/config.ts
+++ b/.vitepress/config.ts
@@ -598,6 +598,10 @@ function guide(): DefaultTheme.SidebarItem[] {
       text: '测试上下文',
       link: '/guide/test-context',
     },
+    {
+      text: '测试注释',
+      link: '/guide/test-annotations',
+    },
     {
       text: '测试环境',
       link: '/guide/environment',
diff --git a/guide/test-annotations.md b/guide/test-annotations.md
index 88f23625..59d762b3 100644
--- a/guide/test-annotations.md
+++ b/guide/test-annotations.md
@@ -1,11 +1,11 @@
 ---
-title: Test Annotations | Guide
+title: 测试注释 | 指南
 outline: deep
 ---
 
-# Test Annotations
+# 测试注释 {#test-annotations}
 
-Vitest supports annotating your tests with custom messages and files via the [`context.annotate`](/guide/test-context#annotate) API. These annotations will be attached to the test case and passed down to reporters in the [`onTestAnnotate`](/advanced/api/reporters#ontestannotate) hook.
+Vitest 支持通过 [`context.annotate`](/guide/test-context#annotate) API 为测试添加自定义消息和文件注释，这些测试注释将附加到测试用例上，并通过  [`onTestAnnotate`](/advanced/api/reporters#ontestannotate) 钩子传递给报告器。
 
 ```ts
 test('hello world', async ({ annotate }) => {
@@ -21,15 +21,15 @@ test('hello world', async ({ annotate }) => {
 ```
 
 ::: warning
-The `annotate` function returns a Promise, so it needs to be awaited if you rely on it somehow. However, Vitest will also automatically await any non-awaited annotation before the test finishes.
+`annotate` 函数返回一个 Promise，因此如果依赖它就需要使用 await。不过 Vitest 也会在测试完成前自动等待所有未 await 的测试注释。
 :::
 
-Depending on your reporter, you will see these annotations differently.
+根据使用的报告器不同，这些测试注释的显示方式也会有所差异。
 
-## Built-in Reporters
+## 内置报告器 {#built-in-reporters}
 ### default
 
-The `default` reporter prints annotations only if the test has failed:
+`默认报告器` 仅在测试失败时打印注解：
 
 ```
   ⎯⎯⎯⎯⎯⎯⎯ Failed Tests 1 ⎯⎯⎯⎯⎯⎯⎯
@@ -53,7 +53,7 @@ Error: thrown error
 
 ### verbose
 
-The `verbose` reporter is the only terminal reporter that reports annotations when the test doesn't fail.
+`verbose` 报告器是唯一会在测试未失败时报告测试注释的终端报告器。
 
 ```
 ✓ example.test.js > an example of a test with annotation
@@ -67,14 +67,14 @@ The `verbose` reporter is the only terminal reporter that reports annotations wh
 
 ### html
 
-The HTML reporter shows annotations the same way the UI does. You can see the annotation on the line where it was called. At the moment, if the annotation wasn't called in a test file, you cannot see it in the UI. We are planning to support a separate test summary view where it will be visible.
+HTML 报告器会以与 UI模式 相同的方式显示测试注释。您可以在调用那行看到测试注释。目前，如果测试文件中没有调用测试注释，您将无法在 UI模式 中看到它。我们计划支持一个单独的测试摘要视图，届时这些测试注释将会显示。
 
 <img alt="Vitest UI" img-light src="/annotations-html-light.png">
 <img alt="Vitest UI" img-dark src="/annotations-html-dark.png">
 
 ### junit
 
-The `junit` reporter lists annotations inside the testcase's `properties` tag. The JUnit reporter will ignore all attachments and will print only the type and the message.
+`junit` 报告器会将测试注释列在测试用例的 `properties` 标签内。JUnit 报告器会忽略所有附件，仅打印类型和消息。
 
 ```xml
 <testcase classname="basic/example.test.js" name="an example of a test with annotation" time="0.14315">
@@ -87,14 +87,14 @@ The `junit` reporter lists annotations inside the testcase's `properties` tag. T
 
 ### github-actions
 
-The `github-actions` reporter will print the annotation as a [notice message](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#setting-a-notice-message) by default. You can configure the `type` by passing down the second argument as `notice`, `warning` or `error`. If type is none of these, Vitest will show the message as a notice.
+`github-actions` 报告器默认会将 [通知消息](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#setting-a-notice-message) 为通知消息打印。 你可以通过第二个参数配置消息的 `type` 为 `notice`, `warning` or `error`。 如果不是这三种类型，Vitest 默认使用消息类型 (notice)。
 
 <img alt="GitHub Actions" img-light src="/annotations-gha-light.png">
 <img alt="GitHub Actions" img-dark src="/annotations-gha-dark.png">
 
 ### tap
 
-The `tap` and `tap-flat` reporters print annotations as diagnostic messages on a new line starting with a `#` symbol. They will ignore all attachments and will print only the type and message:
+`tap` 和 `tap-flat` 报告器会将注释作为诊断信息打印在新的一行上，并以 #符号开头。它们会忽略所有附件，仅打印类型和消息：
 
 ```
 ok 1 - an example of a test with annotation # time=143.15ms

From 5930650f8ca7152a97669fe521a7d38b2bf1b40d Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 24 Nov 2025 01:28:18 +0800
Subject: [PATCH 24/50] !docs: recovery /guide/test-annotations

---
 guide/environment.md      | 4 ++--
 guide/test-annotations.md | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/guide/environment.md b/guide/environment.md
index 9801a18d..cf0d2b9f 100644
--- a/guide/environment.md
+++ b/guide/environment.md
@@ -27,7 +27,7 @@ Vitest 并不将 `browser` 视作一种测试环境。如果你想让部分测
 
 ## 特定文件的环境 {#environments-for-specific-files}
 
-如果配置中设置 `environment` 选项时，它将应用于项目中的所有测试文件。要获得更细粒度的控制，你可以使用控制注释为特定文件指定环境。控制注释是以 `@vitest-environment` 开头，后跟环境名称的注释：
+如果在配置文件中设置 `environment` 选项时，它将应用于项目中的所有测试文件。要获得更细粒度的控制，你可以使用控制注释为特定文件指定环境。控制注释是以 `@vitest-environment` 开头，后跟环境名称的注释：
 
 ```ts
 // @vitest-environment jsdom
@@ -74,7 +74,7 @@ export default <Environment>{
 ```
 
 ::: warning
-Vitest 要求环境对象显式提供 `viteEnvironment` 字段（若省略则取 Vitest 环境名）。该字段必须设为 `ssr`、`client` 或任意自定义 [Vite 环境](https://cn.vite.dev/guide/api-environment) 名称，用于指定处理测试文件的目标环境。
+Vitest 需要指定环境对象上的 `transformMode` 选项。它应该等于 `ssr` 或 `web`。该值决定插件如何转换源代码。如果设置为 `ssr`，则插件挂钩在转换或解析文件时将收到 `ssr: true`。 否则，`ssr` 被设置为 `false`。
 :::
 
 你还可以通过 `vitest/environments` 访问默认的 Vitest 环境：
diff --git a/guide/test-annotations.md b/guide/test-annotations.md
index 59d762b3..6bd3b7a1 100644
--- a/guide/test-annotations.md
+++ b/guide/test-annotations.md
@@ -87,7 +87,7 @@ HTML 报告器会以与 UI模式 相同的方式显示测试注释。您可以
 
 ### github-actions
 
-`github-actions` 报告器默认会将 [通知消息](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#setting-a-notice-message) 为通知消息打印。 你可以通过第二个参数配置消息的 `type` 为 `notice`, `warning` or `error`。 如果不是这三种类型，Vitest 默认使用消息类型 (notice)。
+`github-actions` 报告器默认会将 [通知消息](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#setting-a-notice-message) 为通知消息打印。 你可以通过第二个参数配置消息的 `type` 为 `notice`, `warning` or `error`。 如果不是这三种类型，Vitest 默认使用通知消息 (notice)。
 
 <img alt="GitHub Actions" img-light src="/annotations-gha-light.png">
 <img alt="GitHub Actions" img-dark src="/annotations-gha-dark.png">

From 5847c231ddc544aec78220504a267f0ead0593fc Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 24 Nov 2025 01:32:35 +0800
Subject: [PATCH 25/50] !docs: recovery /guide/extending-matchers

---
 guide/extending-matchers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guide/extending-matchers.md b/guide/extending-matchers.md
index 37f5cd40..f2e9b12c 100644
--- a/guide/extending-matchers.md
+++ b/guide/extending-matchers.md
@@ -6,7 +6,7 @@ title: 扩展断言 | 指南
 
 由于 Vitest 兼容 Chai 和 Jest，所以可以根据个人喜好使用 `chai.use` API 或者 `expect.extend`。
 
-本文将以 `expect.extend` 为例探讨扩展断言。如果你对 Chai 的 API 更感兴趣，可以查看[它的指南](https://www.chaijs.com/guide/plugins/)。
+本文将以 `expect.extend` 为例探讨扩展断言。如果你对 Chai 的 API 更感兴趣，可以查看 [他们的指南](https://www.chaijs.com/guide/plugins/)。
 
 为了扩展默认的断言，可以使用对象包裹断言的形式调用 `expect.extend` 方法。
 

From 857916242e5e06355eefda817ab9175469d74ae4 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 24 Nov 2025 01:38:52 +0800
Subject: [PATCH 26/50] !docs: recovery /guide/common-errors

---
 guide/common-errors.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guide/common-errors.md b/guide/common-errors.md
index bf9ea91c..888d3289 100644
--- a/guide/common-errors.md
+++ b/guide/common-errors.md
@@ -68,7 +68,7 @@ vitest --pool=forks
 
 ## Segfaults and native code errors
 
-运行 [原生 NodeJS 模块](https://nodejs.org/api/addons.html)在 `pool: 'threads'` 中，可能会遇到来自原生代码的神秘错误。
+运行 [原生 NodeJS 模块](https://nodejs.org/api/addons.html) 在 `pool: 'threads'` 中，可能会遇到来自原生代码的神秘错误。
 
 - `Segmentation fault (core dumped)`
 - `thread '<unnamed>' panicked at 'assertion failed`

From 63ca56acd41ced46e6a842f043577d870ca29336 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 24 Nov 2025 02:10:52 +0800
Subject: [PATCH 27/50] !docs: recovery /guide/debugging

---
 guide/debugging.md   | 18 +-----------------
 guide/environment.md |  2 +-
 2 files changed, 2 insertions(+), 18 deletions(-)

diff --git a/guide/debugging.md b/guide/debugging.md
index 726d2e2b..9bc5b6a5 100644
--- a/guide/debugging.md
+++ b/guide/debugging.md
@@ -4,28 +4,12 @@ title: 调试 | 指南
 
 # 调试 {#debugging}
 
-## 终端 {#terminal}
-
-在非集成开发环境下，为了调试一个测试文件，你可以使用 [`ndb`](https://github.com/GoogleChromeLabs/ndb)。仅仅在你的代码的任何位置添加一个 `debugger` 语句，然后运行 `ndb`：
-
-```sh
-# 全局安装 ndb
-npm install -g ndb
-
-# 或者使用 yarn
-yarn global add ndb
-
-# 在启用 debugger 的情况下运行测试
-ndb npm run test
-```
-
 :::tip
 在调试测试时，你可能需要使用以下选项：
 
 - [`--test-timeout=0`](/guide/cli#testtimeout) 以防止测试在断点处停止时超时
 - [`--no-file-parallelism`](/guide/cli#fileparallelism) 以防止测试文件并行运行
 :::
-
 ## VS Code
 
 在 VSCode 中快速调试测试的方法是通过 `JavaScript Debug Terminal` 。打开一个新的 `JavaScript Debug Terminal` 并直接运行 `npm run test` 或 `vitest` 。*这适用于在 Node 中运行的任何代码，因此将适用于大多数 JS 测试框架*。
@@ -128,7 +112,7 @@ vitest --inspect-brk=127.0.0.1:3000 --browser --no-file-parallelism
 
 然后在调试模式下运行此配置。IDE 将在编辑器中设置的 JS/TS 断点处停止。
 
-## Node 解释器, 例如 Chrome开发者工具
+## Node 解释器, 例如 Chrome开发者工具 {#node-inspector-e-g-chrome-devtools}
 
 Vitest 还支持在没有 IDE 的情况下调试测试。然而，这要求测试不是并行运行的。可以使用以下命令之一启动 Vitest。
 
diff --git a/guide/environment.md b/guide/environment.md
index cf0d2b9f..11388a57 100644
--- a/guide/environment.md
+++ b/guide/environment.md
@@ -49,7 +49,7 @@ import type { Environment } from 'vitest/environments'
 export default <Environment>{
   name: 'custom',
   viteEnvironment: 'ssr',
-  // optional - only if you support "experimental-vm" pool
+  // 可选 - 仅在支持 "experimental-vm" 的情况下使用
   async setupVM() {
     const vm = await import('node:vm')
     const context = vm.createContext()

From 8cd9c1a2a70382efa80437393ecbc0c8680ecf37 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 24 Nov 2025 02:23:13 +0800
Subject: [PATCH 28/50] !docs: recovery /guide/improving-performance

---
 guide/improving-performance.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/guide/improving-performance.md b/guide/improving-performance.md
index 367e23d3..3e7b40c9 100644
--- a/guide/improving-performance.md
+++ b/guide/improving-performance.md
@@ -8,7 +8,11 @@ title: 性能优化 | 指南
 
 默认情况下，Vitest 在基于[pool](/config/#pool) 的隔离环境中运行每个测试文件：
 
-这会大大增加测试时间，对于那些不依赖副作用并且能够正确清理其状态的项目来说，这可能不是所期望的（对于拥有 `node` 环境的项目来说，这通常是正确的）。在这种情况下，禁用隔离将提高测试速度。要做到这一点，我们可以在 CLI 中提供 `--no-isolate` 标志，或者在配置文件中将 [`test.isolate`](/config/#isolate) 属性设置为 `false`。
+- `threads` 池在单独的 [`Worker`](https://nodejs.org/api/worker_threads.html#class-worker) 中运行每个测试文件
+- `forks` 池在单独的 [子进程](https://nodejs.org/api/child_process.html#child_processforkmodulepath-args-options) 中运行每个测试文件
+- `vmThreads` 池在单独的 [VM 上下文](https://nodejs.org/api/vm.html#vmcreatecontextcontextobject-options) 中运行每个测试文件，但使用 workers 实现并行。
+
+对于那些不依赖副作用并且能够正确清理其状态的项目来说，这可能不是所期望的（对于拥有 `node` 环境的项目来说，这通常是正确的），这会大大增加测试时间。在这种情况下，禁用隔离将提高测试速度。要做到这一点，我们可以在 CLI 中提供 `--no-isolate` 标志，或者在配置文件中将 [`test.isolate`](/config/#isolate) 属性设置为 `false`。
 
 ::: code-group
 
@@ -58,13 +62,9 @@ export default defineConfig({
 
 :::
 
-## 限制搜索目录 {#limiting-directory-search}
-
-你可以通过 [`test.dir`](/config/#test-dir) 选项限制 Vitest 搜索文件的工作目录。如果根目录中存在不相关的文件夹和文件，这将加快搜索速度。
-
 ## 运行池 {#pool}
 
-默认情况下，Vitest 在 `pool: 'forks'` 中运行测试。虽然 `'forks'` 池更适合解决兼容性问题（[hanging process](/guide/common-errors.html#failed-to-terminate-worker) 和[segfaults](/guide/common-errors.html#segfaults-and-native-code-errors)），但在较大的项目中，它可能比 `pool: 'threads'` 稍慢。
+默认情况下，Vitest 在 `pool: 'forks'` 中运行测试。虽然 `'forks'` 池更适合解决兼容性问题（ [hanging process](/guide/common-errors.html#failed-to-terminate-worker) 和 [segfaults](/guide/common-errors.html#segfaults-and-native-code-errors)），但在较大的项目中，它可能比 `pool: 'threads'` 稍慢。
 
 你可以尝试通过切换配置中的 `pool` 选项来改善测试运行时间：
 
@@ -106,7 +106,7 @@ vitest run --reporter=blob --shard=3/3 # 3rd machine
 vitest run --merge-reports
 ```
 
-::: GitHub Actions 详细示例
+::: details GitHub Actions 示例
 同样方案也应用于 https://github.com/vitest-tests/test-sharding 仓库。
 
 ```yaml

From df050531600d637e8a7a50f9d5d3e4a7d5cf264a Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Sat, 29 Nov 2025 21:39:37 +0800
Subject: [PATCH 29/50] !docs: recovery /config/

---
 config/index.md   | 549 +++++++++++++++++++++++++++++++---------------
 guide/snapshot.md |   2 +-
 2 files changed, 379 insertions(+), 172 deletions(-)

diff --git a/config/index.md b/config/index.md
index 9acd9040..dec7c6db 100644
--- a/config/index.md
+++ b/config/index.md
@@ -2,7 +2,7 @@
 outline: deep
 ---
 
-# 配置索引 {#configuring-vitest}
+# 配置 Vitest {#configuring-vitest}
 
 如果我们正在使用 Vite 并且拥有一个 `vite.config` 文件，Vitest 会读取它来匹配我们的 Vite 应用的插件和设置。如果我们想要为测试配置不同的设置，或者我们的并不特别依赖于 Vite，我们我们可以选择：
 
@@ -12,7 +12,7 @@ outline: deep
 
 要配置 Vitest 本身，请在我们的 Vite 配置中添加 `test` 属性。如果我们是从 `vite` 本身导入 `defineConfig`，我们还需要在配置文件顶部使用[三斜杠指令](https://www.typescriptlang.org/docs/handbook/triple-slash-directives.html#-reference-types-)添加对 Vitest 类型引用。
 
-::: details Open Config Examples
+::: details 打开配置示例
 使用 `vite` 中的 `defineConfig` 时使用以下步骤：
 
 ```ts [vite.config.js]
@@ -104,7 +104,7 @@ export default defineConfig({
 })
 ```
 
-由于 Vitest 使用 Vite 的配置，我们也可以使用 [Vite](https://vitejs.dev/config/) 中的任何配置选项。例如，使用 `define` 来定义全局变量，或者使用 `resolve.alias` 来定义别名——这些选项应该在顶级定义，而不是在 `test` 属性内部。
+由于 Vitest 使用 Vite 的配置，我们也可以使用 [Vite](https://vitejs.dev/config/) 中的任何配置选项。例如，使用 `define` 来定义全局变量，或者使用 `resolve.alias` 来定义别名，这些选项应该在顶级定义，而不是在 `test` 属性内部。
 
 在 [项目](/guide/projects) 配置里不被支持的选项，会在旁边标注 <NonProjectOption /> 。这表示这些选项只能在 Vitest 的根配置中进行设置。
 :::
@@ -113,6 +113,7 @@ export default defineConfig({
 
 - **类型:** `string[]`
 - **默认值:** `['**/*.{test,spec}.?(c|m)[jt]s?(x)']`
+- **命令行终端:** `vitest [...include], vitest **/*.test.js`
 
 匹配包含测试文件的 glob 规则。
 
@@ -123,11 +124,17 @@ export default defineConfig({
 ### exclude
 
 - **类型:** `string[]`
-- **默认值:** `['**/node_modules/**', '**/.git/**']`
-- **命令行终端:** `vitest --exclude "**/excluded-file" --exclude "*/other-files/*.js"`
+- **默认值:** `['**/node_modules/**', '**/dist/**', '**/cypress/**', '**/.{idea,git,cache,output,temp}/**', '**/{karma,rollup,webpack,vite,vitest,jest,ava,babel,nyc,cypress,tsup,build,eslint,prettier}.config.*']`
+- **命令行终端:** `vitest --exclude "**/excluded-file"`
 
 匹配排除测试文件的 glob 规则。
 
+::: warning
+该选项不会影响代码覆盖率。如需从覆盖率报告中排除特定文件，请使用 [`coverage.exclude`](#coverage-exclude)。
+
+如果使用命令行参数，这是唯一一个不会被覆盖配置的选项的参数。通过 `--exclude` 标志添加的所有 glob 规则都将追加到 `exclude` 中。
+:::
+
 ### includeSource
 
 - **类型:** `string[]`
@@ -192,7 +199,7 @@ Vite-Node 调试器选项。
 
 这些选项支持在 `node_modules` 中编写的包名称或在 [`deps.moduleDirectories`](#deps-moduledirectories) 中指定的包名称。例如，位于 `packages/some-name` 内的包`@company/some-name` 应指定为 `some-name`，并且 `packages` 应包含在 `deps.moduleDirectories` 中。基本上，Vitest 总是检查文件路径，而不是实际的包名称。
 
-如果成功匹配，Vitest 会在 _file path_ 上调用它，而不是包名称。
+如果使用正则匹配，Vitest 会在 _file path_ 上调用它，而不是包名称。
 
 #### server.deps.inline
 
@@ -225,10 +232,10 @@ Vite 将处理内联模块。这可能有助于处理以 ESM 格式传送 `.js`
 
 处理依赖关系解析。
 
-#### deps.optimizer {#deps-optimizer}
+#### deps.optimizer
 
 - **类型:** `{ ssr?, client? }`
-- **参考:** [Dep Optimization Options](https://vitejs.dev/config/dep-optimization-options.html)
+- **参考:** [依赖优化选项](https://vitejs.dev/config/dep-optimization-options.html)
 
 启用依赖优化。如果你有很多测试，这可能会提高它们的性能。
 
@@ -239,13 +246,7 @@ Vite 将处理内联模块。这可能有助于处理以 ESM 格式传送 `.js`
 - 你的 `alias` 配置现在在捆绑包中得到处理
 - 测试中的代码更接近于它在浏览器中的运行方式
 
-仅当包名出现在 `deps.optimizer?.[mode].include` 中时，才会被预打包（如 Svelte 等插件会自动填充）。完整选项见 [Vite 文档](https://cn.vitejs.dev/config/dep-optimization-options.html)（Vitest 暂不支持 `disable` 与 `noDiscovery`）。
-
-默认策略：
-
-- `jsdom` / `happy-dom` → `optimizer.client`
-
-- `node` / `edge` → `optimizer.ssr`
+请注意，只有 `deps.experimentalOptimizer?.[mode].include` 选项中的包会被捆绑（一些插件会自动填充它，比如 Svelte）。 你可以在 [Vite](https://cn.vitejs.dev/config/dep-optimization-options.html) 文档中阅读有关可用选项的更多信息。默认情况，Vitest 的 `experimentalOptimizer.web` 用在 `jsdom` 和 `happy-dom`, 在 `node` 和 `edge` 环境下使用 `experimentalOptimizer.ssr`，但这可以在 [`transformMode`](#transformmode) 进行配置。
 
 此选项还继承了你的 `optimizeDeps` 配置（对于 web 环境， Vitest 将会继承 `optimizeDeps`，对于 ssr 则是 `ssr.optimizeDeps`）。如果你在 `deps.experimentalOptimizer` 中重新定义 `include`/`exclude`/`entries` 选项，它将在运行测试时覆盖你的 `optimizeDeps`。如果它们在 `exclude` 中配置，Vitest 会自动从 `include` 中删除相同的选项。
 
@@ -260,27 +261,14 @@ Vite 将处理内联模块。这可能有助于处理以 ESM 格式传送 `.js`
 
 启用依赖优化。
 
-#### deps.client  {#deps-client}
-
-#### deps.web <Badge type="info">0.34.2+</Badge>
-
-仅当环境设为 `client` 时，下列选项才会作用于外部文件。
-
-默认映射：
-
-- `jsdom`、`happy-dom` → `client`
-
-- `node`、`edge` → `ssr`
-
-故这些选项对后者中的文件无效。
-
+#### deps.web
 - **类型:** `{ transformAssets?, ... }`
 
 当转换模式设置为 `web` 时应用于外部文件的选项。默认情况下，`jsdom` 和 `happy-dom` 使用 `web` 模式，而 `node` 和 `edge` 环境使用 `ssr` 转换模式，因此这些选项不会影响这些环境中的文件。
 
 通常，`node_modules` 内的文件是外部化的，但这些选项也会影响 [`server.deps.external`](#server-deps-external) 中的文件。
 
-#### deps.client.transformAssets
+#### deps.web.transformAssets
 
 - **类型:** `boolean`
 - **默认值:** `true`
@@ -293,7 +281,7 @@ Vitest 是否应该像 Vite 在浏览器中一样处理静态资源（.png、.sv
 目前，此选项适用于 [`vmThreads`](#vmthreads) 和 [`vmForks`](#vmForks) 池。
 :::
 
-#### deps.client.transformCss
+#### deps.web.transformCss
 
 - **类型:** `boolean`
 - **默认值:** `true`
@@ -306,7 +294,7 @@ Vitest 是否应该像 Vite 在浏览器中一样处理静态资源（.css, .scs
 目前，此选项仅适用于 [`vmThreads`](#vmthreads) 和 [`vmForks`](#vmForks) 池。
 :::
 
-#### deps.client.transformGlobPattern
+#### deps.web.transformGlobPattern
 
 - **类型:** `RegExp | RegExp[]`
 - **默认值:** `[]`
@@ -368,9 +356,9 @@ export default defineConfig({
 ### runner
 
 - **类型**: `VitestRunnerConstructor`
-- **默认值**: `node`, when running tests, or `benchmark`, when running benchmarks
+- **默认值**: 运行测试时为`node`，运行基准测试时为 `benchmark`
 
-自定义测试运行程序的路径。这是一项高级功能，应与自定义库运行器一起使用。你可以在 [文档](/advanced/runner) 中阅读更多相关信息。
+自定义测试运行器的路径。这是一项高级功能，应与自定义库运行器一起使用。你可以在 [文档](/advanced/runner) 中阅读更多相关信息。
 
 ### benchmark
 
@@ -431,7 +419,7 @@ git checkout feature
 vitest bench --compare main.json
 ```
 
-#### benchmark.compare {#benchmark-compare}
+#### benchmark.compare
 
 - **类型:** `string | undefined`
 - **默认值:** `undefined`
@@ -445,12 +433,12 @@ vitest bench --compare main.json
 在测试内部运行时定义自定义别名。它们将与来自 `resolve.alias` 的别名合并。
 
 ::: warning
-Vitest 使用 Vite SSR 基元来运行测试，这有[一定的缺陷](https://vitejs.dev/guide/ssr.html#ssr-externals)。
+Vitest 使用 Vite SSR 基元来运行测试，这有 [一定的缺陷](https://vitejs.dev/guide/ssr.html#ssr-externals)。
 
-1. 别名只影响由[inlined](#server-deps-inline)模块直接用`import`关键字导入的模块（默认情况下所有源代码都是内联的）。
+1. 别名只影响由 [inlined](#server-deps-inline) 模块直接用 `import` 关键字导入的模块（默认情况下所有源代码都是内联的）。
 2. Vitest 不支持对 `require` 调用进行别名。
 3. 如果我们要别名外部依赖（例如，`react` -> `preact`），我们可能需要别名实际的 `node_modules` 包，以使其适用于外部依赖。[Yarn](https://classic.yarnpkg.com/en/docs/cli/add/#toc-yarn-add-alias) 和 [pnpm](https://pnpm.io/aliases/) 都支持通过 `npm:` 前缀进行别名。
-   :::
+:::
 
 ### globals
 
@@ -583,7 +571,7 @@ export default <Environment>{
 Vitest 还通过 `vitest/environments` 入口导出 `builtinEnvironments`，以防你只想扩展它。 你可以在 [测试环境指南](/guide/environment) 中阅读有关扩展测试环境的更多信息。
 
 ::: tip
-jsdom 环境变量导出了等同于当前[JSDOM](https://github.com/jsdom/jsdom) 的 `jsdom` 全局变量实例。如果你想让 TypeScript 识别它，可以在使用此环境时将 `vitest/jsdom`添加到 `tsconfig.json` 中：
+jsdom 环境变量导出了等同于当前 [JSDOM](https://github.com/jsdom/jsdom) 的 `jsdom` 全局变量实例。如果你想让 TypeScript 识别它，可以在使用此环境时将 `vitest/jsdom`添加到 `tsconfig.json` 中：
 
 ```json [tsconfig.json]
 {
@@ -602,6 +590,101 @@ jsdom 环境变量导出了等同于当前[JSDOM](https://github.com/jsdom/jsdom
 
 这些选项被传递给当前 [`environment`](#environment) 的 `setup` 方法。 默认情况下，如果你将其用作测试环境，则只能配置 JSDOM 选项。
 
+### environmentMatchGlobs
+
+- **类型:** `[string, EnvironmentName][]`
+- **默认值:** `[]`
+
+::: danger DEPRECATED
+此 API 在 Vitest 3 中已弃用。请使用 [projects](/guide/projects) 来定义不同的配置。
+
+```ts
+export default defineConfig({
+  test: {
+    environmentMatchGlobs: [ // [!code --]
+      ['./*.jsdom.test.ts', 'jsdom'], // [!code --]
+    ], // [!code --]
+    workspace: [ // [!code ++]
+      { // [!code ++]
+        extends: true, // [!code ++]
+        test: { // [!code ++]
+          environment: 'jsdom', // [!code ++]
+        }, // [!code ++]
+      }, // [!code ++]
+    ], // [!code ++]
+  },
+})
+```
+:::
+
+基于 globs 自动匹配执行环境。将使用第一个匹配项。
+
+例如：
+
+```ts
+import { defineConfig } from 'vitest/config'
+
+export default defineConfig({
+  test: {
+    environmentMatchGlobs: [
+      // `tests/dom` 目录中的所有测试将在 jsdom 中运行。
+      ['tests/dom/**', 'jsdom'],
+      // `tests/` 目录中所有以 `.edge.test.ts` 结尾的测试将在 edge-runtime 中运行。
+      ['**/*.edge.test.ts', 'edge-runtime'],
+      // ...
+    ],
+  },
+})
+```
+
+### poolMatchGlobs
+
+- **类型:** `[string, 'threads' | 'forks' | 'vmThreads' | 'vmForks' | 'typescript'][]`
+- **默认值:** `[]`
+
+::: danger DEPRECATED
+此 API 在 Vitest 3 中已被弃用。请使用 [projects](/guide/projects) 来定义不同的配置：
+
+```ts
+export default defineConfig({
+  test: {
+    poolMatchGlobs: [ // [!code --]
+      ['./*.threads.test.ts', 'threads'], // [!code --]
+    ], // [!code --]
+    workspace: [ // [!code ++]
+      { // [!code ++]
+        test: { // [!code ++]
+          extends: true, // [!code ++]
+          pool: 'threads', // [!code ++]
+        }, // [!code ++]
+      }, // [!code ++]
+    ], // [!code ++]
+  },
+})
+```
+:::
+
+基于 globs 模式来匹配运行池中的测试并运行，将使用第一个匹配项。
+
+例如:
+
+```ts
+import { defineConfig } from 'vitest/config'
+
+export default defineConfig({
+  test: {
+    poolMatchGlobs: [
+      // all tests in "worker-specific" directory will run inside a worker as if you enabled `--pool=threads` for them,
+      ['**/tests/worker-specific/**', 'threads'],
+      // run all tests in "browser" directory in an actual browser
+      ['**/tests/browser/**', 'browser'],
+      // all other tests will run based on "browser.enabled" and "threads" options, if you didn't specify other globs
+      // ...
+    ],
+  },
+})
+```
+
 ### update<NonProjectOption />
 
 - **类型:** `boolean`
@@ -673,17 +756,7 @@ export default defineConfig({
 - **默认值:** `'default'`
 - **命令行终端:** `--reporter=<name>`, `--reporter=<name1> --reporter=<name2>`
 
-用于输出的自定义 reporters 。 Reporters 可以是 [一个 Reporter 实例](https://github.com/vitest-dev/vitest/blob/main/packages/vitest/src/node/types/reporter.ts) 或选择内置的 reporters 字符串：
-
-- `'default'` - 当他们经过测试套件
-- `'basic'` - 给定一个类似于 CI 中的默认报告实例
-- `'verbose'` - 保持完整的任务树可见
-- `'dot'` - 将每个任务显示为一个点
-- `'junit'` - JUnit XML 报告器（你可以使用 `VITEST_JUNIT_SUITE_NAME` 环境变量配置 `test suites` 标签名称）
-- `'json'` - 给出一个简单的 JSON 总结
-- `'html'` - 根据 [`@vitest/ui`](/guide/ui) 输出 HTML 报告
-- `'hanging-process'` - 如果 Vitest 无法安全退出进程，则显示挂起进程列表。 这可能是一个复杂的操作，只有在 Vitest 始终无法退出进程时才启用它
-- 自定义报告的路径 (例如 `'./path/to/reporter.ts'`, `'@scope/reporter'`)
+自定义 [报告器](/guide/reporters) 输出。报告器可以是 [Reporter 实例](https://github.com/vitest-dev/vitest/blob/main/packages/vitest/src/node/types/reporter.ts)、用于选择内置报告器的字符串，或自定义实现的路径（例如 `./path/to/reporter.ts`、`@scope/reporter`）。
 
 ### outputFile<NonProjectOption />
 
@@ -692,7 +765,7 @@ export default defineConfig({
 
 当指定 `--reporter=json`、`--reporter=html` 或 `--reporter=junit` 时，将测试结果写入一个文件。通过提供对象而不是字符串，你可以在使用多个报告器时定义单独的输出。
 
-### pool<NonProjectOption /> {#pool}
+### pool<NonProjectOption />
 
 - **类型:** `'threads' | 'forks' | 'vmThreads' | 'vmForks'`
 - **默认值:** `'forks'`
@@ -710,9 +783,9 @@ export default defineConfig({
 
 #### vmThreads<NonProjectOption />
 
-在 `threads` 线程池中使用[ VM 上下文](https://nodejs.org/api/vm.html)（在受限环境中）运行测试。
+在 `threads` 线程池中使用 [VM 上下文](https://nodejs.org/api/vm.html)（在沙箱环境中）运行测试。
 
-这样可以加快测试速度，但是当运行[ ESM 代码](https://github.com/nodejs/node/issues/37648)时，VM 模块可能不稳定。你的测试可能会[泄漏内存](https://github.com/nodejs/node/issues/33439)，为了解决这个问题，考虑手动编辑 [`poolOptions.vmThreads.memoryLimit`](#pooloptions-vmthreads-memorylimit) 的值。
+这样可以加快测试速度，但是当运行 [ESM 代码](https://github.com/nodejs/node/issues/37648) 时，VM 模块可能不稳定。你的测试可能会 [泄漏内存](https://github.com/nodejs/node/issues/33439)，为了解决这个问题，考虑手动编辑 [`poolOptions.vmThreads.memoryLimit`](#pooloptions-vmthreads-memorylimit) 的值。
 
 ::: warning
 在沙箱中运行代码有一些优点（测试速度更快），但也有许多缺点。
@@ -738,14 +811,14 @@ catch (err) {
 
 与 `vmThreads` 池类似，但通过 [tinypool](https://github.com/tinylibs/tinypool) 使用 `child_process` 而不使用 `worker_threads`。测试与主进程之间的通信速度虽然不如 `vmThreads` 快。但进程相关的 API（如 `process.chdir()` ）在 `vmForks` 中却可以使用。请注意，这个与 `vmThreads` 中列出的池具有相同的缺陷。
 
-### poolOptions<NonProjectOption /> {#pooloptions}
+### poolOptions<NonProjectOption />
 
 - **类型:** `Record<'threads' | 'forks' | 'vmThreads' | 'vmForks', {}>`
 - **默认值:** `{}`
 
 #### poolOptions.threads
 
-`threads` 池的选项。
+`threads` 池相关选项。
 
 ```ts
 import { defineConfig } from 'vitest/config'
@@ -764,10 +837,17 @@ export default defineConfig({
 ##### poolOptions.threads.maxThreads<NonProjectOption />
 
 - **类型:** `number | string`
-- **默认值:** _available CPUs_
+- **默认值:** _可用 CPU 核心数_
 
 最大线程数或百分比。还可以使用`VITEST_MAX_THREADS`环境变量进行设置。
 
+##### poolOptions.threads.minThreads<NonProjectOption />
+
+- **类型:** `number | string`
+- **默认值:** _可用 CPU 核心数_
+
+最小线程数或百分比。还可以使用`VITEST_MIN_THREADS`环境变量进行设置。
+
 ##### poolOptions.threads.singleThread
 
 - **类型:** `boolean`
@@ -810,7 +890,7 @@ export default defineConfig({
 
 #### poolOptions.forks
 
-`forks` 池的选项。
+`forks` 池相关选项。
 
 ```ts
 import { defineConfig } from 'vitest/config'
@@ -829,10 +909,17 @@ export default defineConfig({
 ##### poolOptions.forks.maxForks<NonProjectOption />
 
 - **类型:** `number | string`
-- **默认值:** _available CPUs_
+- **默认值:** _可用 CPU 核心数_
 
 最大分支数量或百分比。你也可以使用 `VITEST_MAX_FORKS` 环境变量。
 
+##### poolOptions.forks.minForks<NonProjectOption />
+
+- **类型:** `number | string`
+- **默认值:** _可用 CPU 核心数_
+
+最小分支数量或百分比。你也可以使用 `VITEST_MIN_FORKS` 环境变量。
+
 ##### poolOptions.forks.isolate
 
 - **类型:** `boolean`
@@ -866,7 +953,7 @@ export default defineConfig({
 
 #### poolOptions.vmThreads
 
-`vmThreads` 池的选项。
+`vmThreads` 池相关选项。
 
 ```ts
 import { defineConfig } from 'vitest/config'
@@ -885,10 +972,17 @@ export default defineConfig({
 ##### poolOptions.vmThreads.maxThreads<NonProjectOption />
 
 - **类型:** `number | string`
-- **默认:** _available CPUs_
+- **默认值:** _可用 CPU 核心数_
 
 最大线程数或百分比。还可以使用`VITEST_MAX_THREADS`环境变量进行设置。
 
+##### poolOptions.vmThreads.minThreads<NonProjectOption />
+
+- **类型:** `number | string`
+- **默认值:** _可用 CPU 核心数_
+
+最小线程数或百分比。还可以使用`VITEST_MAX_THREADS`环境变量进行设置。
+
 ##### poolOptions.vmThreads.memoryLimit<NonProjectOption />
 
 - **类型:** `string | number`
@@ -906,15 +1000,17 @@ export default defineConfig({
 - 有单位时
   - `50%` - 如上，占系统总内存的百分比
   - `100KB`, `65MB`, 等 - 用单位表示固定的内存限制
-    - `K` / `KB` - Kilobytes (x1000)
-    - `KiB` - Kibibytes (x1024)
-    - `M` / `MB` - Megabytes - `MiB` - Mebibytes
-    - `G` / `GB` - Gigabytes - `GiB` - Gibibytes
+    - `K` / `KB` - 千字节 (x1000)
+    - `KiB` - 千字节 (x1024)
+    - `M` / `MB`- 千字节
+    - `MiB` - 兆字节
+    - `G` / `GB` - 千兆字节
+    - `GiB` - 千兆字节
 
 :::
 
 ::: warning
-由于系统内存报告不正确，基于百分比的内存限制[在 Linux CircleCI 上不起作用](https://github.com/jestjs/jest/issues/11956#issuecomment-1212925677)。
+由于系统内存报告不正确，基于百分比的内存限制 [在 Linux CircleCI 上不起作用](https://github.com/jestjs/jest/issues/11956#issuecomment-1212925677)。
 :::
 
 ##### poolOptions.vmThreads.useAtomics<NonProjectOption />
@@ -939,7 +1035,7 @@ export default defineConfig({
 
 #### poolOptions.vmForks<NonProjectOption />
 
-`vmForks` 池的选项
+`vmForks` 池相关选项
 
 ```ts
 import { defineConfig } from 'vitest/config'
@@ -958,10 +1054,17 @@ export default defineConfig({
 ##### poolOptions.vmForks.maxForks<NonProjectOption />
 
 - **类型:** `number | string`
-- **默认值:** _available CPUs_
+- **默认值:** _可用 CPU 核心数_
 
 最大线程数或百分比。你也可以使用 `VITEST_MAX_FORKS` 环境变量。
 
+##### poolOptions.vmForks.minForks<NonProjectOption />
+
+- **类型:** `number | string`
+- **默认值:** _可用 CPU 核心数_
+
+最小线程数或百分比。你也可以使用 `VITEST_MIN_FORKS` 环境变量。
+
 ##### poolOptions.vmForks.memoryLimit<NonProjectOption />
 
 - **类型:** `string | number`
@@ -980,7 +1083,7 @@ export default defineConfig({
 使用时要小心，因为某些选项（如 `--prof` 、`--title`）可能会导致 worker 崩溃。查看 https://github.com/nodejs/node/issues/41103 了解更多详情。
 :::
 
-### fileParallelism<NonProjectOption /> {#fileparallelism}
+### fileParallelism<NonProjectOption />
 
 - **类型:** `boolean`
 - **默认值:** `true`
@@ -989,19 +1092,25 @@ export default defineConfig({
 所有测试文件应该并行运行。将其设置为 `false` 将覆盖 `maxWorkers` 和 `minWorkers` 选项为 `1`。
 
 ::: tip
-此选项不会影响在同一文件中运行的测试。如果你想并行运行这些程序，请在[description](/api/#describe-concurrent)或通过[a config](#sequence-concurrent) 上使用 `concurrent` 选项。
+此选项不会影响在同一文件中运行的测试。如果你想并行运行这些程序，请在 [description](/api/#describe-concurrent) 或通过 [配置](#sequence-concurrent) 上使用 `concurrent` 选项。
 :::
 
-### maxWorkers<NonProjectOption /> {#maxworkers}
+### maxWorkers<NonProjectOption />
 
 - **类型:** `number | string`
 
 运行测试时设置的最大工作线程数或百分比。`poolOptions。｛threads，vmThreads｝.maxThreads `/`poolOptions.forks.maxForks` 具有更高的优先级。
 
+### minWorkers<NonProjectOption />
+
+- **类型:** `number | string`
+
+运行测试时设置的最小工作线程数或百分比。`poolOptions.{threads,vmThreads}.minThreads`/`poolOptions.forks.minForks` 具有更高的优先级。
+
 ### testTimeout
 
 - **类型:** `number`
-- **默认值:** `5_000` in Node.js, `15_000` if `browser.enabled` is `true`
+- **默认值:** 在 Node.js 环境下为 `5_000`，当 browser.enabled 为 `true` 时为 `15_000`
 - **命令行终端:** `--test-timeout=5000`, `--testTimeout=5000`
 
 测试的默认超时时间（以毫秒为单位）。使用 `0` 完全禁用超时。
@@ -1009,7 +1118,7 @@ export default defineConfig({
 ### hookTimeout
 
 - **类型:** `number`
-- **默认值:** `10_000` in Node.js, `30_000` if `browser.enabled` is `true`
+- **默认值:** 在 Node.js 环境下为 `10_000`，当 browser.enabled 为 `true` 时为 `30_000`
 - **命令行终端:** `--hook-timeout=10000`, `--hookTimeout=10000`
 
 钩子(hook)的默认超时时间（以毫秒为单位）。使用 `0` 完全禁用超时。
@@ -1036,7 +1145,7 @@ Vitest 关闭时等待关闭的默认超时时间，以毫秒为单位
 
 - **类型:** `string | string[]`
 
-setup 文件的路径。它们将运行在每个测试文件之前。
+setup 文件的路径。它们将在每个测试文件之前运行。
 
 ::: info 提示
 编辑设置文件将自动触发所有测试的重新运行。
@@ -1094,8 +1203,10 @@ test('api key is defined', () => {
 ```
 :::
 
+可以参考 如何在覆盖率报告中包含或排除文件 里的示例。
+
 ::: warning
-属性必须是字符串，值必须是[可序列化](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm#supported_types)，因为该对象将在不同进程之间传输。
+属性必须是字符串，值必须是 [可序列化](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm#supported_types)，因为该对象将在不同进程之间传输。
 :::
 
 ::: tip
@@ -1225,7 +1336,6 @@ npx vitest --coverage.enabled --coverage.provider=istanbul
 - **命令行终端:** `--coverage.enabled`, `--coverage.enabled=false`
 
 是否启用收集测试覆盖率。可以使用 `--coverage` 覆盖 CLI 选项。
-
 #### coverage.include
 
 - **类型:** `string[]`
@@ -1233,20 +1343,74 @@ npx vitest --coverage.enabled --coverage.provider=istanbul
 - **可用的测试提供者:** `'v8' | 'istanbul'`
 - **命令行终端:** `--coverage.include=<pattern>`, `--coverage.include=<pattern1> --coverage.include=<pattern2>`
 
-以 glob 模式指定需要统计覆盖率的文件列表。默认情况下，只有被测试实际执行到的文件会被纳入覆盖率统计。
+以 glob 模式指定需要统计覆盖率的文件列表。
 
-建议在 glob 模式中明确包含文件扩展名。
+#### coverage.extension
 
-可以参考 [如何在覆盖率报告中包含或排除文件](/guide/coverage.html#including-and-excluding-files-from-coverage-report) 里的示例。
+- **类型:** `string | string[]`
+- **默认值:** `['.js', '.cjs', '.mjs', '.ts', '.mts', '.tsx', '.jsx', '.vue', '.svelte', '.marko', '.astro']`
+- **可用的测试提供者:** `'v8' | 'istanbul'`
+- **命令行终端:** `--coverage.extension=<extension>`, `--coverage.extension=<extension1> --coverage.extension=<extension2>`
 
 #### coverage.exclude
 
 - **类型:** `string[]`
-- **默认值:** : `[]`
+- **默认值:**
+
+```js
+[
+  'coverage/**',
+  'dist/**',
+  '**/node_modules/**',
+  '**/[.]**',
+  'packages/*/test?(s)/**',
+  '**/*.d.ts',
+  '**/virtual:*',
+  '**/__x00__*',
+  '**/\x00*',
+  'cypress/**',
+  'test?(s)/**',
+  'test?(-*).?(c|m)[jt]s?(x)',
+  '**/*{.,-}{test,spec,bench,benchmark}?(-d).?(c|m)[jt]s?(x)',
+  '**/__tests__/**',
+  '**/{karma,rollup,webpack,vite,vitest,jest,ava,babel,nyc,cypress,tsup,build,eslint,prettier}.config.*',
+  '**/vitest.{workspace,projects}.[jt]s?(on)',
+  '**/.{eslint,mocha,prettier}rc.{?(c|m)js,yml}',
+]
+```
+
 - **可用的测试提供者:** `'v8' | 'istanbul'`
 - **命令行终端:** `--coverage.exclude=<path>`, `--coverage.exclude=<path1> --coverage.exclude=<path2>`
 
-想要查看示例，请参考 [如何在覆盖率报告中包含或排除文件](/guide/coverage.html#including-and-excluding-files-from-coverage-report)。
+使用全局模式排除在覆盖范围之外的文件列表。
+
+该选项覆盖所有默认选项。添加新的忽略模式时，扩展默认选项：
+
+```ts
+import { coverageConfigDefaults, defineConfig } from 'vitest/config'
+
+export default defineConfig({
+  test: {
+    coverage: {
+      exclude: ['**/custom-pattern/**', ...coverageConfigDefaults.exclude],
+    },
+  },
+})
+```
+
+::: tip NOTE
+Vitest 会自动将测试文件的 `include` 模式添加到 `coverage.exclude` 中。
+无法显示测试文件的覆盖率。
+:::
+
+#### coverage.all
+
+- **类型:** `boolean`
+- **默认值:** `true`
+- **可用的测试提供者:** `'v8' | 'istanbul'`
+- **命令行终端:** `--coverage.all`, `--coverage.all=false`
+
+是否将所有文件（包括未测试的文件）包括在报告中。
 
 #### coverage.clean
 
@@ -1279,7 +1443,7 @@ npx vitest --coverage.enabled --coverage.provider=istanbul
 
 配置测试覆盖率报告写入的目录。
 
-要预览覆盖范围报告，请使用 [HTML reporter](/guide/reporters.html#html-reporter), 该选项必须设置为 html 报告目录的子目录 (比如 `./html/coverage`).
+要预览覆盖范围报告，请使用 [HTML 报告器](/guide/reporters.html#html-reporter), 该选项必须设置为 html 报告目录的子目录 (比如 `./html/coverage`).
 
 #### coverage.reporter
 
@@ -1306,7 +1470,7 @@ npx vitest --coverage.enabled --coverage.provider=istanbul
   }
   ```
 
-我们还可以传递自定义覆盖报告器。查看[自定义覆盖报告器](/guide/coverage#%E8%87%AA%E5%AE%9A%E4%B9%89%E8%A6%86%E7%9B%96%E7%8E%87%E6%8F%90%E4%BE%9B%E8%80%85)了解更多详情。
+我们还可以传递自定义覆盖报告器。查看 [自定义覆盖率的报告器](/guide/coverage#custom-coverage-reporter) 了解更多详情。
 
 <!-- eslint-skip -->
 
@@ -1324,9 +1488,9 @@ npx vitest --coverage.enabled --coverage.provider=istanbul
 }
 ```
 
-我们可以在 Vitest UI 中查看覆盖率报告：查看 [Vitest UI Coverage](/guide/coverage#vitest-ui) 了解更多详情。
+我们可以在 Vitest UI 中查看覆盖率报告：查看 [UI 模式](/guide/coverage#vitest-ui) 了解更多详情。
 
-#### coverage.reportOnFailure {#coverage-reportonfailure}
+#### coverage.reportOnFailure
 
 - **类型:** `boolean`
 - **默认值:** `false`
@@ -1439,23 +1603,6 @@ statements 的全局阈值。
 如果当前覆盖率优于配置的阈值时，将所有阈值 `lines`、`functions`、`branches` 和 `statements` 更新到配置文件中。
 此选项有助于在覆盖率提高时保持阈值不变。
 
-你还可以传递一个函数来格式化更新的阈值：
-
-<!-- eslint-skip -->
-```ts
-{
-  coverage: {
-    thresholds: {
-      // 更新不带小数的阈值
-      autoUpdate: (newThreshold) => Math.floor(newThreshold),
-
-      // 95.85 -> 95
-      functions: 95,
-    }
-  }
-}
-```
-
 ##### coverage.thresholds.100
 
 - **类型:** `boolean`
@@ -1532,6 +1679,47 @@ Vitest 会将所有文件，包括那些被 glob 模式覆盖的文件，计入
 }
 ```
 
+#### coverage.ignoreEmptyLines
+
+- **类型:** `boolean`
+- **默认值:** `true` (`false` in v1)
+- **可用的测试提供者:** `'v8'`
+- **命令行终端:** `--coverage.ignoreEmptyLines=<boolean>`
+
+忽略空行、注释和其他非运行时代码，如 Typescript 类型。
+
+该选项只有在使用的编译器删除了转译代码中的注释和其他非运行时代码时才有效。
+默认情况下，Vite 使用 ESBuild，它会删除 `.ts`、`.tsx` 和 `.jsx` 文件中的注释和 Typescript 类型。
+
+如果还想将 ESBuild 应用于其他文件，请在 [`esbuild` 选项](https://cn.vitejs.dev/config/shared-options.html#esbuild) 中定义它们：
+
+```ts
+import { defineConfig } from 'vitest/config'
+
+export default defineConfig({
+  esbuild: {
+    // 使用 ESBuild 转换所有文件以删除代码覆盖率中的注释。
+    // `test.coverage.ignoreEmptyLines` 需要工作：
+    include: ['**/*.js', '**/*.jsx', '**/*.mjs', '**/*.ts', '**/*.tsx'],
+  },
+  test: {
+    coverage: {
+      provider: 'v8',
+      ignoreEmptyLines: true,
+    },
+  },
+})
+```
+
+#### coverage.experimentalAstAwareRemapping
+
+- **Type:** `boolean`
+- **Default:** `false`
+- **Available for providers:** `'v8'`
+- **CLI:** `--coverage.experimentalAstAwareRemapping=<boolean>`
+
+基于实验性 AST 分析的覆盖率重映射。相比默认模式能提供更精确的结果。
+
 #### coverage.ignoreClassMethods
 
 - **类型:** `string[]`
@@ -1587,7 +1775,7 @@ Vitest 会将所有文件，包括那些被 glob 模式覆盖的文件，计入
 - **可用的测试提供者:** `'custom'`
 - **命令行终端:** `--coverage.customProviderModule=<path or module name>`
 
-指定自定义覆盖率提供者的模块名称或路径。有关详细信息，请参阅[指南 - 自定义覆盖率提供者](/guide/coverage#custom-coverage-provider)。
+指定自定义覆盖率提供者的模块名称或路径。有关详细信息，请参阅 [指南 - 自定义覆盖率提供者](/guide/coverage#custom-coverage-provider)。
 
 ### testNamePattern<NonProjectOption />
 
@@ -1627,12 +1815,12 @@ test('doNotRun', () => {
 
 提供 API 服务的端口。当设置为 true 时，默认端口为 51204
 
-### browser <Badge type="warning">experimental</Badge> {#browser}
+### browser <Badge type="warning">实验性</Badge> {#browser}
 
 - **默认值:** `{ enabled: false }`
 - **命令行终端:** `--browser=<name>`, `--browser.name=chrome --browser.headless`
 
-运行浏览器测试的配置。请参阅[“浏览器配置参考”](/guide/browser/config)。
+运行浏览器测试的配置。请参阅 [“浏览器配置参考”](/guide/browser/config)。
 
 ::: warning
 这是一项实验性功能。重大更改可能不会遵循 semver，请在使用时锁定 Vitest 的版本。
@@ -1643,41 +1831,64 @@ test('doNotRun', () => {
 - **类型:** `boolean`
 - **默认值:** `false`
 
-每个测试开始前自动调用 [`vi.clearAllMocks()`](/api/vi#vi-clearallmocks)，仅清除 mock 调用记录，不影响其实现。
+每次测试前，会对所有监听对象调用 [`.mockClear()`](/api/mock#mockclear)。这将清除模拟历史记录，但不会影响模拟实现。
 
 ### mockReset
 
 - **类型:** `boolean`
 - **默认值:** `false`
 
-每个测试开始前自动调用 [`vi.resetAllMocks()`](/api/vi#vi-resetallmocks)，既清空 mock 调用记录，又将所有实现重置。
+每次测试前，都会对所有监听对象调用 [`.mockReset()`](/api/mock#mockreset)。这将清除模拟历史记录，并将每个实现重置为其原始状态。
 
 ### restoreMocks
 
 - **类型:** `boolean`
 - **默认值:** `false`
 
-每个测试开始前自动调用 [`vi.restoreAllMocks()`](/api/vi#vi-restoreallmocks)，恢复所有由 [`vi.spyOn`](#vi-spyon) 创建的 spy 的原始实现。
+每次测试前，都会对所有监听对象调用 [`.mockRestore()`](/api/mock#mockrestore)。
+这将清除模拟历史记录，将每个实现恢复为原始实现，并恢复被监视对象的原始描述符。
 
-### unstubEnvs {#unstubenvs}
+### unstubEnvs
 
 - **类型:** `boolean`
 - **默认值:** `false`
 
 将在每次测试前调用 [`vi.unstubAllEnvs`](/api/#vi-unstuballenvs)。
 
-### unstubGlobals {#unstubglobals}
+### unstubGlobals
 
 - **类型:** `boolean`
 - **默认值:** `false`
 
 将在每次测试前调用 [`vi.unstubAllGlobals`](/api/#vi-unstuballglobals)。
 
+### testTransformMode
+
+- **类型:** `{ web?, ssr? }`
+
+确定与测试中的 glob 模式匹配的所有导入模块的转换方法。默认情况下，依赖于环境。例如，使用 JSDOM 环境的测试将处理所有带有 `ssr: false` 标志的文件，而使用 Node 环境的测试将处理所有带有 `ssr: true` 的模块。
+
+#### testTransformMode.ssr
+
+- **类型:** `string[]`
+- **默认值:** `[]`
+
+对指定的文件使用 SSR 转换管道。<br>
+Vite 插件在处理这些文件时会收到 `ssr: true` 标志。
+
+#### testTransformMode.web
+
+- **类型:** `string[]`
+- **默认值:** `[]`
+
+首先会进行正常的转换流程（针对浏览器环境），然后进行 SSR 重写以在 Node 中运行代码。<br>
+Vite 插件在处理这些文件时会收到 `ssr: false` 标志。
+
 ### snapshotFormat<NonProjectOption />
 
 - **类型:** `PrettyFormatOptions`
 
-快照测试的格式选项。这些选项被传递给我们 fork 的 [`pretty-format`](https://www.npmjs.com/package/pretty-format)。除了 `pretty-format` 选项外，我们还支持 `printShadowRoot: boolean`。
+快照测试的格式选项。这些选项被传递给 [`pretty-format`](https://www.npmjs.com/package/pretty-format)。
 
 ::: tip
 请注意，此对象上的 `plugins` 字段将被忽略。
@@ -1685,17 +1896,17 @@ test('doNotRun', () => {
 如果你需要通过 pretty-format 插件扩展快照序列器，请使用 [`expect.addSnapshotSerializer`](/api/expect#expect-addsnapshotserializer) 或 [snapshotSerializers](#snapshotserializers) 选项。
 :::
 
-### snapshotSerializers<NonProjectOption /> {#snapshotserializers}
+### snapshotSerializers<NonProjectOption />
 
 - **类型:** `string[]`
 - **默认值:** `[]`
 
-快照测试的快照序列化程序模块的路径列表，如果要添加自定义快照序列化器，则非常有用。有关详细信息，请参阅[自定义序列化器](/guide/snapshot#custom-serializer)。
+快照测试的快照序列化程序模块的路径列表，如果要添加自定义快照序列化器，则非常有用。有关详细信息，请参阅 [自定义序列化器](/guide/snapshot#custom-serializer)。
 
 ### resolveSnapshotPath<NonProjectOption />
 
 - **类型**: `(testPath: string, snapExtension: string, context: { config: SerializedConfig }) => string`
-- **默认值**: stores snapshot files in `__snapshots__` directory
+- **默认值**: 将快照文件存储在 `__snapshots__` 目录中
 
 覆盖快照的默认路径。例如，要在测试文件旁边存储一下快照：
 
@@ -1848,9 +2059,9 @@ npx vitest --sequence.shuffle --sequence.seed=1000
 #### groupOrder <Version>3.2.0</Version> {#grouporder}
 
 - **类型：** `number`
-- **Default:** `0`
+- **默认值:** `0`
 
-控制使用多个[项目](/guide/projects) 时该项目运行测试的顺序。
+控制使用多个 [项目](/guide/projects) 时该项目运行测试的顺序。
 
 - 具有相同组序号的项目将一起运行，并且组从低到高运行。
 - 如果不设置此选项，所有项目将并行运行。
@@ -1859,7 +2070,7 @@ npx vitest --sequence.shuffle --sequence.seed=1000
 此设置仅影响项目运行的顺序，而不影响项目中测试的顺序。
 要控制项目内的测试隔离或测试顺序，请使用 [`isolate`](#isolate) 和 [`sequence.sequencer`](#sequence-sequencer) 选项。
 
-::: 详细信息示例
+::: details 示例
 考虑这个例子：
 
 ```ts
@@ -1900,11 +2111,11 @@ export default defineConfig({
 这些项目中的测试将按以下顺序运行：
 
 ```
- 0. slow  |
+ 1. slow  |
           |> 一起运行
- 0. fast  |
+ 2. fast  |
 
- 1. flaky |> 在 slow 和 fast 之后单独运行
+ 3. flaky |> 在 slow 和 fast 之后单独运行
 ```
 :::
 
@@ -1916,29 +2127,25 @@ export default defineConfig({
 
 如果你希望测试随机运行，可以使用此选项或 CLI 参数 [`--sequence.shuffle`](/guide/cli) 启用它。
 
-Vitest 通常使用缓存对测试进行排序，因此长时间运行的测试会更早开始 - 这会使测试运行得更快。 如果你的测试将以随机顺序运行，你将失去这种性能改进，但跟踪意外依赖于先前运行的测试可能很有用。
-
-- **类型**: `boolean | { files?, tests? }`
-- **默认值**: `false`
-- **命令行终端**: `--sequence.shuffle`, `--sequence.shuffle=false`
+Vitest 通常使用缓存对测试进行排序，因此长时间运行的测试会更早开始，这会使测试运行得更快。如果你的测试将以随机顺序运行，你将失去这种性能改进，但跟踪意外依赖于先前运行的测试可能很有用。
 
-#### sequence.shuffle.files {#sequence-shuffle-files}
+#### sequence.shuffle.files
 
 - **类型**: `boolean`
 - **默认值**: `false`
 - **命令行终端**: `--sequence.shuffle.files`, `--sequence.shuffle.files=false`
 
-是否随机化文件，注意如果启用此选项，长时间运行的测试将不会提前启动。
+是否随机执行测试文件顺序。请注意，若启用此选项，耗时较长的测试将不会提前开始执行。
 
-#### sequence.shuffle.tests {#sequence-shuffle-tests}
+#### sequence.shuffle.tests
 
 - **类型**: `boolean`
 - **默认值**: `false`
 - **命令行终端**: `--sequence.shuffle.tests`, `--sequence.shuffle.tests=false`
 
-是否随机测试。
+是否随机执行测试顺序。
 
-#### sequence.concurrent {#sequence-concurrent}
+#### sequence.concurrent
 
 - **类型**: `boolean`
 - **默认值**: `false`
@@ -1970,7 +2177,7 @@ Vitest 通常使用缓存对测试进行排序，因此长时间运行的测试
 该选项不会影响 [`onTestFinished`](/api/#ontestfinished)。它总是以相反的顺序调用。
 :::
 
-#### sequence.setupFiles {#sequence-setupfiles}
+#### sequence.setupFiles
 
 - **类型**: `'list' | 'parallel'`
 - **默认值**: `'parallel'`
@@ -1983,17 +2190,17 @@ Vitest 通常使用缓存对测试进行排序，因此长时间运行的测试
 
 ### typecheck
 
-用于配置 [typechecking](/guide/testing-types) 测试环境的选项。
+[类型测试](/guide/testing-types) 测试环境的配置选项。
 
-#### typecheck.enabled {#typecheck-enabled}
+#### typecheck.enabled
 
 - **类型**: `boolean`
 - **默认值**: `false`
 - **命令行终端**: `--typecheck`, `--typecheck.enabled`
 
-常规测试时是否进行类型检查。
+在常规测试的同时启用类型检查。
 
-#### typecheck.only {#typecheck-only}
+#### typecheck.only
 
 - **类型**: `boolean`
 - **默认值**: `false`
@@ -2065,9 +2272,9 @@ Vitest 通常使用缓存对测试进行排序，因此长时间运行的测试
 - **默认值**: `300`
 - **命令行终端:**:`--slow-test-threshold=<number>`, `--slowTestThreshold=<number>`
 
-如果测试被认为是缓慢的，那么会在报告结果中显示毫秒值。
+测试或测试套件执行超过该毫秒数即被视为缓慢，并在结果中相应标注。
 
-### chaiConfig {#chaiconfig}
+### chaiConfig
 
 - **类型:** `{ includeStack?, showDiff?, truncateThreshold? }`
 - **默认值:** `{ includeStack: false, showDiff: true, truncateThreshold: 40 }`
@@ -2097,7 +2304,7 @@ Vitest 通常使用缓存对测试进行排序，因此长时间运行的测试
 
 此配置选项影响在 `test.each` 标题和断言错误消息中截断值的方式。
 
-### bail {#bail}
+### bail
 
 - **类型:** `number`
 - **默认值:** `0`
@@ -2107,7 +2314,7 @@ Vitest 通常使用缓存对测试进行排序，因此长时间运行的测试
 
 默认情况下，即使其中一些测试失败，Vitest 也会运行你的所有测试用例。这可能不适用于 CI 构建，你只对 100% 成功的构建感兴趣，并且希望在测试失败时尽早停止测试执行。`bail` 选项可用于通过在发生故障时防止运行更多测试来加速 CI 运行。
 
-### retry {#retry}
+### retry
 
 - **类型:** `number`
 - **默认值:** `0`
@@ -2141,7 +2348,7 @@ export default defineConfig({
 })
 ```
 
-### onStackTrace<NonProjectOption /> {#onstacktrace}
+### onStackTrace<NonProjectOption />
 
 - **类型**: `(error: Error, frame: ParsedStack) => boolean | void`
 
@@ -2170,30 +2377,6 @@ export default defineConfig({
 })
 ```
 
-### onUnhandledError<NonProjectOption /> {#onunhandlederror}
-
-- **类型：** `(error: (TestError | Error) & { type: string }) => boolean | void`
-
-自定义处理程序，用于过滤掉不应报告的未处理错误。 如果过滤掉错误，则不会再影响测试结果。
-
-如果你希望报告未处理的错误而不影响测试结果，可以考虑使用 [`dangerouslyIgnoreUnhandledErrors`](#dangerouslyIgnoreUnhandledErrors) 选项
-
-```ts
-import type { ParsedStack } from 'vitest'
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    onUnhandledError(error): boolean | void {
-      // 忽略名为 “MySpecialError” 的所有错误。
-      if (error.name === 'MySpecialError') {
-        return false
-      }
-    },
-  },
-})
-```
-
 ### diff
 
 - **类型:** `string`
@@ -2341,7 +2524,31 @@ Expand all common lines.
 
 通过委托各自的处理程序，告诉假冒计时器清除 "native"（即非假冒）计时器。禁用时，如果计时器在启动假计时器会话之前已经存在，则可能导致意外行为。
 
-### projects<NonProjectOption /> {#projects}
+### workspace<NonProjectOption />
+
+- **类型:** `string | TestProjectConfiguration`
+- **命令行终端:** `--workspace=./file.js`
+- **默认值:** `vitest.{workspace,projects}.{js,ts,json}` close to the config file or root
+
+相对于[root](#root) 的 [workspace](/guide/workspace) 配置文件的路径。
+
+Since Vitest 3, you can also define the workspace array in the root config. If the `workspace` is defined in the config manually, Vitest will ignore the `vitest.workspace` file in the root.
+
+### workspace<NonProjectOption />
+
+::: danger 弃用
+此选项已弃用，将在下一个主要版本中移除。请改用 [`projects`](#projects)。
+:::
+
+- **类型:** `string | TestProjectConfiguration`
+- **命令行终端:** `--workspace=./file.js`
+- **默认值:** 配置文件或根目录附近的 `vitest.{workspace,projects}.{js,ts,json}` 文件
+
+相对于 [root](#root) 的 [workspace](/guide/projects) 配置文件路径。
+
+从 Vitest 3 起，您也可以在根配置中定义 workspace 数组。如果手动在配置中定义了 `workspace`，Vitest 将忽略根目录下的 `vitest.workspace` 文件。
+
+### projects<NonProjectOption />
 
 - **类型:** `TestProjectConfiguration[]`
 - **默认值:** `[]`
@@ -2356,7 +2563,7 @@ Expand all common lines.
 
 在隔离的环境中运行测试。此选项对 `vmThreads` 和 `vmForks` 池没有影响。
 
-如果你的代码不依赖于副作用（对于具有 `node` 环境的项目通常如此），禁用此选项可能会[改进性能](/guide/improving-performance)。
+如果你的代码不依赖于副作用（这在 `node` 环境的项目通常如此），禁用此选项可能会 [性能提升](/guide/improving-performance)。
 
 ::: tip
 你可以使用 [`poolOptions`](#poolOptions) 属性禁用特定池的隔离。
@@ -2367,14 +2574,14 @@ Expand all common lines.
 - **类型:** `boolean`
 - **默认值:** `false`
 
-Vitest API 在 [reporters](#reporters) 中接收任务时是否应包含`location`属性。如果我们有大量测试，这可能会导致性能小幅下降。
+Vitest API 在 [reporters](#reporters) 中接收任务时是否应包含 `location` 属性。如果我们有大量测试，这可能会导致性能小幅下降。
 
 `location` 属性的 `列` 和 `行` 值与原始文件中的 `test` 或 `describe` 位置相对应。
 
 如果我们没有明确禁用该选项，并且在运行 Vitest 时使用了该选项，则该选项将自动启用：
 - [Vitest UI](/guide/ui)
-- 或使用不带 [headless](/guide/browser/#headless) 模式的 [浏览器模式](/guide/browser/)
-- 或使用[HTML 报告器](/guide/reporters#html-reporter)
+- 或使用不带 [无头模式](/guide/browser/#headless) 的 [浏览器](/guide/browser/)
+- 或使用 [HTML 报告器](/guide/reporters#html-reporter)
 
 ::: tip
 如果不使用依赖于该选项的自定义代码，该选项将不起作用。
@@ -2405,10 +2612,10 @@ export interface SnapshotEnvironment {
 ::: warning
 这是一个低级选项，仅适用于无法访问默认 Node.js API 的高级情况。
 
-如果只需要配置快照功能，请使用 [`snapshotFormat`](#snapshotformat)或 [`resolveSnapshotPath`](#resolvesnapshotpath)选项。
+如果只需要配置快照功能，请使用 [`snapshotFormat`](#snapshotformat) 或 [`resolveSnapshotPath`](#resolvesnapshotpath) 选项。
 :::
 
-### env {#env}
+### env
 
 - **类型:** `Partial<NodeJS.ProcessEnv>`
 
@@ -2456,7 +2663,7 @@ export interface SnapshotEnvironment {
 
 每次调用 `console` 方法时都输出堆栈追踪信息，这对于排查问题非常有帮助。
 
-### attachmentsDir <Version>3.2.0</Version> {#attachmentsdir}
+### attachmentsDir <Version>3.2.0</Version>
 
 - **类型:** `string`
 - **默认值:** `'.vitest-attachments'`
diff --git a/guide/snapshot.md b/guide/snapshot.md
index 576e4f16..5b711f89 100644
--- a/guide/snapshot.md
+++ b/guide/snapshot.md
@@ -111,7 +111,7 @@ test('image snapshot', () => {
 })
 ```
 
-## 自定义序列化程序 {#custom-serializer}
+## 自定义序列化器 {#custom-serializer}
 
 你可以添加自己的逻辑来修改快照的序列化方式。像 Jest 一样，Vitest 默认有内置的 JavaScript 类型、HTML 元素、ImmutableJS 和 React 元素提供了默认的序列化程序。
 

From 7a51d05cb2cd7f382a8a3ddeb2ab52589c47d6f8 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Sat, 29 Nov 2025 23:07:16 +0800
Subject: [PATCH 30/50] !docs: recovery /api/expect

---
 api/expect.md | 62 +++------------------------------------------------
 1 file changed, 3 insertions(+), 59 deletions(-)

diff --git a/api/expect.md b/api/expect.md
index 29ce3970..cacf3676 100644
--- a/api/expect.md
+++ b/api/expect.md
@@ -31,7 +31,7 @@ expect(input).to.equal(2) // chai API
 expect(input).toBe(2) // jest API
 ```
 
-从技术上讲，这个示例没有使用 [`test`](/api/#test) 函数，因此在控制台中你将看到 Nodejs 错误而不是 Vitest 输出。 要了解更多关于 `test` 的信息，请阅读[测试 API 参考](/api/)。
+从技术上讲，这个示例没有使用 [`test`](/api/#test) 函数，因此在控制台中你将看到 Nodejs 错误而不是 Vitest 输出。 要了解更多关于 `test` 的信息，请阅读 [Test API](/api/)。
 
 此外，`expect` 可以静态地使用来访问匹配器函数，稍后将会介绍。
 
@@ -39,36 +39,6 @@ expect(input).toBe(2) // jest API
 如果表达式没有类型错误，则 `expect` 对测试类型没有影响。 如果你想使用 Vitest 作为[类型检查器](/guide/testing-types)，请使用 [`expectTypeOf`](/api/expect-typeof) 或 [`assertType`](/api/assert-type) 。
 :::
 
-## assert
-
-- **类型:** `Chai.AssertStatic`
-
-Vitest 将 Chai 的 [`assert` API](https://www.chaijs.com/api/assert/) 以 `expect.assert` 的形式重新导出。你可以在  [Assert API page](/api/assert) 页面查看支持的方法。
-
-如果你需要缩小类型范围时，这将特别有用，因为 `expect.to*` 方法不支持此功能：
-
-```ts
-interface Cat {
-  __type: 'Cat'
-  mew(): void
-}
-interface Dog {
-  __type: 'Dog'
-  bark(): void
-}
-type Animal = Cat | Dog
-
-const animal: Animal = { __type: 'Dog', bark: () => {} }
-
-expect.assert(animal.__type === 'Dog')
-// 不显示类型错误！
-expect(animal.bark()).toBeUndefined()
-```
-
-::: tip
-注意，`expect.assert` 还支持其他缩小类型的方法（如：`assert.isDefined`，`assert.exists`等）。
-:::
-
 ## soft
 
 - **类型:** `ExpectStatic & (actual: any) => Assertions`
@@ -330,32 +300,6 @@ test('we don\'t have apples', () => {
 })
 ```
 
-## toBeNullable
-
-- **类型:** `() => Awaitable<void>`
-
-`toBeNullable` simply asserts if something is nullable (`null` or `undefined`).
-
-```ts
-import { expect, test } from 'vitest'
-
-function apples() {
-  return null
-}
-
-function bananas() {
-  return null
-}
-
-test('we don\'t have apples', () => {
-  expect(apples()).toBeNullable()
-})
-
-test('we don\'t have bananas', () => {
-  expect(bananas()).toBeNullable()
-})
-```
-
 ## toBeNaN
 
 - **类型:** `() => Awaitable<void>`
@@ -1335,7 +1279,7 @@ test('spy function returns bananas on second call', async () => {
 
 - **类型:** `(predicate: (value: any) => boolean) => Awaitable<void>`
 
-该断言检查一个值是否满足「某个谓词/certain predicate」。
+该断言检查一个值是否满足某个谓词（certain predicate）。
 
 ```ts
 import { describe, expect, it } from 'vitest'
@@ -1746,7 +1690,7 @@ declare module 'vitest' {
 :::
 
 :::tip
-如果想了解更多信息，请查看 [扩展断言 (Matchers) 指南](/guide/extending-matchers)。
+如果想了解更多信息，请查看 [扩展断言](/guide/extending-matchers)。
 :::
 
 ## expect.addEqualityTesters {#expect-addequalitytesters}

From bd66c8966c09e35acb0adf3cacb358907aee3148 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Sat, 29 Nov 2025 23:23:32 +0800
Subject: [PATCH 31/50] !docs: recovery /api/expect-typeof

---
 api/expect-typeof.md | 41 -----------------------------------------
 1 file changed, 41 deletions(-)

diff --git a/api/expect-typeof.md b/api/expect-typeof.md
index 6f086611..02245225 100644
--- a/api/expect-typeof.md
+++ b/api/expect-typeof.md
@@ -31,9 +31,6 @@ expectTypeOf({ a: 1, b: 1 }).not.toEqualTypeOf<{ a: number }>()
 
 - **类型:** `<T>(expected: T) => void`
 
-::: warning 弃用
-自 expect-type v1.2.0 版本起，此匹配器已被弃用。请改用 [`toExtend`](#toextend)。
-:::
 此匹配器检查期望类型是否扩展了提供的类型。它不同于 `toEqual`，更类似于 [expect's](/api/expect) `toMatchObject()`。使用此匹配器，你可以检查对象是否“匹配”类型。
 
 ```ts
@@ -44,44 +41,6 @@ expectTypeOf<number>().toMatchTypeOf<string | number>()
 expectTypeOf<string | number>().not.toMatchTypeOf<number>()
 ```
 
-## toExtend
-
-- **类型：** `<T>(expected: T) => void`
-
-这个匹配器用于检查期望类型是否扩展了提供的类型。它与 `toEqual` 不同，更类似于 [expect](/api/expect) 的 `toMatchObject()`。使用这个匹配器，你可以检查一个对象是否"匹配"某个类型。
-
-```ts
-import { expectTypeOf } from 'vitest'
-
-expectTypeOf({ a: 1, b: 1 }).toExtend({ a: 1 })
-expectTypeOf<number>().toExtend<string | number>()
-expectTypeOf<string | number>().not.toExtend<number>()
-```
-
-## toMatchObjectType
-
-- **类型：** `() => void`
-
-这个匹配器对对象类型执行严格检查，确保期望的类型与提供的对象类型相匹配。它比 [`toExtend`](#toextend) 更严格，是在处理对象类型时的推荐选择，因为它更有可能捕获到像只读属性这样的问题。
-
-```ts
-import { expectTypeOf } from 'vitest'
-
-expectTypeOf({ a: 1, b: 2 }).toMatchObjectType<{ a: number }>() // preferred
-expectTypeOf({ a: 1, b: 2 }).toExtend<{ a: number }>() // works but less strict
-
-// 支持嵌套对象检查
-const user = {
-  name: 'John',
-  address: { city: 'New York', zip: '10001' }
-}
-expectTypeOf(user).toMatchObjectType<{ name: string, address: { city: string } }>()
-```
-
-::: warning
-这个匹配器只适用于普通对象类型。对于联合类型和其他复杂类型，它将会失败。对于这些情况，请改用 [`toExtend`](#toextend)。
-:::
-
 ## extract
 
 - **类型:** `ExpectTypeOf<ExtractedUnion>`

From a0983a58ee52204cb49f26be3e620bf938fa8aa0 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Sat, 29 Nov 2025 23:25:00 +0800
Subject: [PATCH 32/50] !docs: recovery /api/assert-type

---
 api/assert-type.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/api/assert-type.md b/api/assert-type.md
index 973b9f6c..e4f9364c 100644
--- a/api/assert-type.md
+++ b/api/assert-type.md
@@ -1,13 +1,13 @@
 # assertType
 
-- **类型:** `<T>(value: T): void`
-
-你可以使用此函数作为 [`expectTypeOf`](/api/expect-typeof) 的替代方法，以轻松地断言参数类型等于提供的泛型。
-
 ::: warning
 在运行时，此函数不执行任何操作。要 [启用类型检查](/guide/testing-types#run-typechecking)，不要忘记传递 `--typecheck` 标志。
 :::
 
+- **类型:** `<T>(value: T): void`
+
+你可以使用此函数作为 [`expectTypeOf`](/api/expect-typeof) 的替代方法，以轻松地断言参数类型等于提供的泛型。
+
 ```ts
 import { assertType } from 'vitest'
 

From 7166ea7b24bf192985990877d431dd4459381b0b Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Sat, 29 Nov 2025 23:47:24 +0800
Subject: [PATCH 33/50] !docs: recovery /api/assert

---
 api/assert.md | 455 +++++++++-----------------------------------------
 1 file changed, 79 insertions(+), 376 deletions(-)

diff --git a/api/assert.md b/api/assert.md
index 78fcd770..8f484404 100644
--- a/api/assert.md
+++ b/api/assert.md
@@ -724,11 +724,7 @@ import { assert, test } from 'vitest'
 test('assert.notInclude', () => {
   assert.notInclude([1, 2, 3], 4, 'array doesn\'t contain 4')
   assert.notInclude('foobar', 'baz', 'foobar doesn\'t contain baz')
-  assert.notInclude(
-    { foo: 'bar', hello: 'universe' },
-    { foo: 'baz' },
-    'object doesn\'t contain property'
-  )
+  assert.notInclude({ foo: 'bar', hello: 'universe' }, { foo: 'baz' }, 'object doesn\'t contain property')
 })
 ```
 
@@ -1079,16 +1075,8 @@ test('assert.nestedPropertyVal', () => {
 import { assert, test } from 'vitest'
 
 test('assert.notNestedPropertyVal', () => {
-  assert.notNestedPropertyVal(
-    { tea: { green: 'matcha' } },
-    'tea.green',
-    'konacha'
-  )
-  assert.notNestedPropertyVal(
-    { tea: { green: 'matcha' } },
-    'coffee.green',
-    'matcha'
-  )
+  assert.notNestedPropertyVal({ tea: { green: 'matcha' } }, 'tea.green', 'konacha')
+  assert.notNestedPropertyVal({ tea: { green: 'matcha' } }, 'coffee.green', 'matcha')
 })
 ```
 
@@ -1102,16 +1090,8 @@ test('assert.notNestedPropertyVal', () => {
 import { assert, test } from 'vitest'
 
 test('assert.notNestedPropertyVal', () => {
-  assert.notNestedPropertyVal(
-    { tea: { green: 'matcha' } },
-    'tea.green',
-    'konacha'
-  )
-  assert.notNestedPropertyVal(
-    { tea: { green: 'matcha' } },
-    'coffee.green',
-    'matcha'
-  )
+  assert.notNestedPropertyVal({ tea: { green: 'matcha' } }, 'tea.green', 'konacha')
+  assert.notNestedPropertyVal({ tea: { green: 'matcha' } }, 'coffee.green', 'matcha')
 })
 ```
 
@@ -1125,21 +1105,9 @@ test('assert.notNestedPropertyVal', () => {
 import { assert, test } from 'vitest'
 
 test('assert.notDeepNestedPropertyVal', () => {
-  assert.notDeepNestedPropertyVal(
-    { tea: { green: { matcha: 'yum' } } },
-    'tea.green',
-    { oolong: 'yum' }
-  )
-  assert.notDeepNestedPropertyVal(
-    { tea: { green: { matcha: 'yum' } } },
-    'tea.green',
-    { matcha: 'yuck' }
-  )
-  assert.notDeepNestedPropertyVal(
-    { tea: { green: { matcha: 'yum' } } },
-    'tea.black',
-    { matcha: 'yum' }
-  )
+  assert.notDeepNestedPropertyVal({ tea: { green: { matcha: 'yum' } } }, 'tea.green', { oolong: 'yum' })
+  assert.notDeepNestedPropertyVal({ tea: { green: { matcha: 'yum' } } }, 'tea.green', { matcha: 'yuck' })
+  assert.notDeepNestedPropertyVal({ tea: { green: { matcha: 'yum' } } }, 'tea.black', { matcha: 'yum' })
 })
 ```
 
@@ -1156,15 +1124,7 @@ test('assert.lengthOf', () => {
   assert.lengthOf([1, 2, 3], 3, 'array has length of 3')
   assert.lengthOf('foobar', 6, 'string has length of 6')
   assert.lengthOf(new Set([1, 2, 3]), 3, 'set has size of 3')
-  assert.lengthOf(
-    new Map([
-      ['a', 1],
-      ['b', 2],
-      ['c', 3],
-    ]),
-    3,
-    'map has size of 3'
-  )
+  assert.lengthOf(new Map([['a', 1], ['b', 2], ['c', 3]]), 3, 'map has size of 3')
 })
 ```
 
@@ -1179,21 +1139,9 @@ import { assert, test } from 'vitest'
 
 test('assert.hasAnyKeys', () => {
   assert.hasAnyKeys({ foo: 1, bar: 2, baz: 3 }, ['foo', 'iDontExist', 'baz'])
-  assert.hasAnyKeys(
-    { foo: 1, bar: 2, baz: 3 },
-    { foo: 30, iDontExist: 99, baz: 1337 }
-  )
-  assert.hasAnyKeys(
-    new Map([
-      [{ foo: 1 }, 'bar'],
-      ['key', 'value'],
-    ]),
-    [{ foo: 1 }, 'key']
-  )
-  assert.hasAnyKeys(new Set([{ foo: 'bar' }, 'anotherKey']), [
-    { foo: 'bar' },
-    'anotherKey',
-  ])
+  assert.hasAnyKeys({ foo: 1, bar: 2, baz: 3 }, { foo: 30, iDontExist: 99, baz: 1337 })
+  assert.hasAnyKeys(new Map([[{ foo: 1 }, 'bar'], ['key', 'value'],]), [{ foo: 1 }, 'key'])
+  assert.hasAnyKeys(new Set([{ foo: 'bar' }, 'anotherKey']), [{ foo: 'bar' }, 'anotherKey'])
 })
 ```
 
@@ -1208,20 +1156,9 @@ import { assert, test } from 'vitest'
 
 test('assert.hasAllKeys', () => {
   assert.hasAllKeys({ foo: 1, bar: 2, baz: 3 }, ['foo', 'bar', 'baz'])
-  assert.hasAllKeys(
-    { foo: 1, bar: 2, baz: 3 },
-    { foo: 30, bar: 99, baz: 1337 }
-  )
-  assert.hasAllKeys(
-    new Map([
-      [{ foo: 1 }, 'bar'],
-      ['key', 'value'],
-    ]),
-    [{ foo: 1 }, 'key']
-  )
-  assert.hasAllKeys(
-    new Set([{ foo: 'bar' }, 'anotherKey'], [{ foo: 'bar' }, 'anotherKey'])
-  )
+  assert.hasAllKeys({ foo: 1, bar: 2, baz: 3 }, { foo: 30, bar: 99, baz: 1337 })
+  assert.hasAllKeys(new Map([[{ foo: 1 }, 'bar'], ['key', 'value'],]), [{ foo: 1 }, 'key'])
+  assert.hasAllKeys(new Set([{ foo: 'bar' }, 'anotherKey'], [{ foo: 'bar' }, 'anotherKey']))
 })
 ```
 
@@ -1238,30 +1175,11 @@ test('assert.containsAllKeys', () => {
   assert.containsAllKeys({ foo: 1, bar: 2, baz: 3 }, ['foo', 'baz'])
   assert.containsAllKeys({ foo: 1, bar: 2, baz: 3 }, ['foo', 'bar', 'baz'])
   assert.containsAllKeys({ foo: 1, bar: 2, baz: 3 }, { foo: 30, baz: 1337 })
-  assert.containsAllKeys(
-    { foo: 1, bar: 2, baz: 3 },
-    { foo: 30, bar: 99, baz: 1337 }
-  )
-  assert.containsAllKeys(
-    new Map([
-      [{ foo: 1 }, 'bar'],
-      ['key', 'value'],
-    ]),
-    [{ foo: 1 }]
-  )
-  assert.containsAllKeys(
-    new Map([
-      [{ foo: 1 }, 'bar'],
-      ['key', 'value'],
-    ]),
-    [{ foo: 1 }, 'key']
-  )
-  assert.containsAllKeys(
-    new Set([{ foo: 'bar' }, 'anotherKey'], [{ foo: 'bar' }])
-  )
-  assert.containsAllKeys(
-    new Set([{ foo: 'bar' }, 'anotherKey'], [{ foo: 'bar' }, 'anotherKey'])
-  )
+  assert.containsAllKeys({ foo: 1, bar: 2, baz: 3 }, { foo: 30, bar: 99, baz: 1337 })
+  assert.containsAllKeys(new Map([[{ foo: 1 }, 'bar'], ['key', 'value'],]), [{ foo: 1 }])
+  assert.containsAllKeys(new Map([[{ foo: 1 }, 'bar'], ['key', 'value'],]), [{ foo: 1 }, 'key'])
+  assert.containsAllKeys(new Set([{ foo: 'bar' }, 'anotherKey'], [{ foo: 'bar' }]))
+  assert.containsAllKeys(new Set([{ foo: 'bar' }, 'anotherKey'], [{ foo: 'bar' }, 'anotherKey']))
 })
 ```
 
@@ -1275,25 +1193,10 @@ test('assert.containsAllKeys', () => {
 import { assert, test } from 'vitest'
 
 test('assert.doesNotHaveAnyKeys', () => {
-  assert.doesNotHaveAnyKeys({ foo: 1, bar: 2, baz: 3 }, [
-    'one',
-    'two',
-    'example',
-  ])
-  assert.doesNotHaveAnyKeys(
-    { foo: 1, bar: 2, baz: 3 },
-    { one: 1, two: 2, example: 'foo' }
-  )
-  assert.doesNotHaveAnyKeys(
-    new Map([
-      [{ foo: 1 }, 'bar'],
-      ['key', 'value'],
-    ]),
-    [{ one: 'two' }, 'example']
-  )
-  assert.doesNotHaveAnyKeys(
-    new Set([{ foo: 'bar' }, 'anotherKey'], [{ one: 'two' }, 'example'])
-  )
+  assert.doesNotHaveAnyKeys({ foo: 1, bar: 2, baz: 3 }, ['one', 'two', 'example',])
+  assert.doesNotHaveAnyKeys({ foo: 1, bar: 2, baz: 3 }, { one: 1, two: 2, example: 'foo' })
+  assert.doesNotHaveAnyKeys(new Map([[{ foo: 1 }, 'bar'], ['key', 'value'],]), [{ one: 'two' }, 'example'])
+  assert.doesNotHaveAnyKeys(new Set([{ foo: 'bar' }, 'anotherKey'], [{ one: 'two' }, 'example']))
 })
 ```
 
@@ -1307,26 +1210,10 @@ test('assert.doesNotHaveAnyKeys', () => {
 import { assert, test } from 'vitest'
 
 test('assert.hasAnyKeys', () => {
-  assert.doesNotHaveAnyKeys({ foo: 1, bar: 2, baz: 3 }, [
-    'one',
-    'two',
-    'example',
-  ])
-  assert.doesNotHaveAnyKeys(
-    { foo: 1, bar: 2, baz: 3 },
-    { one: 1, two: 2, example: 'foo' }
-  )
-  assert.doesNotHaveAnyKeys(
-    new Map([
-      [{ foo: 1 }, 'bar'],
-      ['key', 'value'],
-    ]),
-    [{ one: 'two' }, 'example']
-  )
-  assert.doesNotHaveAnyKeys(new Set([{ foo: 'bar' }, 'anotherKey']), [
-    { one: 'two' },
-    'example',
-  ])
+  assert.doesNotHaveAnyKeys({ foo: 1, bar: 2, baz: 3 }, ['one', 'two', 'example',])
+  assert.doesNotHaveAnyKeys({ foo: 1, bar: 2, baz: 3 }, { one: 1, two: 2, example: 'foo' })
+  assert.doesNotHaveAnyKeys(new Map([[{ foo: 1 }, 'bar'], ['key', 'value'],]), [{ one: 'two' }, 'example'])
+  assert.doesNotHaveAnyKeys(new Set([{ foo: 'bar' }, 'anotherKey']), [{ one: 'two' }, 'example',])
 })
 ```
 
@@ -1340,38 +1227,12 @@ test('assert.hasAnyKeys', () => {
 import { assert, test } from 'vitest'
 
 test('assert.hasAnyDeepKeys', () => {
-  assert.hasAnyDeepKeys(
-    new Map([
-      [{ one: 'one' }, 'valueOne'],
-      [1, 2],
-    ]),
-    { one: 'one' }
-  )
-  assert.hasAnyDeepKeys(
-    new Map([
-      [{ one: 'one' }, 'valueOne'],
-      [1, 2],
-    ]),
-    [{ one: 'one' }, { two: 'two' }]
-  )
-  assert.hasAnyDeepKeys(
-    new Map([
-      [{ one: 'one' }, 'valueOne'],
-      [{ two: 'two' }, 'valueTwo'],
-    ]),
-    [{ one: 'one' }, { two: 'two' }]
-  )
-  assert.hasAnyDeepKeys(new Set([{ one: 'one' }, { two: 'two' }]), {
-    one: 'one',
-  })
-  assert.hasAnyDeepKeys(new Set([{ one: 'one' }, { two: 'two' }]), [
-    { one: 'one' },
-    { three: 'three' },
-  ])
-  assert.hasAnyDeepKeys(new Set([{ one: 'one' }, { two: 'two' }]), [
-    { one: 'one' },
-    { two: 'two' },
-  ])
+  assert.hasAnyDeepKeys(new Map([[{ one: 'one' }, 'valueOne'], [1, 2],]), { one: 'one' })
+  assert.hasAnyDeepKeys(new Map([[{ one: 'one' }, 'valueOne'], [1, 2],]), [{ one: 'one' }, { two: 'two' }])
+  assert.hasAnyDeepKeys(new Map([[{ one: 'one' }, 'valueOne'], [{ two: 'two' }, 'valueTwo'],]), [{ one: 'one' }, { two: 'two' }])
+  assert.hasAnyDeepKeys(new Set([{ one: 'one' }, { two: 'two' }]), { one: 'one', })
+  assert.hasAnyDeepKeys(new Set([{ one: 'one' }, { two: 'two' }]), [{ one: 'one' }, { three: 'three' },])
+  assert.hasAnyDeepKeys(new Set([{ one: 'one' }, { two: 'two' }]), [{ one: 'one' }, { two: 'two' },])
 })
 ```
 
@@ -1385,21 +1246,10 @@ test('assert.hasAnyDeepKeys', () => {
 import { assert, test } from 'vitest'
 
 test('assert.hasAnyDeepKeys', () => {
-  assert.hasAllDeepKeys(new Map([[{ one: 'one' }, 'valueOne']]), {
-    one: 'one',
-  })
-  assert.hasAllDeepKeys(
-    new Map([
-      [{ one: 'one' }, 'valueOne'],
-      [{ two: 'two' }, 'valueTwo'],
-    ]),
-    [{ one: 'one' }, { two: 'two' }]
-  )
+  assert.hasAllDeepKeys(new Map([[{ one: 'one' }, 'valueOne']]), { one: 'one', })
+  assert.hasAllDeepKeys(new Map([[{ one: 'one' }, 'valueOne'], [{ two: 'two' }, 'valueTwo'],]), [{ one: 'one' }, { two: 'two' }])
   assert.hasAllDeepKeys(new Set([{ one: 'one' }]), { one: 'one' })
-  assert.hasAllDeepKeys(new Set([{ one: 'one' }, { two: 'two' }]), [
-    { one: 'one' },
-    { two: 'two' },
-  ])
+  assert.hasAllDeepKeys(new Set([{ one: 'one' }, { two: 'two' }]), [{ one: 'one' }, { two: 'two' },])
 })
 ```
 
@@ -1413,27 +1263,10 @@ test('assert.hasAnyDeepKeys', () => {
 import { assert, test } from 'vitest'
 
 test('assert.containsAllDeepKeys', () => {
-  assert.containsAllDeepKeys(
-    new Map([
-      [{ one: 'one' }, 'valueOne'],
-      [1, 2],
-    ]),
-    { one: 'one' }
-  )
-  assert.containsAllDeepKeys(
-    new Map([
-      [{ one: 'one' }, 'valueOne'],
-      [{ two: 'two' }, 'valueTwo'],
-    ]),
-    [{ one: 'one' }, { two: 'two' }]
-  )
-  assert.containsAllDeepKeys(new Set([{ one: 'one' }, { two: 'two' }]), {
-    one: 'one',
-  })
-  assert.containsAllDeepKeys(new Set([{ one: 'one' }, { two: 'two' }]), [
-    { one: 'one' },
-    { two: 'two' },
-  ])
+  assert.containsAllDeepKeys(new Map([[{ one: 'one' }, 'valueOne'], [1, 2],]), { one: 'one' })
+  assert.containsAllDeepKeys(new Map([[{ one: 'one' }, 'valueOne'], [{ two: 'two' }, 'valueTwo'],]), [{ one: 'one' }, { two: 'two' }])
+  assert.containsAllDeepKeys(new Set([{ one: 'one' }, { two: 'two' }]), { one: 'one', })
+  assert.containsAllDeepKeys(new Set([{ one: 'one' }, { two: 'two' }]), [{ one: 'one' }, { two: 'two' },])
 })
 ```
 
@@ -1447,27 +1280,10 @@ test('assert.containsAllDeepKeys', () => {
 import { assert, test } from 'vitest'
 
 test('assert.doesNotHaveAnyDeepKeys', () => {
-  assert.doesNotHaveAnyDeepKeys(
-    new Map([
-      [{ one: 'one' }, 'valueOne'],
-      [1, 2],
-    ]),
-    { thisDoesNot: 'exist' }
-  )
-  assert.doesNotHaveAnyDeepKeys(
-    new Map([
-      [{ one: 'one' }, 'valueOne'],
-      [{ two: 'two' }, 'valueTwo'],
-    ]),
-    [{ twenty: 'twenty' }, { fifty: 'fifty' }]
-  )
-  assert.doesNotHaveAnyDeepKeys(new Set([{ one: 'one' }, { two: 'two' }]), {
-    twenty: 'twenty',
-  })
-  assert.doesNotHaveAnyDeepKeys(new Set([{ one: 'one' }, { two: 'two' }]), [
-    { twenty: 'twenty' },
-    { fifty: 'fifty' },
-  ])
+  assert.doesNotHaveAnyDeepKeys(new Map([[{ one: 'one' }, 'valueOne'], [1, 2],]), { thisDoesNot: 'exist' })
+  assert.doesNotHaveAnyDeepKeys(new Map([[{ one: 'one' }, 'valueOne'], [{ two: 'two' }, 'valueTwo'],]), [{ twenty: 'twenty' }, { fifty: 'fifty' }])
+  assert.doesNotHaveAnyDeepKeys(new Set([{ one: 'one' }, { two: 'two' }]), { twenty: 'twenty', })
+  assert.doesNotHaveAnyDeepKeys(new Set([{ one: 'one' }, { two: 'two' }]), [{ twenty: 'twenty' }, { fifty: 'fifty' },])
 })
 ```
 
@@ -1481,27 +1297,10 @@ test('assert.doesNotHaveAnyDeepKeys', () => {
 import { assert, test } from 'vitest'
 
 test('assert.doesNotHaveAllDeepKeys', () => {
-  assert.doesNotHaveAllDeepKeys(
-    new Map([
-      [{ one: 'one' }, 'valueOne'],
-      [1, 2],
-    ]),
-    { thisDoesNot: 'exist' }
-  )
-  assert.doesNotHaveAllDeepKeys(
-    new Map([
-      [{ one: 'one' }, 'valueOne'],
-      [{ two: 'two' }, 'valueTwo'],
-    ]),
-    [{ twenty: 'twenty' }, { one: 'one' }]
-  )
-  assert.doesNotHaveAllDeepKeys(new Set([{ one: 'one' }, { two: 'two' }]), {
-    twenty: 'twenty',
-  })
-  assert.doesNotHaveAllDeepKeys(new Set([{ one: 'one' }, { two: 'two' }]), [
-    { one: 'one' },
-    { fifty: 'fifty' },
-  ])
+  assert.doesNotHaveAllDeepKeys(new Map([[{ one: 'one' }, 'valueOne'], [1, 2],]), { thisDoesNot: 'exist' })
+  assert.doesNotHaveAllDeepKeys(new Map([[{ one: 'one' }, 'valueOne'], [{ two: 'two' }, 'valueTwo'],]), [{ twenty: 'twenty' }, { one: 'one' }])
+  assert.doesNotHaveAllDeepKeys(new Set([{ one: 'one' }, { two: 'two' }]), { twenty: 'twenty', })
+  assert.doesNotHaveAllDeepKeys(new Set([{ one: 'one' }, { two: 'two' }]), [{ one: 'one' }, { fifty: 'fifty' },])
 })
 ```
 
@@ -1524,26 +1323,10 @@ test('assert.throws', () => {
   assert.throws(fn, /Error thrown must have a msg that matches this/)
   assert.throws(fn, ReferenceError)
   assert.throws(fn, errorInstance)
-  assert.throws(
-    fn,
-    ReferenceError,
-    'Error thrown must be a ReferenceError and have this msg'
-  )
-  assert.throws(
-    fn,
-    errorInstance,
-    'Error thrown must be the same errorInstance and have this msg'
-  )
-  assert.throws(
-    fn,
-    ReferenceError,
-    /Error thrown must be a ReferenceError and match this/
-  )
-  assert.throws(
-    fn,
-    errorInstance,
-    /Error thrown must be the same errorInstance and match this/
-  )
+  assert.throws(fn, ReferenceError, 'Error thrown must be a ReferenceError and have this msg')
+  assert.throws(fn, errorInstance, 'Error thrown must be the same errorInstance and have this msg')
+  assert.throws(fn, ReferenceError, /Error thrown must be a ReferenceError and match this/)
+  assert.throws(fn, errorInstance, /Error thrown must be the same errorInstance and match this/)
 })
 ```
 
@@ -1636,11 +1419,7 @@ test('assert.sameMembers', () => {
 import { assert, test } from 'vitest'
 
 test('assert.sameDeepMembers', () => {
-  assert.sameDeepMembers(
-    [{ a: 1 }, { b: 2 }, { c: 3 }],
-    [{ b: 2 }, { a: 1 }, { c: 3 }],
-    'same deep members'
-  )
+  assert.sameDeepMembers([{ a: 1 }, { b: 2 }, { c: 3 }], [{ b: 2 }, { a: 1 }, { c: 3 }], 'same deep members')
 })
 ```
 
@@ -1654,11 +1433,7 @@ test('assert.sameDeepMembers', () => {
 import { assert, test } from 'vitest'
 
 test('assert.sameDeepMembers', () => {
-  assert.sameDeepMembers(
-    [{ a: 1 }, { b: 2 }, { c: 3 }],
-    [{ b: 2 }, { a: 1 }, { c: 3 }],
-    'same deep members'
-  )
+  assert.sameDeepMembers([{ a: 1 }, { b: 2 }, { c: 3 }], [{ b: 2 }, { a: 1 }, { c: 3 }], 'same deep members')
 })
 ```
 
@@ -1686,11 +1461,7 @@ test('assert.sameOrderedMembers', () => {
 import { assert, test } from 'vitest'
 
 test('assert.notSameOrderedMembers', () => {
-  assert.notSameOrderedMembers(
-    [1, 2, 3],
-    [2, 1, 3],
-    'not same ordered members'
-  )
+  assert.notSameOrderedMembers([1, 2, 3], [2, 1, 3], 'not same ordered members')
 })
 ```
 
@@ -1704,11 +1475,7 @@ test('assert.notSameOrderedMembers', () => {
 import { assert, test } from 'vitest'
 
 test('assert.sameDeepOrderedMembers', () => {
-  assert.sameDeepOrderedMembers(
-    [{ a: 1 }, { b: 2 }, { c: 3 }],
-    [{ a: 1 }, { b: 2 }, { c: 3 }],
-    'same deep ordered members'
-  )
+  assert.sameDeepOrderedMembers([{ a: 1 }, { b: 2 }, { c: 3 }], [{ a: 1 }, { b: 2 }, { c: 3 }], 'same deep ordered members')
 })
 ```
 
@@ -1722,16 +1489,8 @@ test('assert.sameDeepOrderedMembers', () => {
 import { assert, test } from 'vitest'
 
 test('assert.notSameDeepOrderedMembers', () => {
-  assert.notSameDeepOrderedMembers(
-    [{ a: 1 }, { b: 2 }, { c: 3 }],
-    [{ a: 1 }, { b: 2 }, { z: 5 }],
-    'not same deep ordered members'
-  )
-  assert.notSameDeepOrderedMembers(
-    [{ a: 1 }, { b: 2 }, { c: 3 }],
-    [{ b: 2 }, { a: 1 }, { c: 3 }],
-    'not same deep ordered members'
-  )
+  assert.notSameDeepOrderedMembers([{ a: 1 }, { b: 2 }, { c: 3 }], [{ a: 1 }, { b: 2 }, { z: 5 }], 'not same deep ordered members')
+  assert.notSameDeepOrderedMembers([{ a: 1 }, { b: 2 }, { c: 3 }], [{ b: 2 }, { a: 1 }, { c: 3 }], 'not same deep ordered members')
 })
 ```
 
@@ -1773,11 +1532,7 @@ test('assert.notIncludeMembers', () => {
 import { assert, test } from 'vitest'
 
 test('assert.includeDeepMembers', () => {
-  assert.includeDeepMembers(
-    [{ a: 1 }, { b: 2 }, { c: 3 }],
-    [{ b: 2 }, { a: 1 }, { b: 2 }],
-    'include deep members'
-  )
+  assert.includeDeepMembers([{ a: 1 }, { b: 2 }, { c: 3 }], [{ b: 2 }, { a: 1 }, { b: 2 }], 'include deep members')
 })
 ```
 
@@ -1791,11 +1546,7 @@ test('assert.includeDeepMembers', () => {
 import { assert, test } from 'vitest'
 
 test('assert.notIncludeDeepMembers', () => {
-  assert.notIncludeDeepMembers(
-    [{ a: 1 }, { b: 2 }, { c: 3 }],
-    [{ b: 2 }, { f: 5 }],
-    'not include deep members'
-  )
+  assert.notIncludeDeepMembers([{ a: 1 }, { b: 2 }, { c: 3 }], [{ b: 2 }, { f: 5 }], 'not include deep members')
 })
 ```
 
@@ -1823,16 +1574,8 @@ test('assert.includeOrderedMembers', () => {
 import { assert, test } from 'vitest'
 
 test('assert.notIncludeOrderedMembers', () => {
-  assert.notIncludeOrderedMembers(
-    [1, 2, 3],
-    [2, 1],
-    'not include ordered members'
-  )
-  assert.notIncludeOrderedMembers(
-    [1, 2, 3],
-    [2, 3],
-    'not include ordered members'
-  )
+  assert.notIncludeOrderedMembers([1, 2, 3], [2, 1], 'not include ordered members')
+  assert.notIncludeOrderedMembers([1, 2, 3], [2, 3], 'not include ordered members')
 })
 ```
 
@@ -1846,11 +1589,7 @@ test('assert.notIncludeOrderedMembers', () => {
 import { assert, test } from 'vitest'
 
 test('assert.includeDeepOrderedMembers', () => {
-  assert.includeDeepOrderedMembers(
-    [{ a: 1 }, { b: 2 }, { c: 3 }],
-    [{ a: 1 }, { b: 2 }],
-    'include deep ordered members'
-  )
+  assert.includeDeepOrderedMembers([{ a: 1 }, { b: 2 }, { c: 3 }], [{ a: 1 }, { b: 2 }], 'include deep ordered members')
 })
 ```
 
@@ -1864,21 +1603,9 @@ test('assert.includeDeepOrderedMembers', () => {
 import { assert, test } from 'vitest'
 
 test('assert.includeDeepOrderedMembers', () => {
-  assert.notIncludeDeepOrderedMembers(
-    [{ a: 1 }, { b: 2 }, { c: 3 }],
-    [{ a: 1 }, { f: 5 }],
-    'not include deep ordered members'
-  )
-  assert.notIncludeDeepOrderedMembers(
-    [{ a: 1 }, { b: 2 }, { c: 3 }],
-    [{ b: 2 }, { a: 1 }],
-    'not include deep ordered members'
-  )
-  assert.notIncludeDeepOrderedMembers(
-    [{ a: 1 }, { b: 2 }, { c: 3 }],
-    [{ b: 2 }, { c: 3 }],
-    'not include deep ordered members'
-  )
+  assert.notIncludeDeepOrderedMembers([{ a: 1 }, { b: 2 }, { c: 3 }], [{ a: 1 }, { f: 5 }], 'not include deep ordered members')
+  assert.notIncludeDeepOrderedMembers([{ a: 1 }, { b: 2 }, { c: 3 }], [{ b: 2 }, { a: 1 }], 'not include deep ordered members')
+  assert.notIncludeDeepOrderedMembers([{ a: 1 }, { b: 2 }, { c: 3 }], [{ b: 2 }, { c: 3 }], 'not include deep ordered members')
 })
 ```
 
@@ -1907,9 +1634,7 @@ import { assert, test } from 'vitest'
 
 test('assert.changes', () => {
   const obj = { val: 10 }
-  function fn() {
-    obj.val = 22
-  }
+  function fn() { obj.val = 22 };
   assert.changes(fn, obj, 'val')
 })
 ```
@@ -1925,9 +1650,7 @@ import { assert, test } from 'vitest'
 
 test('assert.changesBy', () => {
   const obj = { val: 10 }
-  function fn() {
-    obj.val += 2
-  }
+  function fn() { obj.val += 2 };
   assert.changesBy(fn, obj, 'val', 2)
 })
 ```
@@ -1943,9 +1666,7 @@ import { assert, test } from 'vitest'
 
 test('assert.doesNotChange', () => {
   const obj = { val: 10 }
-  function fn() {
-    obj.val += 2
-  }
+  function fn() { obj.val += 2 };
   assert.doesNotChange(fn, obj, 'val', 2)
 })
 ```
@@ -1961,9 +1682,7 @@ import { assert, test } from 'vitest'
 
 test('assert.changesButNotBy', () => {
   const obj = { val: 10 }
-  function fn() {
-    obj.val += 10
-  }
+  function fn() { obj.val += 10 };
   assert.changesButNotBy(fn, obj, 'val', 5)
 })
 ```
@@ -1979,9 +1698,7 @@ import { assert, test } from 'vitest'
 
 test('assert.increases', () => {
   const obj = { val: 10 }
-  function fn() {
-    obj.val = 13
-  }
+  function fn() { obj.val = 13 };
   assert.increases(fn, obj, 'val')
 })
 ```
@@ -2013,9 +1730,7 @@ import { assert, test } from 'vitest'
 
 test('assert.doesNotIncrease', () => {
   const obj = { val: 10 }
-  function fn() {
-    obj.val = 8
-  }
+  function fn() { obj.val = 8 }
   assert.doesNotIncrease(fn, obj, 'val')
 })
 ```
@@ -2031,9 +1746,7 @@ import { assert, test } from 'vitest'
 
 test('assert.increasesButNotBy', () => {
   const obj = { val: 10 }
-  function fn() {
-    obj.val += 15
-  }
+  function fn() { obj.val += 15 };
   assert.increasesButNotBy(fn, obj, 'val', 10)
 })
 ```
@@ -2049,9 +1762,7 @@ import { assert, test } from 'vitest'
 
 test('assert.decreases', () => {
   const obj = { val: 10 }
-  function fn() {
-    obj.val = 5
-  }
+  function fn() { obj.val = 5 };
   assert.decreases(fn, obj, 'val')
 })
 ```
@@ -2067,9 +1778,7 @@ import { assert, test } from 'vitest'
 
 test('assert.decreasesBy', () => {
   const obj = { val: 10 }
-  function fn() {
-    obj.val -= 5
-  }
+  function fn() { obj.val -= 5 };
   assert.decreasesBy(fn, obj, 'val', 5)
 })
 ```
@@ -2085,9 +1794,7 @@ import { assert, test } from 'vitest'
 
 test('assert.doesNotDecrease', () => {
   const obj = { val: 10 }
-  function fn() {
-    obj.val = 15
-  }
+  function fn() { obj.val = 15 }
   assert.doesNotDecrease(fn, obj, 'val')
 })
 ```
@@ -2103,9 +1810,7 @@ import { assert, test } from 'vitest'
 
 test('assert.doesNotDecreaseBy', () => {
   const obj = { val: 10 }
-  function fn() {
-    obj.val = 5
-  }
+  function fn() { obj.val = 5 };
   assert.doesNotDecreaseBy(fn, obj, 'val', 1)
 })
 ```
@@ -2121,9 +1826,7 @@ import { assert, test } from 'vitest'
 
 test('assert.decreasesButNotBy', () => {
   const obj = { val: 10 }
-  function fn() {
-    obj.val = 5
-  }
+  function fn() { obj.val = 5 };
   assert.decreasesButNotBy(fn, obj, 'val', 1)
 })
 ```

From 7ad16bfe16cbcaf8c6b95afa4ce976b6920ed738 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Sun, 30 Nov 2025 00:00:05 +0800
Subject: [PATCH 34/50] !docs: recovery /guide/comparisons

---
 guide/comparisons.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/guide/comparisons.md b/guide/comparisons.md
index 5ad17741..df86e033 100644
--- a/guide/comparisons.md
+++ b/guide/comparisons.md
@@ -8,7 +8,7 @@ title: 与其他测试框架对比 | 指南
 
 [Jest](https://jestjs.io/) 在测试框架领域占据了主导地位，因为它为大多数 JavaScript 项目提供开箱即用的支持，具备舒适的 API（`it` 和 `expect`），且覆盖了大多数测试的需求（例如快照、模拟和覆盖率）。我们感谢 Jest 团队和社区创建了一个令人愉悦的测试 API，并引入了许多已成为 Web 生态系统标准的测试模式。
 
-在 Vite 项目中使用 Jest 是可能的。[@sodatea](https://bsky.app/profile/haoqun.dev) 开发了 [vite-jest](https://github.com/sodatea/vite-jest#readme) ，旨在为 [Jest](https://jestjs.io/) 提供一流的 Vite 集成。[Jest 中最后的阻碍](https://github.com/sodatea/vite-jest/blob/main/packages/vite-jest/README.md#vite-jest)已经解决。因此，在 Vite 项目的单元测试中，Jest 仍是一个可用选项。
+在 Vite 项目中使用 Jest 是可能的。[@sodatea](https://bsky.app/profile/haoqun.dev) 开发了 [vite-jest](https://github.com/sodatea/vite-jest#readme) ，旨在为 [Jest](https://jestjs.io/) 提供一流的 Vite 集成。[Jest 中最后的阻碍](https://github.com/sodatea/vite-jest/blob/main/packages/vite-jest/README.md#vite-jest) 已经解决。因此，在 Vite 项目的单元测试中，Jest 仍是一个可用选项。
 
 然而，在 [Vite](https://vitejs.dev) 已为最常见的 Web 工具（TypeScript、JSX、最流行的 UI 框架）提供了支持的情况下，引入 Jest 会增添不必要的复杂性。如果你的应用由 Vite 驱动，那么配置和维护两个不同的管道是不合理的。如果使用 Vitest，你可以在同一个管道中进行开发、构建和测试环境的配置，它们共享相同的插件和 `vite.config.js` 文件。
 
@@ -18,7 +18,7 @@ title: 与其他测试框架对比 | 指南
 
 [Cypress](https://www.cypress.io/) 是基于浏览器的测试工具，这对 Vitest 形成了补充。如果你想使用 Cypress，建议将 Vitest 用于测试项目中不依赖于浏览器的部分，而将 Cypress 用于测试依赖浏览器的部分。
 
-Cypress 作为端到端测试工具而广为人知，但他们[最新的组件测试运行器](https://on.cypress.io/component) 对 Vite 项目的组件测试提供了很好的支持，并且是测试任何依赖于浏览器逻辑的代码的理想选择。
+Cypress 作为端到端测试工具而广为人知，但他们 [最新的组件测试运行器](https://on.cypress.io/component) 对 Vite 项目的组件测试提供了很好的支持，并且是测试任何依赖于浏览器逻辑的代码的理想选择。
 
 基于浏览器的测试框架，例如 Cypress, WebdriverIO 和 Web Test Runner，能捕获到 Vitest 无法捕获的问题，因为他们使用了真实的浏览器和浏览器 API。
 
@@ -40,7 +40,7 @@ WebdriverIO 具有与 Cypress 相同的优点，允许你在真实的浏览器
 
 ## Web Test Runner
 
-[@web/test-runner](https://modern-web.dev/docs/test-runner/overview/)在无头浏览器中运行测试，提供与 web 应用程序相同的执行环境，而无需模仿浏览器 API 或 DOM。这也使得使用 devtools 在真实的浏览器中进行调试成为可能，尽管它没有像 Cypress 那样展示一个指示测试进度的 UI。
+[@web/test-runner](https://modern-web.dev/docs/test-runner/overview/) 在无头浏览器中运行测试，提供与 web 应用程序相同的执行环境，而无需模仿浏览器 API 或 DOM。这也使得使用 devtools 在真实的浏览器中进行调试成为可能，尽管它没有像 Cypress 那样展示一个指示测试进度的 UI。
 
 要在 Vite 项目中使用 @web/test-runner，请使用[@remcovaes/web-test-runner-Vite-plugin](https://github.com/remcovaes/web-test-runner-vite-plugin)。@web/testrunner 不包括断言或模拟对象库，所以你需要自行添加它们。
 

From 34077a7d2bfd1539f21c5f826cf8d367dae119c6 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Sun, 30 Nov 2025 00:09:34 +0800
Subject: [PATCH 35/50] !docs: remove  /advanced/api files

---
 advanced/api.md      | 351 -------------------------------------------
 guide/comparisons.md |   2 +-
 2 files changed, 1 insertion(+), 352 deletions(-)
 delete mode 100644 advanced/api.md

diff --git a/advanced/api.md b/advanced/api.md
deleted file mode 100644
index 40abb3b4..00000000
--- a/advanced/api.md
+++ /dev/null
@@ -1,351 +0,0 @@
----
-outline: [2, 3]
----
-
-# Node API
-
-::: warning
-Vitest 暴露了实验性的私有 API。由于可能不遵循语义化版本规范（SemVer），因此可能会出现不兼容的更改，请在使用 Vitest 时锁定版本。
-:::
-
-## 启动 Vitest
-
-你可以使用 Vitest 的 Node API 开始运行 Vitest 测试：
-
-```js
-import { startVitest } from 'vitest/node'
-
-const vitest = await startVitest('test')
-
-await vitest?.close()
-```
-
-如果测试可以启动，则 `startVitest` 函数返回 `Vitest` 实例。 如果出现以下情况之一，则返回 `undefined`：
-
-- Vitest 未找到 `vite` 包 (通常与 Vitest 一起安装)
-- 如果启用了 `coverage`，并且运行模式为 "test"，但并未安装 "coverage" 包（`@vitest/coverage-v8` 或 `@vitest/coverage-istanbul`）
-- 如果未安装环境包 (`jsdom`/`happy-dom`/`@edge-runtime/vm`)
-
-如果在运行期间返回 `undefined` 或者测试失败, Vitest 会将 `process.exitCode` 设置为 `1`。
-
-如果未启用监视模式，Vitest 将会调用 `close` 方法。
-
-如果启用了监视模式并且终端支持 TTY, 则 Vitest 会注册控制台快捷键。
-
-你可以将过滤器列表作为第二个参数传递下去。Vitest 将仅运行包含其文件路径中至少一个传递字符串的测试。
-
-此外，你可以使用第三个参数传递 CLI 参数，这将覆盖任何测试配置选项。
-
-或者，你可以将完整的 Vite 配置作为第四个参数传递进去，这将优先于任何其他用户定义的选项。
-
-运行测试后，您可以从 `state.getFiles` API 获取结果：
-
-```ts
-const vitest = await startVitest('test')
-
-console.log(vitest.state.getFiles()) // [{ type: 'file', ... }]
-```
-
-自 Vitest 2.1 起，建议使用["Reported Tasks" API](/advanced/reporters#reported-tasks) 和 `state.getFiles`。今后，Vitest 将直接返回这些对象：
-
-```ts
-const vitest = await startVitest('test')
-
-const [fileTask] = vitest.state.getFiles()
-const testFile = vitest.state.getReportedEntity(fileTask)
-```
-
-## 创建 Vitest
-
-你可以使用 `createVitest` 函数创建自己的 Vitest 实例. 它返回与 `startVitest` 相同的 `Vitest` 实例, 但不会启动测试，也不会验证已安装的包。
-
-```js
-import { createVitest } from 'vitest/node'
-
-const vitest = await createVitest('test', {
-  watch: false,
-})
-```
-
-## parseCLI
-
-你可以使用此方法来解析 CLI 参数。它接受字符串（其中参数由单个空格分隔）或与 Vitest CLI 使用的格式相同的 CLI 参数的字符串数组。它返回一个过滤器和`选项`，你可以稍后将其传递给 `createVitest` 或 `startVitest` 方法。
-
-```ts
-import { parseCLI } from 'vitest/node'
-
-parseCLI('vitest ./files.ts --coverage --browser=chrome')
-```
-
-## Vitest
-
-Vitest 实例需要当前的测试模式。它可以是以下之一：
-
-- 运行运行时测试时为 `test`
-- 运行基准测试时为 `benchmark`
-- 运行类型测试时为 `typecheck`
-
-### 模式
-
-#### test
-
-测试模式仅会调用 `test` 或 `it` 中的函数，并在遇到 `bench` 时抛出错误。此模式使用配置中的 `include` 和 `exclude` 选项查找测试文件。
-
-#### benchmark
-
-基准测试模式会调用 `bench` 函数，并在遇到 `test` 或 `it` 时抛出错误。此模式使用配置中的 `benchmark.include` 和 `benchmark.exclude` 选项查找基准测试文件。
-
-#### typecheck
-
-类型检查模式不会*运行*测试。它仅分析类型并提供摘要信息。此模式使用配置中的 `typecheck.include` 和 `typecheck.exclude` 选项查找要分析的文件。
-
-### start
-
-你可以使用 `start` 方法运行测试或者基准测试。你还可以传递一个字符串数组以筛选测试文件。
-
-### `provide`
-
-Vitest 提供了 `provide` 方法，它是 `vitest.getRootTestProject().provide` 的简写形式。通过这个方法，你可以将值从主线程传递到测试中。所有值在存储之前都会通过 `structuredClone` 进行检查，但值本身不会被克隆。
-
-要在测试中接收值，需要从 `vitest` entrypont 导入 `inject` 方法：
-
-```ts
-import { inject } from 'vitest'
-const port = inject('wsPort') // 3000
-```
-
-为了提高类型安全性，我们鼓励您增强 `ProvidedContext` 的类型：
-
-```ts
-import { createVitest } from 'vitest/node'
-
-const vitest = await createVitest('test', {
-  watch: false,
-})
-vitest.provide('wsPort', 3000)
-
-declare module 'vitest' {
-  export interface ProvidedContext {
-    wsPort: number
-  }
-}
-```
-
-::: warning
-在技术上来说，`provide` 是 [`TestProject`](#testproject) 的一个方法，因此它受限于特定的项目。然而，所有项目都从核心项目继承了值，这使得 `vitest.provide` 成为了一种普遍的方式来向测试传递值。
-:::
-
-::: tip
-该方法同样适用于[全局配置文件](/config/#globalsetup)，在无法使用公共API的情况下。
-
-```js
-export default function setup({ provide }) {
-  provide('wsPort', 3000)
-}
-```
-:::
-
-## TestProject <Version>3.0.0</Version> {#testproject}
-
-- **别名**: `WorkspaceProject` before 3.0.0
-
-### name
-
-这个 name 是由用户指定的唯一字符串，或由 Vitest 解释得出。如果用户未提供名称，Vitest 会尝试在项目根目录加载 `package.json` 文件，并从中获取 `name` 属性作为 name 。若项目中不存在 `package.json` 文件，则 Vitest 默认使用文件夹的名字。对于内联项目，Vitest 使用数字（转换为字符串）作为 name 。
-
-::: code-group
-```ts [node.js]
-import { createVitest } from 'vitest/node'
-
-const vitest = await createVitest('test')
-vitest.projects.map(p => p.name) === [
-  '@pkg/server',
-  'utils',
-  '2',
-  'custom'
-]
-```
-```ts [vitest.workspace.js]
-export default [
-  './packages/server', // package.json 中包含 "@pkg/server"
-  './utils', // 没有 package.json 文件
-  {
-    // 不要自定义名称
-    test: {
-      pool: 'threads',
-    },
-  },
-  {
-    // 自定义名称
-    test: {
-      name: 'custom',
-    },
-  },
-]
-```
-:::
-
-### vitest
-
-`vitest` 是指全局的 [`vitest`](#vitest) 进程。
-
-### serializedConfig
-
-所有测试都会接收到的测试配置。Vitest 手动[序列化配置](https://github.com/vitest-dev/vitest/blob/main/packages/vitest/src/node/config/serializeConfig.ts)，通过移除所有无法序列化的函数和属性来实现。由于这个值在测试和 Node 环境中都可用，因此它从主入口点导出。
-
-```ts
-import type { SerializedConfig } from 'vitest'
-
-const config: SerializedConfig = vitest.projects[0].serializedConfig
-```
-
-### globalConfig
-
-`vitest` 初始化时所使用的测试配置。如果这是根项目，`globalConfig` 和 `config` 将引用同一个对象。这个配置对于不能在项目级别设置的值非常有用，比如 `coverage` 或 `reporters`。
-
-```ts
-import type { ResolvedConfig } from 'vitest/node'
-
-vitest.config === vitest.projects[0].globalConfig
-```
-
-### config
-
-这是项目的解析后的测试配置。
-
-### vite
-
-这是项目的 `ViteDevServer`。每个项目都有自己的 Vite 服务器。
-
-### browser
-
-此值仅在测试运行于浏览器中时才会被设置。如果启用了 `browser`，但测试尚未运行，这将为 `undefined`。如果您需要检查项目是否支持浏览器测试，请使用 `project.isBrowserSupported()` 方法。
-
-::: warning
-这个浏览器API尚在实验阶段，并不遵循语义化（SemVer）版本控制。浏览器API将会独立于其他API进行标准化。
-:::
-
-### provide
-
-这是一种在 [`config.provide`](/config/#provide) 字段之外向测试提供自定义值的方法。所有值在存储之前都会通过 [`structuredClone`](https://developer.mozilla.org/en-US/docs/Web/API/Window/structuredClone) 进行验证，但 `providedContext` 中的值本身不会被克隆。
-
-::: code-group
-```ts [node.js]
-import { createVitest } from 'vitest/node'
-
-const vitest = await createVitest('test')
-const project = vitest.projects.find(p => p.name === 'custom')
-project.provide('key', 'value')
-await vitest.start()
-```
-```ts [test.spec.js]
-import { inject } from 'vitest'
-const value = inject('key')
-```
-:::
-
-这些值可以动态提供。在测试中提供的值将在下一次运行时更新。
-
-### getProvidedContext
-
-这将返回上下文对象。每个项目也会继承由 `vitest.provide` 设置的全局上下文。
-
-```ts
-import { createVitest } from 'vitest/node'
-
-const vitest = await createVitest('test')
-vitest.provide('global', true)
-const project = vitest.projects.find(p => p.name === 'custom')
-project.provide('key', 'value')
-
-// { global: true, key: 'value' }
-const context = project.getProvidedContext()
-```
-
-::: tip
-项目上下文的值总是会覆盖全局的值。
-:::
-
-### createSpecification
-
-创建一个测试规范，该规范可用于 `vitest.runFiles`。规范将测试文件限定在特定的 `project` 和（可选的）`pool` 中。
-
-```ts
-import { resolve } from 'node:path/posix'
-import { createVitest } from 'vitest/node'
-
-const vitest = await createVitest('test')
-const project = vitest.projects[0]
-const specification = project.createSpecification(
-  resolve('./basic.test.ts'),
-  'threads', // 可选覆盖
-)
-await vitest.runFiles([specification], true)
-```
-
-::: warning
-`createSpecification` 需要一个绝对文件路径。但是它不会解析文件或检查文件系统上是否存在该文件。
-:::
-
-### isRootProject
-
-检查当前项目是否为根项目。我们也可以尝试调用 `vitest.getRootTestProject()` 来获取根项目。
-
-根项目通常不运行任何测试，并且不包含在 `vitest.projects` 中，除非我们明确地将根配置包含在它们的工作空间中。
-
-根项目的主要目标是设置全局配置。实际上，`rootProject.config` 直接引用了 `rootProject.globalConfig` 和 `vitest.config`。
-
-### globTestFiles
-
-匹配所有测试文件。这个函数返回一个包含常规测试和类型检查测试的对象：
-
-```ts
-interface GlobReturn {
-  /**
-   * 测试符合筛选条件的文件。
-   */
-  testFiles: string[]
-  /**
-   * 与筛选器匹配的类型检查测试文件。除非 `typecheck.enabled` 为 `true`，否则将为空。
-   */
-  typecheckTestFiles: string[]
-}
-```
-
-::: tip
-Vitest 使用 [fast-glob](https://www.npmjs.com/package/fast-glob) 来查找测试文件。`test.dir`、`test.root`、`root` 或 `process.cwd()` 定义了 `cwd` 选项。
-
-这个方法会查看几个配置选项：
-
-- `test.include`、`test.exclude` 用于查找常规测试文件；
-- `test.includeSource`、`test.exclude` 用于查找源代码中的测试；
-- `test.typecheck.include`、`test.typecheck.exclude` 用于查找类型检查测试。
-:::
-
-### matchesTestGlob
-
-此方法用于检查文件是否为常规测试文件。它使用与 `globTestFiles` 相同的配置属性进行验证。
-
-此方法还接受第二个参数，即源代码。这用于验证文件是否为源代码中的测试。如果我们需要多次为多个项目调用此方法，建议先读取文件一次，然后直接传递源代码。
-
-```ts
-import { resolve } from 'node:path/posix'
-import { createVitest } from 'vitest/node'
-
-const vitest = await createVitest('test')
-const project = vitest.projects[0]
-
-project.matchesTestGlob(resolve('./basic.test.ts')) // true
-project.matchesTestGlob(resolve('./basic.ts')) // false
-project.matchesTestGlob(resolve('./basic.ts'), `
-if (import.meta.vitest) {
-  // ...
-}
-`) // 如果设置了 `includeSource` 则为 true
-```
-
-### close
-
-关闭项目及其所有相关资源。此操作只能调用一次；关闭的承诺会被缓存，直到服务器重新启动。如果再次需要资源，请创建一个新项目。
-
-具体来说，这个方法会关闭 Vite 服务器，停止类型检查服务，如果浏览器正在运行则关闭它，删除存放源代码的临时目录，并重置提供的上下文。
diff --git a/guide/comparisons.md b/guide/comparisons.md
index df86e033..91057419 100644
--- a/guide/comparisons.md
+++ b/guide/comparisons.md
@@ -42,7 +42,7 @@ WebdriverIO 具有与 Cypress 相同的优点，允许你在真实的浏览器
 
 [@web/test-runner](https://modern-web.dev/docs/test-runner/overview/) 在无头浏览器中运行测试，提供与 web 应用程序相同的执行环境，而无需模仿浏览器 API 或 DOM。这也使得使用 devtools 在真实的浏览器中进行调试成为可能，尽管它没有像 Cypress 那样展示一个指示测试进度的 UI。
 
-要在 Vite 项目中使用 @web/test-runner，请使用[@remcovaes/web-test-runner-Vite-plugin](https://github.com/remcovaes/web-test-runner-vite-plugin)。@web/testrunner 不包括断言或模拟对象库，所以你需要自行添加它们。
+要在 Vite 项目中使用 @web/test-runner，请使用 [@remcovaes/web-test-runner-Vite-plugin](https://github.com/remcovaes/web-test-runner-vite-plugin)。@web/testrunner 不包括断言或模拟对象库，所以你需要自行添加它们。
 
 ## uvu
 

From efcf6df59ae44069bc67d2eab9989d4697869d81 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Sun, 30 Nov 2025 00:40:09 +0800
Subject: [PATCH 36/50] !docs: recovery /guide/browser/index

---
 guide/browser/index.md | 135 ++++++++++++++++++++++-------------------
 1 file changed, 72 insertions(+), 63 deletions(-)

diff --git a/guide/browser/index.md b/guide/browser/index.md
index 109639a7..1de5689e 100644
--- a/guide/browser/index.md
+++ b/guide/browser/index.md
@@ -8,7 +8,7 @@ outline: deep
 此页面提供有关 Vitest API 中实验性浏览器模式功能的信息，该功能允许你在浏览器中本地运行测试，提供对窗口和文档等浏览器全局变量的访问。此功能目前正在开发中，API 未来可能会更改。
 
 ::: tip
-如果你需要 `expect` 、`vi` ，或者像测试项目、类型测试等通用 API 的文档，请查看 [「快速上手」指南](/guide/)。
+如果你需要 `expect` 、`vi` ，或者像测试项目、类型测试等通用 API 的文档，请查看 [“快速起步” 指南](/guide/)。
 :::
 
 <img alt="Vitest UI" img-light src="/ui-browser-1-light.png">
@@ -35,7 +35,7 @@ bunx vitest init browser
 
 ### 手动安装 {#manual-installation}
 
-我们也可以手动安装软件包。默认情况下，浏览器模式不需要任何额外的 E2E provider 就能在本地运行测试，因为它会复用你现有的浏览器。
+我们也可以手动安装软件包。默认情况下，浏览器模式不需要任何额外的端到端 provider 就能在本地运行测试，因为它会复用你现有的浏览器。
 
 ::: code-group
 ```bash [npm]
@@ -104,9 +104,9 @@ import { playwright } from '@vitest/browser-playwright'
 export default defineConfig({
   test: {
     browser: {
-      provider: playwright(),
+      provider: playwright(), // 或者 'webdriverio'
       enabled: true,
-      // at least one instance is required
+      // 至少需要一个实例
       instances: [
         { browser: 'chromium' },
       ],
@@ -210,26 +210,6 @@ export default defineConfig({
   }
 })
 ```
-```ts [qwik]
-import { qwikVite } from '@builder.io/qwik/optimizer'
-import { playwright } from '@vitest/browser-playwright'
-
-// optional, run the tests in SSR mode
-import { testSSR } from 'vitest-browser-qwik/ssr-plugin'
-
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  plugins: [testSSR(), qwikVite()],
-  test: {
-    browser: {
-      enabled: true,
-      provider: playwright(),
-      instances: [{ browser: 'chromium' }]
-    },
-  },
-})
-```
 :::
 
 如果你想让部分测试通过基于 Node 的运行器执行，可以在配置中使用 [`projects`](/guide/projects) 选项，并为不同的测试策略提供独立的配置：
@@ -245,8 +225,8 @@ export default defineConfig({
     projects: [
       {
         test: {
-          // an example of file based convention,
-          // you don't have to follow it
+          // 基于文件命名约定的示例
+          // 非强制要求
           include: [
             'tests/unit/**/*.{test,spec}.ts',
             'tests/**/*.unit.{test,spec}.ts',
@@ -257,8 +237,8 @@ export default defineConfig({
       },
       {
         test: {
-          // an example of file based convention,
-          // you don't have to follow it
+          // 基于文件命名约定的示例
+          // 非强制要求
           include: [
             'tests/browser/**/*.{test,spec}.ts',
             'tests/**/*.browser.{test,spec}.ts',
@@ -278,9 +258,9 @@ export default defineConfig({
 })
 ```
 
-## Browser Option Types
+## 浏览器选项类型 {#browser-option-types}
 
-Vitest 中的浏览器选项取决于provider。如果在配置文件中传递 `--browser` 且未指定其名称，则 Vitest 将失败。可用选项：
+Vitest 中的浏览器选项取决于 provider。如果在配置文件中传递 `--browser` 且未指定其名称，则 Vitest 将失败。可用选项：
 - `webdriverio` 支持这些浏览器:
   - `firefox`
   - `chrome`
@@ -291,18 +271,62 @@ Vitest 中的浏览器选项取决于provider。如果在配置文件中传递 `
   - `webkit`
   - `chromium`
 
-## Browser Compatibility
+## TypeScript
+
+默认情况下，TypeScript 无法识别 providers 选项和额外的 `expect` 属性。如果我们不使用任何 providers ，请确保在测试、[设置文件](/config/#setupfiles) 或 [配置文件](/config/) 中引用 `@vitest/browser/matchers`，以获取额外的 `expect` 定义。如果我们使用自定义 providers ，请确保在同一文件中添加 `@vitest/browser/providers/playwright` 或 `@vitest/browser/providers/webdriverio`，以便 TypeScript 可以获取自定义选项的定义：
+
+::: code-group
+```ts [default]
+/// <reference types="@vitest/browser/matchers" />
+```
+```ts [playwright]
+/// <reference types="@vitest/browser/providers/playwright" />
+```
+```ts [webdriverio]
+/// <reference types="@vitest/browser/providers/webdriverio" />
+```
+:::
+
+或者，我们也可以将它们添加到 `tsconfig.json` 文件中的 `compilerOptions.types` 字段。请注意，在此字段中指定任何内容将禁用 `@types/*` 包的 [自动加载](https://www.typescriptlang.org/tsconfig/#types) 功能。
+
+::: code-group
+```json [default]
+{
+  "compilerOptions": {
+    "types": ["@vitest/browser/matchers"]
+  }
+}
+```
+```json [playwright]
+{
+  "compilerOptions": {
+    "types": ["@vitest/browser/providers/playwright"]
+  }
+}
+```
+```json [webdriverio]
+{
+  "compilerOptions": {
+    "types": ["@vitest/browser/providers/webdriverio"]
+  }
+}
+```
+:::
+
+## 浏览器兼容性 {#browser-compatibility}
 
 Vitest 使用 [Vite dev server](https://cn.vitejs.dev/guide/#browser-support) 来运行我们的测试，因此我们只支持 [`esbuild.target`](https://cn.vitejs.dev/config/shared-options#esbuild)选项（默认为 `esnext`）中指定的功能。
 
-默认情况下，Vite 的目标浏览器支持本地 [ES Modules](https://caniuse.com/es6-module)、本地 [ESM dynamic import](https://caniuse.com/es6-module-dynamic-import) 和 [`import.meta`](https://caniuse.com/mdn-javascript_operators_import_meta)。此外，我们还利用 [`BroadcastChannel`](https://caniuse.com/?search=BroadcastChannel)在 iframe 之间进行通信：
+默认情况下，Vite 的目标浏览器支持原生 [ES Modules](https://caniuse.com/es6-module)、原生 [ESM 动态导入](https://caniuse.com/es6-module-dynamic-import) 和 [`import.meta`](https://caniuse.com/mdn-javascript_operators_import_meta)。此外，我们还利用 [`BroadcastChannel`](https://caniuse.com/?search=BroadcastChannel)在 iframe 之间进行通信：
 
 - Chrome >=87
 - Firefox >=78
 - Safari >=15.4
 - Edge >=88
 
-## Running Tests
+## 运行测试 {#running-tests}
+
+当在 browser 选项中指定浏览器名称时，Vitest 默认会尝试使用 `preview` 启动指定浏览器，并运行测试。若不想使用 `preview`，可通过 `browser.provider` 选项配置自定义浏览器 provider。
 
 要使用 CLI 指定浏览器，请使用 `--browser` 标志后跟浏览器名称，如下所示：
 
@@ -322,13 +346,13 @@ npx vitest --browser.headless
 
 Vitest 默认会在开发模式下自动打开浏览器界面，测试会在页面中央的 iframe 中执行。你可以通过选择界面中的预设尺寸、在测试中调用 `page.viewport` 方法，或者在 [配置文件](/config/#browser-viewport) 中设置默认值来调整视口大小。
 
-## Headless
+## 无头模式 {#headless}
 
-headless 模式是浏览器模式下可用的另一个选项。在 headless 模式下，浏览器在没有用户界面的情况下在后台运行，这对于运行自动化测试非常有用。Vitest 中的 headless 选项可以设置为布尔值以启用或禁用 headless 模式。
+无头模式是浏览器模式下可用的另一个选项。在无头模式下，浏览器在没有用户界面的情况下在后台运行，这对于运行自动化测试非常有用。Vitest 中的 headless 选项可以设置为布尔值以启用或禁用无头模式。
 
-在使用 headless 模式时，Vitest 不会自动打开用户界面。如果我们希望继续使用用户界面，同时让测试以 headless 模式运行，我们可以安装`[@vitest/ui](/guide/ui)`包，并在运行Vitest时传递`--ui`标志。
+在使用无头模式时，Vitest 不会自动打开用户界面。如果我们希望继续使用用户界面，同时让测试以 无头模式运行，我们可以安装 [`@vitest/ui`](/guide/ui) 包，并在运行Vitest时传递 `--ui` 标志。
 
-这是启用 headless 模式的示例配置：
+这是启用无头模式的示例配置：
 
 ```ts [vitest.config.ts]
 import { defineConfig } from 'vitest/config'
@@ -345,19 +369,19 @@ export default defineConfig({
 })
 ```
 
-你还可以在 CLI 中使用 `--browser.headless` 标志设置 headless 模式，如下所示：
+你还可以在 CLI 中使用 `--browser.headless` 标志设置无头模式，如下所示：
 
 ```sh
 npx vitest --browser.headless
 ```
 
-在这种情况下，Vitest 将使用 Chrome 浏览器以 headless 模式运行。
+在这种情况下，Vitest 将使用 Chrome 浏览器以无头模式运行。
 
 ::: warning
 默认情况下Headless模式不可用。我们需要使用 [`playwright`](https://npmjs.com/package/playwright) 或 [`webdriverio`](https://www.npmjs.com/package/webdriverio) 提供程序来启用此功能。
 :::
 
-## Examples
+## 示例 {#examples}
 
 一般情况下，我们不需要任何依赖来使用浏览器模式：
 
@@ -367,7 +391,7 @@ import { page } from 'vitest/browser'
 import { render } from './my-render-function.js'
 
 test('properly handles form inputs', async () => {
-  render() // mount DOM elements
+  render() // 挂载 DOM 元素
 
   // 断言初始状态。
   await expect.element(page.getByText('Hi, my name is Alice')).toBeInTheDocument()
@@ -391,9 +415,9 @@ test('properly handles form inputs', async () => {
 
 其他框架也有社区提供的软件包：
 
-- [`vitest-browser-lit`](https://github.com/EskiMojo14/vitest-browser-lit) to render [lit](https://lit.dev) components
-- [`vitest-browser-preact`](https://github.com/JoviDeCroock/vitest-browser-preact) to render [preact](https://preactjs.com) components
-- [`vitest-browser-qwik`](https://github.com/kunai-consulting/vitest-browser-qwik) to render [qwik](https://qwik.dev) components
+- [`vitest-browser-lit`](https://github.com/EskiMojo14/vitest-browser-lit) 渲染 [lit](https://lit.dev) 组件
+- [`vitest-browser-preact`](https://github.com/JoviDeCroock/vitest-browser-preact) 渲染 [preact](https://preactjs.com) 组件
+- [`vitest-browser-qwik`](https://github.com/kunai-consulting/vitest-browser-qwik) 渲染 [qwik](https://qwik.dev) 组件
 
 如果你的框架没有被包含在内，请随时创建你自己的软件包——它是一个简单的封装，围绕着框架渲染器和 `page.elementLocator` API。我们会在本页面添加指向它的链接。请确保其名称以 `vitest-browser-` 开头。
 
@@ -406,7 +430,7 @@ import { page } from 'vitest/browser'
 await expect.element(page.getByText('Hello World')).toBeInTheDocument()
 ```
 
-Vitest 暴露了一个[上下文 API](/guide/browser/context)，其中包含一组在测试中可能对你有用的实用程序。例如，如果你需要进行交互操作，比如点击元素或在输入框中输入文本，你可以使用来自 `vitest/browser` 的 `userEvent`。更多内容请参阅[交互性 API](/guide/browser/interactivity-api)。
+Vitest 暴露了一个 [上下文 API](/guide/browser/context)，其中包含一组在测试中可能对你有用的实用程序。例如，如果你需要进行交互操作，比如点击元素或在输入框中输入文本，你可以使用来自 `vitest/browser` 的 `userEvent`。更多内容请参阅 [交互性 API](/guide/browser/interactivity-api)。
 
 ```ts
 import { page, userEvent } from 'vitest/browser'
@@ -499,29 +523,14 @@ test('greeting appears on click', async () => {
   await expect.element(greeting).toBeInTheDocument()
 })
 ```
-```tsx [qwik]
-import { render } from 'vitest-browser-qwik'
-import Greeting from './greeting'
-
-test('greeting appears on click', async () => {
-  // renderSSR and renderHook are also available
-  const screen = render(<Greeting />)
-
-  const button = screen.getByRole('button')
-  await button.click()
-  const greeting = screen.getByText(/hello world/iu)
-
-  await expect.element(greeting).toBeInTheDocument()
-})
-```
 :::
 
 Vitest 并不支持所有开箱即用的框架，但我们可以使用外部工具来运行这些框架的测试。我们还鼓励社区创建他们自己的 `vitest-browser` 封装程序，如果我们有这样的封装程序，请随时将其添加到上述示例中。
 
 对于不支持的框架，我们建议使用 `testing-library` 软件包：
 
-- [`@solidjs/testing-library`](https://testing-library.com/docs/solid-testing-library/intro) to render [solid](https://www.solidjs.com) components
-- [`@marko/testing-library`](https://testing-library.com/docs/marko-testing-library/intro) to render [marko](https://markojs.com) components
+- [`@solidjs/testing-library`](https://testing-library.com/docs/solid-testing-library/intro) 渲染 [solid](https://www.solidjs.com) 组件
+- [`@marko/testing-library`](https://testing-library.com/docs/marko-testing-library/intro) 渲染 [marko](https://markojs.com) 组件
 
 我们还可以在 [`browser-examples`](https://github.com/vitest-tests/browser-examples) 中查看更多的案例。
 
@@ -583,7 +592,7 @@ test('renders a message', async () => {
 
 在这类情况下，Vitest 会为相关 API 提供带有默认返回值的内置 mock，从而避免用户不小心使用同步弹窗等 Web API 时导致程序卡死。不过，仍然强烈建议用户自行对这些 Web API 进行 mock，以获得更稳定、可控的测试体验。更多内容可参考 [模拟](/guide/mocking) 章节。
 
-### 对模块的导出内容进行监听（Spy）。 {#spying-on-module-exports}
+### 对模块的导出内容进行监听（Spy） {#spying-on-module-exports}
 
 在浏览器模式下，Vitest 依赖浏览器自身对 ESM 模块的原生支持来加载模块。此时，模块的命名空间对象是不可修改的，这与 Node.js 测试中 Vitest 能够对模块执行打补丁不同。因此，你不能对通过 import 导入的对象使用 `vi.spyOn` ：
 

From 4f42594d32fa65a1103bab1609d0f61beae9d54d Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 1 Dec 2025 00:31:26 +0800
Subject: [PATCH 37/50] !docs: recovery /guide/browser/config

---
 guide/browser/config.md | 338 +++++++++++-----------------------------
 1 file changed, 93 insertions(+), 245 deletions(-)

diff --git a/guide/browser/config.md b/guide/browser/config.md
index 381e8275..21ed00a0 100644
--- a/guide/browser/config.md
+++ b/guide/browser/config.md
@@ -4,13 +4,12 @@
 
 ```ts [vitest.config.ts]
 import { defineConfig } from 'vitest/config'
-import { playwright } from '@vitest/browser-playwright'
 
 export default defineConfig({
   test: {
     browser: {
       enabled: true,
-      provider: playwright(),
+      provider: 'playwright',
       instances: [
         {
           browser: 'chromium',
@@ -22,7 +21,7 @@ export default defineConfig({
 })
 ```
 
-请参阅 ["配置参考"](/config/) 文章以获取不同的配置示例。
+请参阅 ["配置文件"](/config/) 文章以获取不同的配置示例。
 
 ::: warning
 此页面上列出的 _所有选项_ 都位于配置中的 `test` 属性内：
@@ -47,11 +46,23 @@ export default defineConfig({
 ## browser.instances
 
 - **类型:** `BrowserConfig`
-- **默认值:** `[]`
+- **默认值:** `[{ browser: name }]`
+
+定义多个浏览器设置。每个配置必须至少有一个 `browser` 字段。配置支持我们的提供者配置：
+
+- [配置 Playwright](/guide/browser/playwright)
+- [配置 WebdriverIO](/guide/browser/webdriverio)
+
+::: tip
+为了在使用内置提供者时获得更好的类型安全性，我们应该在 [配置文件](/config/) 中引用以下类型之一（针对我们使用的提供者）：
 
-定义多个浏览器设置。每个配置必须至少有一个 `browser` 字段。
+```ts
+/// <reference types="@vitest/browser/providers/playwright" />
+/// <reference types="@vitest/browser/providers/webdriverio" />
+```
+:::
 
-你可以指定大部分[项目选项](/config/)(未标记<NonProjectOption />图标的选项)和一些 `browser` 选项，如`browser.testerHtmlPath`。
+你可以指定大部分 [配置选项](/config/) (未标记<NonProjectOption />图标的选项)和一些 `browser` 选项，如`browser.testerHtmlPath`。
 
 ::: warning
 每个浏览器配置都从根配置继承选项：
@@ -76,7 +87,9 @@ export default defineConfig({
 })
 ```
 
-有关更多示例，请参阅 ["多设置" 指南](/guide/browser/multiple-setups)。
+在开发过程中，Vitest 仅支持一个 [非无头](#browser-headless) 配置。我们可以通过在配置中指定 `headless: false`，或提供 `--browser.headless=false` 标志，或使用 `--project=chromium` 标志过滤项目来限制有头项目。
+
+有关更多示例，请参阅 ["多种设置" 指南](/guide/browser/multiple-setups)。
 :::
 
 可用的 `browser` 选项列表：
@@ -89,7 +102,22 @@ export default defineConfig({
 - [`browser.screenshotFailures`](#browser-screenshotfailures)
 - [`browser.provider`](#browser-provider)
 
-在底层，Vitest 将这些实例转换为共享单个 Vite 服务器的单独[测试项目](/advanced/api/test-project)，以获得更好的缓存性能。
+在底层，Vitest 将这些实例转换为共享单个 Vite 服务器的单独 [测试项目](/advanced/api/test-project)，以获得更好的缓存性能。
+
+## browser.name <Badge type="danger">已弃用</Badge> {#browser-name}
+
+- **类型:** `string`
+- **CLI:** `--browser=safari`
+
+::: danger 已弃用
+此 API 已弃用，并将在 Vitest 4 中移除。请改用 [`browser.instances`](#browser-instances) 选项。
+:::
+
+在特定浏览器中运行所有测试。不同提供者中的可能选项：
+
+- `webdriverio`: `firefox`, `chrome`, `edge`, `safari`
+- `playwright`: `firefox`, `webkit`, `chromium`
+- 自定义：任何将传递给提供者的字符串
 
 ## browser.headless
 
@@ -123,84 +151,68 @@ HTML 入口点的路径。可以是相对于项目根目录的路径。此文件
 
 ## browser.provider {#browser-provider}
 
-- **类型:** `BrowserProviderOption`
+- **类型:** `'webdriverio' | 'playwright' | 'preview' | string`
 - **默认值:** `'preview'`
-- **命令行终端:** `--browser.provider=playwright`
-
-提供者工厂的返回值。你可以从 `@vitest/browser-<provider-name>` 导入工厂函数，或者创建自己的提供者：
+- **CLI:** `--browser.provider=playwright`
 
-```ts{8-10}
-import { playwright } from '@vitest/browser-playwright'
-import { webdriverio } from '@vitest/browser-webdriverio'
-import { preview } from '@vitest/browser-preview'
+在运行浏览器测试时使用的提供者路径。Vitest 提供了三个提供者，分别是 `preview`（默认）、`webdriverio` 和 `playwright`。自定义提供者应使用 `default` 导出，并具有以下类型：
 
-export default defineConfig({
-  test: {
-    browser: {
-      provider: playwright(),
-      provider: webdriverio(),
-      provider: preview(), // default
-    },
-  },
-})
+```ts
+export interface BrowserProvider {
+  name: string
+  supportsParallelism: boolean
+  getSupportedBrowsers: () => readonly string[]
+  beforeCommand?: (command: string, args: unknown[]) => Awaitable<void>
+  afterCommand?: (command: string, args: unknown[]) => Awaitable<void>
+  getCommandsContext: (sessionId: string) => Record<string, unknown>
+  openPage: (sessionId: string, url: string, beforeNavigate?: () => Promise<void>) => Promise<void>
+  getCDPSession?: (sessionId: string) => Promise<CDPSession>
+  close: () => Awaitable<void>
+  initialize: (
+    ctx: TestProject,
+    options: BrowserProviderInitializationOptions
+  ) => Awaitable<void>
+}
 ```
 
-要配置提供者如何初始化浏览器，你可以将选项传递给工厂函数：
+::: danger 高级 API
+自定义提供者 API 高度实验性，并且可能在补丁版本之间发生变化。如果你只需要在浏览器中运行测试，请改用 [`browser.instances`](#browser-instances) 选项。
+:::
+
+## browser.providerOptions <Badge type="danger">已弃用</Badge> {#browser-provideroptions}
+
+- **类型:** `BrowserProviderOptions`
+
+::: danger 已弃用
+此 API 已弃用，并将在 Vitest 4 中移除。请改用 [`browser.instances`](#browser-instances) 选项。
+:::
+
+调用 `provider.initialize` 时传递给提供者的选项。
 
-```ts{7-13,20-26}
-import { playwright } from '@vitest/browser-playwright'
+```ts
+import { defineConfig } from 'vitest/config'
 
 export default defineConfig({
   test: {
     browser: {
-      // shared provider options between all instances
-      provider: playwright({
-        launchOptions: {
-          slowMo: 50,
-          channel: 'chrome-beta',
+      providerOptions: {
+        launch: {
+          devtools: true,
         },
-        actionTimeout: 5_000,
-      }),
-      instances: [
-        { browser: 'chromium' },
-        {
-          browser: 'firefox',
-          // overriding options only for a single instance
-          // this will NOT merge options with the parent one
-          provider: playwright({
-            launchOptions: {
-              firefoxUserPrefs: {
-                'browser.startup.homepage': 'https://example.com',
-              },
-            },
-          })
-        }
-      ],
+      },
     },
   },
 })
 ```
 
-### Custom Provider <Badge type="danger">advanced</Badge>
-
-::: danger ADVANCED API
-自定义提供者 API 高度实验性，并且可能在补丁版本之间发生变化。如果你只需要在浏览器中运行测试，请改用 [`browser.instances`](#browser-instances) 选项。
-:::
+::: tip
+为了在使用内置提供者时获得更好的类型安全性，我们应该在 [配置文件](/config/) 中引用以下类型之一（针对我们使用的提供者）：
 
 ```ts
-export interface BrowserProvider {
-  name: string
-  mocker?: BrowserModuleMocker
-  /**
-   * @experimental opt-in into file parallelisation
-   */
-  supportsParallelism: boolean
-  getCommandsContext: (sessionId: string) => Record<string, unknown>
-  openPage: (sessionId: string, url: string) => Promise<void>
-  getCDPSession?: (sessionId: string) => Promise<CDPSession>
-  close: () => Awaitable<void>
-}
+/// <reference types="@vitest/browser/providers/playwright" />
+/// <reference types="@vitest/browser/providers/webdriverio" />
 ```
+:::
 
 ## browser.ui
 
@@ -282,12 +294,25 @@ export interface BrowserScript {
 }
 ```
 
+## browser.testerScripts
+
+- **类型:** `BrowserScript[]`
+- **默认值:** `[]`
+
+::: danger 已弃用
+此 API 已弃用，并将在 Vitest 4 中移除。请改用 [`browser.testerHtmlPath`](#browser-testerhtmlpath) 字段。
+:::
+
+在测试环境初始化之前应注入到测试器 HTML 中的自定义脚本。这对于注入 Vitest 浏览器实现所需的 polyfill 非常有用。在几乎所有情况下，建议使用 [`setupFiles`](#setupfiles) 代替此选项。
+
+脚本的 `src` 和 `content` 将由 Vite 插件处理。
+
 ## browser.commands
 
 - **类型:** `Record<string, BrowserCommand>`
 - **默认值:** `{ readFile, writeFile, ... }`
 
-可以在浏览器测试中从 `vitest/browser` 导入的自定义[命令](/guide/browser/commands)。
+可以从 `@vitest/browser/commands` 导入的自定义 [命令](/guide/browser/commands)。
 
 ## browser.connectTimeout
 
@@ -299,180 +324,3 @@ export interface BrowserScript {
 ::: info
 这是浏览器与 Vitest 服务器建立 WebSocket 连接所需的时间。在正常情况下，此超时不应被触发。
 :::
-
-## browser.trace
-
-- **类型：** `'on' | 'off' | 'on-first-retry' | 'on-all-retries' | 'retain-on-failure' | object`
-- **命令行终端:** `--browser.trace=on`, `--browser.trace=retain-on-failure`
-- **Default:** `'off'`
-
-Capture a trace of your browser test runs. You can preview traces with [Playwright Trace Viewer](https://trace.playwright.dev/).
-
-This options supports the following values:
-
-- `'on'` - capture trace for all tests. (not recommended as it's performance heavy)
-- `'off'` - do not capture traces.
-- `'on-first-retry'` - capture trace only when retrying the test for the first time.
-- `'on-all-retries'` - capture trace on every retry of the test.
-- `'retain-on-failure'` - capture trace only for tests that fail. This will automatically delete traces for tests that pass.
-- `object` - an object with the following shape:
-
-```ts
-interface TraceOptions {
-  mode: 'on' | 'off' | 'on-first-retry' | 'on-all-retries' | 'retain-on-failure'
-  /**
-   * The directory where all traces will be stored. By default, Vitest
-   * stores all traces in `__traces__` folder close to the test file.
-   */
-  tracesDir?: string
-  /**
-   * Whether to capture screenshots during tracing. Screenshots are used to build a timeline preview.
-   * @default true
-   */
-  screenshots?: boolean
-  /**
-   * If this option is true tracing will
-   * - capture DOM snapshot on every action
-   * - record network activity
-   * @default true
-   */
-  snapshots?: boolean
-}
-```
-
-::: danger WARNING
-This option is supported only by the [**playwright**](/guide/browser/playwright) provider.
-:::
-
-## browser.trackUnhandledErrors
-
-- **类型：** `boolean`
-- **Default:** `true`
-
-启用对未捕获错误和异常的跟踪，以便 Vitest 报告。
-
-如果需要隐藏某些错误，建议使用 [`onUnhandledError`](/config/#onunhandlederror) 选项。
-
-禁用此功能将完全移除所有 Vitest 的错误处理机制，有助于在启用“暂停于异常”功能时进行调试。
-
-## browser.expect
-
-- **类型：** `ExpectOptions`
-
-### browser.expect.toMatchScreenshot
-
-[`toMatchScreenshot`](/guide/browser/assertion-api.html#tomatchscreenshot) 断言的默认选项。
-这些选项将应用于所有截图断言。
-
-::: tip
-为截图断言设置全局默认值，有助于在整个测试套件中保持一致性，并减少单个测试中的重复。如果需要，你仍可以在特定测试用例的断言级别覆盖这些默认值。
-:::
-
-```ts
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    browser: {
-      enabled: true,
-      expect: {
-        toMatchScreenshot: {
-          comparatorName: 'pixelmatch',
-          comparatorOptions: {
-            threshold: 0.2,
-            allowedMismatchedPixels: 100,
-          },
-          resolveScreenshotPath: ({ arg, browserName, ext, testFileName }) =>
-            `custom-screenshots/${testFileName}/${arg}-${browserName}${ext}`,
-        },
-      },
-    },
-  },
-})
-```
-
-`toMatchScreenshot` 断言中可用的 [所有选项](/guide/browser/assertion-api#options) 均可在此配置。此外，还提供了两个路径解析函数：`resolveScreenshotPath` 和 `resolveDiffPath`。
-
-#### browser.expect.toMatchScreenshot.resolveScreenshotPath
-
-- **类型：** `(data: PathResolveData) => string`
-- **Default output:** `` `${root}/${testFileDirectory}/${screenshotDirectory}/${testFileName}/${arg}-${browserName}-${platform}${ext}` ``
-
-一个用于自定义参考截图存储位置的函数。该函数接收一个包含以下属性的对象：
-
-- `arg: string`
-
-  路径**不含**扩展名，已清理且相对于测试文件。
-  这来自传递给 `toMatchScreenshot` 的参数；如果没有参数，将使用自动生成的名称。
-
-  ```ts
-  test('calls `onClick`', () => {
-    expect(locator).toMatchScreenshot()
-    // arg = "calls-onclick-1"
-  })
-
-  expect(locator).toMatchScreenshot('foo/bar/baz.png')
-  // arg = "foo/bar/baz"
-
-  expect(locator).toMatchScreenshot('../foo/bar/baz.png')
-  // arg = "foo/bar/baz"
-  ```
-
-- `ext: string`
-
-  截图扩展名，带前导点。
-
-  可以通过传递给 `toMatchScreenshot` 的参数设置，但如果使用了不支持的扩展名，值将回退为 `'.png'`。
-
-- `browserName: string`
-
-  实例的浏览器名称。
-
-- `platform: NodeJS.Platform`
-
-  [`process.platform`](https://nodejs.org/docs/v22.16.0/api/process.html#processplatform) 属性的值。
-
-- `screenshotDirectory: string`
-
-  如果未提供值，则为 [`browser.screenshotDirectory`](/guide/browser/config#browser-screenshotdirectory)。
-
-- `root: string`
-
-  项目根目录（[`root`](/config/#root)）的绝对路径。
-
-- `testFileDirectory: string`
-
-  测试文件的路径，相对于项目的根目录（[`root`](/config/#root)）。
-
-- `testFileName: string`
-
-  测试文件的文件名。
-
-- `testName: string`
-
-  [`test`](/api/#test) 的名称，包括父级 [`describe`](/api/#describe) ，已清理。
-
-- `attachmentsDir: string`
-
-如果未提供值，则为 [`attachmentsDir`](/config/#attachmentsdir) 提供的默认值。
-
-例如，按浏览器分组截图：
-
-```ts
-resolveScreenshotPath: ({ arg, browserName, ext, root, testFileName }) =>
-  `${root}/screenshots/${browserName}/${testFileName}/${arg}${ext}`
-```
-
-#### browser.expect.toMatchScreenshot.resolveDiffPath
-
-- **类型：** `(data: PathResolveData) => string`
-- **Default output:** `` `${root}/${attachmentsDir}/${testFileDirectory}/${testFileName}/${arg}-${browserName}-${platform}${ext}` ``
-
-一个用于自定义截图比较失败时差异图像存储位置的函数。它接收与 [`resolveScreenshotPath`](#browser-expect-tomatchscreenshot-resolvescreenshotpath) 相同的数据对象。
-
-例如，将差异图像存储在附件的子目录中：
-
-```ts
-resolveDiffPath: ({ arg, attachmentsDir, browserName, ext, root, testFileName }) =>
-  `${root}/${attachmentsDir}/screenshot-diffs/${testFileName}/${arg}-${browserName}${ext}`
-```

From 6148fbd923875059017df8068a0412a66e9c2e60 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 1 Dec 2025 00:58:06 +0800
Subject: [PATCH 38/50] !docs: recovery /guide/browser/playwright

---
 .vitepress/config.ts        |  4 +-
 config/index.md             |  4 +-
 guide/browser/config.md     |  6 +--
 guide/browser/playwright.md | 87 ++++++++++++++++++-------------------
 guide/environment.md        |  2 +-
 guide/migration.md          |  2 +-
 6 files changed, 52 insertions(+), 53 deletions(-)

diff --git a/.vitepress/config.ts b/.vitepress/config.ts
index 6dac9959..4f61a370 100644
--- a/.vitepress/config.ts
+++ b/.vitepress/config.ts
@@ -296,9 +296,9 @@ export default ({ mode }: { mode: string }) => {
               collapsed: false,
               items: [
                 {
-                  text: '浏览器模式配置',
+                  text: '浏览器配置',
                   link: '/guide/browser/config',
-                  docFooterText: '浏览器模式配置 | 浏览器模式',
+                  docFooterText: '浏览器配置 | 浏览器模式',
                 },
                 {
                   text: '配置 Playwright',
diff --git a/config/index.md b/config/index.md
index dec7c6db..9d37cbc3 100644
--- a/config/index.md
+++ b/config/index.md
@@ -2532,7 +2532,7 @@ Expand all common lines.
 
 相对于[root](#root) 的 [workspace](/guide/workspace) 配置文件的路径。
 
-Since Vitest 3, you can also define the workspace array in the root config. If the `workspace` is defined in the config manually, Vitest will ignore the `vitest.workspace` file in the root.
+自 Vitest 3 起，您也可以在根配置中直接定义 `workspace` 数组。若手动在配置中声明了 workspace 参数，Vitest 将忽略项目根目录下的 `vitest.workspace` 文件。
 
 ### workspace<NonProjectOption />
 
@@ -2593,7 +2593,7 @@ Vitest API 在 [reporters](#reporters) 中接收任务时是否应包含 `locati
 
 自定义快照环境实现的路径。如果在不支持 Node.js API 的环境中运行测试，该选项将非常有用。此选项对浏览器运行程序没有任何影响。
 
-该对象应具有 `SnapshotEnvironment` 的形状，用于解析和读/写快照文件：
+该对象应具有 `SnapshotEnvironment` 的接口规范，用于解析和读/写快照文件：
 
 ```ts
 export interface SnapshotEnvironment {
diff --git a/guide/browser/config.md b/guide/browser/config.md
index 21ed00a0..b8ee8eb7 100644
--- a/guide/browser/config.md
+++ b/guide/browser/config.md
@@ -1,4 +1,4 @@
-# 浏览器配置参考 {#browser-config-reference}
+# 浏览器配置 {#browser-config-reference}
 
 我们可以通过更新 [配置文件](/config/) 中的 `test.browser` 字段来更改浏览器配置。一个简单的配置文件示例如下：
 
@@ -155,7 +155,7 @@ HTML 入口点的路径。可以是相对于项目根目录的路径。此文件
 - **默认值:** `'preview'`
 - **CLI:** `--browser.provider=playwright`
 
-在运行浏览器测试时使用的提供者路径。Vitest 提供了三个提供者，分别是 `preview`（默认）、`webdriverio` 和 `playwright`。自定义提供者应使用 `default` 导出，并具有以下类型：
+在运行浏览器测试时使用的提供者路径。Vitest 提供了三个提供者，分别是 `preview`（默认）、`webdriverio` 和 `playwright`。自定义提供者应使用 `default` 导出，并符合以下接口规范：
 
 ```ts
 export interface BrowserProvider {
@@ -261,7 +261,7 @@ export default defineConfig({
 
 在测试 iframe 初始化之前应注入到编排器 HTML 中的自定义脚本。此 HTML 文档仅设置 iframe，并不实际导入我们的代码。
 
-脚本的 `src` 和 `content` 将由 Vite 插件处理。脚本应提供以下形状：
+脚本的 `src` 和 `content` 将由 Vite 插件处理。脚本应符合以下接口规范：
 
 ```ts
 export interface BrowserScript {
diff --git a/guide/browser/playwright.md b/guide/browser/playwright.md
index 170f91df..59f93cba 100644
--- a/guide/browser/playwright.md
+++ b/guide/browser/playwright.md
@@ -1,52 +1,36 @@
 # 配置 Playwright {#configuring-playwright}
 
-要使用 playwright 运行测试，你需要安装 [`@vitest/browser-playwright`](https://www.npmjs.com/package/@vitest/browser-playwright) npm 包，并在配置中的 `test.browser.provider` 属性中指定其 `playwright` 导出：
+默认情况下，TypeScript 无法识别提供者选项和额外的 `expect` 属性。请确保引用 `@vitest/browser/providers/playwright`，以便 TypeScript 可以获取自定义选项的定义：
 
-```ts [vitest.config.js]
-import { playwright } from '@vitest/browser-playwright'
-import { defineConfig } from 'vitest/config'
+```ts [vitest.shims.d.ts]
+/// <reference types="@vitest/browser/providers/playwright" />
+```
 
-export default defineConfig({
-  test: {
-    browser: {
-      provider: playwright(),
-      instances: [{ browser: 'chromium' }]
-    },
-  },
-})
+或者，我们也可以将其添加到 `tsconfig.json` 文件中的 `compilerOptions.types` 字段。请注意，在此字段中指定任何内容将禁用 `@types/*` 包的 [自动加载](https://www.typescriptlang.org/tsconfig/#types)。
+
+```json [tsconfig.json]
+{
+  "compilerOptions": {
+    "types": ["@vitest/browser/providers/playwright"]
+  }
+}
 ```
 
-你可以在顶层或实例内部调用 `playwright` 时配置 [`launchOptions`](https://playwright.dev/docs/api/class-browsertype#browser-type-launch)、[`connectOptions`](https://playwright.dev/docs/api/class-browsertype#browser-type-connect) 和 [`contextOptions`](https://playwright.dev/docs/api/class-browser#browser-new-context)：
+Vitest 打开一个页面以在同一文件中运行所有测试。我们可以在 `instances` 中配置 `launch` 、`connect` 和 `context` 属性：
 
-```ts{7-14,21-26} [vitest.config.js]
-import { playwright } from '@vitest/browser-playwright'
+```ts{9-11} [vitest.config.ts]
 import { defineConfig } from 'vitest/config'
 
 export default defineConfig({
   test: {
     browser: {
-      // shared provider options between all instances
-      provider: playwright({
-        launchOptions: {
-          slowMo: 50,
-          channel: 'chrome-beta',
-        },
-        actionTimeout: 5_000,
-      }),
       instances: [
-        { browser: 'chromium' },
         {
           browser: 'firefox',
-          // overriding options only for a single instance
-          // this will NOT merge options with the parent one
-          provider: playwright({
-            launchOptions: {
-              firefoxUserPrefs: {
-                'browser.startup.homepage': 'https://example.com',
-              },
-            },
-          })
-        }
+          launch: {},
+          connect: {},
+          context: {},
+        },
       ],
     },
   },
@@ -54,10 +38,25 @@ export default defineConfig({
 ```
 
 ::: warning
-Unlike Playwright test runner, Vitest opens a _single_ page to run all tests that are defined in the same file. This means that isolation is restricted to a single test file, not to every individual test.
+在 Vitest 3 之前，这些选项位于 `test.browser.providerOptions` 属性中：
+
+```ts [vitest.config.ts]
+export default defineConfig({
+  test: {
+    browser: {
+      providerOptions: {
+        launch: {},
+        context: {},
+      },
+    },
+  },
+})
+```
+
+`providerOptions` 已被弃用，推荐使用 `instances`。
 :::
 
-## launchOptions
+## launch
 
 这些选项直接传递给 `playwright[browser].launch` 命令。我们可以在 [Playwright 文档](https://playwright.dev/docs/api/class-browsertype#browser-type-launch) 中阅读有关该命令和可用参数的更多信息。
 
@@ -67,17 +66,17 @@ Vitest 将忽略 `launch.headless` 选项。请改用 [`test.browser.headless`](
 请注意，如果启用了 [`--inspect`](/guide/cli#inspect)，Vitest 会将调试标志推送到 `launch.args`。
 :::
 
-## connectOptions
+## connect <Version>3.2.0</Version> {#connect}
 
-这些选项直接传递给 `playwright[browser].connect` 命令。你可以在 [Playwright 文档](https://playwright.dev/docs/api/class-browsertype#browser-type-connect) 中了解更多关于该命令和可用参数的信息。
+这些选项会直接传递给 `playwright[browser].connect` 命令。您可以在 [Playwright 文档](https://playwright.dev/docs/api/class-browsertype#browser-type-connect) 中，查阅该命令的详细说明及可用参数。
 
 ::: warning
-由于此命令连接到现有的 Playwright 服务器，任何 `launch` 选项都将被忽略。
+由于此命令会连接至现有的 Playwright 服务端，所有 `launch` 相关配置都将被忽略。
 :::
 
-## contextOptions
+## context
 
-Vitest 通过调用 [`browser.newContext()`](https://playwright.dev/docs/api/class-browsercontext) 为每个测试文件创建一个新的上下文。你可以通过指定 [自定义参数](https://playwright.dev/docs/api/class-browser#browser-new-context) 来配置此行为。
+Vitest 通过调用 [`browser.newContext()`](https://playwright.dev/docs/api/class-browsercontext) 为每个测试文件创建一个新的上下文。我们可以通过指定 [自定义参数](https://playwright.dev/docs/api/class-apirequest#api-request-new-context) 来配置此行为。
 
 ::: tip
 请注意，上下文是为每个 _测试文件_ 创建的，而不是像 Playwright 测试运行器那样为每个 _测试_ 创建。
@@ -89,16 +88,16 @@ Vitest 通过调用 [`browser.newContext()`](https://playwright.dev/docs/api/cla
 建议使用 [`test.browser.viewport`](/guide/browser/config#browser-headless) 而不是在此处指定它，因为在无头模式下运行测试时会丢失该设置。
 :::
 
-## `actionTimeout`
+## `actionTimeout` <Version>3.0.0</Version>
 
-- **Default:** no timeout
+- **默认值：** 无超时，3.0.0 之前为 1 秒
 
 此值配置 Playwright 等待所有可访问性检查通过并 [操作](/guide/browser/interactivity-api) 实际完成的默认超时时间。
 
 我们还可以为每个操作配置操作超时：
 
 ```ts
-import { page, userEvent } from 'vitest/browser'
+import { page, userEvent } from '@vitest/browser/context'
 
 await userEvent.click(page.getByRole('button'), {
   timeout: 1_000,
diff --git a/guide/environment.md b/guide/environment.md
index 11388a57..d695facb 100644
--- a/guide/environment.md
+++ b/guide/environment.md
@@ -41,7 +41,7 @@ test('test', () => {
 
 ## 自定义环境 {#custom-environment}
 
-你可以创建自己的包来扩展 Vitest 环境。为此，请创建一个名为 `vitest-environment-${name}` 的包，或者指定一个有效的 JS/TS 文件路径。该包应该导出一个形状为 `Environment` 的对象。
+你可以创建自己的包来扩展 Vitest 环境。为此，请创建一个名为 `vitest-environment-${name}` 的包，或者指定一个有效的 JS/TS 文件路径。该包应该导出一个接口规范为 `Environment` 的对象。
 
 ```ts
 import type { Environment } from 'vitest/environments'
diff --git a/guide/migration.md b/guide/migration.md
index feafbcc6..cea5e126 100644
--- a/guide/migration.md
+++ b/guide/migration.md
@@ -419,7 +419,7 @@ expect({ foo: 'bar' }).toMatchInlineSnapshot(`
 
 选项 `coverage.all` 现在默认启用。这意味着，所有符合 `coverage.include` 模式的项目文件都将被处理，即使它们未被执行。
 
-更改了覆盖阈值 API 的形状，现在它支持使用 glob 模式为特定文件指定阈值：
+更改了覆盖阈值 API 的接口规范，现在它支持使用 glob 模式为特定文件指定阈值：
 
 ```diff
 export default defineConfig({

From d5e4a5bf467309812cabfcbb059f8d7fcc880bf0 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 1 Dec 2025 01:01:43 +0800
Subject: [PATCH 39/50] !docs: recovery /guide/browser/webdriverio

---
 guide/browser/webdriverio.md | 75 +++++++++++++++++++-----------------
 1 file changed, 40 insertions(+), 35 deletions(-)

diff --git a/guide/browser/webdriverio.md b/guide/browser/webdriverio.md
index 25784f6a..213f6553 100644
--- a/guide/browser/webdriverio.md
+++ b/guide/browser/webdriverio.md
@@ -1,64 +1,69 @@
-# 配置 WebdriverIO {#configuring-webdriverio}
+# 配置 WebdriverIO  {#configuring-webdriverio}
 
-::: info Playwright 与 WebdriverIO
+::: info 对比 Playwright 与 WebdriverIO
 如果我们的项目尚未使用 WebdriverIO，我们建议从 [Playwright](/guide/browser/playwright) 开始，因为它更易于配置且 API 更灵活。
 :::
 
-要使用 WebdriverIO 运行测试，你需要安装 [`@vitest/browser-webdriverio`](https://www.npmjs.com/package/@vitest/browser-webdriverio) npm 包，并在配置中的 `test.browser.provider` 属性中指定其 `webdriverio` 导出：
+默认情况下，TypeScript 无法识别提供者选项和额外的 `expect` 属性。请确保引用 `@vitest/browser/providers/webdriverio`，以便 TypeScript 可以获取自定义选项的定义：
 
-```ts [vitest.config.js]
-import { webdriverio } from '@vitest/browser-webdriverio'
+```ts [vitest.shims.d.ts]
+/// <reference types="@vitest/browser/providers/webdriverio" />
+```
+
+或者，我们也可以将其添加到 `tsconfig.json` 文件中的 `compilerOptions.types` 字段。请注意，在此字段中指定任何内容将禁用 `@types/*` 包的 [自动加载](https://www.typescriptlang.org/tsconfig/#types)。
+
+```json [tsconfig.json]
+{
+  "compilerOptions": {
+    "types": ["@vitest/browser/providers/webdriverio"]
+  }
+}
+```
+
+Vitest 打开一个页面以在同一文件中运行所有测试。我们可以在 `instances` 中配置 `RemoteOptions` 中指定的任何属性：
+
+```ts{9-12} [vitest.config.ts]
 import { defineConfig } from 'vitest/config'
 
 export default defineConfig({
   test: {
     browser: {
-      provider: webdriverio(),
-      instances: [{ browser: 'chrome' }]
+      instances: [
+        {
+          browser: 'chrome',
+          capabilities: {
+            browserVersion: 86,
+            platformName: 'Windows 10',
+          },
+        },
+      ],
     },
   },
 })
 ```
 
-你可以配置 [`remote`](https://webdriver.io/docs/api/modules/#remoteoptions-modifier) 函数接受的所有参数：
-
-```ts{8-12,19-25} [vitest.config.js]
-import { webdriverio } from '@vitest/browser-webdriverio'
-import { defineConfig } from 'vitest/config'
+::: warning
+在 Vitest 3 之前，这些选项位于 `test.browser.providerOptions` 属性中：
 
+```ts [vitest.config.ts]
 export default defineConfig({
   test: {
     browser: {
-      // shared provider options between all instances
-      provider: webdriverio({
-        capabilities: {
-          browserVersion: '82',
-        },
-      }),
-      instances: [
-        { browser: 'chrome' },
-        {
-          browser: 'firefox',
-          // overriding options only for a single instance
-          // this will NOT merge options with the parent one
-          provider: webdriverio({
-            capabilities: {
-              'moz:firefoxOptions': {
-                args: ['--disable-gpu'],
-              },
-            },
-          })
-        },
-      ],
+      providerOptions: {
+        capabilities: {},
+      },
     },
   },
 })
 ```
 
-你可以在 [WebdriverIO 文档](https://webdriver.io/docs/configuration/) 中找到大多数可用选项。请注意，Vitest 将忽略所有测试运行器选项，因为我们仅使用 `webdriverio` 的浏览器功能。
+`providerOptions` 已被弃用，推荐使用 `instances`。
+:::
+
+我们可以在 [WebdriverIO 文档](https://webdriver.io/docs/configuration/) 中找到大多数可用选项。请注意，Vitest 将忽略所有测试运行器选项，因为我们仅使用 `webdriverio` 的浏览器功能。
 
 ::: tip
 最有用的选项位于 `capabilities` 对象上。WebdriverIO 允许嵌套功能，但 Vitest 将忽略这些选项，因为我们依赖于不同的机制来生成多个浏览器。
 
-请注意，Vitest 将忽略 `capabilities.browserName` — 请改用 [`test.browser.instances.browser`](/guide/browser/config#browser-capabilities-name)。
+请注意，Vitest 将忽略 `capabilities.browserName`。请改用 [`test.browser.instances.name`](/guide/browser/config#browser-capabilities-name)。
 :::

From 323db582cb4a23c26b3b1e403b8233c6ca4bb856 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 1 Dec 2025 01:03:32 +0800
Subject: [PATCH 40/50] !docs: recovery /guide/browser/preview

---
 .vitepress/config.ts     |  7 +------
 guide/browser/preview.md | 32 --------------------------------
 2 files changed, 1 insertion(+), 38 deletions(-)
 delete mode 100644 guide/browser/preview.md

diff --git a/.vitepress/config.ts b/.vitepress/config.ts
index 4f61a370..d88aba88 100644
--- a/.vitepress/config.ts
+++ b/.vitepress/config.ts
@@ -298,7 +298,7 @@ export default ({ mode }: { mode: string }) => {
                 {
                   text: '浏览器配置',
                   link: '/guide/browser/config',
-                  docFooterText: '浏览器配置 | 浏览器模式',
+                  docFooterText: '浏览器模式配置 | 浏览器模式',
                 },
                 {
                   text: '配置 Playwright',
@@ -310,11 +310,6 @@ export default ({ mode }: { mode: string }) => {
                   link: '/guide/browser/webdriverio',
                   docFooterText: '配置 WebdriverIO | 浏览器模式',
                 },
-                {
-                  text: 'Configuring Preview',
-                  link: '/guide/browser/preview',
-                  docFooterText: 'Configuring Preview | 浏览器模式',
-                },
               ],
             },
             {
diff --git a/guide/browser/preview.md b/guide/browser/preview.md
deleted file mode 100644
index 8b8bb3d4..00000000
--- a/guide/browser/preview.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# Configuring Preview
-
-::: warning
-The `preview` provider's main functionality is to show tests in a real browser environment. However, it does not support advanced browser automation features like multiple browser instances or headless mode. For more complex scenarios, consider using [Playwright](/guide/browser/playwright) or [WebdriverIO](/guide/browser/webdriverio).
-:::
-
-To see your tests running in a real browser, you need to install the [`@vitest/browser-preview`](https://www.npmjs.com/package/@vitest/browser-preview) npm package and specify its `preview` export in the `test.browser.provider` property of your config:
-
-```ts [vitest.config.js]
-import { preview } from '@vitest/browser-preview'
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    browser: {
-      provider: preview(),
-      instances: [{ browser: 'chromium' }]
-    },
-  },
-})
-```
-
-This will open a new browser window using your default browser to run the tests. You can configure which browser to use by setting the `browser` property in the `instances` array. Vitest will try to open that browser automatically, but it might not work in some environments. In that case, you can manually open the provided URL in your desired browser.
-
-## Differences with Other Providers
-
-The preview provider has some limitations compared to other providers like [Playwright](/guide/browser/playwright) or [WebdriverIO](/guide/browser/webdriverio):
-
-- It does not support headless mode; the browser window will always be visible.
-- It does not support multiple instances of the same browser; each instance must use a different browser.
-- It does not support advanced browser capabilities or options; you can only specify the browser name.
-- It does not support CDP (Chrome DevTools Protocol) commands or other low-level browser interactions. Unlike Playwright or WebdriverIO, the [`userEvent`](/guide/browser/interactivity-api) API is just re-exported from [`@testing-library/user-event`](https://www.npmjs.com/package/@testing-library/user-event) and does not have any special integration with the browser.

From 211636ff2b830ca39ee74d9b27ab1df6ee5f3d3c Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 1 Dec 2025 01:09:04 +0800
Subject: [PATCH 41/50] !docs: recovery /guide/browser/context

---
 guide/browser/context.md | 44 +++++-----------------------------------
 1 file changed, 5 insertions(+), 39 deletions(-)

diff --git a/guide/browser/context.md b/guide/browser/context.md
index 2e5f6c07..fd4cc603 100644
--- a/guide/browser/context.md
+++ b/guide/browser/context.md
@@ -9,7 +9,7 @@ Vitest 通过 `vitest/browser` 入口点公开上下文模块。从 2.0 开始
 ## `userEvent`
 
 ::: tip
-`userEvent` API 的详细说明见[Interactivity API](/guide/browser/interactivity-api).
+`userEvent` API 的详细说明见 [Interactivity API](/guide/browser/interactivity-api)。
 :::
 
 ```ts
@@ -43,7 +43,7 @@ export const userEvent: {
 ## `commands`
 
 ::: tip
-Commands API 的详细说明见[Commands API](/guide/browser/commands).
+Commands API 的详细说明见 [Commands API](/guide/browser/commands)。
 :::
 
 ```ts
@@ -73,10 +73,11 @@ export const page: {
    * 对测试 iframe 或特定元素进行截图。
    * @returns 截图文件的路径或路径和 base64 编码。
    */
-  screenshot: ((options: Omit<ScreenshotOptions, 'base64'> & { base64: true }) => Promise<{
+  screenshot(options: Omit<ScreenshotOptions, 'base64'> & { base64: true }): Promise<{
     path: string
     base64: string
-  }>) & ((options?: ScreenshotOptions) => Promise<string>)
+  }>
+  screenshot(options?: ScreenshotOptions): Promise<string>
   /**
    * 使用自定义方法扩展默认的 `page` 对象。
    */
@@ -85,12 +86,6 @@ export const page: {
    * 将一个 HTML 元素包装在 `Locator` 中。在查询元素时，搜索将始终返回此元素。
    */
   elementLocator(element: Element): Locator
-  /**
-   * The iframe locator. This is a document locator that enters the iframe body
-   * and works similarly to the `page` object.
-   * **Warning:** At the moment, this is supported only by the `playwright` provider.
-   */
-  frameLocator(iframeElement: Locator): FrameLocator
 
   /**
    * Locator API。更多详细信息请参见其文档。
@@ -114,37 +109,8 @@ export const page: {
 在这种情况下，`path` 也会被忽略。
 :::
 
-### frameLocator
-
-```ts
-function frameLocator(iframeElement: Locator): FrameLocator
-```
-
-`frameLocator` 方法返回一个 `FrameLocator` 实例，可用于查找 iframe 内的元素。
-
-frame locator 类似于 `page`。它不指向 Iframe HTML 元素，而是指向 iframe 的文档。
-
-```ts
-const frame = page.frameLocator(
-  page.getByTestId('iframe')
-)
-
-await frame.getByText('Hello World').click() // ✅
-await frame.click() // ❌ Not available
-```
-
-::: danger IMPORTANT
-目前，`frameLocator` 方法仅支持 `playwright` 提供者。
-
-交互方法（如 `click` 或 `fill`）在 iframe 内的元素上始终可用，但使用 `expect.element` 进行断言时要求 iframe 具有[同源策略](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy)。
-:::
-
 ## `cdp`
 
-```ts
-function cdp(): CDPSession
-```
-
 `cdp` 导出返回当前的 Chrome DevTools 协议会话。它主要用于库作者在其基础上构建工具。
 
 ::: warning

From 5e8102333ed751db1df2b8012aa69565d4551626 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 1 Dec 2025 01:19:14 +0800
Subject: [PATCH 42/50] !docs: recovery /guide/browser/interactivity-api

---
 guide/browser/interactivity-api.md | 45 ++++++++++++++++++------------
 1 file changed, 27 insertions(+), 18 deletions(-)

diff --git a/guide/browser/interactivity-api.md b/guide/browser/interactivity-api.md
index ea88e14e..43e5c328 100644
--- a/guide/browser/interactivity-api.md
+++ b/guide/browser/interactivity-api.md
@@ -12,7 +12,16 @@ import { userEvent } from 'vitest/browser'
 await userEvent.click(document.querySelector('.button'))
 ```
 
-几乎所有的 `userEvent` 方法都继承了其提供者的选项。
+几乎所有的 `userEvent` 方法都继承了其提供者的选项。要在我们的 IDE 中查看所有可用选项，请根据我们的提供者，将 `webdriver` 或 `playwright` 类型添加到我们的 [setup 文件](/config/#setupfile) 或 [配置文件](/config/)中（取决于我们的 `tsconfig.json` 中 `included` 部分包含的内容）：
+
+::: code-group
+```ts [playwright]
+/// <reference types="@vitest/browser/providers/playwright" />
+```
+```ts [webdriverio]
+/// <reference types="@vitest/browser/providers/webdriverio" />
+```
+:::
 
 ## userEvent.setup
 
@@ -30,11 +39,11 @@ import { userEvent as vitestUserEvent } from 'vitest/browser'
 import { userEvent as originalUserEvent } from '@testing-library/user-event'
 import { userEvent as vitestUserEvent } from '@vitest/browser/context'
 
-await vitestUserEvent.keyboard('{Shift}') // press shift without releasing
-await vitestUserEvent.keyboard('{/Shift}') // releases shift
+await vitestUserEvent.keyboard('{Shift}') // 按住 shift 键不放
+await vitestUserEvent.keyboard('{/Shift}') // 放开 shift 键不放
 
-await originalUserEvent.keyboard('{Shift}') // press shift without releasing
-await originalUserEvent.keyboard('{/Shift}') // DID NOT release shift because the state is different
+await originalUserEvent.keyboard('{Shift}') // 按住 shift 键不放
+await originalUserEvent.keyboard('{/Shift}') // 没有放开 shift 键，因为状态不同
 ```
 
 这种行为更有用，因为我们并没有模拟键盘，而是实际按下了 Shift 键，所以保留原来的行为会在字段中键入时造成意想不到的问题。
@@ -58,12 +67,12 @@ test('clicks on an element', async () => {
   const logo = page.getByRole('img', { name: /logo/ })
 
   await userEvent.click(logo)
-  // or you can access it directly on the locator
+  // 或者你可以直接从定位器上访问
   await logo.click()
 })
 ```
 
-References:
+相关链接：
 
 - [Playwright `locator.click` API](https://playwright.dev/docs/api/class-locator#locator-click)
 - [WebdriverIO `element.click` API](https://webdriver.io/docs/api/element/click/)
@@ -89,12 +98,12 @@ test('triggers a double click on an element', async () => {
   const logo = page.getByRole('img', { name: /logo/ })
 
   await userEvent.dblClick(logo)
-  // or you can access it directly on the locator
+  // 或者你可以直接从定位器上访问
   await logo.dblClick()
 })
 ```
 
-References:
+相关链接：
 
 - [Playwright `locator.dblclick` API](https://playwright.dev/docs/api/class-locator#locator-dblclick)
 - [WebdriverIO `element.doubleClick` API](https://webdriver.io/docs/api/element/doubleClick/)
@@ -126,7 +135,7 @@ test('triggers a triple click on an element', async () => {
   })
 
   await userEvent.tripleClick(logo)
-  // or you can access it directly on the locator
+  // 或者你可以直接从定位器上访问
   await logo.tripleClick()
 
   expect(tripleClickFired).toBe(true)
@@ -160,7 +169,7 @@ test('update input', async () => {
   await userEvent.fill(input, '{{a[[') // input.value == {{a[[
   await userEvent.fill(input, '{Shift}') // input.value == {Shift}
 
-  // or you can access it directly on the locator
+  // 或者你可以直接从定位器上访问
   await input.fill('foo') // input.value == foo
 })
 ```
@@ -255,7 +264,7 @@ function type(
 
 `type` 方法在 [`keyboard`](https://testing-library.com/docs/user-event/keyboard) API 的基础上实现了 `@testing-library/user-event` 的 [`type`](https://testing-library.com/docs/user-event/utility/#type) 工具。
 
-你可以使用此函数向 `input` `、textarea` 或 `contenteditable` 元素中模拟键盘输入。[它兼容 user-event 提供的 keyboard 语法](https://testing-library.com/docs/user-event/keyboard)。
+你可以使用此函数向 `input` 、`textarea` 或 `contenteditable` 元素中模拟键盘输入。[它兼容 user-event 提供的 keyboard 语法](https://testing-library.com/docs/user-event/keyboard)。
 
 如果只需按下字符而无需输入，请使用 [`userEvent.keyboard`](#userevent-keyboard) API。
 
@@ -299,7 +308,7 @@ test('clears input', async () => {
   expect(input).toHaveValue('foo')
 
   await userEvent.clear(input)
-  // or you can access it directly on the locator
+  // 或者你可以直接从定位器上访问
   await input.clear()
 
   expect(input).toHaveValue('')
@@ -343,7 +352,7 @@ test('clears input', async () => {
   const select = page.getByRole('select')
 
   await userEvent.selectOptions(select, 'Option 1')
-  // or you can access it directly on the locator
+  // 或者你可以直接从定位器上访问
   await select.selectOptions('Option 1')
 
   expect(select).toHaveValue('option-1')
@@ -393,7 +402,7 @@ test('hovers logo element', async () => {
   const logo = page.getByRole('img', { name: /logo/ })
 
   await userEvent.hover(logo)
-  // or you can access it directly on the locator
+  // 或者你可以直接从定位器上访问
   await logo.hover()
 })
 ```
@@ -426,7 +435,7 @@ test('unhover logo element', async () => {
   const logo = page.getByRole('img', { name: /logo/ })
 
   await userEvent.unhover(logo)
-  // or you can access it directly on the locator
+  // 或者你可以直接从定位器上访问
   await logo.unhover()
 })
 ```
@@ -458,7 +467,7 @@ test('can upload a file', async () => {
   const file = new File(['file'], 'file.png', { type: 'image/png' })
 
   await userEvent.upload(input, file)
-  // or you can access it directly on the locator
+  // 或者你可以直接从定位器上访问
   await input.upload(file)
 
   // you can also use file paths relative to the root of the project
@@ -496,7 +505,7 @@ test('drag and drop works', async () => {
   const target = page.getByTestId('logo-target')
 
   await userEvent.dragAndDrop(source, target)
-  // or you can access it directly on the locator
+  // 或者你可以直接从定位器上访问
   await source.dropTo(target)
 
   await expect.element(target).toHaveTextContent('Logo is processed')

From c98fe250aa5fb0d36f838e729dd408e5a1f9bdd2 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 1 Dec 2025 02:02:19 +0800
Subject: [PATCH 43/50] !docs: recovery /guide/browser/locators

---
 guide/browser/locators.md | 93 ++++++++++++++++++++-------------------
 1 file changed, 48 insertions(+), 45 deletions(-)

diff --git a/guide/browser/locators.md b/guide/browser/locators.md
index 7f6699da..57403e14 100644
--- a/guide/browser/locators.md
+++ b/guide/browser/locators.md
@@ -3,7 +3,7 @@ title: Locators | Browser Mode
 outline: [2, 3]
 ---
 
-# 定位 {#locators}
+# 定位器 {#locators}
 
 定位器是表示一个或多个元素的方式。每个定位器都由一个称为选择器的字符串定义。Vitest 通过提供方便的方法在后台生成这些选择器，从而抽象了选择器。
 
@@ -189,7 +189,7 @@ await page.getByRole('button', { name: /submit/i }).click()
   page.getByRole('button', { selected: false }) // ❌
   ```
 
-##### See also
+##### 更多内容请参阅 {#see-also}
 
 - [MDN 上的 ARIA 角色列表](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles)
 - [w3.org 上的 ARIA 角色列表](https://www.w3.org/TR/wai-aria-1.2/#role_definitions)
@@ -219,7 +219,7 @@ page.getByAltText('non existing alt text') // ❌
 
   `text` 是否精确匹配：区分大小写且完全匹配字符串。默认情况下禁用此选项。如果 `text` 是正则表达式，则忽略此选项。请注意，精确匹配仍然会修剪空白字符。
 
-#### See also
+#### 更多内容请参阅 {#see-also-1}
 
 - [testing-library's `ByAltText`](https://testing-library.com/docs/queries/byalttext/)
 
@@ -266,7 +266,7 @@ function getByLabelText(
 
   `text` 是否精确匹配：区分大小写且完全匹配字符串。默认情况下禁用此选项。如果 `text` 是正则表达式，则忽略此选项。请注意，精确匹配仍然会修剪空白字符。
 
-#### See also
+#### 更多内容请参阅 {#see-also-2}
 
 - [testing-library's `ByLabelText`](https://testing-library.com/docs/queries/bylabeltext/)
 
@@ -298,7 +298,7 @@ page.getByPlaceholder('not found') // ❌
 
   `text` 是否精确匹配：区分大小写且完全匹配字符串。默认情况下禁用此选项。如果 `text` 是正则表达式，则忽略此选项。请注意，精确匹配仍然会修剪空白字符。
 
-#### See also
+#### 更多内容请参阅 {#see-also-3}
 
 - [testing-library's `ByPlaceholderText`](https://testing-library.com/docs/queries/byplaceholdertext/)
 
@@ -330,7 +330,7 @@ page.getByText('about', { exact: true }) // ❌
 
   `text` 是否精确匹配：区分大小写且完全匹配字符串。默认情况下禁用此选项。如果 `text` 是正则表达式，则忽略此选项。请注意，精确匹配仍然会修剪空白字符。
 
-#### See also
+#### 更多内容请参阅 {#see-also-4}
 
 - [testing-library's `ByText`](https://testing-library.com/docs/queries/bytext/)
 
@@ -358,7 +358,7 @@ page.getByTitle('Create') // ❌
 
   `text` 是否精确匹配：区分大小写且完全匹配字符串。默认情况下禁用此选项。如果 `text` 是正则表达式，则忽略此选项。请注意，精确匹配仍然会修剪空白字符。
 
-#### See also
+#### 更多内容请参阅 {#see-also-5}
 
 - [testing-library's `ByTitle`](https://testing-library.com/docs/queries/bytitle/)
 
@@ -387,7 +387,7 @@ page.getByTestId('non-existing-element') // ❌
 
   `text` 是否精确匹配：区分大小写和整个字符串。默认情况下禁用此选项。如果 `text` 是正则表达式，则忽略此选项。请注意，精确匹配仍然会修剪空格。
 
-#### See also
+#### 更多内容请参阅 {#see-also-6}
 
 - [testing-library's `ByTestId`](https://testing-library.com/docs/queries/bytestid/)
 
@@ -460,7 +460,7 @@ page.getByRole('textbox').last() // ✅
 function and(locator: Locator): Locator
 ```
 
-This method creates a new locator that matches both the parent and provided locator. The following example finds a button with a specific title:
+此方法创建一个新定位器，需同时匹配父级和传入的定位器。以下示例用于查找具有特定标题的按钮：
 
 ```ts
 page.getByRole('button').and(page.getByTitle('Subscribe'))
@@ -472,10 +472,10 @@ page.getByRole('button').and(page.getByTitle('Subscribe'))
 function or(locator: Locator): Locator
 ```
 
-This method creates a new locator that matches either one or both locators.
+此方法创建一个新定位器，只需匹配其中一个或同时匹配两个定位器。
 
 ::: warning
-Note that if locator matches more than a single element, calling another method might throw an error if it expects a single element:
+注意：若定位器匹配到多个元素，调用预期单个元素的方法可能会报错：
 
 ```tsx
 <>
@@ -485,7 +485,7 @@ Note that if locator matches more than a single element, calling another method
 
 page.getByRole('button')
   .or(page.getByRole('link'))
-  .click() // ❌ matches multiple elements
+  .click() // ❌ 匹配到多个元素
 ```
 :::
 
@@ -495,13 +495,13 @@ page.getByRole('button')
 function filter(options: LocatorOptions): Locator
 ```
 
-This methods narrows down the locator according to the options, such as filtering by text. It can be chained to apply multiple filters.
+此方法会根据选项（例如按文本过滤）缩小定位器范围。可通过链式调用应用多个过滤器。
 
 ### has
 
 - **类型：** `Locator`
 
-This options narrows down the selector to match elements that contain other elements matching provided locator. For example, with this HTML:
+此选项会限定选择器范围，仅匹配包含符合指定定位器元素的节点。例如对于以下 HTML 结构：
 
 ```html{1,3}
 <article>
@@ -512,26 +512,28 @@ This options narrows down the selector to match elements that contain other elem
 </article>
 ```
 
-We can narrow down the locator to only find the `article` with `Vitest` text inside:
+我们可以限定定位器范围，仅查找内含 `Vitest` 文本的 `article` 元素：
 
 ```ts
 page.getByRole('article').filter({ has: page.getByText('Vitest') }) // ✅
 ```
 
 ::: warning
-Provided locator (`page.getByText('Vitest')` in the example) must be relative to the parent locator (`page.getByRole('article')` in the example). It will be queried starting with the parent locator, not the document root.
 
-Meaning, you cannot pass down a locator that queries the element outside of the parent locator:
+传入的定位器（示例中的 `page.getByText('Vitest')`）必须相对于父级定位器（示例中的 `page.getByRole('article')`）。查询会从父级定位器开始，而非文档根节点。
+
+这意味着不能传入在父级定位器范围之外查询元素的定位器：
 
 ```ts
 page.getByText('Vitest').filter({ has: page.getByRole('article') }) // ❌
 ```
 
-This example will fail because the `article` element is outside the element with `Vitest` text.
+此示例会失败，因为 `article` 元素位于包含 `Vitest` 文本的元素之外。
+
 :::
 
 ::: tip
-This method can be chained to narrow down the element even further:
+此方法支持链式调用以进一步缩小元素定位范围：
 
 ```ts
 page.getByRole('article')
@@ -544,7 +546,7 @@ page.getByRole('article')
 
 - **类型：** `Locator`
 
-This option narrows down the selector to match elements that do not contain other elements matching provided locator. For example, with this HTML:
+此选项会限定选择器范围，仅匹配不包含指定定位器元素的节点。例如对于以下 HTML 结构：
 
 ```html{1,3}
 <article>
@@ -555,7 +557,7 @@ This option narrows down the selector to match elements that do not contain othe
 </article>
 ```
 
-We can narrow down the locator to only find the `article` that doesn't have `Rolldown` inside.
+我们可以限定定位器范围，仅查找内部不含 `Rolldown` 文本的 `article` 元素：
 
 ```ts
 page.getByRole('article')
@@ -565,14 +567,14 @@ page.getByRole('article')
 ```
 
 ::: warning
-Note that provided locator is queried against the parent, not the document root, just like [`has`](#has) option.
+注意：与 [`has`](#has) 选项相同，传入的定位器是针对父级元素而非文档根节点进行查询。
 :::
 
 ### hasText
 
 - **类型：** `string | RegExp`
 
-This options narrows down the selector to only match elements that contain provided text somewhere inside. When the `string` is passed, matching is case-insensitive and searches for a substring.
+此选项会限定选择器范围，仅匹配内部某处包含指定文本的元素。当传入 `string` 时，匹配不区分大小写且执行子字符串搜索。
 
 ```html{1,3}
 <article>
@@ -583,7 +585,7 @@ This options narrows down the selector to only match elements that contain provi
 </article>
 ```
 
-Both locators will find the same element because the search is case-insensitive:
+由于搜索不区分大小写，以下两个定位器将匹配到同一个元素：
 
 ```ts
 page.getByRole('article').filter({ hasText: 'Vitest' }) // ✅
@@ -594,7 +596,7 @@ page.getByRole('article').filter({ hasText: 'Vite' }) // ✅
 
 - **类型：** `string | RegExp`
 
-This options narrows down the selector to only match elements that do not contain provided text somewhere inside. When the `string` is passed, matching is case-insensitive and searches for a substring.
+此选项会限定选择器范围，仅匹配内部不包含指定文本的元素。当传入 `string` 时，匹配不区分大小写且执行子字符串搜索。
 
 ## Methods
 
@@ -799,8 +801,7 @@ const { path, base64 } = await button.screenshot({
 ```
 
 ::: warning WARNING <Version>3.2.0</Version>
-Note that `screenshot` will always return a base64 string if `save` is set to `false`.
-The `path` is also ignored in that case.
+注意，当 `save` 设置为 `false` 时，`screenshot` 将始终返回 base64 字符串。在此情况下，路径参数也会被忽略。
 :::
 
 ### query
@@ -832,7 +833,7 @@ page.getByText('Hello', { exact: true }).query() // ✅ HTMLSpanElement
 这些定位器将抛出错误：
 
 ```ts
-// returns multiple elements
+// 返回多个元素
 page.getByText('Hello').query() // ❌
 page.getByText(/^Hello/).query() // ❌
 ```
@@ -877,11 +878,11 @@ page.getByText('Hello', { exact: true }).element() // ✅
 这些定位器将抛出错误：
 
 ```ts
-// returns multiple elements
+// 返回多个元素
 page.getByText('Hello').element() // ❌
 page.getByText(/^Hello/).element() // ❌
 
-// returns no elements
+// 不返回任意元素
 page.getByText('Hello USA').element() // ❌
 ```
 
@@ -922,7 +923,7 @@ function all(): Locator[]
 
 在内部，此方法调用 `.elements` 并使用 [`page.elementLocator`](/guide/browser/context#page) 包装每个元素。
 
-- [See `locator.elements()`](#elements)
+- [更多内容请参阅  `locator.elements()`](#elements)
 
 ## Properties
 
@@ -959,15 +960,16 @@ test('works correctly', async () => {
 ### length
 
 This getter returns a number of elements that this locator is matching. It is equivalent to calling `locator.elements().length`.
+此属性返回当前定位器匹配的元素数量，等效于调用 g `locator.elements().length`。
 
-Consider the following DOM structure:
+参考以下 DOM 结构：
 
 ```html
 <button>Click Me!</button>
 <button>Don't click me!</button>
 ```
 
-This property will always succeed:
+该属性始终会执行成功：
 
 ```ts
 page.getByRole('button').length // ✅ 2
@@ -975,16 +977,17 @@ page.getByRole('button', { title: 'Click Me!' }).length // ✅ 1
 page.getByRole('alert').length // ✅ 0
 ```
 
-## Custom Locators <Version>3.2.0</Version> <Badge type="danger">advanced</Badge> {#custom-locators}
+## 自定义定位器 <Version>3.2.0</Version> <Badge type="danger">advanced</Badge> {#custom-locators}
 
-You can extend built-in locators API by defining an object of locator factories. These methods will exist as methods on the `page` object and any created locator.
+您可以通过定义定位器工厂对象来扩展内置定位器 API。这些方法将作为 `page` 对象和所有已创建定位器的方法存在。
 
-These locators can be useful if built-in locators are not enough. For example, when you use a custom framework for your UI.
+当内置定位器无法满足需求时（例如使用自定义 UI 框架时），这些定位器会非常有用。
 
-The locator factory needs to return a selector string or a locator itself.
+定位器工厂需要返回一个选择器字符串或定位器本身
 
 ::: tip
-The selector syntax is identical to Playwright locators. Please, read [their guide](https://playwright.dev/docs/other-locators) to better understand how to work with them.
+
+选择器语法与 Playwright 定位器完全一致。建议阅读 [Playwright 指南](https://playwright.dev/docs/other-locators) 以更好地理解其工作原理。
 :::
 
 ```ts
@@ -998,8 +1001,8 @@ locators.extend({
     return `.comments :text("${count} comments")`
   },
   async previewComments() {
-    // you have access to the current locator via "this"
-    // beware that if the method was called on `page`, `this` will be `page`,
+    // 可通过 "this" 访问当前定位器
+    // 注意：若方法在 `page` 上调用，`this` 将指向 `page` 而非定位器！
     // not the locator!
     if (this !== page) {
       await this.click()
@@ -1008,16 +1011,16 @@ locators.extend({
   }
 })
 
-// if you are using typescript, you can extend LocatorSelectors interface
-// to have the autocompletion in locators.extend, page.* and locator.* methods
+// 使用 TypeScript 时可扩展 LocatorSelectors 接口
+// 以在 locators.extend、page.* 和 locator.* 方法中获得自动补全
 declare module 'vitest/browser' {
   interface LocatorSelectors {
-    // if the custom method returns a string, it will be converted into a locator
-    // if it returns anything else, then it will be returned as usual
+    // 若自定义方法返回字符串，将被转换为定位器
+    // 若返回其他类型，则按原样返回
     getByArticleTitle(title: string): Locator
     getByArticleCommentsCount(count: number): Locator
 
-    // Vitest will return a promise and won't try to convert it into a locator
+    // Vitest 将返回 Promise 且不会尝试将其转换为定位器
     previewComments(this: Locator): Promise<void>
   }
 }

From b1e5dbfadd747627e3075c6b3e53292eeee17c59 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 1 Dec 2025 02:26:36 +0800
Subject: [PATCH 44/50] !docs: recovery /guide/browser/assertion-api

---
 guide/browser/assertion-api.md | 251 ++++-----------------------------
 1 file changed, 24 insertions(+), 227 deletions(-)

diff --git a/guide/browser/assertion-api.md b/guide/browser/assertion-api.md
index c2eb7ad0..598e367f 100644
--- a/guide/browser/assertion-api.md
+++ b/guide/browser/assertion-api.md
@@ -284,13 +284,13 @@ function toBeVisible(): Promise<void>
 若要检查列表中至少有一个元素是可见的，请使用 `locator.first()`。
 
 ```ts
-// A specific element is visible.
+// 检测特定元素可见
 await expect.element(page.getByText('Welcome')).toBeVisible()
 
-// At least one item in the list is visible.
+// 检测列表中至少有一项可见
 await expect.element(page.getByTestId('todo-item').first()).toBeVisible()
 
-// At least one of the two elements is visible, possibly both.
+// 检测两个元素中至少有一个可见（可能同时可见）
 await expect.element(
   page.getByRole('button', { name: 'Sign in' })
     .or(page.getByRole('button', { name: 'Sign up' }))
@@ -298,27 +298,6 @@ await expect.element(
 ).toBeVisible()
 ```
 
-## toBeInViewport
-
-```ts
-function toBeInViewport(options: { ratio?: number }): Promise<void>
-```
-
-This allows you to check if an element is currently in viewport with [IntersectionObserver API](https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API).
-
-You can pass `ratio` argument as option, which means the minimal ratio of the element should be in viewport. `ratio` should be in 0~1.
-
-```ts
-// A specific element is in viewport.
-await expect.element(page.getByText('Welcome')).toBeInViewport()
-
-// 50% of a specific element should be in viewport
-await expect.element(page.getByText('To')).toBeInViewport({ ratio: 0.5 })
-
-// Full of a specific element should be in viewport
-await expect.element(page.getByText('Vitest')).toBeInViewport({ ratio: 1 })
-```
-
 ## toContainElement
 
 ```ts
@@ -379,9 +358,9 @@ await expect.element(getByTestId('parent')).toContainHTML('</span>')
 function toHaveAccessibleDescription(description?: string | RegExp): Promise<void>
 ```
 
-这允许你断言一个元素具有预期的[可访问描述](https://w3c.github.io/accname/)。
+这允许你断言一个元素具有预期的 [可访问描述](https://w3c.github.io/accname/)。
 
-你可以传递预期的可访问描述的确切字符串，或者通过传递正则表达式来进行部分匹配，或者使用[`expect.stringContaining`](/api/expect#expect-stringcontaining)或[`expect.stringMatching`](/api/expect#expect-stringmatching)。
+你可以传递预期的可访问描述的确切字符串，或者通过传递正则表达式来进行部分匹配，或者使用 [`expect.stringContaining`](/api/expect#expect-stringcontaining) 或 [`expect.stringMatching`](/api/expect#expect-stringmatching)。
 
 ```html
 <a
@@ -429,9 +408,9 @@ await expect.element(getByTestId('logo2')).toHaveAccessibleDescription(
 function toHaveAccessibleErrorMessage(message?: string | RegExp): Promise<void>
 ```
 
-这允许你断言一个元素具有预期的[可访问错误消息](https://w3c.github.io/aria/#aria-errormessage)。
+这允许你断言一个元素具有预期的 [可访问错误消息](https://w3c.github.io/aria/#aria-errormessage)。
 
-你可以传递预期的可访问错误消息的确切字符串。或者，你可以通过传递正则表达式或使用[`expect.stringContaining`](/api/expect#expect-stringcontaining)或[`expect.stringMatching`](/api/expect#expect-stringmatching)来进行部分匹配。
+你可以传递预期的可访问错误消息的确切字符串。或者，你可以通过传递正则表达式或使用 [`expect.stringContaining`](/api/expect#expect-stringcontaining) 或 [`expect.stringMatching`](/api/expect#expect-stringmatching)来进行部分匹配。
 
 ```html
 <input
@@ -450,7 +429,7 @@ function toHaveAccessibleErrorMessage(message?: string | RegExp): Promise<void>
 ```
 
 ```ts
-// Inputs with Valid Error Messages
+// 有效错误信息的输入项
 await expect.element(getByRole('textbox', { name: 'Has Error' })).toHaveAccessibleErrorMessage()
 await expect.element(getByRole('textbox', { name: 'Has Error' })).toHaveAccessibleErrorMessage(
   'This field is invalid',
@@ -462,7 +441,7 @@ await expect.element(
   getByRole('textbox', { name: 'Has Error' }),
 ).not.toHaveAccessibleErrorMessage('This field is absolutely correct!')
 
-// Inputs without Valid Error Messages
+// 没有效错误信息的输入项
 await expect.element(
   getByRole('textbox', { name: 'No Error Attributes' }),
 ).not.toHaveAccessibleErrorMessage()
@@ -478,9 +457,9 @@ await expect.element(
 function toHaveAccessibleName(name?: string | RegExp): Promise<void>
 ```
 
-这允许你断言一个元素具有预期的[可访问名称](https://w3c.github.io/accname/)。例如，它有助于断言表单元素和按钮是否被正确标记。
+这允许你断言一个元素具有预期的 [可访问名称](https://w3c.github.io/accname/)。例如，它有助于断言表单元素和按钮是否被正确标记。
 
-你可以传递预期的可访问名称的确切字符串，或者通过传递正则表达式进行部分匹配，也可以使用[`expect.stringContaining`](/api/expect#expect-stringcontaining)或[`expect.stringMatching`](/api/expect#expect-stringmatching)。
+你可以传递预期的可访问名称的确切字符串，或者通过传递正则表达式进行部分匹配，也可以使用 [`expect.stringContaining`](/api/expect#expect-stringcontaining) 或 [`expect.stringMatching`](/api/expect#expect-stringmatching)。
 
 ```html
 <img data-testid="img-alt" src="" alt="Test alt" />
@@ -510,7 +489,7 @@ await expect.element(getByTestId('input-title')).toHaveAccessibleName()
 function toHaveAttribute(attribute: string, value?: unknown): Promise<void>
 ```
 
-这允许你检查给定的元素是否具有某个属性。你还可以选择性地验证该属性是否具有特定的预期值或使用[`expect.stringContaining`](/api/expect#expect-stringcontaining)或[`expect.stringMatching`](/api/expect#expect-stringmatching)进行部分匹配。
+这允许你检查给定的元素是否具有某个属性。你还可以选择性地验证该属性是否具有特定的预期值或使用 [`expect.stringContaining`](/api/expect#expect-stringcontaining) 或 [`expect.stringMatching`](/api/expect#expect-stringmatching) 进行部分匹配。
 
 ```html
 <button data-testid="ok-button" type="submit" disabled>ok</button>
@@ -542,7 +521,7 @@ function toHaveClass(...classNames: (string | RegExp)[]): Promise<void>
 
 这允许你检查给定元素在其 `class` 属性中是否包含某些类。除非你断言该元素没有任何类，否则必须提供至少一个类。
 
-类名列表可以包括字符串和正则表达式。正则表达式会与目标元素中的每个单独类进行匹配，**而不是与其完整的 `class` 属性值整体匹配**。
+类名列表可以包括字符串和正则表达式。正则表达式会与目标元素中的每个单独类进行匹配，而不是与其完整的 `class` 属性值整体匹配。
 
 ::: warning
 请注意，当仅提供正则表达式时，不能使用 `exact: true` 选项。
@@ -566,14 +545,14 @@ await expect.element(deleteButton).toHaveClass('btn-danger', 'btn')
 await expect.element(deleteButton).not.toHaveClass('btn-link')
 await expect.element(deleteButton).not.toHaveClass(/link/)
 
-// ⚠️ regexp matches against individual classes, not the whole classList
+// ⚠️ 正则表达式仅匹配单个类名而非整个 classList
 await expect.element(deleteButton).not.toHaveClass(/btn extra/)
 
-// the element has EXACTLY a set of classes (in any order)
+// 精确匹配类集合（顺序无关）
 await expect.element(deleteButton).toHaveClass('btn-danger extra btn', {
   exact: true
 })
-// if it has more than expected it is going to fail
+// 若存在多余类则断言失败
 await expect.element(deleteButton).not.toHaveClass('btn-danger extra', {
   exact: true
 })
@@ -705,7 +684,7 @@ function toHaveTextContent(
 
 若要进行不区分大小写的匹配，可以使用带有 `/i` 修饰符的 `RegExp`。
 
-如果你想匹配整个内容，可以使用 `RegExp` 来实现。
+如果你想匹配整段内容，可以使用 `RegExp` 来实现。
 
 ```html
 <span data-testid="text-content">Text Content</span>
@@ -715,9 +694,9 @@ function toHaveTextContent(
 const element = getByTestId('text-content')
 
 await expect.element(element).toHaveTextContent('Content')
-// to match the whole content
+// 匹配整段内容
 await expect.element(element).toHaveTextContent(/^Text Content$/)
-// to use case-insensitive match
+// 不区分大小写匹配
 await expect.element(element).toHaveTextContent(/content$/i)
 await expect.element(element).not.toHaveTextContent('content')
 ```
@@ -903,11 +882,11 @@ await expect.element(inputCheckboxIndeterminate).toBePartiallyChecked()
 function toHaveRole(role: ARIARole): Promise<void>
 ```
 
-这允许你断言某个元素具有预期的[角色](https://www.w3.org/TR/html-aria/#docconformance)。
+这允许你断言某个元素具有预期的 [角色](https://www.w3.org/TR/html-aria/#docconformance)。
 
 在你已经通过某种查询（而非角色本身）获取到某个元素，并希望对其可访问性进行更多断言时，这非常有用。
 
-角色可以匹配显式角色（通过 `role` 属性），也可以通过[隐式 ARIA 语义](https://www.w3.org/TR/html-aria/#docconformance)匹配隐式角色。
+角色可以匹配显式角色（通过 `role` 属性），也可以通过 [隐式 ARIA 语义](https://www.w3.org/TR/html-aria/#docconformance) 匹配隐式角色。
 
 ```html
 <button data-testid="button">Continue</button>
@@ -979,12 +958,12 @@ selection.removeAllRanges()
 selection.empty()
 selection.addRange(range)
 
-// selection of child applies to the parent as well
+// 子元素的选择同样适用于父元素
 range.selectNodeContents(getByTestId('child').element())
 await expect.element(getByTestId('child')).toHaveSelection('selected')
 await expect.element(getByTestId('parent')).toHaveSelection('selected')
 
-// selection that applies from prev all, parent text before child, and part child.
+// 选择范围包含：前序同级元素、父元素中子元素前的文本、以及子元素的部分内容
 range.setStart(getByTestId('prev').element(), 0)
 range.setEnd(getByTestId('child').element().childNodes[0], 3)
 await expect.element(queryByTestId('prev')).toHaveSelection('prev')
@@ -992,7 +971,7 @@ await expect.element(queryByTestId('child')).toHaveSelection('sel')
 await expect.element(queryByTestId('parent')).toHaveSelection('text sel')
 await expect.element(queryByTestId('next')).not.toHaveSelection()
 
-// selection that applies from part child, parent text after child and part next.
+// 选择范围包含：子元素的部分内容、父元素中子元素后的文本、以及后续同级元素的部分内容
 range.setStart(getByTestId('child').element().childNodes[0], 3)
 range.setEnd(getByTestId('next').element().childNodes[0], 2)
 await expect.element(queryByTestId('child')).toHaveSelection('ected')
@@ -1000,185 +979,3 @@ await expect.element(queryByTestId('parent')).toHaveSelection('ected text')
 await expect.element(queryByTestId('prev')).not.toHaveSelection()
 await expect.element(queryByTestId('next')).toHaveSelection('ne')
 ```
-
-## toMatchScreenshot <Badge type="warning">实验性</Badge> {#tomatchscreenshot}
-
-```ts
-function toMatchScreenshot(
-  options?: ScreenshotMatcherOptions,
-): Promise<void>
-function toMatchScreenshot(
-  name?: string,
-  options?: ScreenshotMatcherOptions,
-): Promise<void>
-```
-
-::: tip
-`toMatchScreenshot` 断言可在 [Vitest 配置](/guide/browser/config#browser-expect-tomatchscreenshot) 中全局设定。
-:::
-
-该断言通过将元素或整页的截图与预先保存的基准图像进行比对，实现视觉回归测试。
-
-若差异超出设定阈值，测试即告失败。为便于定位变更，断言会自动生成：
-
-- 测试过程中的实际截图
-- 预期的基准截图
-- 差异高亮的对比图（如技术可行）
-
-::: warning 截图稳定性
-该断言会不断重试截图，直到连续两次结果完全一致，从而削弱动画、加载状态或其他动态内容带来的抖动。可通过 `timeout` 选项设定最长等待时间。
-
-但浏览器渲染易受多种变量影响：
-
-- 浏览器及其版本差异
-- 操作系统（Windows、macOS、Linux）
-- 屏幕分辨率与像素密度
-- GPU 驱动及硬件加速策略
-- 字体渲染与系统字体差异
-
-建议先阅读 [视觉回归测试指南](/guide/browser/visual-regression-testing)，再落地实施。
-:::
-
-::: tip
-若截图对比因**有意变更**而失败，可在监听模式下按 `u` 键，或运行测试时加上 `-u`/`--update` 标志，以更新基准图。
-:::
-
-```html
-<button data-testid="button">Fancy Button</button>
-```
-
-```ts
-// basic usage, auto-generates screenshot name
-await expect.element(getByTestId('button')).toMatchScreenshot()
-
-// with custom name
-await expect.element(getByTestId('button')).toMatchScreenshot('fancy-button')
-
-// with options
-await expect.element(getByTestId('button')).toMatchScreenshot({
-  comparatorName: 'pixelmatch',
-  comparatorOptions: {
-    allowedMismatchedPixelRatio: 0.01,
-  },
-})
-
-// with both name and options
-await expect.element(getByTestId('button')).toMatchScreenshot('fancy-button', {
-  comparatorName: 'pixelmatch',
-  comparatorOptions: {
-    allowedMismatchedPixelRatio: 0.01,
-  },
-})
-```
-
-### Options
-
-- `comparatorName: "pixelmatch" = "pixelmatch"`
-
-  用于比较图像的算法/库名称。
-
-  目前，仅支持 [“pixelmatch”](https://github.com/mapbox/pixelmatch)。
-
-- `comparatorOptions: object`
-
-  用于调整比较器行为的选项，可设置的属性取决于所选的比较算法。
-
-  Vitest 已内置默认值，但可以覆盖。
-
-  - [`"pixelmatch"` options](#pixelmatch-comparator-options)
-
-  ::: warning
-  **始终显式设置 `comparatorName`，以确保 `comparatorOptions` 的类型推断正确**。
-
-  否则，TypeScript 无法识别哪些选项是有效的。
-
-  ```ts
-  // ❌ TypeScript can't infer the correct options
-  await expect.element(button).toMatchScreenshot({
-    comparatorOptions: {
-      // might error when new comparators are added
-      allowedMismatchedPixelRatio: 0.01,
-    },
-  })
-
-  // ✅ TypeScript knows these are pixelmatch options
-  await expect.element(button).toMatchScreenshot({
-    comparatorName: 'pixelmatch',
-    comparatorOptions: {
-      allowedMismatchedPixelRatio: 0.01,
-    },
-  })
-  ```
-  :::
-
-- `screenshotOptions: object`
-
-  与 [`locator.screenshot()`](/guide/browser/locators.html#screenshot) 支持的选项一致，但以下情况除外：
-
-  - `'base64'`
-  - `'path'`
-  - `'save'`
-  - `'type'`
-
-- `timeout: number = 5_000`
-
-  等待获取稳定截图的时间。
-
-  设为 `0` 可禁用超时，但如果无法确定稳定截图，进程将不会结束。
-
-#### `"pixelmatch"` comparator options
-
-使用 `"pixelmatch"` 比较器时，以下选项可用：
-
-- `allowedMismatchedPixelRatio: number | undefined = undefined`
-
-  允许的捕获截图与参考图像之间不同的像素比例的最大值，范围为 `0` 到 `1`。
-
-  例如，`allowedMismatchedPixelRatio: 0.02` 表示最多允许 2% 的像素不同，否则测试失败。
-
-- `allowedMismatchedPixels: number | undefined = undefined`
-
-  允许的捕获截图与参考图像之间不同的像素的最大数量。
-
-  如果设置为 `undefined`，任何非零差异都将导致测试失败。
-
-  例如，`allowedMismatchedPixels: 10` 表示最多允许 10 个像素不同，否则测试失败。
-
-- `threshold: number = 0.1`
-
-  两张图像中相同像素的可接受颜色差异范围，值越小越敏感。
-
-  比较使用 [YIQ 色彩空间](https://en.wikipedia.org/wiki/YIQ)。
-
-- `includeAA: boolean = false`
-
-  如果为 `true`，则禁用抗锯齿像素的检测和忽略。
-
-- `alpha: number = 0.1`
-
-  差异图像中未改变像素的混合级别，范围为 `0`（白色）到 `1`（原始亮度）。
-
-- `aaColor: [r: number, g: number, b: number] = [255, 255, 0]`
-
-  差异图像中抗锯齿像素的颜色。
-
-- `diffColor: [r: number, g: number, b: number] = [255, 0, 0]`
-
-  差异图像中不同像素的颜色。
-
-- `diffColorAlt: [r: number, g: number, b: number] | undefined = undefined`
-
-  可选的替代颜色，用于区分深色和浅色背景下的差异，帮助区分添加和移除的内容。
-  如果未设置，则所有差异均使用 `diffColor`。
-
-- `diffMask: boolean = false`
-
-  如果为 `true`，则仅以透明背景上的遮罩形式显示差异，而不是将其叠加在原始图像上。
-
-  如果检测到抗锯齿像素，则不会显示。
-
-::: warning
-当 `allowedMismatchedPixels` 和 `allowedMismatchedPixelRatio` 同时设置时，将采用更严格的限制值。
-
-例如，如果你允许 100 个像素差异或 2% 的比例差异，且图像总像素为 10,000，那么实际限制将是 100 个像素，而不是 200 个。
-:::

From ce1df6708540fb94820e918ffec92ee6b6988397 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 1 Dec 2025 02:43:46 +0800
Subject: [PATCH 45/50] !docs: recovery /guide/browser/commands

---
 guide/browser/commands.md | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/guide/browser/commands.md b/guide/browser/commands.md
index e0a248e3..d7d2595c 100644
--- a/guide/browser/commands.md
+++ b/guide/browser/commands.md
@@ -59,7 +59,7 @@ expect(input).toHaveValue('a')
 CDP session仅适用于 `playwright` provider，并且仅在使用 `chromium` 浏览器时有效。有关详细信息，请参阅 playwright 的 [`CDPSession`](https://playwright.dev/docs/api/class-cdpsession)文档。
 :::
 
-## Custom Commands
+## 自定义命令 {#custom-commands}
 
 我们也可以通过 [`browser.commands`](/guide/browser/config#browser-commands) 配置选项添加自己的命令。如果我们正在开发一个库，可以通过插件内的`config`钩子来提供它们：
 
@@ -108,7 +108,8 @@ test('custom command works correctly', async () => {
   expect(result).toEqual({ someValue: true })
 })
 
-// if you are using TypeScript, you can augment the module
+// 如果你正在使用 TypeScript，你可以扩展类型声明：
+
 declare module 'vitest/browser' {
   interface BrowserCommands {
     myCustomCommand: (arg1: string, arg2: string) => Promise<{
@@ -122,7 +123,7 @@ declare module 'vitest/browser' {
 如果自定义命令具有相同的名称，则它们将覆盖内置命令。
 :::
 
-### 自定义命令 `playwright` {#custom-playwright-commands}
+### 自定义 `playwright` 命令  {#custom-playwright-commands}
 
 Vitest 在命令上下文中公开了几个`playwright`特定属性。
 
@@ -148,7 +149,7 @@ export const myCommand: BrowserCommand<[string, number]> = async (
 }
 ```
 
-### Custom `webdriverio` commands
+### 自定义 `webdriverio` 命令 {#custom-webdriverio-commands}
 
 Vitest 在上下文对象上公开了一些 `webdriverio` 特有属性。
 

From d524e975d181bbd63130e229351b8618b6f5ac4a Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 1 Dec 2025 02:49:57 +0800
Subject: [PATCH 46/50] !docs: recovery /guide/browser/multiple-setups

---
 .vitepress/config.ts             |  4 ++--
 guide/browser/multiple-setups.md | 21 +++++++++++++++++++--
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/.vitepress/config.ts b/.vitepress/config.ts
index d88aba88..5349f25b 100644
--- a/.vitepress/config.ts
+++ b/.vitepress/config.ts
@@ -348,9 +348,9 @@ export default ({ mode }: { mode: string }) => {
               collapsed: false,
               items: [
                 {
-                  text: '多种设置',
+                  text: '多环境配置',
                   link: '/guide/browser/multiple-setups',
-                  docFooterText: '多种设置 | 浏览器模式',
+                  docFooterText: '多环境配置 | 浏览器模式',
                 },
                 {
                   text: '组件测试',
diff --git a/guide/browser/multiple-setups.md b/guide/browser/multiple-setups.md
index 95d070a2..925e83b5 100644
--- a/guide/browser/multiple-setups.md
+++ b/guide/browser/multiple-setups.md
@@ -1,4 +1,4 @@
-# 多种设置 {#multiple-setups}
+# 多环境配置 {#multiple-setups}
 
 你可以使用 [`browser.instances`](/guide/browser/config#browser-instances) 选项来指定多个不同的浏览器设置。
 
@@ -28,7 +28,7 @@ export default defineConfig({
 })
 ```
 
-## 不同的设置 {#different-setups}
+## 不同的配置方案 {#different-setups}
 
 你还可以独立于浏览器指定不同的配置选项（尽管，实例也可以有 `browser` 字段）：
 
@@ -119,3 +119,20 @@ export default defineConfig({
 })
 ```
 :::
+
+::: warning
+Vitest 无法运行多个将 `headless` 模式设置为 `false`（默认行为）的实例。在开发过程中，你可以在终端中选择要运行的项目：
+
+```shell
+? Found multiple projects that run browser tests in headed mode: "chromium", "firefox".
+Vitest cannot run multiple headed browsers at the same time. Select a single project
+to run or cancel and run tests with "headless: true" option. Note that you can also
+start tests with --browser=name or --project=name flag. › - Use arrow-keys. Return to submit.
+❯   chromium
+    firefox
+```
+
+如果我们在 CI 中有多个非 headless 项目（即在配置中手动设置了 `headless: false` 并且未在 CI 环境中覆盖），Vitest 将运行失败并且不会启动任何测试。
+
+这一限制不影响在无头模式下运行测试的能力。只要实例没有设置 `headless: false`，你仍然可以并行运行所有实例。
+:::

From 43e995ec6d53164caee0c10e96c900e2a3d335e2 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 1 Dec 2025 02:52:03 +0800
Subject: [PATCH 47/50] typo: fix some issues /guide/browser/ some file

---
 .vitepress/config.ts                       |  15 -
 guide/browser/component-testing.md         | 575 -----------------
 guide/browser/trace-view.md                |  74 ---
 guide/browser/visual-regression-testing.md | 692 ---------------------
 4 files changed, 1356 deletions(-)
 delete mode 100644 guide/browser/component-testing.md
 delete mode 100644 guide/browser/trace-view.md
 delete mode 100644 guide/browser/visual-regression-testing.md

diff --git a/.vitepress/config.ts b/.vitepress/config.ts
index 5349f25b..53d31cd2 100644
--- a/.vitepress/config.ts
+++ b/.vitepress/config.ts
@@ -352,21 +352,6 @@ export default ({ mode }: { mode: string }) => {
                   link: '/guide/browser/multiple-setups',
                   docFooterText: '多环境配置 | 浏览器模式',
                 },
-                {
-                  text: '组件测试',
-                  link: '/guide/browser/component-testing',
-                  docFooterText: '组件测试 | 浏览器模式',
-                },
-                {
-                  text: '可视化回归测试',
-                  link: '/guide/browser/visual-regression-testing',
-                  docFooterText: '可视化回归测试 | 浏览器模式',
-                },
-                {
-                  text: '跟踪查看器',
-                  link: '/guide/browser/trace-view',
-                  docFooterText: '跟踪查看器 | 浏览器模式',
-                },
               ],
             },
             {
diff --git a/guide/browser/component-testing.md b/guide/browser/component-testing.md
deleted file mode 100644
index f1f8e9b8..00000000
--- a/guide/browser/component-testing.md
+++ /dev/null
@@ -1,575 +0,0 @@
----
-title: Component Testing | Guide
-outline: deep
----
-
-# 组件测试 {#component-testing}
-
-组件测试是一种专注于独立测试单个UI组件的测试策略。与测试整个用户流程的端到端测试不同，组件测试验证每个组件单独工作是否正确，使它们运行更快且更容易调试。
-
-Vitest为多个框架提供全面的组件测试支持，包括Vue、React、Svelte、Lit、Preact、Qwik、Solid、Marko等。本指南涵盖了使用Vitest有效测试组件的特定模式、工具和最佳实践。
-
-## 为什么进行组件测试？ {#why-component-testing}
-
-组件测试位于单元测试和端到端测试之间，提供了几个优势：
-
-- **更快的反馈** - 测试单个组件而无需加载整个应用程序
-- **隔离测试** - 关注组件行为而无需外部依赖
-- **更好的调试** - 更容易定位特定组件中的问题
-- **全面的覆盖** - 更容易测试边缘情况和错误状态
-
-## 组件测试的浏览器模式 {#browser-mode-for-component-testing}
-
-Vitest中的组件测试使用**浏览器模式**在真实浏览器环境中运行测试，支持使用Playwright、WebdriverIO或预览模式。这提供了最准确的测试环境，因为你的组件在真实浏览器中运行，具有实际的DOM实现、CSS渲染和浏览器API。
-
-### 为什么使用浏览器模式？ {#why-browser-mode}
-
-浏览器模式是组件测试的推荐方法，因为它提供了最准确的测试环境。与DOM模拟库不同，浏览器模式能够捕获影响用户的真实世界问题。
-
-::: tip
-浏览器模式能够捕获DOM模拟库可能遗漏的问题，包括：
-- CSS布局和样式问题
-- 真实浏览器API行为
-- 准确的事件处理和传播
-- 正确的焦点管理和无障碍功能特性
-
-:::
-
-### 本指南的目的 {#purpose-of-this-guide}
-
-本指南专门介绍使用Vitest功能的**组件测试模式和最佳实践**。虽然许多示例使用浏览器模式（因为这是推荐的方法），但这里的重点是组件特定的测试策略，而不是浏览器配置细节。
-
-有关详细的浏览器设置、配置选项和高级浏览器功能，请参阅[浏览器模式文档](/guide/browser/)。
-
-## 什么是好的组件测试 {#what-makes-a-good-component-test}
-
-好的组件测试关注**行为和用户体验**，而不是实现细节：
-
-- **测试契约** - 组件如何接收输入（props）并产生输出（事件、渲染）
-- **测试用户交互** - 点击、表单提交、键盘导航
-- **测试边缘情况** - 错误状态、加载状态、空状态
-- **避免测试内部实现** - 状态变量、私有方法、CSS类
-
-### 组件测试层次结构 {#component-testing-hierarchy}
-
-```
-1. Critical User Paths → Always test these
-2. Error Handling      → Test failure scenarios
-3. Edge Cases          → Empty data, extreme values
-4. Accessibility       → Screen readers, keyboard nav
-5. Performance         → Large datasets, animations
-```
-
-## 组件测试策略 {#component-testing-strategies}
-
-### 隔离策略 {#isolation-strategy}
-
-通过模拟依赖项来隔离测试组件：
-
-```tsx
-// For API requests, we recommend MSW (Mock Service Worker)
-// See: https://vitest.dev/guide/mocking/requests
-//
-// vi.mock(import('../api/userService'), () => ({
-//   fetchUser: vi.fn().mockResolvedValue({ name: 'John' })
-// }))
-
-// Mock child components to focus on parent logic
-vi.mock(import('../components/UserCard'), () => ({
-  default: vi.fn(({ user }) => `<div>User: ${user.name}</div>`)
-}))
-
-test('UserProfile handles loading and data states', async () => {
-  const { getByText } = render(<UserProfile userId="123" />)
-
-  // Test loading state
-  await expect.element(getByText('Loading...')).toBeInTheDocument()
-
-  // Test for data to load (expect.element auto-retries)
-  await expect.element(getByText('User: John')).toBeInTheDocument()
-})
-```
-
-### 集成策略 {#integration-strategy}
-
-测试组件协作和数据流：
-
-```tsx
-test('ProductList filters and displays products correctly', async () => {
-  const mockProducts = [
-    { id: 1, name: 'Laptop', category: 'Electronics', price: 999 },
-    { id: 2, name: 'Book', category: 'Education', price: 29 }
-  ]
-
-  const { getByLabelText, getByText } = render(
-    <ProductList products={mockProducts} />
-  )
-
-  // Initially shows all products
-  await expect.element(getByText('Laptop')).toBeInTheDocument()
-  await expect.element(getByText('Book')).toBeInTheDocument()
-
-  // Filter by category
-  await userEvent.selectOptions(
-    getByLabelText(/category/i),
-    'Electronics'
-  )
-
-  // Only electronics should remain
-  await expect.element(getByText('Laptop')).toBeInTheDocument()
-  await expect.element(queryByText('Book')).not.toBeInTheDocument()
-})
-```
-
-## Testing Library 集成 {#testing-library-integration}
-
-虽然Vitest为流行的框架提供了官方包([`vitest-browser-vue`](https://www.npmjs.com/package/vitest-browser-vue)、[`vitest-browser-react`](https://www.npmjs.com/package/vitest-browser-react)、[`vitest-browser-svelte`](https://www.npmjs.com/package/vitest-browser-svelte))，但你也可以为尚未得到官方支持的框架集成[Testing Library](https://testing-library.com/)。
-
-### 何时使用 Testing Library {#when-to-use-testing-library}
-
-- 你的框架还没有官方的Vitest浏览器包
-- 你正在迁移使用Testing Library的现有测试
-- 你更喜欢Testing Library的API来处理特定的测试场景
-
-### 集成模式 {#integration-pattern}
-
-关键是使用 `page.elementLocator()` 来桥接 Testing Library 的 DOM 输出与 Vitest 的浏览器模式 API：
-
-```jsx
-// For Solid.js components
-import { render } from '@testing-library/solid'
-import { page } from 'vitest/browser'
-
-test('Solid component handles user interaction', async () => {
-  // Use Testing Library to render the component
-  const { baseElement, getByRole } = render(() =>
-    <Counter initialValue={0} />
-  )
-
-  // Bridge to Vitest's browser mode for interactions and assertions
-  const screen = page.elementLocator(baseElement)
-
-  // Use Vitest's page queries for finding elements
-  const incrementButton = screen.getByRole('button', { name: /increment/i })
-
-  // Use Vitest's assertions and interactions
-  await expect.element(screen.getByText('Count: 0')).toBeInTheDocument()
-
-  // Trigger user interaction using Vitest's page API
-  await incrementButton.click()
-
-  await expect.element(screen.getByText('Count: 1')).toBeInTheDocument()
-})
-```
-
-### 可用的 Testing Library 包 {#available-testing-library-packages}
-
-与Vitest配合使用效果良好的流行Testing Library包：
-
-- [`@testing-library/solid`](https://github.com/solidjs/solid-testing-library) - 用于Solid.js
-- [`@marko/testing-library`](https://testing-library.com/docs/marko-testing-library/intro) - 用于Marko
-- [`@testing-library/svelte`](https://testing-library.com/docs/svelte-testing-library/intro) - [`vitest-browser-svelte`](https://www.npmjs.com/package/vitest-browser-svelte)的替代方案
-- [`@testing-library/vue`](https://testing-library.com/docs/vue-testing-library/intro) - [`vitest-browser-vue`](https://www.npmjs.com/package/vitest-browser-vue)的替代方案
-
-::: tip Migration Path
-如果你的框架后来获得了官方的Vitest支持，你可以通过替换Testing Library的 `render` 函数来逐步迁移，同时保持大部分测试逻辑不变。
-:::
-
-## 最佳实践 {#best-practices}
-
-### 1. 在CI/CD中使用浏览器模式 {#_1-use-browser-mode-for-ci-cd}
-确保测试在真实浏览器环境中运行以获得最准确的测试结果。浏览器模式提供准确的CSS渲染、真实的浏览器API和正确的事件处理。
-
-### 2. 测试用户交互 {#_2-test-user-interactions}
-使用Vitest的[交互API](/guide/browser/interactivity-api)模拟真实用户行为。使用`page.getByRole()`和`userEvent`方法，如我们的[高级测试模式](#advanced-testing-patterns)所示：
-
-```tsx
-// Good: Test actual user interactions
-await page.getByRole('button', { name: /submit/i }).click()
-await page.getByLabelText(/email/i).fill('user@example.com')
-
-// Avoid: Testing implementation details
-// component.setState({ email: 'user@example.com' })
-```
-
-### 3. 测试可访问性 {#_3-test-accessibility}
-通过测试键盘导航、焦点管理和ARIA属性，确保组件对所有用户都能正常工作。请查看我们的[测试可访问性](#testing-accessibility)示例了解实用模式：
-
-```tsx
-// Test keyboard navigation
-await userEvent.keyboard('{Tab}')
-await expect.element(document.activeElement).toHaveFocus()
-
-// Test ARIA attributes
-await expect.element(modal).toHaveAttribute('aria-modal', 'true')
-```
-
-### 4. 模拟外部依赖 {#_4-mock-external-dependencies}
-通过模拟API和外部服务，将测试重点放在组件逻辑上。这使得测试更快、更可靠。请查看我们的[隔离策略](#isolation-strategy)获取示例：
-
-```tsx
-// For API requests, we recommend using MSW (Mock Service Worker)
-// See: https://vitest.dev/guide/mocking/requests
-// This provides more realistic request/response mocking
-
-// For module mocking, use the import() syntax
-vi.mock(import('../components/UserCard'), () => ({
-  default: vi.fn(() => <div>Mocked UserCard</div>)
-}))
-```
-
-### 5. 使用有意义的测试描述 {#_5-use-meaningful-test-descriptions}
-编写测试描述时，应解释预期行为，而不是实现细节：
-
-```tsx
-// Good: Describes user-facing behavior
-test('shows error message when email format is invalid')
-test('disables submit button while form is submitting')
-
-// Avoid: Implementation-focused descriptions
-test('calls validateEmail function')
-test('sets isSubmitting state to true')
-```
-
-## 高级测试模式 {#advanced-testing-patterns}
-
-### 测试组件状态管理 {#testing-component-state-management}
-
-```tsx
-// Testing stateful components and state transitions
-test('ShoppingCart manages items correctly', async () => {
-  const { getByText, getByTestId } = render(<ShoppingCart />)
-
-  // Initially empty
-  await expect.element(getByText('Your cart is empty')).toBeInTheDocument()
-
-  // Add item
-  await page.getByRole('button', { name: /add laptop/i }).click()
-
-  // Verify state change
-  await expect.element(getByText('1 item')).toBeInTheDocument()
-  await expect.element(getByText('Laptop - $999')).toBeInTheDocument()
-
-  // Test quantity updates
-  await page.getByRole('button', { name: /increase quantity/i }).click()
-  await expect.element(getByText('2 items')).toBeInTheDocument()
-})
-```
-
-### 测试带有数据获取的异步组件 {#testing-async-components-with-data-fetching}
-
-```tsx
-// Option 1: Recommended - Use MSW (Mock Service Worker) for API mocking
-import { http, HttpResponse } from 'msw'
-import { setupServer } from 'msw/node'
-
-// Set up MSW server with API handlers
-const server = setupServer(
-  http.get('/api/users/:id', ({ params }) => {
-    const { id } = params
-    if (id === '123') {
-      return HttpResponse.json({ name: 'John Doe', email: 'john@example.com' })
-    }
-    return HttpResponse.json({ error: 'User not found' }, { status: 404 })
-  })
-)
-
-// Start server before all tests
-beforeAll(() => server.listen())
-afterEach(() => server.resetHandlers())
-afterAll(() => server.close())
-
-test('UserProfile handles loading, success, and error states', async () => {
-  // Test success state
-  const { getByText } = render(<UserProfile userId="123" />)
-  // expect.element auto-retries until elements are found
-  await expect.element(getByText('John Doe')).toBeInTheDocument()
-  await expect.element(getByText('john@example.com')).toBeInTheDocument()
-
-  // Test error state by overriding the handler for this test
-  server.use(
-    http.get('/api/users/:id', () => {
-      return HttpResponse.json({ error: 'User not found' }, { status: 404 })
-    })
-  )
-
-  const { getByText: getErrorText } = render(<UserProfile userId="999" />)
-  await expect.element(getErrorText('Error: User not found')).toBeInTheDocument()
-})
-```
-
-### 测试组件通信 {#testing-component-communication}
-
-```tsx
-// Test parent-child component interaction
-test('parent and child components communicate correctly', async () => {
-  const mockOnSelectionChange = vi.fn()
-
-  const { getByText } = render(
-    <ProductCatalog onSelectionChange={mockOnSelectionChange}>
-      <ProductFilter />
-      <ProductGrid />
-    </ProductCatalog>
-  )
-
-  // Interact with child component
-  await page.getByRole('checkbox', { name: /electronics/i }).click()
-
-  // Verify parent receives the communication
-  expect(mockOnSelectionChange).toHaveBeenCalledWith({
-    category: 'electronics',
-    filters: ['electronics']
-  })
-
-  // Verify other child component updates (expect.element auto-retries)
-  await expect.element(getByText('Showing Electronics products')).toBeInTheDocument()
-})
-```
-
-### 测试带验证的复杂表单 {#testing-complex-forms-with-validation}
-
-```tsx
-test('ContactForm handles complex validation scenarios', async () => {
-  const mockSubmit = vi.fn()
-  const { getByLabelText, getByText } = render(
-    <ContactForm onSubmit={mockSubmit} />
-  )
-
-  const nameInput = page.getByLabelText(/full name/i)
-  const emailInput = page.getByLabelText(/email/i)
-  const messageInput = page.getByLabelText(/message/i)
-  const submitButton = page.getByRole('button', { name: /send message/i })
-
-  // Test validation triggers
-  await submitButton.click()
-
-  await expect.element(getByText('Name is required')).toBeInTheDocument()
-  await expect.element(getByText('Email is required')).toBeInTheDocument()
-  await expect.element(getByText('Message is required')).toBeInTheDocument()
-
-  // Test partial validation
-  await nameInput.fill('John Doe')
-  await submitButton.click()
-
-  await expect.element(getByText('Name is required')).not.toBeInTheDocument()
-  await expect.element(getByText('Email is required')).toBeInTheDocument()
-
-  // Test email format validation
-  await emailInput.fill('invalid-email')
-  await submitButton.click()
-
-  await expect.element(getByText('Please enter a valid email')).toBeInTheDocument()
-
-  // Test successful submission
-  await emailInput.fill('john@example.com')
-  await messageInput.fill('Hello, this is a test message.')
-  await submitButton.click()
-
-  expect(mockSubmit).toHaveBeenCalledWith({
-    name: 'John Doe',
-    email: 'john@example.com',
-    message: 'Hello, this is a test message.'
-  })
-})
-```
-
-### 测试错误边界 {#testing-error-boundaries}
-
-```tsx
-// Test how components handle and recover from errors
-function ThrowError({ shouldThrow }: { shouldThrow: boolean }) {
-  if (shouldThrow) {
-    throw new Error('Component error!')
-  }
-  return <div>Component working fine</div>
-}
-
-test('ErrorBoundary catches and displays errors gracefully', async () => {
-  const { getByText, rerender } = render(
-    <ErrorBoundary fallback={<div>Something went wrong</div>}>
-      <ThrowError shouldThrow={false} />
-    </ErrorBoundary>
-  )
-
-  // Initially working
-  await expect.element(getByText('Component working fine')).toBeInTheDocument()
-
-  // Trigger error
-  rerender(
-    <ErrorBoundary fallback={<div>Something went wrong</div>}>
-      <ThrowError shouldThrow={true} />
-    </ErrorBoundary>
-  )
-
-  // Error boundary should catch it
-  await expect.element(getByText('Something went wrong')).toBeInTheDocument()
-})
-```
-
-### 测试可访问性 {#testing-accessibility}
-
-```tsx
-test('Modal component is accessible', async () => {
-  const { getByRole, getByLabelText } = render(
-    <Modal isOpen={true} title="Settings">
-      <SettingsForm />
-    </Modal>
-  )
-
-  // Test focus management - modal should receive focus when opened
-  // This is crucial for screen reader users to know a modal opened
-  const modal = getByRole('dialog')
-  await expect.element(modal).toHaveFocus()
-
-  // Test ARIA attributes - these provide semantic information to screen readers
-  await expect.element(modal).toHaveAttribute('aria-labelledby') // Links to title element
-  await expect.element(modal).toHaveAttribute('aria-modal', 'true') // Indicates modal behavior
-
-  // Test keyboard navigation - Escape key should close modal
-  // This is required by ARIA authoring practices
-  await userEvent.keyboard('{Escape}')
-  // expect.element auto-retries until modal is removed
-  await expect.element(modal).not.toBeInTheDocument()
-
-  // Test focus trap - tab navigation should cycle within modal
-  // This prevents users from tabbing to content behind the modal
-  const firstInput = getByLabelText(/username/i)
-  const lastButton = getByRole('button', { name: /save/i })
-
-  // Use click to focus on the first input, then test tab navigation
-  await firstInput.click()
-  await userEvent.keyboard('{Shift>}{Tab}{/Shift}') // Shift+Tab goes backwards
-  await expect.element(lastButton).toHaveFocus() // Should wrap to last element
-})
-```
-
-## 调试组件测试 {#debugging-component-tests}
-
-### 1. 使用浏览器开发者工具 {#_1-use-browser-dev-tools}
-
-浏览器模式在真实浏览器中运行测试，让你可以使用完整的开发者工具。当测试失败时，你可以：
-
-- **在测试执行期间打开浏览器开发者工具**（按F12或右键点击→检查）
-- **在测试代码或组件代码中设置断点**
-- **检查DOM**以查看实际渲染的输出
-- **检查控制台错误**以查找JavaScript错误或警告
-- **监控网络请求**以调试API调用
-
-对于有头模式调试，可以在浏览器配置中临时添加`headless: false`。
-
-### 2. 添加调试语句 {#_2-add-debug-statements}
-
-使用策略性日志记录来理解测试失败：
-
-```tsx
-test('debug form validation', async () => {
-  render(<ContactForm />)
-
-  const submitButton = page.getByRole('button', { name: /submit/i })
-  await submitButton.click()
-
-  // Debug: Check if element exists with different query
-  const errorElement = page.getByText('Email is required')
-  console.log('Error element found:', errorElement.length)
-
-  await expect.element(errorElement).toBeInTheDocument()
-})
-```
-
-### 3. 检查渲染输出 {#_3-inspect-rendered-output}
-
-当组件未按预期渲染时，请系统性地进行调查：
-
-**使用Vitest的浏览器UI：**
-- 在启用浏览器模式的情况下运行测试
-- 打开终端中显示的浏览器URL以查看测试运行情况
-- 可视化检查有助于识别CSS问题、布局问题或缺失元素
-
-**测试元素查询：**
-```tsx
-// Debug why elements can't be found
-const button = page.getByRole('button', { name: /submit/i })
-console.log('Button count:', button.length) // Should be 1
-
-// Try alternative queries if the first one fails
-if (button.length === 0) {
-  console.log('All buttons:', page.getByRole('button').length)
-  console.log('By test ID:', page.getByTestId('submit-btn').length)
-}
-```
-
-### 4. 验证选择器 {#_4-verify-selectors}
-
-选择器问题是测试失败的常见原因。请系统性地调试它们：
-
-**检查可访问名称：**
-```tsx
-// If getByRole fails, check what roles/names are available
-const buttons = page.getByRole('button').all()
-for (const button of buttons) {
-  // Use element() to get the DOM element and access native properties
-  const element = button.element()
-  const accessibleName = element.getAttribute('aria-label') || element.textContent
-  console.log(`Button: "${accessibleName}"`)
-}
-```
-
-**测试不同的查询策略：**
-```tsx
-// Multiple ways to find the same element using .or for auto-retrying
-const submitButton = page.getByRole('button', { name: /submit/i }) // By accessible name
-  .or(page.getByTestId('submit-button')) // By test ID
-  .or(page.getByText('Submit')) // By exact text
-// Note: Vitest doesn't have page.locator(), use specific getBy* methods instead
-```
-
-**常见的选择器调试模式：**
-```tsx
-test('debug element queries', async () => {
-  render(<LoginForm />)
-
-  // Check if element is visible and enabled
-  const emailInput = page.getByLabelText(/email/i)
-  await expect.element(emailInput).toBeVisible() // Will show if element is visible and print DOM if not
-})
-```
-
-### 5. 调试异步问题 {#_5-debugging-async-issues}
-
-组件测试经常涉及时机问题：
-
-```tsx
-test('debug async component behavior', async () => {
-  render(<AsyncUserProfile userId="123" />)
-
-  // expect.element will automatically retry and show helpful error messages
-  await expect.element(page.getByText('John Doe')).toBeInTheDocument()
-})
-```
-
-## 从其他测试框架迁移 {#migration-from-other-testing-frameworks}
-
-### 从 Jest + Testing Library 迁移 {#from-jest-testing-library}
-
-大多数 Jest + Testing Library 测试只需少量更改即可工作：
-
-```ts
-// Before (Jest)
-import { render, screen } from '@testing-library/react' // [!code --]
-
-// After (Vitest)
-import { render } from 'vitest-browser-react' // [!code ++]
-```
-
-### 主要差异 {#key-differences}
-
-- 使用 `await expect.element()` 而不是 `expect()` 进行 DOM 断言
-- 使用 `vitest/browser` 进行用户交互而不是 `@testing-library/user-event`
-- 浏览器模式提供真实的浏览器环境以进行准确的测试
-
-## 了解更多 {#learn-more}
-
-- [浏览器模式文档](/guide/browser/)
-- [断言API](/guide/browser/assertion-api)
-- [交互性API](/guide/browser/interactivity-api)
-- [示例仓库](https://github.com/vitest-tests/browser-examples)
diff --git a/guide/browser/trace-view.md b/guide/browser/trace-view.md
deleted file mode 100644
index d78db55d..00000000
--- a/guide/browser/trace-view.md
+++ /dev/null
@@ -1,74 +0,0 @@
-# Trace View
-
-Vitest Browser Mode supports generating Playwright's [trace files](https://playwright.dev/docs/trace-viewer#viewing-remote-traces). To enable tracing, you need to set the [`trace`](/guide/browser/config#browser-trace) option in the `test.browser` configuration.
-
-::: warning
-Generating trace files is only available when using the [Playwright provider](/guide/browser/playwright).
-:::
-
-::: code-group
-```ts [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-import { playwright } from '@vitest/browser-playwright'
-
-export default defineConfig({
-  test: {
-    browser: {
-      provider: playwright(),
-      trace: 'on',
-    },
-  },
-})
-```
-```bash [CLI]
-vitest --browser.trace=on
-```
-:::
-
-By default, Vitest will generate a trace file for each test. You can also configure it to only generate traces on test failures by setting `trace` to `'on-first-retry'`, `'on-all-retries'` or `'retain-on-failure'`. The files will be saved in `__traces__` folder next to your test files. The name of the trace includes the project name, the test name, the [`repeats` count and `retry` count](/api/#test-api-reference):
-
-```
-chromium-my-test-0-0.trace.zip
-^^^^^^^^ project name
-         ^^^^^^ test name
-                ^ repeat count
-                  ^ retry count
-```
-
-To change the output directory, you can set the `tracesDir` option in the `test.browser.trace` configuration. This way all traces will be stored in the same directory, grouped by the test file.
-
-```ts [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-import { playwright } from '@vitest/browser-playwright'
-
-export default defineConfig({
-  test: {
-    browser: {
-      provider: playwright(),
-      trace: {
-        mode: 'on',
-        // the path is relative to the root of the project
-        tracesDir: './playwright-traces',
-      },
-    },
-  },
-})
-```
-
-The traces are available in reporters as [annotations](/guide/test-annotations). For example, in the HTML reporter, you can find the link to the trace file in the test details.
-
-## Preview
-
-To open the trace file, you can use the Playwright Trace Viewer. Run the following command in your terminal:
-
-```bash
-npx playwright show-trace "path-to-trace-file"
-```
-
-This will start the Trace Viewer and load the specified trace file.
-
-Alternatively, you can open the Trace Viewer in your browser at https://trace.playwright.dev and upload the trace file there.
-
-## Limitations
-
-At the moment, Vitest cannot populate the "Sources" tab in the Trace Viewer. This means that while you can see the actions and screenshots captured during the test, you won't be able to view the source code of your tests directly within the Trace Viewer. You will need to refer back to your code editor to see the test implementation.
diff --git a/guide/browser/visual-regression-testing.md b/guide/browser/visual-regression-testing.md
deleted file mode 100644
index 4037932c..00000000
--- a/guide/browser/visual-regression-testing.md
+++ /dev/null
@@ -1,692 +0,0 @@
----
-title: 可视化回归测试
-outline: [2, 3]
----
-
-# 可视化回归测试 {#visual-regression-testing}
-
-Vitest 原生支持可视化回归测试。它会自动截取 UI 组件或页面的截图，并与基准图像对比，以捕捉那些非预期的视觉变化。
-
-与只验证功能逻辑的功能测试不同，可视化测试能发现样式异常、布局偏移和渲染错误——这些问题如果没有细致的人工检查，往往会被忽略。
-
-## 为什么需要可视化回归测试？ {#why-visual-regression-testing}
-
-视觉 bug 不会报错，但它们的外观已经改变。这正是可视化测试的意义所在：
-
-- 按钮依然能提交表单，但颜色却变成了亮粉色
-- 文本在桌面端显示正常，在移动端却被挤压变形
-- 功能没问题，可两个容器已跑出视口
-- 精心的 CSS 重构完成了，却破坏了某个无人测试的页面布局
-
-可视化回归测试是 UI 的安全网，确保这些变化在进入生产环境之前就被自动发现并处理。
-
-## 快速入门 {#getting-started}
-
-::: warning 浏览器渲染差异
-可视化回归测试对运行环境非常敏感，不同机器生成的截图可能存在差异，常见原因包括：
-
-- 字体渲染差异（最常见，Windows、macOS、Linux 各不相同）
-- GPU 驱动与硬件加速
-- 是否使用无头模式
-- 浏览器版本与设置
-- ……甚至偶发的系统差异
-
-因此，Vitest 会在截图文件名中添加浏览器和平台信息（如 `button-chromium-darwin.png`），避免不同环境的截图互相覆盖。
-
-要获得稳定结果，应使用相同的测试环境。**推荐**采用云端服务（如 [Azure App Testing](https://azure.microsoft.com/en-us/products/playwright-testing)）或基于 [Docker containers](https://playwright.dev/docs/docker) 的环境。
-:::
-
-在 Vitest 中，可通过 [`toMatchScreenshot` assertion](/guide/browser/assertion-api.html#tomatchscreenshot) 断言运行可视化回归测试：
-
-```ts
-import { expect, test } from 'vitest'
-import { page } from 'vitest/browser'
-
-test('hero section looks correct', async () => {
-  // ...the rest of the test
-
-  // capture and compare screenshot
-  await expect(page.getByTestId('hero')).toMatchScreenshot('hero-section')
-})
-```
-
-### 创建基准截图 {#creating-references}
-
-首次运行可视化测试时， Vitest 会生成一张基准（ baseline ）截图，并提示如下错误信息使测试失败：
-
-```
-expect(element).toMatchScreenshot()
-
-No existing reference screenshot found; a new one was created. Review it before running tests again.
-
-Reference screenshot:
-  tests/__screenshots__/hero.test.ts/hero-section-chromium-darwin.png
-```
-
-确认截图正确后再次运行测试，Vitest 会将后续结果与该基准图比较。
-
-::: tip
-基准截图存放在测试文件所在目录下的 `__screenshots__` 文件夹中，
-**请务必提交到版本库**。
-:::
-
-### 截图组织方式 {#screenshot-organization}
-
-Vitest 默认将截图按以下结构保存：
-
-```
-.
-├── __screenshots__
-│   └── test-file.test.ts
-│       ├── test-name-chromium-darwin.png
-│       ├── test-name-firefox-linux.png
-│       └── test-name-webkit-win32.png
-└── test-file.test.ts
-```
-
-文件名由三部分组成：
-- **测试名**：来自 `toMatchScreenshot()` 的第一个参数，或自动根据测试用例名生成
-- **浏览器名**：`chrome`、`chromium`、`firefox`、`webkit`
-- **平台**：如 `aix`、`darwin`、`linux`、`win32` 等
-
-这种命名方式可避免不同环境生成的截图互相覆盖。
-
-### 更新基准截图 {#updating-references}
-
-当你有意修改 UI 时，需要更新基准截图：
-
-```bash
-$ vitest --update
-```
-
-提交前务必核对更新后的截图，确保改动符合预期。
-
-## 配置可视化测试 {#configuring-visual-tests}
-
-### 全局配置 {#global-configuration}
-
-可在 [Vitest 配置文件](/guide/browser/config#browser-expect-tomatchscreenshot) 中设定可视化回归测试的默认规则：
-
-```ts [vitest.config.ts]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    browser: {
-      expect: {
-        toMatchScreenshot: {
-          comparatorName: 'pixelmatch',
-          comparatorOptions: {
-            // 0-1, how different can colors be?
-            threshold: 0.2,
-            // 1% of pixels can differ
-            allowedMismatchedPixelRatio: 0.01,
-          },
-        },
-      },
-    },
-  },
-})
-```
-
-### 单测试配置 {#per-test-configuration}
-
-若某个测试需要不同的比较标准，可在调用时覆盖全局设置：
-
-```ts
-await expect(element).toMatchScreenshot('button-hover', {
-  comparatorName: 'pixelmatch',
-  comparatorOptions: {
-    // more lax comparison for text-heavy elements
-    allowedMismatchedPixelRatio: 0.1,
-  },
-})
-```
-
-## 最佳实践 {#best-practices}
-
-### 聚焦测试目标元素 {#test-specific-elements}
-
-除非确实需要测试整个页面，否则应优先只对目标组件截图，这能显著减少因页面其他部分变化而造成的误报。
-
-```ts
-// ❌ Captures entire page; prone to unrelated changes
-await expect(page).toMatchScreenshot()
-
-// ✅ Captures only the component under test
-await expect(page.getByTestId('product-card')).toMatchScreenshot()
-```
-
-### 处理动态内容 {#handle-dynamic-content}
-
-测试中，如果页面包含诸如时间戳、用户信息或随机值等动态内容，往往会导致结果不一致而造成测试失败。
-解决方法有两种：一是模拟这些动态数据的生成源；
-二是在使用 Playwright 进行截图时，在 `screenshotOptions` 中启用
-[`mask` 选项](https://playwright.dev/docs/api/class-page#page-screenshot-option-mask)，
-将这些动态区域遮盖，从而确保测试结果的稳定性。
-
-```ts
-await expect(page.getByTestId('profile')).toMatchScreenshot({
-  screenshotOptions: {
-    mask: [page.getByTestId('last-seen')],
-  },
-})
-```
-
-### 禁用所有动画 {#disable-animations}
-
-动画效果往往会导致测试结果出现波动。为避免这种情况，
-可以在测试执行过程中注入一段自定义的 CSS 样式代码，用于禁用所有动画，从而提升测试的稳定性。
-
-```css
-*, *::before, *::after {
-  animation-duration: 0s !important;
-  animation-delay: 0s !important;
-  transition-duration: 0s !important;
-  transition-delay: 0s !important;
-}
-```
-
-::: tip
-在使用 Playwright 作为测试工具时，若执行断言操作，动画会被自动禁用。
-具体而言，`screenshotOptions` 配置中的 `animations` 选项会默认设为 `"disabled"`，从而确保截图与测试结果的稳定一致。
-:::
-
-### 设置合理的阈值 {#set-appropriate-thresholds}
-
-在视觉回归测试中，阈值调整是一项需要权衡的工作——它取决于页面内容、测试环境、
-应用所能容忍的差异范围，且可能因具体测试而有所不同。
-
-Vitest 并未为像素差异设定默认阈值，这需要由用户根据实际需求来决定。
-官方建议使用 `allowedMismatchedPixelRatio`，让阈值按截图的整体尺寸比例计算，而非依赖固定像素数量。
-
-当 `allowedMismatchedPixelRatio` 与 `allowedMismatchedPixels` 同时设置时，
-Vitest 会优先采用二者中限制更严格的那一个，以确保测试结果的准确性与一致性。
-
-### 保持统一的视口大小 {#set-consistent-viewport-sizes}
-
-浏览器实例的默认窗口尺寸可能存在差异，这会影响视觉回归测试的稳定性。为避免由于尺寸不一致而产生的截图偏差，
-建议在测试脚本或浏览器实例配置中显式指定一个固定的视口大小，从而确保测试结果的可重复性与一致性。
-
-```ts
-await page.viewport(1280, 720)
-```
-
-```ts [vitest.config.ts]
-import { playwright } from '@vitest/browser-playwright'
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    browser: {
-      enabled: true,
-      provider: playwright(),
-      instances: [
-        {
-          browser: 'chromium',
-          viewport: { width: 1280, height: 720 },
-        },
-      ],
-    },
-  },
-})
-```
-
-### 使用 Git LFS 管理基准截图 {#use-git-lfs}
-
-对于规模较大的视觉回归测试套件，建议将基准截图文件存储在
-[Git LFS](https://github.com/git-lfs/git-lfs?tab=readme-ov-file) 中。
-这样既能避免仓库体积膨胀，又能高效管理和传输这些大尺寸文件，提升团队协作效率。
-
-## 调试视觉测试失败 {#debugging-failed-tests}
-
-当视觉回归测试未能通过时， Vitest 会生成三张关键截图，帮助你分析问题所在：
-
-1. **参考截图（ Reference screenshot ）**：测试期望的基准图像
-2. **实际截图（ Actual screenshot ）**：测试运行过程中截取的画面
-3. **差异图（ Diff image ）**：用高亮标记出参考图与实际图的差异（有时可能不会生成）
-
-在调试时，你会在输出中看到类似如下的文件列表或路径信息：
-
-```
-expect(element).toMatchScreenshot()
-
-Screenshot does not match the stored reference.
-245 pixels (ratio 0.03) differ.
-
-Reference screenshot:
-  tests/__screenshots__/button.test.ts/button-chromium-darwin.png
-
-Actual screenshot:
-  tests/.vitest-attachments/button.test.ts/button-chromium-darwin-actual.png
-
-Diff image:
-  tests/.vitest-attachments/button.test.ts/button-chromium-darwin-diff.png
-```
-
-### 如何解读差异图 {#understanding-the-diff-image}
-
-- **红色像素**：表示参考截图与实际截图之间存在显著差异的区域
-- **黄色像素**：由抗锯齿处理带来的细微差异（仅在未忽略抗锯齿时可见）
-- **透明或原始图像部分**：表示两张截图在该区域完全一致
-
-:::tip
-如果差异图几乎被红色覆盖，说明测试结果与预期严重不符，需要重点排查。
-若只是文字边缘零星出现少量红点，可能只是渲染细节差异，此时适当提高阈值即可解决。
-:::
-
-## 常见问题与解决方案 {#common-issues-and-solutions}
-
-### 字体渲染引发的误报 {#false-positives-from-font-rendering}
-
-由于不同操作系统在字体可用性与渲染方式上差异明显，视觉回归测试中可能会出现“误报”现象。为降低这种风险，可以考虑以下做法：
-
-- 使用 Web 字体，并在测试执行前等待字体完全加载；
-
-  ```ts
-  // wait for fonts to load
-  await document.fonts.ready
-
-  // continue with your tests
-  ```
-
-- 对包含大量文字的区域适当提高像素差异的比较阈值，以减少因字体渲染细微差别导致的误报；
-
-  ```ts
-  await expect(page.getByTestId('article-summary')).toMatchScreenshot({
-    comparatorName: 'pixelmatch',
-    comparatorOptions: {
-      // 10% of the pixels are allowed to change
-      allowedMismatchedPixelRatio: 0.1,
-    },
-  })
-  ```
-
-- 使用云端服务或容器化测试环境，确保字体渲染效果在各次测试中保持一致，从而减少系统差异带来的影响；
-
-### 测试不稳定或截图尺寸不一致 {#flaky-tests-or-different-screenshot-sizes}
-
-如果测试结果出现随机通过或失败，或者在不同运行中生成的截图尺寸不一致，可以采取以下措施：
-
-- 确保页面所有内容均已加载完成，包括加载指示器与动画；
-- 明确设置固定的视口大小，例如：`await page.viewport(1920, 1080)`；
-- 检查页面在视口临界尺寸下的响应式布局表现；
-- 排查是否存在非预期的动画或过渡效果干扰截图结果；
-- 对体积较大的截图适当延长测试的超时时间；
-- 使用云端服务或容器化环境，确保字体渲染、浏览器配置等保持一致。
-
-## 团队版视觉回归测试方案 {#visual-regression-testing-for-teams}
-
-视觉回归测试对环境的稳定性要求极高，而本地开发机并不适合担当这一角色。
-
-在团队协作中，常见的三种方案是：
-
-1. **自托管运行器**：部署过程复杂，日常维护工作量大；
-2. **GitHub Actions**：对开源项目免费，可与任何测试框架或服务集成；
-3. **云服务**：如 [Microsoft Playwright Testing](https://azure.microsoft.com/en-us/products/playwright-testing)，专为解决视觉测试环境一致性问题而构建。
-
-我们将重点介绍第 2 和第 3 种方案，因为它们能最快投入使用。
-
-主要权衡点在于：
-
-- **GitHub Actions**：视觉测试只能在持续集成（CI）环境中运行，开发者无法直接在本地执行；
-- **Microsoft 云服务**：可在任意环境运行，但需额外付费，并且仅支持 Playwright。
-
-:::: tabs key:vrt-for-teams
-=== GitHub Actions
-
-要点在于，将视觉回归测试与常规测试分离运行。
-否则，你可能会因截图差异引发的失败日志而浪费数小时进行排查。
-
-#### 测试组织建议 {#organizing-your-tests}
-
-首先，应将视觉回归测试与其他测试隔离管理。
-建议单独建立一个 `visual` 文件夹（或根据项目结构选择更合适的目录名称）来存放这些测试用例，以便维护与执行。
-
-```json [package.json]
-{
-  "scripts": {
-    "test:unit": "vitest --exclude tests/visual/*.test.ts",
-    "test:visual": "vitest tests/visual/*.test.ts"
-  }
-}
-```
-
-这样，开发者就能在本地运行 `npm run test:unit` ，而无需受到视觉回归测试的影响；
-视觉测试则放在环境一致的持续集成（ CI ）平台中运行，以确保结果稳定可靠。
-
-::: tip 抉择
-不喜欢用 glob 匹配模式？那你也可以创建独立的 [测试项目](/guide/projects)，并通过以下方式来运行它们：
-
-- `vitest --project unit`
-- `vitest --project visual`
-:::
-
-#### 持续集成（ CI ）环境配置 {#ci-setup}
-
-在 CI 环境中运行视觉回归测试时，需要确保浏览器已正确安装。至于如何安装，则取决于你所使用的 CI 服务提供商及其运行环境。
-
-::: tabs key:provider
-== Playwright
-
-[Playwright](https://npmjs.com/package/playwright) 能让浏览器安装与管理变得非常简单。
-你只需固定所用的 Playwright 版本，并在运行测试之前加入以下命令或脚本：
-
-```yaml [.github/workflows/ci.yml]
-# ...the rest of the workflow
-- name: Install Playwright Browsers
-  run: npx --no playwright install --with-deps --only-shell
-```
-
-== WebdriverIO
-
-[WebdriverIO](https://www.npmjs.com/package/webdriverio) 要求用户自行准备浏览器环境。不过，
-[ @browser-actions ](https://github.com/browser-actions) 团队已经为此提供了方便的解决方案，
-帮你轻松完成浏览器的安装与配置。
-
-```yaml [.github/workflows/ci.yml]
-# ...the rest of the workflow
-- uses: browser-actions/setup-chrome@v1
-  with:
-    chrome-version: 120
-```
-
-:::
-
-最后，运行你的视觉回归测试：
-
-```yaml [.github/workflows/ci.yml]
-# ...the rest of the workflow
-# ...browser setup
-- name: Visual Regression Testing
-  run: npm run test:visual
-```
-
-#### 更新工作流程 {#the-update-workflow}
-
-关键点来了——切勿在每一次 Pull Request 中都自动更新截图，
-<small>*(那只会带来混乱)*</small>。更稳妥的方式，是建立一个手动触发的工作流程，
-让开发者在有意更改 UI 时主动运行，从而更新基准截图。
-
-该工作流程具备以下特性：
-- 仅在功能分支上运行，确保主分支安全不受影响；
-- 自动将触发流程的开发者署名为共同作者；
-- 阻止同一分支上的并发执行，避免冲突与资源浪费；
-- 生成一份清晰美观的执行摘要，便于快速查看结果。
-  - **当基准截图发生变动时**，系统会列出所有具体的变化项，方便开发者快速了解差异。
-
-    <img alt="Action summary after updates" img-light src="/vrt-gha-summary-update-light.png">
-    <img alt="Action summary after updates" img-dark src="/vrt-gha-summary-update-dark.png">
-
-  - **当没有任何变化时**，系统同样会明确提示，让你一目了然。
-
-    <img alt="Action summary after no updates" img-light src="/vrt-gha-summary-no-update-light.png">
-    <img alt="Action summary after no updates" img-dark src="/vrt-gha-summary-no-update-dark.png">
-
-::: tip
-这只是实现的其中一种方式。
-有些团队倾向于在 Pull Request 中添加特定评论（如 `/update-screenshots`）来触发更新，
-也有团队通过添加标签来完成这一操作。
-你可以根据自身的开发流程进行调整。
-
-关键在于，必须建立一种可控的机制来更新基准截图，
-以避免不必要的混乱和错误。
-:::
-
-```yaml [.github/workflows/update-screenshots.yml]
-name: Update Visual Regression Screenshots
-
-on:
-  workflow_dispatch: # manual trigger only
-
-env:
-  AUTHOR_NAME: 'github-actions[bot]'
-  AUTHOR_EMAIL: '41898282+github-actions[bot]@users.noreply.github.com'
-  COMMIT_MESSAGE: |
-    test: update visual regression screenshots
-
-    Co-authored-by: ${{ github.actor }} <${{ github.actor_id }}+${{ github.actor }}@users.noreply.github.com>
-
-jobs:
-  update-screenshots:
-    runs-on: ubuntu-24.04
-
-    # safety first: don't run on main
-    if: github.ref_name != github.event.repository.default_branch
-
-    # one at a time per branch
-    concurrency:
-      group: visual-regression-screenshots@${{ github.ref_name }}
-      cancel-in-progress: true
-
-    permissions:
-      contents: write # needs to push changes
-
-    steps:
-      - name: Checkout selected branch
-        uses: actions/checkout@v4
-        with:
-          ref: ${{ github.ref_name }}
-          # use PAT if triggering other workflows
-          # token: ${{ secrets.GITHUB_TOKEN }}
-
-      - name: Configure Git
-        run: |
-          git config --global user.name "${{ env.AUTHOR_NAME }}"
-          git config --global user.email "${{ env.AUTHOR_EMAIL }}"
-
-      # your setup steps here (node, pnpm, whatever)
-      - name: Setup Node.js
-        uses: actions/setup-node@v4
-        with:
-          node-version: 24
-
-      - name: Install dependencies
-        run: npm ci
-
-      - name: Install Playwright Browsers
-        run: npx --no playwright install --with-deps --only-shell
-
-      # the magic happens below 🪄
-      - name: Update Visual Regression Screenshots
-        run: npm run test:visual --update
-
-      # check what changed
-      - name: Check for changes
-        id: check_changes
-        run: |
-          CHANGED_FILES=$(git status --porcelain | awk '{print $2}')
-          if [ "${CHANGED_FILES:+x}" ]; then
-            echo "changes=true" >> $GITHUB_OUTPUT
-            echo "Changes detected"
-
-            # save the list for the summary
-            echo "changed_files<<EOF" >> $GITHUB_OUTPUT
-            echo "$CHANGED_FILES" >> $GITHUB_OUTPUT
-            echo "EOF" >> $GITHUB_OUTPUT
-            echo "changed_count=$(echo "$CHANGED_FILES" | wc -l)" >> $GITHUB_OUTPUT
-          else
-            echo "changes=false" >> $GITHUB_OUTPUT
-            echo "No changes detected"
-          fi
-
-      # commit if there are changes
-      - name: Commit changes
-        if: steps.check_changes.outputs.changes == 'true'
-        run: |
-          git add -A
-          git commit -m "${{ env.COMMIT_MESSAGE }}"
-
-      - name: Push changes
-        if: steps.check_changes.outputs.changes == 'true'
-        run: git push origin ${{ github.ref_name }}
-
-      # pretty summary for humans
-      - name: Summary
-        run: |
-          if [[ "${{ steps.check_changes.outputs.changes }}" == "true" ]]; then
-            echo "### 📸 Visual Regression Screenshots Updated" >> $GITHUB_STEP_SUMMARY
-            echo "" >> $GITHUB_STEP_SUMMARY
-            echo "Successfully updated **${{ steps.check_changes.outputs.changed_count }}** screenshot(s) on \`${{ github.ref_name }}\`" >> $GITHUB_STEP_SUMMARY
-            echo "" >> $GITHUB_STEP_SUMMARY
-            echo "#### Changed Files:" >> $GITHUB_STEP_SUMMARY
-            echo "\`\`\`" >> $GITHUB_STEP_SUMMARY
-            echo "${{ steps.check_changes.outputs.changed_files }}" >> $GITHUB_STEP_SUMMARY
-            echo "\`\`\`" >> $GITHUB_STEP_SUMMARY
-            echo "" >> $GITHUB_STEP_SUMMARY
-            echo "✅ The updated screenshots have been committed and pushed. Your visual regression baseline is now up to date!" >> $GITHUB_STEP_SUMMARY
-          else
-            echo "### ℹ️ No Screenshot Updates Required" >> $GITHUB_STEP_SUMMARY
-            echo "" >> $GITHUB_STEP_SUMMARY
-            echo "The visual regression test command ran successfully but no screenshots needed updating." >> $GITHUB_STEP_SUMMARY
-            echo "" >> $GITHUB_STEP_SUMMARY
-            echo "All screenshots are already up to date! 🎉" >> $GITHUB_STEP_SUMMARY
-          fi
-```
-
-=== Azure App Testing
-
-你的测试依旧在本地运行，只是将浏览器托管到云端执行。
-这基于 Playwright 的远程浏览器功能，但所有云端基础设施均由 Microsoft 负责维护与管理。
-
-#### 测试组织建议
-
-为控制成本，应将视觉回归测试与其他测试分离管理，
-并确保只有那些实际需要截取页面截图的用例才会调用该服务。
-
-最为简洁高效的做法，是使用 [Test Projects](/guide/projects) 功能来隔离这些测试。
-
-<!-- eslint-disable style/quote-props -->
-```ts [vitest.config.ts]
-import { env } from 'node:process'
-import { defineConfig } from 'vitest/config'
-import { playwright } from '@vitest/browser-playwright'
-
-export default defineConfig({
-  // ...global Vite config
-  tests: {
-    // ...global Vitest config
-    projects: [
-      {
-        extends: true,
-        test: {
-          name: 'unit',
-          include: ['tests/**/*.test.ts'],
-          // regular config, can use local browsers
-        },
-      },
-      {
-        extends: true,
-        test: {
-          name: 'visual',
-          // or you could use a different suffix, e.g.,: `tests/**/*.visual.ts?(x)`
-          include: ['visual-regression-tests/**/*.test.ts?(x)'],
-          browser: {
-            enabled: true,
-            provider: playwright({
-              connectOptions: {
-                wsEndpoint: `${env.PLAYWRIGHT_SERVICE_URL}?${new URLSearchParams({
-                  'api-version': '2025-09-01',
-                  os: 'linux', // always use Linux for consistency
-                  // helps identifying runs in the service's dashboard
-                  runName: `Vitest ${env.CI ? 'CI' : 'local'} run @${new Date().toISOString()}`,
-                })}`,
-                exposeNetwork: '<loopback>',
-                headers: {
-                  Authorization: `Bearer ${env.PLAYWRIGHT_SERVICE_ACCESS_TOKEN}`,
-                },
-                timeout: 30_000,
-              }
-            }),
-            headless: true,
-            instances: [
-              {
-                browser: 'chromium',
-                viewport: { width: 2560, height: 1440 },
-              },
-            ],
-          },
-        },
-      },
-    ],
-  },
-})
-```
-
-该服务会提供两个关键环境变量：
-
-- `PLAYWRIGHT_SERVICE_URL`：指示 Playwright 连接的服务器地址
-- `PLAYWRIGHT_SERVICE_ACCESS_TOKEN`：你的身份验证令牌
-
-<!-- eslint-enable style/quote-props -->
-
-Follow the [official guide to create a Playwright Workspace](https://learn.microsoft.com/en-us/azure/app-testing/playwright-workspaces/quickstart-run-end-to-end-tests?tabs=playwrightcli&pivots=playwright-test-runner#create-a-workspace).
-
-Once your workspace is created, configure Vitest to use it:
-
-1. **Set the endpoint URL**: following the [official guide](https://learn.microsoft.com/en-us/azure/app-testing/playwright-workspaces/quickstart-run-end-to-end-tests?tabs=playwrightcli&pivots=playwright-test-runner#configure-the-browser-endpoint), retrieve the URL and set it as the `PLAYWRIGHT_SERVICE_URL` environment variable.
-2. **Enable token authentication**: [enable access tokens](https://learn.microsoft.com/en-us/azure/app-testing/playwright-workspaces/how-to-manage-authentication?pivots=playwright-test-runner#enable-authentication-using-access-tokens) for your workspace, then [generate a token](https://learn.microsoft.com/en-us/azure/app-testing/playwright-workspaces/how-to-manage-access-tokens#generate-a-workspace-access-token) and set it as the `PLAYWRIGHT_SERVICE_ACCESS_TOKEN` environment variable.
-
-::: danger 令牌务必保密！
-切勿将 `PLAYWRIGHT_SERVICE_ACCESS_TOKEN` 提交到代码仓库。
-任何获取到该令牌的人都可能在你的账户上产生高额费用。
-在本地开发时，应通过环境变量引用令牌；在 CI 中，应将其存放于安全的密钥管理中。
-:::
-
-然后，将 `test` 脚本按如下方式拆分运行：
-
-```json [package.json]
-{
-  "scripts": {
-    "test:visual": "vitest --project visual",
-    "test:unit": "vitest --project unit"
-  }
-}
-```
-
-#### 运行测试
-
-```bash
-# Local development
-npm run test:unit    # free, runs locally
-npm run test:visual  # uses cloud browsers
-
-# Update screenshots
-npm run test:visual -- --update
-```
-
-这种方式的最大优势在于“开箱即用”：
-
-- **截图结果一致**：所有人共享相同的云端浏览器环境，避免环境差异；
-- **支持本地执行**：开发者可在本地直接运行并更新视觉回归测试；
-- **按量计费**：仅有视觉测试会消耗服务分钟数，成本可控；
-- **零运维负担**：无需配置 Docker 或复杂的工作流，几乎不需额外维护。
-
-#### 持续集成（ CI ）环境配置
-
-在 CI 平台中，将所需的密钥添加到环境变量或机密配置中：
-
-```yaml
-env:
-  PLAYWRIGHT_SERVICE_URL: ${{ vars.PLAYWRIGHT_SERVICE_URL }}
-  PLAYWRIGHT_SERVICE_ACCESS_TOKEN: ${{ secrets.PLAYWRIGHT_SERVICE_ACCESS_TOKEN }}
-```
-
-接下来，你只需像往常一样运行测试，其余的由服务全权负责处理。
-
-::::
-
-### 该选哪一个？ {#so-which-one}
-
-两种方案都可行，关键在于团队最在意的痛点是什么。
-
-如果你的团队已经深度依赖 GitHub 生态，那么 **GitHub Actions** 几乎是无可替代的选择——对开源项目免费、
-支持任意浏览器服务商、并且可完全掌控执行流程。
-
-缺点在于：当有人在本地生成的截图与 CI 环境的基准不一致时，就会出现那句熟悉的“在我机器上没问题”。
-
-如果团队需要在本地执行视觉回归测试，那么云服务或许更适合。
-这种方式特别适合有设计师参与审核，或开发者希望在推送代码前发现并修复问题的团队，
-能够跳过“推送—等待—检查—修改—再推送”的繁琐循环。
-
-如果依然犹豫，不妨先从 GitHub Actions 开始；等到本地测试成为痛点时，再引入云服务也不迟。

From 8be2149e55e23659536be472d382a4ad2f2f89a3 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 1 Dec 2025 02:57:14 +0800
Subject: [PATCH 48/50] fix: dead link

---
 api/vi.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/api/vi.md b/api/vi.md
index fd28be9c..221a80fe 100644
--- a/api/vi.md
+++ b/api/vi.md
@@ -150,7 +150,7 @@ axios.get(`/apples/${increment(1)}`)
 请注意，如果不调用 `vi.mock` ，模块**不会**被自动模拟。要复制 Jest 的自动锁定行为，可以在 [`setupFiles`](/config/#setupfiles) 中为每个所需的模块调用 `vi.mock` 。
 :::
 
-如果没有提供 `__mocks__` 文件夹或工厂，Vitest 将导入原始模块并自动模拟其所有输出。有关应用的规则，请参阅 [模块](/mocking.html#automocking-algorithm)。
+如果没有提供 `__mocks__` 文件夹或工厂，Vitest 将导入原始模块并自动模拟其所有输出。有关应用的规则，请参阅 [模块](/guide/mocking#automocking-algorithm)。
 
 ### vi.doMock
 
@@ -258,7 +258,7 @@ vi.mock('./example.js', async () => {
 
 - **类型**: `<T>(path: string) => Promise<MaybeMockedDeep<T>>`
 
-导入模块并模拟其所有属性（包括嵌套属性）。遵循与 [`vi.mock`](#vi-mock) 相同的规则。有关应用的规则，请参阅 [模块](/mocking.html#automocking-algorithm)。
+导入模块并模拟其所有属性（包括嵌套属性）。遵循与 [`vi.mock`](#vi-mock) 相同的规则。有关应用的规则，请参阅 [模块](/guide/mocking#automocking-algorithm)。
 
 ### vi.unmock
 
@@ -393,7 +393,7 @@ expect(getApples).toHaveNthReturnedWith(2, 5)
 
 - **Type:** `<T>(value: T) => MaybeMockedDeep<T>`
 
-它与 `vi.mock()` 模拟模块相同，深层模拟给定对象的属性和方法。详见 [自动模拟](/guide/mocking.html#automocking-algorithm)。
+它与 `vi.mock()` 模拟模块相同，深层模拟给定对象的属性和方法。详见 [自动模拟](/guide/mocking#automocking-algorithm)。
 
 ```ts
 const original = {
@@ -632,7 +632,7 @@ IntersectionObserver === undefined
 
 ## Fake Timers
 
-本节介绍如何使用 [模拟计时器](/guide/mocking.html#timers)。
+本节介绍如何使用 [模拟计时器](/guide/mocking#timers)。
 
 ### vi.advanceTimersByTime
 

From d12062aa1114951a15b1f9f2e8862fe2f5934b15 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 1 Dec 2025 03:02:44 +0800
Subject: [PATCH 49/50] fix: dead link

---
 config/index.md | 12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/config/index.md b/config/index.md
index 9d37cbc3..f512be33 100644
--- a/config/index.md
+++ b/config/index.md
@@ -2530,20 +2530,10 @@ Expand all common lines.
 - **命令行终端:** `--workspace=./file.js`
 - **默认值:** `vitest.{workspace,projects}.{js,ts,json}` close to the config file or root
 
-相对于[root](#root) 的 [workspace](/guide/workspace) 配置文件的路径。
+相对于[root](#root) 的 [workspace](/guide/projects) 配置文件的路径。
 
 自 Vitest 3 起，您也可以在根配置中直接定义 `workspace` 数组。若手动在配置中声明了 workspace 参数，Vitest 将忽略项目根目录下的 `vitest.workspace` 文件。
 
-### workspace<NonProjectOption />
-
-::: danger 弃用
-此选项已弃用，将在下一个主要版本中移除。请改用 [`projects`](#projects)。
-:::
-
-- **类型:** `string | TestProjectConfiguration`
-- **命令行终端:** `--workspace=./file.js`
-- **默认值:** 配置文件或根目录附近的 `vitest.{workspace,projects}.{js,ts,json}` 文件
-
 相对于 [root](#root) 的 [workspace](/guide/projects) 配置文件路径。
 
 从 Vitest 3 起，您也可以在根配置中定义 workspace 数组。如果手动在配置中定义了 `workspace`，Vitest 将忽略根目录下的 `vitest.workspace` 文件。

From 47b871ef6b38f1713a2a58f2168ccf7610c952d5 Mon Sep 17 00:00:00 2001
From: noise <noisefan@163.com>
Date: Mon, 1 Dec 2025 03:08:22 +0800
Subject: [PATCH 50/50] fix: /config/ workspace options

---
 config/index.md | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/config/index.md b/config/index.md
index f512be33..11e1e275 100644
--- a/config/index.md
+++ b/config/index.md
@@ -2528,16 +2528,12 @@ Expand all common lines.
 
 - **类型:** `string | TestProjectConfiguration`
 - **命令行终端:** `--workspace=./file.js`
-- **默认值:** `vitest.{workspace,projects}.{js,ts,json}` close to the config file or root
+- **默认值:** 配置文件或根目录附近的 `vitest.{workspace,projects}.{js,ts,json}`
 
 相对于[root](#root) 的 [workspace](/guide/projects) 配置文件的路径。
 
 自 Vitest 3 起，您也可以在根配置中直接定义 `workspace` 数组。若手动在配置中声明了 workspace 参数，Vitest 将忽略项目根目录下的 `vitest.workspace` 文件。
 
-相对于 [root](#root) 的 [workspace](/guide/projects) 配置文件路径。
-
-从 Vitest 3 起，您也可以在根配置中定义 workspace 数组。如果手动在配置中定义了 `workspace`，Vitest 将忽略根目录下的 `vitest.workspace` 文件。
-
 ### projects<NonProjectOption />
 
 - **类型:** `TestProjectConfiguration[]`