diff --git a/.vitepress/config.ts b/.vitepress/config.ts
index db94f657..0255089e 100644
--- a/.vitepress/config.ts
+++ b/.vitepress/config.ts
@@ -723,53 +723,53 @@ export default ({ mode }: { mode: string }) => {
             ],
           },
           {
-            text: 'Learn',
+            text: '学习',
             collapsed: false,
             items: [
               {
-                text: 'Writing Tests',
+                text: '编写测试用例',
                 link: '/guide/learn/writing-tests',
-                docFooterText: 'Writing Tests | Learn',
+                docFooterText: '编写测试用例 | 学习',
               },
               {
-                text: 'Using Matchers',
+                text: '使用匹配器',
                 link: '/guide/learn/matchers',
-                docFooterText: 'Using Matchers | Learn',
+                docFooterText: '使用匹配器 | 学习',
               },
               {
-                text: 'Testing Async Code',
+                text: '测试异步代码',
                 link: '/guide/learn/async',
-                docFooterText: 'Testing Async Code | Learn',
+                docFooterText: '测试异步代码 | 学习',
               },
               {
-                text: 'Setup and Teardown',
+                text: '初始化与清理',
                 link: '/guide/learn/setup-teardown',
-                docFooterText: 'Setup and Teardown | Learn',
+                docFooterText: 'Setup and Teardown | 学习',
               },
               {
-                text: 'Mock Functions',
+                text: '模拟函数',
                 link: '/guide/learn/mock-functions',
-                docFooterText: 'Mock Functions | Learn',
+                docFooterText: '模拟函数 | 学习',
               },
               {
-                text: 'Snapshot Testing',
+                text: '快照测试',
                 link: '/guide/learn/snapshots',
-                docFooterText: 'Snapshot Testing | Learn',
+                docFooterText: '快照测试 | 学习',
               },
               {
-                text: 'Testing in Practice',
+                text: '测试实践',
                 link: '/guide/learn/testing-in-practice',
-                docFooterText: 'Testing in Practice | Learn',
+                docFooterText: '测试实践 | 学习',
               },
               {
-                text: 'Debugging Tests',
+                text: '调试测试',
                 link: '/guide/learn/debugging-tests',
-                docFooterText: 'Debugging Tests | Learn',
+                docFooterText: '调试测试 | 学习',
               },
               {
-                text: 'Writing Tests with AI',
+                text: '使用 AI 编写测试',
                 link: '/guide/learn/writing-tests-with-ai',
-                docFooterText: 'Writing Tests with AI | Learn',
+                docFooterText: '使用 AI 编写测试 | 学习',
               },
             ],
           },
diff --git a/guide/learn/async.md b/guide/learn/async.md
index 4997ff87..18b14db7 100644
--- a/guide/learn/async.md
+++ b/guide/learn/async.md
@@ -1,20 +1,20 @@
 ---
-title: Testing Asynchronous Code | Guide
+title: 测试异步代码 | 指南
 prev:
-  text: Using Matchers
+  text: 使用匹配器
   link: /guide/learn/matchers
 next:
-  text: Setup and Teardown
+  text: 初始化与清理
   link: /guide/learn/setup-teardown
 ---
 
-# Testing Asynchronous Code
+# 测试异步代码 {#testing-asynchronous-code}
 
-JavaScript code frequently runs asynchronously. Whether you're fetching data, reading files, or waiting on timers, Vitest needs to know when the code it is testing has completed before moving on to the next test. Here are the patterns you'll use most often.
+JavaScript 代码经常以异步方式运行。无论是获取数据、读取文件还是等待定时器，Vitest 都需要知道它正在测试的代码何时完成，然后才能继续执行下一个测试。下面是最常见的几种写法。
 
 ## Async/Await
 
-The most straightforward approach is to make your test function `async`. Vitest will automatically wait for the returned promise to resolve before considering the test complete. If the promise rejects, the test fails with the rejection reason.
+最直接的方法是让你的测试函数变为 `async`。Vitest 会自动等待返回的 Promise resolve，然后才认为测试完成。如果 Promise 被 reject，测试将失败，并显示拒绝原因。
 
 ```js
 import { expect, test } from 'vitest'
@@ -29,11 +29,11 @@ test('fetches user by id', async () => {
 })
 ```
 
-This is the pattern you'll use the vast majority of the time. It reads just like synchronous code, and errors propagate naturally through `await`.
+这是你绝大多数时候会使用的形式。它读起来就像同步代码一样，错误也会通过 `await` 自然地传播。
 
-## Resolves and Rejects
+## Resolves 与 Rejects {#resolves-and-rejects}
 
-Sometimes you'd rather assert on a promise directly instead of `await`-ing it into a variable first. The [`.resolves`](/api/expect#resolves) and [`.rejects`](/api/expect#rejects) helpers let you do this. They unwrap the promise and then apply the matcher to the resolved or rejected value:
+有时你可能更愿意直接对 Promise 进行断言，而不是先将其通过 `await` 赋值给变量。[`.resolves`](/api/expect#resolves) 和 [`.rejects`](/api/expect#rejects) 工具函数让你能够做到这一点。它们会解开 Promise，然后将匹配器应用到 resolved 或 rejected 值上：
 
 ```js
 test('resolves to Alice', async () => {
@@ -46,12 +46,12 @@ test('rejects with an error', async () => {
 ```
 
 ::: warning
-Don't forget the `await` before `expect`. Vitest will detect unawaited assertions and print a warning at the end of the test, but it's best to always include `await` explicitly. Vitest will also wait for all pending promises in `Promise.all` before starting the next test, but relying on this behavior makes tests harder to understand.
+不要忘记在 `expect` 前面加上 `await`。Vitest 会检测未等待的断言，并在测试结束时打印警告，但最好始终显式地添加 `await`。Vitest 还会在启动下一个测试之前，等待 `Promise.all` 中所有仍在进行的 Promise 完成，不过依赖这种行为会让测试更难理解。
 :::
 
-## Assertion Counting
+## 断言计数 {#assertion-counting}
 
-With async code, there's a subtle risk: an assertion inside a callback or `.then()` chain might never execute, and the test would still pass because no assertion failed. [`expect.hasAssertions()`](/api/expect#hasassertions) guards against this by verifying that at least one assertion ran during the test:
+对于异步代码，存在一个不易察觉的风险：回调函数或 `.then()` 链中的断言可能根本没有执行，而测试仍然会通过，因为没有断言失败。[`expect.hasAssertions()`](/api/expect#hasassertions) 正是用来防范这种情况的，它会检查该测试在执行期间是否至少运行过一条断言：
 
 ```js
 test('callback is invoked', async () => {
@@ -61,11 +61,11 @@ test('callback is invoked', async () => {
   data.items.forEach((item) => {
     expect(item.id).toBeDefined()
   })
-  // if data.items is empty, the test fails instead of silently passing
+  // 如果 data.items 为空，测试会失败而不是静默通过
 })
 ```
 
-When you know exactly how many assertions should run, [`expect.assertions(n)`](/api/expect#assertions) is more precise:
+当你知道应该运行的确切断言数量时，[`expect.assertions(n)`](/api/expect#assertions) 会更加精确：
 
 ```js
 test('both callbacks are called', async () => {
@@ -78,15 +78,15 @@ test('both callbacks are called', async () => {
 })
 ```
 
-In most cases, `async`/`await` with direct assertions is clear enough and you don't need assertion counting. It's most useful when assertions are inside callbacks, loops, or conditional branches where you want to guarantee they actually executed.
+在大多数情况下，使用直接断言的 `async`/`await` 已经足够清晰，无需额外进行断言计数。断言计数最适用于当断言位于回调函数、循环或条件分支中，而你希望确保它们确实已经执行。
 
 ::: tip
-If you want every test in your project to require at least one assertion, enable [`expect.requireAssertions`](/config/expect#expect-requireassertions) in your config instead of adding `expect.hasAssertions()` to each test manually.
+如果你希望项目中的每个测试都至少需要一个断言，可以在配置中启用 [`expect.requireAssertions`](/config/expect#expect-requireassertions)，而不是手动为每个测试添加 `expect.hasAssertions()`。
 :::
 
-## Callbacks
+## 回调函数 {#callbacks}
 
-Some older APIs use callbacks instead of promises. Since Vitest works with promises, the simplest approach is to wrap the callback in a `Promise`:
+一些较旧的 API 使用回调函数而非 Promise。由于 Vitest 与 Promise 协同工作，最简单的方法是将回调函数包装在 `Promise` 中：
 
 ```js
 function fetchData(callback) {
@@ -101,25 +101,25 @@ test('the data is peanut butter', async () => {
 })
 ```
 
-This pattern works for any callback-based API. Pass `resolve` as the success callback, and the test will wait until the callback is invoked.
+这种形式适用于任何基于回调的 API。将 `resolve` 作为成功回调传递进去，测试就会一直等待，直到该回调被调用。
 
 ::: tip
-Most modern Node.js APIs (such as `fs/promises` and `fetch`) support promises natively, so you can use `async`/`await` directly. The callback wrapping pattern above is mainly useful for older libraries that haven't adopted promises yet.
+大多数现代 Node.js API（例如 `fs/promises` 和 `fetch`）原生支持 Promise，因此你可以直接使用 `async`/`await`。上述的回调包装形式主要适用于尚未采用 Promise 的旧版库。
 :::
 
-## Timeouts
+## 超时 {#timeouts}
 
-By default, each test has a 5-second timeout. If a test takes longer than that (perhaps because a promise never resolves, or a network request hangs), it will fail with a timeout error. This prevents your test suite from getting stuck indefinitely.
+默认情况下，每个测试有 5 秒的超时时间。如果某个测试耗时超过此限制（可能是因为 Promise 从未 resolve，或网络请求挂起），它将因超时错误而失败。这可以防止你的测试套件无限期地卡住。
 
-You can set a [custom timeout](/api/test#timeout) as the third argument to `test`, which is useful for tests that legitimately need more time:
+你可以将 [自定义超时时间](/api/test#timeout) 作为 `test` 的第三个参数进行设置，这适用于确实需要更多时间的测试：
 
 ```js
 test('long-running operation', async () => {
   await someSlowOperation()
-}, 10_000) // 10 seconds
+}, 10_000) // 10 秒
 ```
 
-If you find yourself needing longer timeouts across many tests, you can change the default for all tests with the [`testTimeout`](/config/testtimeout) config option:
+如果你发现自己需要在许多测试中使用更长的超时时间，可以通过 [`testTimeout`](/config/testtimeout) 配置选项更改所有测试的默认值：
 
 ```js [vitest.config.js]
 import { defineConfig } from 'vitest/config'
@@ -131,27 +131,27 @@ export default defineConfig({
 })
 ```
 
-## Unhandled Rejections
+## 未处理的 Rejection {#unhandled-rejections}
 
-By default, Vitest reports unhandled promise rejections as errors in the test run. If a promise rejects somewhere in your code and nothing catches it, the test run will fail, even if all your assertions passed. This is intentional: unhandled rejections usually indicate real bugs, like a forgotten `await` or a fire-and-forget promise that silently fails.
+默认情况下，Vitest 会将未处理的 Promise reject 报告为测试运行中的错误。如果你的代码中某个 Promise 被 reject 且未被捕获，即使所有断言都通过，测试运行也会失败。这是有意为之的：未处理的 reject 通常表示存在真正的 bug，例如忘记的 `await` 或者一个 “发出后不再等待” 的 Promise 在静默中失败了。
 
 ```js
 test('this causes an unhandled rejection error', () => {
-  // This promise rejects but is never awaited or caught
+  // 这个 Promise 会 reject 但从未被 await 或 catch
   Promise.reject(new Error('oops'))
 })
 ```
 
-To fix this, make sure you `await` all promises or catch expected rejections:
+要修复此问题，请确保对所有 Promise 使用 `await`，或捕获那些预期会发生的 reject：
 
 ```js
 test('handle the rejection', async () => {
-  // Either await the promise
+  // 要么等待 Promise
   await expect(Promise.reject(new Error('oops'))).rejects.toThrow('oops')
 
-  // Or catch it explicitly if you don't need to assert on it
+  // 如果不需要对其断言，可以显式 catch 它
   Promise.reject(new Error('expected')).catch(() => {})
 })
 ```
 
-If your code intentionally produces unhandled rejections, you can filter specific errors with [`onUnhandledError`](/config/onunhandlederror) or disable the check entirely with [`dangerouslyIgnoreUnhandledErrors`](/config/dangerouslyignoreunhandlederrors).
+如果你的代码有意产生未处理的 reject，可以使用 [`onUnhandledError`](/config/onunhandlederror) 过滤特定的错误，或者通过 [`dangerouslyIgnoreUnhandledErrors`](/config/dangerouslyignoreunhandlederrors) 完全禁用此检查。
diff --git a/guide/learn/debugging-tests.md b/guide/learn/debugging-tests.md
index c3d461e7..0480622b 100644
--- a/guide/learn/debugging-tests.md
+++ b/guide/learn/debugging-tests.md
@@ -1,74 +1,74 @@
 ---
-title: Debugging Failing Tests | Guide
+title: 调试失败的测试 | Guide
 prev:
-  text: Testing in Practice
+  text: 测试实践
   link: /guide/learn/testing-in-practice
 next:
-  text: Writing Tests with AI
+  text: 使用 AI 编写测试
   link: /guide/learn/writing-tests-with-ai
 ---
 
-# Debugging Failing Tests
+# 调试失败的测试 {#debugging-failing-tests}
 
-This page covers how to investigate test failures in Vitest: reading error output, isolating problems, identifying common causes, and using the available debugging tools.
+本章介绍如何在 Vitest 中调查测试失败问题：阅读错误输出、隔离问题、识别常见原因以及使用相关调试工具。
 
-## Reading the Error
+## 阅读错误输出 {#reading-the-error}
 
-When a test fails, Vitest gives you several pieces of information. Let's look at a real failure and break it down:
+当测试失败时，Vitest 会提供多个信息片段。让我们来看一个真实的失败案例并进行分析：
 
 <<< ./snippets/debug-output-fail.ansi
 
-There's a lot here, but each part tells you something:
+这里信息很多，但每一部分都在传达有用的信息：
 
-**The header** (`FAIL src/user.test.js > createUser > sets the default role`) tells you which file, describe block, and test failed. This is the full path in the test tree.
+**标题** (`FAIL src/user.test.js > createUser > sets the default role`) 告诉你哪个文件、哪个 describe 块以及哪个测试失败了。这就是它在测试树中的完整路径。
 
-**The assertion message** (`expected { ... } to deeply equal { ... }`) tells you what kind of check failed and shows the two values being compared.
+**断言信息** (`expected { ... } to deeply equal { ... }`) 告诉你哪种检查失败了，并展示参与比较的两个值。
 
-**The diff** shows exactly what's different. Lines starting with <code class="diff-add">+</code> are what you actually got, and lines starting with <code class="diff-remove">-</code> are what you expected. In this case, the role was <code class="diff-add">"viewer"</code> but the test expected <code class="diff-remove">"member"</code>.
+**差异对比** 会准确展示差异所在。以 <code class="diff-add">+</code> 开头的行是你实际得到的结果，以 <code class="diff-remove">-</code> 开头的行是你期望的结果。在这个例子中，role 是 <code class="diff-add">"viewer"</code>，但测试期望的是 <code class="diff-remove">"member"</code>。
 
-**The code snippet** shows the exact line and a few surrounding lines, with a caret (`^`) pointing to the failing assertion. You can click the file path in most terminals and IDEs to jump directly there.
+**代码片段** 会显示出错的确切代码行以及附近几行内容，并用使用脱字符 (`^`) 指向失败的断言。在大多数终端和 IDE 中，你可以点击文件路径直接跳转到对应位置。
 
-At this point, the question is: did the code change (maybe the default role was intentionally updated to `"viewer"`), or is the test wrong? Check the source code for `createUser` to find out. If the default was intentionally changed, update the test. If not, you've found a bug.
+此时，问题是：是代码发生了变化（也许默认 role 被有意更新为 `"viewer"`），还是测试本身有误？检查 `createUser` 的源代码以找出答案。如果默认值是有意更改的，就更新测试。如果不是，那么你就发现了一个 bug。
 
-## Isolating the Problem
+## 隔离问题 {#isolating-the-problem}
 
-When a test fails and the cause isn't immediately clear, the first step is to isolate it. Run just that one test, without the rest of your suite:
+当测试失败且原因不明显时，第一步是将其隔离。只运行那个特定的测试，而不运行测试套件的其他部分：
 
 ```bash
-# Run only the failing test file
+# 仅运行失败的测试文件
 vitest src/user.test.js
 
-# Run only tests matching a name pattern
+# 仅运行匹配名称规则的测试
 vitest -t "sets the default role"
 
-# Combine both for maximum precision
+# 结合两者以获得最大精度
 vitest src/user.test.js -t "sets the default role"
 ```
 
-You can also add [`.only`](/api/test#only) to the test itself:
+你也可以给测试本身添加 [`.only`](/api/test#only)：
 
 ```js
 test.only('sets the default role', () => {
-  // only this test runs in the file
+  // 文件中只有这个测试会运行
 })
 ```
 
-If you have many failures and want to focus on the first one, use [`--bail`](/config/bail) to stop after a set number of failures:
+如果你有很多失败的测试，先聚焦第一个失败测试，可以使用 [`--bail`](/config/bail) 在失败次数达到设定值后停止执行：
 
 ```bash
 vitest --bail 1
 ```
 
-If the test passes when run alone but fails when run with others, you have a test isolation problem (more on that below). If it fails even when run alone, the issue is in the test itself or the code it's testing.
+如果测试单独运行时通过，但与其他测试一起运行时失败，那么你就遇到了测试隔离问题（下文会详细说明）。如果即使单独运行也失败，那么问题就出在测试本身或其测试的代码中。
 
-## Common Causes of Failures
+## 测试失败的常见原因 {#common-causes-of-failures}
 
-### Shared State Between Tests
+### 测试间的共享状态 {#shared-state-between-tests}
 
-This is one of the most common and frustrating issues. A test passes when you run it alone, but fails when the full suite runs. The usual cause is that some other test modifies shared state (a global variable, a module-level cache, a database) and doesn't clean up after itself.
+这是最常见也最令人头疼的问题之一。测试单独运行时通过，但整个测试套件运行时却失败。通常原因是其他测试修改了共享状态（全局变量、模块级缓存、数据库）且没有自行清理。
 
 ```js
-// This is a problem: `users` is shared between tests
+// 这是个问题：`users` 在测试间共享
 const users = []
 
 test('adds a user', () => {
@@ -77,12 +77,12 @@ test('adds a user', () => {
 })
 
 test('starts empty', () => {
-  // This fails because 'Alice' is still in the array!
+  // 这个会失败，因为 'Alice' 还在数组中！
   expect(users).toEqual([])
 })
 ```
 
-The fix is to reset the state before each test with [`beforeEach`](/api/hooks#beforeeach), or better yet, use [`test.extend`](/guide/test-context#extend-test-context) to create fresh state for each test automatically:
+解决方法是在每个测试前使用 [`beforeEach`](/api/hooks#beforeeach) 重置状态，或者更好的是使用 [`test.extend`](/guide/test-context#extend-test-context) 自动为每个测试创建新的状态：
 
 ```js
 const test = baseTest.extend('users', () => [])
@@ -93,24 +93,24 @@ test('adds a user', ({ users }) => {
 })
 
 test('starts empty', ({ users }) => {
-  // Passes: each test gets its own array
+  // 通过：每个测试都有自己的数组
   expect(users).toEqual([])
 })
 ```
 
-### Async Issues
+### 异步问题 {#async-issues}
 
-Tests that involve promises can fail intermittently or in confusing ways if the async flow isn't handled correctly. The most common mistake is forgetting an `await`:
+如果异步流程处理不当，涉及 Promise 的测试可能会间歇性失败，或以令人困惑的方式报错。最常见的错误是忘记 `await`：
 
 ```js
-// This test always passes, even if fetchUser rejects!
+// 即使 fetchUser 被 reject，这个测试总是通过！
 test('fetches user', () => {
-  // Missing await: the test finishes before the promise settles
+  // 缺少 await：测试在 Promise 完成前就结束了
   expect(fetchUser(1)).resolves.toMatchObject({ name: 'Alice' })
 })
 ```
 
-Vitest will usually warn you about unawaited assertions at the end of the test. If you see that warning, add the missing `await`:
+Vitest 通常会在测试结束时警告你有未等待的断言。如果你看到这个警告，就加上缺失的 `await`：
 
 ```js
 test('fetches user', async () => {
@@ -118,23 +118,23 @@ test('fetches user', async () => {
 })
 ```
 
-If a test hangs and eventually times out, it usually means a promise never resolves. Check for missing callbacks, unresolved conditions, or deadlocks in the code you're testing.
+如果测试卡住并最终超时，通常意味着 Promise 永远不会 resolve。检查你测试的代码中是否有缺少的回调、未解决的条件或死锁。
 
-### Stale Snapshots
+### 过时的快照 {#stale-snapshots}
 
-If you're using [snapshot tests](/guide/learn/snapshots) and you intentionally changed the output of your code, the existing snapshots will be outdated. The test fails and shows a diff between the old snapshot and the new output.
+如果你在使用 [快照测试](/guide/learn/snapshots) 并且有意更改了代码的输出，现有的快照就会过时。测试会失败，并显示旧快照与新输出之间的差异。
 
-This is expected. Review the diff to confirm the changes are correct, then update the snapshots by pressing `u` in watch mode or running `vitest -u`.
+这是预期中的结果。检查差异以确认更改是正确的，然后通过监视模式下按 `u` 键或运行 `vitest -u` 来更新快照。
 
-### Wrong Test Environment
+### 错误的测试环境 {#wrong-test-environment}
 
-If your code accesses browser APIs like `document` or `window` and you see errors like "document is not defined", your test is running in the Node environment (the default). You can switch to a browser-like environment with the [`environment`](/config/environment) config option, or better yet, use [Browser Mode](/guide/browser/) which runs tests in a real browser.
+如果你的代码访问了浏览器 API，如 `document` 或 `window`，并且看到类似 "document is not defined" 的错误，说明你的测试正在 Node.js 环境（默认环境）中运行。你可以通过 [`environment`](/config/environment) 配置选项切换到类浏览器环境，或者最好是使用 [浏览器模式](/guide/browser/) 在真实浏览器中运行测试。
 
-### Mocks Not Cleaned Up
+### 未清理模拟 {#mocks-not-cleaned-up}
 
-If a mock from one test leaks into another, you'll get unexpected behavior. For example, a `vi.spyOn` that overrides a method's return value will persist into the next test unless it's restored.
+如果一个测试中的 mock 泄露到另一个测试中，你会得到意外的行为。例如，使用 vi.spyOn 覆盖了某个方法的返回值后，如果没有恢复，它就会持续影响下一个测试。
 
-The easiest fix is to enable automatic mock restoration in your config:
+最简单的解决方法是在配置中启用自动模拟恢复：
 
 ```js [vitest.config.js]
 import { defineConfig } from 'vitest/config'
@@ -146,13 +146,13 @@ export default defineConfig({
 })
 ```
 
-This calls [`mockRestore()`](/api/mock#mockrestore) on every mock after each test. See the [Mock Functions](/guide/learn/mock-functions#resetting-mocks) tutorial for more details.
+这会在每个测试后对每个模拟调用 [`mockRestore()`](/api/mock#mockrestore)。更多详情请参阅 [模拟函数](/guide/learn/mock-functions#resetting-mocks)。
 
-## Debugging Tools
+## 调试工具 {#debugging-tools}
 
-### Console Logging
+### 控制台日志 {#console-logging}
 
-There's nothing wrong with adding `console.log` to your tests. It's the fastest way to inspect values and understand what's happening:
+在测试中添加 `console.log`，检查到完全没问题。这是查看数据、快速搞清楚发生了什么的最快办法：
 
 ```js
 test('transforms data correctly', () => {
@@ -166,49 +166,49 @@ test('transforms data correctly', () => {
 })
 ```
 
-Vitest displays console output inline with the test results, so you can see which test produced which log.
+Vitest 会在测试结果中内联显示控制台输出，因此你可以看到具体哪个测试产生了哪个日志。
 
-### Vitest UI
+### UI 模式 {#vitest-ui}
 
-For a visual overview of your test suite, run Vitest with the `--ui` flag:
+如果想以可视化方式总览整个测试套件，请使用 `--ui` 参数运行 Vitest：
 
 ```bash
 vitest --ui
 ```
 
-This opens a browser-based dashboard where you can see all your tests, their status, and their output. It also includes a module graph that shows how your files are connected, which can help you understand why a change in one file causes failures in another. See the [Vitest UI](/guide/ui) guide for more details.
+这会打开一个基于浏览器的仪表板，你可以在其中看到所有测试、它们的状态和输出。它还包括一个模块图，显示你的文件是如何连接的，这可以帮助你理解为什么一个文件的更改会导致另一个文件中的测试失败。更多详情请参阅 [UI 模式](/guide/ui)。
 
-### VS Code Extension
+### VS Code 扩展 {#vs-code-extension}
 
-The [Vitest VS Code extension](https://vitest.dev/vscode) lets you run and debug individual tests directly from your editor. You can click a "play" button next to any test, set breakpoints, and step through code in the VS Code debugger. This is often faster than switching between the terminal and your editor.
+[Vitest VS Code 扩展](https://cn.vitest.dev/vscode) 允许你直接从编辑器中运行和调试单个测试。你可以点击任何测试旁边的 “播放” 按钮，设置断点，并在 VS Code 调试器逐步跟踪代码执行过程。相比在终端和编辑器之间频繁切换，这种方式通常更高效。
 
-### Verbose Output
+### 详细输出 {#verbose-output}
 
-If the default output isn't showing enough detail, use the verbose reporter:
+如果默认输出显示的信息不够详细，请使用详细报告器：
 
 ```bash
 vitest --reporter=verbose
 ```
 
-This shows every test individually (not just the files), which can help spot patterns in which tests pass and which fail.
+这会单独显示每个测试（不仅仅是文件），这有助于发现哪些测试通过、哪些失败的规律。
 
-### Attaching a Debugger
+### 附加调试器 {#attaching-a-debugger}
 
-For more complex issues where you need to step through code line by line, you can run Vitest with the `--inspect-brk` flag and attach a debugger. The `--no-file-parallelism` flag ensures tests run in the main thread so breakpoints work reliably:
+对于需要逐行执行代码的更复杂问题，你可以使用 `--inspect-brk` 参数运行 Vitest 并附加调试器。`--no-file-parallelism` 参数确保测试在主线程中运行，以便断点可靠工作：
 
 ```bash
 vitest --inspect-brk --no-file-parallelism
 ```
 
-Then attach from VS Code, IntelliJ, or Chrome DevTools (`chrome://inspect`). See the [Debugging](/guide/debugging) guide for detailed setup instructions for each editor.
+然后从 VS Code、IntelliJ 或 Chrome DevTools (`chrome://inspect`) 附加调试器。每种编辑器的详细配置方式，请参阅 [调试](/guide/debugging)。
 
-## Getting Help
+## 获取帮助 {#getting-help}
 
-If you're stuck, these resources can help:
+如果你遇到困难，以下资源可以提供帮助：
 
-- The [Common Errors](/guide/common-errors) page covers specific error messages and their solutions
-- [GitHub Issues](https://github.com/vitest-dev/vitest/issues) for searching known bugs and workarounds
-- The [Discord community](https://chat.vitest.dev) for real-time help from other Vitest users and maintainers
+- [常见错误](/guide/common-errors) 页面涵盖了特定错误信息及其解决方案
+- [GitHub Issues](https://github.com/vitest-dev/vitest/issues) 用于搜索已知 bug 和变通方案
+- [Discord 社区](https://chat.vitest.dev) 可以获取其他 Vitest 用户和维护者的实时帮助
 
 <style>
 .vp-doc code.diff-add {
diff --git a/guide/learn/matchers.md b/guide/learn/matchers.md
index bb7ab79d..de561fe1 100644
--- a/guide/learn/matchers.md
+++ b/guide/learn/matchers.md
@@ -1,20 +1,20 @@
 ---
-title: Using Matchers | Guide
+title: 使用匹配器 | 指南
 prev:
-  text: Writing Tests
+  text: 编写测试
   link: /guide/learn/writing-tests
 next:
-  text: Testing Asynchronous Code
+  text: 测试异步代码
   link: /guide/learn/async
 ---
 
-# Using Matchers
+# 使用匹配器 {#using-matchers}
 
-Vitest uses `expect` with "matchers" to assert that values meet certain conditions. This page covers the matchers you'll use most often. For the complete list, see the [Expect API Reference](/api/expect).
+Vitest 使用 `expect` 配合 “匹配器” 来断言值是否满足特定条件。本章介绍最常用的匹配器。完整列表请参阅 [Expect API](/api/expect)。
 
-## Common Matchers
+## 常见匹配器 {#common-matchers}
 
-The simplest way to test a value is with exact equality. When you write `expect(2 + 2).toBe(4)`, the [`toBe`](/api/expect#tobe) matcher checks that the value is exactly `4` using [`Object.is`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is).
+测试一个值时，最简单的方法是检查它是否精确相等。当你编写 `expect(2 + 2).toBe(4)` 时，[`toBe`](/api/expect#tobe) 匹配器使用 [`Object.is`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is) 检查值是否完全等于 `4`。
 
 ```js
 import { expect, test } from 'vitest'
@@ -24,7 +24,7 @@ test('two plus two is four', () => {
 })
 ```
 
-This works great for primitive values like numbers, strings, and booleans. But when you're comparing objects, `toBe` checks *identity* (whether they're the exact same object in memory), not whether they have the same shape. That's where [`toEqual`](/api/expect#toequal) comes in. It recursively compares every field of an object or element of an array, ignoring object identity:
+这种方式适用于检查数字、字符串和布尔值等原始值。但在比较对象时，`toBe` 检查的是 **恒等性**（它们是否是内存中的同一个对象），而不是它们是否具有相同的结构。这时就需要用到 [`toEqual`](/api/expect#toequal)。它会递归地比较对象或数组的每个字段或元素，忽略对象恒等性：
 
 ```js
 test('object assignment', () => {
@@ -35,32 +35,32 @@ test('object assignment', () => {
 })
 ```
 
-Here's an example that shows the difference more clearly. Two objects with the same content are `toEqual` but not `toBe`:
+下面这个例子更清楚地展示了两者之间的差异。两个内容相同的对象 `toEqual` 会通过，但 `toBe` 会失败：
 
 ```js
 test('toBe vs toEqual', () => {
   const a = { name: 'Alice' }
   const b = { name: 'Alice' }
 
-  // These are different objects in memory
+  // 它们在内存中是不同的对象
   expect(a).not.toBe(b)
 
-  // But they have the same structure
+  // 但结构相同
   expect(a).toEqual(b)
 })
 ```
 
-There's also [`toStrictEqual`](/api/expect#tostrictequal), which is stricter than `toEqual` in three ways: it checks `undefined` properties, distinguishes sparse arrays from `undefined` values, and verifies that objects have the same type (not just the same shape):
+还有 [`toStrictEqual`](/api/expect#tostrictequal)，它在三个方面比 `toEqual` 更严格：检查 `undefined` 属性、区分稀疏数组和 `undefined` 值，以及验证对象是否具有相同的类型（不仅仅是相同的结构）：
 
 ```js
 test('toEqual vs toStrictEqual', () => {
-  // toEqual ignores undefined properties
+  // toEqual 忽略 undefined 属性
   expect({ a: 1 }).toEqual({ a: 1, b: undefined })
 
-  // toStrictEqual catches them
+  // toStrictEqual 会捕获它们
   expect({ a: 1 }).not.toStrictEqual({ a: 1, b: undefined })
 
-  // toEqual doesn't check object types
+  // toEqual 不检查对象类型
   class User {
     constructor(name) {
       this.name = name
@@ -72,10 +72,10 @@ test('toEqual vs toStrictEqual', () => {
 ```
 
 ::: tip
-A good rule of thumb: use `toBe` for primitives (numbers, strings, booleans), `toEqual` for comparing structure, and `toStrictEqual` when you also care about types and explicit `undefined` values.
+一个好的经验法则是：对原始值类型（数字、字符串、布尔值）使用 `toBe`，比较结构时使用 `toEqual`，当你还关心类型和显式的 `undefined` 值时使用 `toStrictEqual`。
 :::
 
-You can also negate any matcher by inserting `.not` before it. This is useful when you want to verify that something is *not* the case:
+你可以在任何匹配器前插入 `.not` 来否定它。适用于验证某些 _不成立_ 情况：
 
 ```js
 test('adding positive numbers is not zero', () => {
@@ -83,17 +83,17 @@ test('adding positive numbers is not zero', () => {
 })
 ```
 
-## Truthiness
+## 真值 {#truthiness}
 
-In tests you sometimes need to distinguish between `undefined`, `null`, and `false`. Other times you don't care about the exact value and just want to know if something is truthy or falsy. Vitest provides matchers for both situations:
+在测试中，有时你需要区分 `undefined`、`null` 和 `false`。其他时候你不关心确切的值，只想知道具体是真值还是假值。Vitest 为这两种情况提供了相应的匹配器：
 
-- [`toBeNull`](/api/expect#tobenull) matches only `null`
-- [`toBeUndefined`](/api/expect#tobeundefined) matches only `undefined`
-- [`toBeDefined`](/api/expect#tobedefined) is the opposite of `toBeUndefined`. It passes for anything that isn't `undefined`
-- [`toBeTruthy`](/api/expect#tobetruthy) matches anything that an `if` statement would treat as true
-- [`toBeFalsy`](/api/expect#tobefalsy) matches anything that an `if` statement would treat as false
+- [`toBeNull`](/api/expect#tobenull) 仅匹配 `null`
+- [`toBeUndefined`](/api/expect#tobeundefined) 仅匹配 `undefined`
+- [`toBeDefined`](/api/expect#tobedefined) 是 `toBeUndefined` 的反义。任何非 `undefined` 的值都会通过
+- [`toBeTruthy`](/api/expect#tobetruthy) 匹配任何 `if` 语句会视为 true 的值
+- [`toBeFalsy`](/api/expect#tobefalsy) 匹配任何 `if` 语句会视为 false 的值
 
-You should pick the matcher that most precisely describes what you're checking. Using `toBeTruthy` when you really mean `toBeDefined` can hide bugs, because `0` and `""` are both defined but falsy.
+你应该选择最能精确描述你检查内容的匹配器。当你实际意思是 `toBeDefined` 时使用 `toBeTruthy` 可能会掩盖 bug，因为 `0` 和 `""` 都是已定义的但却是假值。
 
 ```js
 test('null checks', () => {
@@ -109,15 +109,15 @@ test('null checks', () => {
 test('zero', () => {
   const z = 0
 
-  expect(z).toBeDefined() // passes: 0 is defined
-  expect(z).toBeFalsy() // passes: 0 is falsy
-  expect(z).not.toBeNull() // passes: 0 is not null
+  expect(z).toBeDefined() // 通过：0 已定义
+  expect(z).toBeFalsy() // 通过：0 是假值
+  expect(z).not.toBeNull() // 通过：0 不是 null
 })
 ```
 
-## Numbers
+## 数字 {#numbers}
 
-Most number comparisons are straightforward. Vitest provides the matchers you'd expect for greater-than, less-than, and equality checks:
+大多数数字比较都很直接。Vitest 提供了大于、小于和相等检查的匹配器：
 
 ```js
 test('number comparisons', () => {
@@ -128,29 +128,29 @@ test('number comparisons', () => {
   expect(value).toBeLessThan(5)
   expect(value).toBeLessThanOrEqual(4.5)
 
-  // For exact equality, both toBe and toEqual work the same for numbers
+  // 对于精确相等，toBe 和 toEqual 对数字的效果相同
   expect(value).toBe(4)
   expect(value).toEqual(4)
 })
 ```
 
-There is one common gotcha with floating point arithmetic. In JavaScript, `0.1 + 0.2` doesn't equal `0.3` exactly (it's `0.30000000000000004`). This means a `toBe(0.3)` check will fail. Use [`toBeCloseTo`](/api/expect#tobecloseto) instead, which compares numbers within a small rounding error:
+浮点数运算有一个常见的陷阱。在 JavaScript 中，`0.1 + 0.2` 并不完全等于 `0.3`（它是 `0.30000000000000004`）。这意味着 `toBe(0.3)` 检查会失败。请改用 [`toBeCloseTo`](/api/expect#tobecloseto)，它会在较小的舍入误差范围内比较数字：
 
 ```js
 test('adding floating point numbers', () => {
   const value = 0.1 + 0.2
 
-  // This won't work because of floating point rounding
+  // 由于浮点数舍入，这不会通过
   // expect(value).toBe(0.3)
 
-  // This works
+  // 这个可以
   expect(value).toBeCloseTo(0.3)
 })
 ```
 
-## Strings
+## 字符串 {#strings}
 
-You can test strings against regular expressions with [`toMatch`](/api/expect#tomatch). This is especially handy when you care about a pattern rather than an exact value, like checking that an error message contains a certain word or that a URL matches a particular format:
+你可以使用 [`toMatch`](/api/expect#tomatch) 根据正则表达式测试字符串。当你关心形式而非确切值时，这特别方便，例如检查错误消息是否包含某个单词，或者 URL 是否符合特定格式：
 
 ```js
 test('there is no I in team', () => {
@@ -162,9 +162,9 @@ test('version string matches semver format', () => {
 })
 ```
 
-## Arrays and Iterables
+## 数组和可迭代对象 {#arrays-and-iterables}
 
-[`toContain`](/api/expect#tocontain) checks that an array (or any iterable, like a `Set`) includes a particular item. It uses `===` for comparison, so it works well for primitives:
+[`toContain`](/api/expect#tocontain) 检查数组（或任何可迭代对象，如 `Set`）是否包含特定项。它使用 `===` 进行比较，因此对原始类型效果很好：
 
 ```js
 test('the shopping list has milk in it', () => {
@@ -175,11 +175,11 @@ test('the shopping list has milk in it', () => {
 })
 ```
 
-If you need to check that an array contains an object with a particular structure, use [`toContainEqual`](/api/expect#tocontainequal) instead. It works like `toEqual` but for individual items inside an array.
+如果你需要检查数组是否包含具有特定结构的对象，请改用 [`toContainEqual`](/api/expect#tocontainequal)。它的工作原理类似于 `toEqual`，但用于数组中的单个元素。
 
-## Objects
+## 对象 {#objects}
 
-When testing objects, you often want to check only a few important fields without specifying every property. [`toMatchObject`](/api/expect#tomatchobject) lets you do exactly that. It verifies that the object contains at least the properties you specify, and ignores any additional ones:
+测试对象时，你通常只想检查几个重要的字段，而不是检查每个属性。[`toMatchObject`](/api/expect#tomatchobject) 正是为此而设计。它验证对象至少包含你指定的属性，并忽略任何额外的属性：
 
 ```js
 test('user has expected fields', () => {
@@ -190,7 +190,7 @@ test('user has expected fields', () => {
     createdAt: '2024-01-01'
   }
 
-  // We only care about name and email here
+  // 这里我们只关心 name 和 email
   expect(user).toMatchObject({
     name: 'Alice',
     email: 'alice@example.com',
@@ -198,7 +198,7 @@ test('user has expected fields', () => {
 })
 ```
 
-For checking individual properties, especially nested ones, [`toHaveProperty`](/api/expect#tohaveproperty) is more readable. You pass a dot-separated path and optionally an expected value:
+对于检查单个属性，特别是嵌套属性，[`toHaveProperty`](/api/expect#tohaveproperty) 更具可读性。你传递一个点分隔的路径，并可选择性地传递一个期望值：
 
 ```js
 test('object has property', () => {
@@ -214,9 +214,9 @@ test('object has property', () => {
 })
 ```
 
-## Asymmetric Matchers
+## 非对称匹配器 {#asymmetric-matchers}
 
-Sometimes you don't know the exact value, but you know its type or shape. Asymmetric matchers let you describe what a value should *look like* without pinning down the exact content. They work inside any matcher that does deep comparison, like `toEqual` or `toMatchObject`:
+有时你不知道确切的值，但知道它的类型或结构。非对称匹配器让你可以描述值应该 _看起来应该是什么样_，而无需确定确切内容。它们可以在任何进行深度比较的匹配器内部工作，例如 `toEqual` 或 `toMatchObject`：
 
 ```js
 test('user has the right shape', () => {
@@ -231,17 +231,17 @@ test('user has the right shape', () => {
 })
 ```
 
-The most common asymmetric matchers are:
+最常用的非对称匹配器有：
 
-- [`expect.any(Constructor)`](/api/expect#expect-any) matches any value created with the given constructor (e.g., `Number`, `String`, `Array`)
-- [`expect.stringContaining(str)`](/api/expect#expect-stringcontaining) matches a string that includes the given substring
-- [`expect.stringMatching(regex)`](/api/expect#expect-stringmatching) matches a string against a regular expression
-- [`expect.arrayContaining(arr)`](/api/expect#expect-arraycontaining) matches an array that includes all items in the expected array (order doesn't matter, extra items are allowed)
-- [`expect.objectContaining(obj)`](/api/expect#expect-objectcontaining) matches an object that includes at least the specified properties
+- [`expect.any(Constructor)`](/api/expect#expect-any) 匹配使用给定构造函数创建的任何值（例如 `Number`、`String`、`Array`）
+- [`expect.stringContaining(str)`](/api/expect#expect-stringcontaining) 匹配包含给定子字符串的字符串
+- [`expect.stringMatching(regex)`](/api/expect#expect-stringmatching) 根据正则表达式匹配字符串
+- [`expect.arrayContaining(arr)`](/api/expect#expect-arraycontaining) 匹配包含预期数组中所有项的数组（顺序无关紧要，允许额外项）
+- [`expect.objectContaining(obj)`](/api/expect#expect-objectcontaining) 匹配至少包含指定属性的对象
 
-## Exceptions
+## 异常 {#exceptions}
 
-To verify that a function throws an error, use [`toThrow`](/api/expect#tothrow). You need to wrap the call in another function so that Vitest can catch the error instead of letting it crash the test:
+要验证函数是否抛出错误，请使用 [`toThrow`](/api/expect#tothrow)。你需要将调用包装在另一个函数中，以便 Vitest 可以捕获错误而不是让它导致测试崩溃：
 
 ```js
 function compileCode(code) {
@@ -252,36 +252,36 @@ function compileCode(code) {
 }
 
 test('compiling an empty string throws', () => {
-  // Check that it throws at all
+  // 检查它是否抛出异常
   expect(() => compileCode('')).toThrow()
 
-  // Check the error message
+  // 检查错误信息
   expect(() => compileCode('')).toThrow('Cannot compile empty string')
 
-  // Check the message with a regex
+  // 使用正则表达式检查错误信息
   expect(() => compileCode('')).toThrow(/empty string/)
 })
 ```
 
 ::: tip
-The wrapping function `() => compileCode('')` is important. If you wrote `expect(compileCode('')).toThrow()`, the error would be thrown *before* `expect` gets a chance to catch it, and the test would fail with an unhandled error instead.
+包装函数 `() => compileCode('')` 很重要。如果你写成 `expect(compileCode('')).toThrow()`，错误会在 `expect` 有机会捕获它 _之前_ 就被抛出，测试将因未处理的错误而失败。
 :::
 
-## Soft Assertions
+## 软断言 {#soft-assertions}
 
-Normally, a failing assertion stops the test immediately. That's useful most of the time, but sometimes you want to check several independent things and see all the failures at once rather than fixing them one by one.
+通常，失败的断言会立即停止测试。这适用大多数情况，但有时你想检查多个独立项并一次性看到所有失败，而不是逐个修复。
 
-[`expect.soft`](/api/expect#soft) does exactly that. It records the failure but lets the test keep running:
+[`expect.soft`](/api/expect#soft) 正是为此而设计。它会记录失败，但让测试继续运行：
 
 ```js
 test('check multiple fields', () => {
   const user = { name: 'Alice', age: 30, role: 'admin' }
 
   expect.soft(user.name).toBe('Alice')
-  expect.soft(user.age).toBe(25) // this fails but execution continues
+  expect.soft(user.age).toBe(25) // 这个会失败，但执行会继续
   expect.soft(user.role).toBe('admin')
-  // the test report will show that age didn't match
+  // 测试报告将显示 age 不匹配
 })
 ```
 
-This is especially useful for validating the shape of an API response or a complex object where multiple fields might be wrong at the same time.
+这对于验证 API 响应或复杂对象的结构特别有用，因为多个字段可能同时出错。
diff --git a/guide/learn/mock-functions.md b/guide/learn/mock-functions.md
index 2892ff7b..0b04dea8 100644
--- a/guide/learn/mock-functions.md
+++ b/guide/learn/mock-functions.md
@@ -1,22 +1,22 @@
 ---
-title: Mock Functions | Guide
+title: 模拟函数 | 指南
 prev:
-  text: Setup and Teardown
+  text: 初始化与清理
   link: /guide/learn/setup-teardown
 next:
-  text: Snapshot Testing
+  text: 快照测试
   link: /guide/learn/snapshots
 ---
 
-# Mock Functions
+# 模拟函数 {#mock-functions}
 
-When writing tests, you often need to replace a real function or module with a controlled version. This is called **mocking**. There are several reasons you might want to do this: maybe the real function makes network requests that would slow down your tests, or maybe you need to simulate an error that's hard to trigger with real code. Mock functions let you control what a dependency returns, observe how it was called, and isolate the code under test from side effects.
+在编写测试时，你经常需要用一个可控的版本来替换真实的函数或模块。这被称为 **模拟**。这样做通常有几个原因：比如真实函数会发起网络请求，从而拖慢测试速度，或者你需要模拟一种难以通过真实代码触发的错误。模拟函数可以让你控制依赖项的返回值、观察它是如何被调用的，并将被测代码与副作用隔离开来。
 
-Vitest provides mocking utilities through the [`vi`](/api/vi) object.
+Vitest 通过 [`vi`](/api/vi) 对象提供模拟工具函数。
 
-## Creating Mock Functions
+## 创建 Mock 函数 {#creating-mock-functions}
 
-The simplest way to create a mock is with [`vi.fn()`](/api/vi#vi-fn). This gives you a function that does nothing by default (returns `undefined`), but tracks every call made to it:
+创建模拟最简单的方法是使用 [`vi.fn()`](/api/vi#vi-fn)。这会得到一个默认什么都不做（仅返回 `undefined`）的函数，但它会追踪每一次调用：
 
 ```js
 import { expect, test, vi } from 'vitest'
@@ -24,21 +24,21 @@ import { expect, test, vi } from 'vitest'
 test('mock function basics', () => {
   const getApples = vi.fn()
 
-  // Call it
+  // 调用它
   getApples()
 
-  // Check it was called
+  // 检查它是否被调用过
   expect(getApples).toHaveBeenCalled()
   expect(getApples).toHaveBeenCalledTimes(1)
 
-  // By default, a mock returns undefined
+  // 默认情况下，模拟函数返回 undefined
   expect(getApples()).toBeUndefined()
 })
 ```
 
-## Mock Return Values
+## 模拟返回值 {#mock-return-values}
 
-A mock that always returns `undefined` isn't very useful on its own. You'll usually want to control what it returns so you can test how your code reacts to different values:
+一个总是返回 `undefined` 的模拟函数本身并没有太大用处。通常你会希望控制它的返回值，这样就可以测试你的代码在面对不同返回结果时会如何响应：
 
 ```js
 import { expect, test, vi } from 'vitest'
@@ -46,18 +46,18 @@ import { expect, test, vi } from 'vitest'
 test('mock return values', () => {
   const getApples = vi.fn()
 
-  // Always return this value
+  // 总是返回这个值
   getApples.mockReturnValue(10)
   expect(getApples()).toBe(10)
 
-  // Return this value only once, then fall back to the default
+  // 仅返回此值一次，然后回退到默认值
   getApples.mockReturnValueOnce(20)
-  expect(getApples()).toBe(20) // 20 (one-time)
-  expect(getApples()).toBe(10) // back to default
+  expect(getApples()).toBe(20) // 20（一次性）
+  expect(getApples()).toBe(10) // 回到默认值
 })
 ```
 
-If the function you're mocking is async, use [`mockResolvedValue`](/api/mock#mockresolvedvalue) and [`mockRejectedValue`](/api/mock#mockrejectedvalue) to control the promise outcome:
+如果你模拟的函数是异步的，请使用 [`mockResolvedValue`](/api/mock#mockresolvedvalue) 和 [`mockRejectedValue`](/api/mock#mockrejectedvalue) 来控制 Promise 的结果：
 
 ```js
 test('mock async return values', async () => {
@@ -72,9 +72,9 @@ test('mock async return values', async () => {
 })
 ```
 
-## Mock Implementation
+## 模拟实现 {#mock-implementation}
 
-Sometimes you need more than a fixed return value. You want the mock to actually do something with its arguments. [`mockImplementation`](/api/mock#mockimplementation) lets you provide a full replacement function:
+有时你需要的不只是一个固定的返回值。而是希望模拟函数能根据传入的参数真正执行一些逻辑。[`mockImplementation`](/api/mock#mockimplementation) 允许你提供一个完整的替代函数：
 
 ```js
 import { expect, test, vi } from 'vitest'
@@ -88,15 +88,15 @@ test('mock with custom implementation', () => {
 })
 ```
 
-As a shorthand, you can pass the implementation directly to `vi.fn()`:
+作为快捷方式，你可以直接将实现传递给 `vi.fn()`：
 
 ```js
 const add = vi.fn((a, b) => a + b)
 ```
 
-## Inspecting Calls
+## 检查调用 {#inspecting-calls}
 
-One of the most powerful things about mock functions is that they remember every call made to them. You can assert on how many times a function was called, what arguments it received, and what it returned:
+模拟函数最强大的功能之一是它们能记住每一次调用。你可以断言函数被调用了多少次、接收了什么参数以及返回了什么：
 
 ```js
 import { expect, test, vi } from 'vitest'
@@ -107,18 +107,18 @@ test('inspecting mock calls', () => {
   greet('Alice')
   greet('Bob', 'Charlie')
 
-  // Number of calls
+  // 调用次数
   expect(greet).toHaveBeenCalledTimes(2)
 
-  // Check specific arguments
+  // 检查特定参数
   expect(greet).toHaveBeenCalledWith('Alice')
   expect(greet).toHaveBeenCalledWith('Bob', 'Charlie')
 
-  // Check the arguments of a specific call by position
+  // 按位置检查特定调用的参数
   expect(greet).toHaveBeenNthCalledWith(1, 'Alice')
   expect(greet).toHaveBeenLastCalledWith('Bob', 'Charlie')
 
-  // Access the raw call data
+  // 访问原始调用数据
   expect(greet.mock.calls).toEqual([
     ['Alice'],
     ['Bob', 'Charlie'],
@@ -126,7 +126,7 @@ test('inspecting mock calls', () => {
 })
 ```
 
-The `.mock` property gives you full access to the call history. In addition to `.mock.calls`, you can also inspect `.mock.results` to see what the mock returned (or threw) on each call:
+`.mock` 属性让你能完全访问调用历史。除了 `.mock.calls`，你还可以检查 `.mock.results` 来查看模拟函数每次调用返回了什么或抛出了什么：
 
 ```js
 const double = vi.fn(x => x * 2)
@@ -141,7 +141,7 @@ expect(double.mock.results).toEqual([
 ```
 
 ::: warning
-`.mock.calls` stores references to the arguments, not copies. If you pass an object to a mock and then mutate it afterwards, the recorded call will reflect the mutated state, not the state at the time of the call:
+`.mock.calls` 存储的是对参数的引用，而不是副本。如果你将一个对象传递给模拟函数，之后又修改了它，那么记录的调用将反映修改后的状态，而不是调用时的状态：
 
 ```js
 const fn = vi.fn()
@@ -150,11 +150,11 @@ const obj = { count: 1 }
 fn(obj)
 obj.count = 2
 
-// ❌ This fails! mock.calls[0][0].count is now 2, not 1
+// ❌ 这会失败！mock.calls[0][0].count 现在是 2，而不是 1
 expect(fn).toHaveBeenCalledWith({ count: 1 })
 ```
 
-If you need to assert on the original values, you can use `mockImplementation` to capture a clone at call time:
+如果你需要对原始值进行断言，可以使用 `mockImplementation` 在调用时捕获一个克隆：
 
 ```js
 const calls = []
@@ -166,15 +166,15 @@ const obj = { count: 1 }
 fn(obj)
 obj.count = 2
 
-expect(calls[0]).toEqual({ count: 1 }) // ✅ passes
+expect(calls[0]).toEqual({ count: 1 }) // ✅ 通过
 ```
 
-Alternatively, you can make your assertion before the mutation happens.
+或者，你可以在修改发生之前进行断言。
 :::
 
-## Spying on Methods
+## 监听方法 {#spying-on-methods}
 
-[`vi.spyOn`](/api/vi#vi-spyon) is different from `vi.fn()` in an important way. Instead of creating a brand new function, it wraps an *existing* method on an object. The original implementation still works by default, but you can observe every call and optionally override the behavior:
+[`vi.spyOn`](/api/vi#vi-spyon) 与 `vi.fn()` 有一个重要区别。它不是创建一个全新的函数，而是包装对象上 _现有方法_。默认情况下原始实现仍然会正常执行，但你可以观察每次调用，并且在需要时选择覆盖它的行为：
 
 ```js
 import { expect, test, vi } from 'vitest'
@@ -188,10 +188,10 @@ const calculator = {
 test('spy on a method', () => {
   const spy = vi.spyOn(calculator, 'add')
 
-  // The original implementation still works
+  // 原始实现仍然工作
   expect(calculator.add(1, 2)).toBe(3)
 
-  // But we can observe calls
+  // 但我们可以观察调用
   expect(spy).toHaveBeenCalledWith(1, 2)
   expect(spy).toHaveBeenCalledTimes(1)
 })
@@ -204,17 +204,17 @@ test('spy can override implementation', () => {
 })
 ```
 
-This is particularly useful when you want to verify that your code calls a method correctly without replacing the method's behavior entirely.
+适用于你想验证你的代码正确调用了某个方法，而不是完全替换该方法的行为。
 
-## Resetting Mocks
+## 重置模拟 {#resetting-mocks}
 
-Mock functions accumulate state as tests run. They remember every call, every return value, and any custom implementation you've set. If you don't reset them between tests, this state can leak and cause confusing failures. Vitest provides three levels of cleanup:
+模拟函数随着测试运行会积累状态。它们会记住每次调用、每个返回值以及你设置的任何自定义实现。如果你不在测试之间重置它们，这种状态可能会泄漏并导致难以理解的失败。Vitest 提供了三个级别的清理函数：
 
-- **[`mockClear()`](/api/mock#mockclear)** clears the recorded call history and return values, but keeps any custom implementation you've set
-- **[`mockReset()`](/api/mock#mockreset)** does everything `mockClear` does, and also removes any custom implementation, returning the mock to its default state
-- **[`mockRestore()`](/api/mock#mockrestore)** is specifically for spies created with `vi.spyOn`. It restores the original object method, effectively undoing the spy. On `vi.fn()` mocks, it behaves the same as `mockReset`
+- **[`mockClear()`](/api/mock#mockclear)** 清除记录的调用历史和返回值，但保留你设置的任何自定义实现
+- **[`mockReset()`](/api/mock#mockreset)** 执行 `mockClear` 的所有操作，并且还会移除所有自定义实现，将模拟恢复到其默认状态
+- **[`mockRestore()`](/api/mock#mockrestore)** 专门用于通过 `vi.spyOn` 创建的 spy。它会恢复对象的原始方法，有效地撤销 spy。对于 `vi.fn()` 创建的模拟，其行为与 `mockReset` 相同
 
-In practice, the easiest approach is to restore all mocks automatically after each test:
+在实践中，最简单的方法是在每个测试后自动恢复所有模拟：
 
 ```js
 import { afterEach, expect, test, vi } from 'vitest'
@@ -230,11 +230,11 @@ afterEach(() => {
 test('spy is restored after the test', () => {
   const spy = vi.spyOn(calculator, 'add').mockReturnValue(42)
   expect(calculator.add(1, 2)).toBe(42)
-  // afterEach will restore calculator.add to the original implementation
+  // afterEach 会将 calculator.add 恢复到原始实现
 })
 ```
 
-Even better, you can configure this globally with the [`restoreMocks`](/config/restoremocks) option so you don't need the `afterEach` at all:
+更好的做法是，你可以通过 [`restoreMocks`](/config/restoremocks) 选项全局配置此功能，这样你完全不需要 `afterEach`：
 
 ```js [vitest.config.js]
 import { defineConfig } from 'vitest/config'
@@ -246,9 +246,9 @@ export default defineConfig({
 })
 ```
 
-## Mocking Modules
+## 模拟模块 {#mocking-modules}
 
-Sometimes you need to replace an [entire module](/guide/mocking/modules) rather than a single function. For example, a database client or a logger that you don't want running during tests. [`vi.mock`](/api/vi#vi-mock) lets you replace a module's exports with mock implementations:
+有时你需要替换不是单个函数，而是 [整个模块](/guide/mocking/modules)。例如，一个你不想在测试期间运行的数据库客户端或日志记录器。[`vi.mock`](/api/vi#vi-mock) 允许你用模拟实现替换模块的导出：
 
 ```js
 import { expect, test, vi } from 'vitest'
@@ -268,20 +268,20 @@ test('mock a module', () => {
 ```
 
 ::: warning
-[`vi.mock`](/api/vi#vi-mock) calls are hoisted to the top of the file. They run before any imports. This means the mocked version is in place by the time your test code runs.
+[`vi.mock`](/api/vi#vi-mock) 调用会被提升到文件顶部。它们在所有导入之前运行。这意味着 mock 版本会在你的测试代码运行时就已经就位。
 :::
 
 ::: warning
-Always pass `import('./db.js')` rather than a plain string `'./db.js'`. When you use `import()`, TypeScript can infer the module's types, so the factory function's return value is type-checked and `importOriginal` returns the correctly typed module. As a bonus, if you rename or move the file in your IDE, the import path will be updated automatically. If you use a string, you lose both the type safety and the automatic refactoring.
+始终传递 `import('./db.js')` 而不是纯字符串 `'./db.js'`。当你使用 `import()` 时，TypeScript 可以推断模块的类型，因此工厂函数的返回值会进行类型检查，并且 `importOriginal` 会返回正确类型的模块。此外，如果你在 IDE 中重命名或移动文件，导入路径会自动更新。如果使用字符串，你将失去类型安全和自动重构能力。
 :::
 
-Vitest has comprehensive guides for specific mocking scenarios:
+Vitest 为特定的模拟场景提供了全方面的指南：
 
-- [Mocking Functions](/guide/mocking/functions)
-- [Mocking Modules](/guide/mocking/modules)
-- [Mocking Timers](/guide/mocking/timers)
-- [Mocking Dates](/guide/mocking/dates)
-- [Mocking Globals](/guide/mocking/globals)
-- [Mocking Requests](/guide/mocking/requests)
-- [Mocking the File System](/guide/mocking/file-system)
-- [Mocking Classes](/guide/mocking/classes)
+- [模拟函数](/guide/mocking/functions)
+- [模拟模块](/guide/mocking/modules)
+- [模拟计时器](/guide/mocking/timers)
+- [模拟日期](/guide/mocking/dates)
+- [模拟全局对象](/guide/mocking/globals)
+- [模拟请求](/guide/mocking/requests)
+- [模拟文件系统](/guide/mocking/file-system)
+- [模拟类](/guide/mocking/classes)
diff --git a/guide/learn/setup-teardown.md b/guide/learn/setup-teardown.md
index 2eacac65..cd367286 100644
--- a/guide/learn/setup-teardown.md
+++ b/guide/learn/setup-teardown.md
@@ -1,20 +1,20 @@
 ---
-title: Setup and Teardown | Guide
+title: 初始化与清理 | 指南
 prev:
-  text: Testing Asynchronous Code
+  text: 测试异步代码
   link: /guide/learn/async
 next:
-  text: Mock Functions
+  text: 模拟函数
   link: /guide/learn/mock-functions
 ---
 
-# Setup and Teardown
+# 初始化与清理 {#setup-and-teardown}
 
-Often while writing tests, you need to do some work before tests run (initialize data, connect to a database, start a server) and clean up afterwards. Rather than duplicating this code in every test, Vitest provides lifecycle hooks that run automatically at the right time.
+在编写测试时，经常需要在测试运行前进行一些准备工作（例如初始化数据、连接数据库、启动服务器），并在测试结束后进行清理。为了避免在每个测试中重复这些代码，Vitest 提供了生命周期钩子，它们会在恰当的时机自动执行。
 
-## Repeating Setup for Each Test
+## 为每个测试重复初始化 {#repeating-setup-for-each-test}
 
-The most common hooks are [`beforeEach`](/api/hooks#beforeeach) and [`afterEach`](/api/hooks#aftereach). As the names suggest, `beforeEach` runs before every test in the file, and `afterEach` runs after every test, even if the test fails. This makes them perfect for ensuring each test starts with a known state.
+最常用的钩子是 [`beforeEach`](/api/hooks#beforeeach) 和 [`afterEach`](/api/hooks#aftereach)。顾名思义，`beforeEach` 会在文件中的每个测试之前运行，而 `afterEach` 会在每个测试之后运行，即使测试失败也是如此。这使得它们非常适合确保每个测试都从一个已知的初始状态开始。
 
 ```js
 import { afterEach, beforeEach, expect, test } from 'vitest'
@@ -36,16 +36,16 @@ test('items starts with 3 fruits', () => {
 test('can add an item', () => {
   items.push('date')
   expect(items).toHaveLength(4)
-  // afterEach will reset items for the next test,
-  // so this mutation won't leak into other tests
+  // afterEach 会为下一个测试重置项目，
+  // 因此此处的修改不会影响到其他测试
 })
 ```
 
-Without these hooks, the second test's `push` would affect any test that runs after it, which is a classic source of flaky tests. The hooks guarantee clean state for every test.
+如果没有这些钩子，第二个测试的 `push` 操作会影响其后的所有测试，这是导致测试不稳定的典型原因。这些钩子确保了每个测试都拥有干净的状态。
 
-## One-Time Setup
+## 一次性初始化 {#one-time-setup}
 
-Some setup is too expensive to repeat for every test. If you need to connect to a database, start a server, or load a large file, doing that before every test would slow your suite down dramatically. That's what [`beforeAll`](/api/hooks#beforeall) and [`afterAll`](/api/hooks#afterall) are for. They run once for the entire file:
+有些初始化过于耗时，不适合为每个测试重复执行。如果你需要连接数据库、启动服务器或加载大型文件，在每个测试前都做这些操作会显著拖慢测试套件的速度。这正是 [`beforeAll`](/api/hooks#beforeall) 和 [`afterAll`](/api/hooks#afterall) 的用武之地。它们在整个文件运行期间只执行一次：
 
 ```js
 import { afterAll, beforeAll, expect, test } from 'vitest'
@@ -71,11 +71,11 @@ test('can query products', async () => {
 })
 ```
 
-The database connection is created once, shared across all tests, and then closed when the file finishes running.
+数据库连接只创建一次，在所有测试间共享，并在文件运行结束时关闭。
 
-## Scoping with `describe`
+## 使用 `describe` 进行作用域划分 {#scoping-with-describe}
 
-Hooks defined inside a `describe` block only apply to the tests within that block. Top-level hooks apply to every test in the file. This lets you set up different state for different groups of tests:
+在 `describe` 块内定义的钩子仅适用于该块内的测试。顶层的钩子则适用于文件中的每个测试。这让你可以为不同的测试组初始化不同的状态：
 
 ```js
 import { beforeEach, describe, expect, test } from 'vitest'
@@ -94,7 +94,7 @@ describe('math operations', () => {
 
   test('can subtract', () => {
     value -= 3
-    expect(value).toBe(-3) // value was reset to 0 by beforeEach
+    expect(value).toBe(-3) // value 被 beforeEach 重置为 0
   })
 })
 
@@ -111,11 +111,11 @@ describe('string operations', () => {
 })
 ```
 
-Each `describe` block has its own `beforeEach` that only affects the tests inside it. The string tests don't know or care about the `value` variable, and vice versa.
+每个 `describe` 块都有其自己的 `beforeEach` 钩子，该钩子仅影响其内部的测试。字符串测试不知道也不关心 `value` 变量，反之亦然。
 
-## Execution Order
+## 执行顺序 {#execution-order}
 
-When you have hooks at multiple levels, it's helpful to understand the order they run in. Top-level hooks wrap around inner hooks, forming a nesting structure:
+当你在多个层级上设置钩子时，了解它们的执行顺序会很有用。顶层钩子包裹着内层钩子，形成一种嵌套结构：
 
 ```js
 import { afterAll, afterEach, beforeAll, beforeEach, describe, test } from 'vitest'
@@ -139,7 +139,7 @@ describe('suite', () => {
 })
 ```
 
-This produces the following output:
+这会产生以下输出：
 
 ```
 1 - beforeAll
@@ -156,11 +156,9 @@ This produces the following output:
 8 - afterAll
 ```
 
-Notice the pattern: `beforeAll` and `afterAll` run once for the entire suite, while `beforeEach` and `afterEach` repeat for every test. Within each test, outer `beforeEach` runs first (setting up the broadest context), then inner `beforeEach` runs (narrowing the context). After the test, the order reverses: inner `afterEach` cleans up the narrow context first, then outer `afterEach` handles the broader cleanup.
+注意这里的执行顺序：`beforeAll` 和 `afterAll` 在整个测试套件中只运行一次，而 `beforeEach` 和 `afterEach` 则为每个测试重复执行。在每个测试内部，外层的 `beforeEach` 首先运行（初始化最宽泛的上下文），然后内层的 `beforeEach` 运行（缩小上下文范围）。测试结束后，顺序则相反：内层的 `afterEach` 先清理较窄的上下文，然后外层的 `afterEach` 处理更宽泛的清理工作。
 
-## Cleanup with `onTestFinished`
-
-Sometimes you create a resource inside a test that needs to be cleaned up afterwards. You could use `afterEach`, but that means the cleanup is separated from the setup, which can make the test harder to follow. [`onTestFinished`](/api/hooks#ontestfinished) lets you register a cleanup function right where you create the resource:
+## 使用 `onTestFinished` 进行清理 {#cleanup-with-ontestfinished}
 
 ```js
 import { expect, onTestFinished, test } from 'vitest'
@@ -175,7 +173,7 @@ test('creates a temporary file', () => {
 })
 ```
 
-A similar pattern works with `beforeEach`. You can return a cleanup function and Vitest will call it after each test. This is especially nice when the setup and teardown are closely related:
+类似的模式也适用于 `beforeEach`。你可以返回一个清理函数，Vitest 会在每个测试后调用它。当初始化和清理操作紧密相关时，这种方式极其方便：
 
 ```js
 import { beforeEach } from 'vitest'
@@ -188,11 +186,11 @@ beforeEach(() => {
 })
 ```
 
-## Fixtures with `test.extend`
+## 使用 `test.extend` 的 Fixtures {#fixtures-with-test-extend}
 
-The examples above use `let` variables and `beforeEach` to set up shared state. This works, but it has some downsides: the variable declarations are separated from the initialization, the types require explicit annotation, and it's easy to forget to clean up.
+上述示例使用 `let` 变量和 `beforeEach` 来初始化共享状态。这种方式可行，但存在一些缺点：变量声明与初始化是分离的，类型需要显式注解，并且容易忘记清理。
 
-Vitest offers a better pattern for this with [`test.extend`](/guide/test-context#extend-test-context). You define reusable **fixtures** that are automatically created for each test and cleaned up afterwards:
+Vitest 通过 [`test.extend`](/guide/test-context#extend-test-context) 提供了一个更好的形式。你可以定义可复用的 **fixtures**，它们会自动为每个测试创建并在之后清理：
 
 ```js [my-test.js]
 import { test as baseTest } from 'vitest'
@@ -217,13 +215,13 @@ test('user is created', ({ db, user }) => {
 })
 ```
 
-Fixtures are only initialized when a test actually uses them (by destructuring them from the context), and they can depend on each other. This makes them a great alternative to `beforeEach`/`afterEach` for most setup and teardown patterns.
+Fixtures 仅在测试实际使用它们时（通过从上下文中解构）才会初始化，并且它们可以相互依赖。对于大多数初始化和清理形式，这是 `beforeEach`/`afterEach` 的一个很好的替代方案。
 
-See the [Test Context](/guide/test-context) guide for the full details on fixtures, scoping, and overrides.
+有关 fixtures、作用域和覆盖的完整详细信息，请参阅 [测试上下文](/guide/test-context)。
 
-## Setup Files
+## 初始化文件 {#setup-files}
 
-If you have setup code that should run before every test file in your project (things like polyfills, global configuration, or custom matchers), you can put it in a setup file and point to it with the [`setupFiles`](/config/setupfiles) config option:
+如果你有一些初始化代码需要在项目中的每个测试文件运行前执行（例如 polyfills、全局配置或自定义匹配器），你可以将其放入一个初始化文件中，并通过 [`setupFiles`](/config/setupfiles) 配置选项指向它：
 
 ```js [vitest.config.js]
 import { defineConfig } from 'vitest/config'
@@ -236,15 +234,15 @@ export default defineConfig({
 ```
 
 ```js [test/setup.js]
-// This runs before every test file
+// 这会在每个测试文件之前运行
 import { expect } from 'vitest'
 import { customMatchers } from './custom-matchers.js'
 
 expect.extend(customMatchers)
 ```
 
-Unlike `beforeAll`, which runs once per file, setup files run in a separate phase before the test file even starts being collected. This makes them the right place for things like extending the `expect` API or configuring global polyfills.
+与每个文件运行一次的 `beforeAll` 不同，初始化文件在测试文件甚至开始收集之前，在一个独立的阶段运行。这使得它们非常适合扩展 `expect` API 或配置全局 polyfills 等操作。
 
 ::: tip
-For advanced cases where your test needs to run *inside* a wrapping context (like a database transaction or a tracing span), see the [`aroundEach`](/api/hooks#aroundeach) and [`aroundAll`](/api/hooks#aroundall) hooks. For the complete lifecycle picture, see [Test Run Lifecycle](/guide/lifecycle).
+对于需要在包装上下文（例如数据库事务或跟踪范围）_内部_ 运行测试的高级场景，请参阅 [`aroundEach`](/api/hooks#aroundeach) 和 [`aroundAll`](/api/hooks#aroundall) 钩子。有关完整的生命周期图，请参阅 [测试运行生命周期](/guide/lifecycle)。
 :::
diff --git a/guide/learn/snapshots.md b/guide/learn/snapshots.md
index 9b0ed9d8..1c703fa3 100644
--- a/guide/learn/snapshots.md
+++ b/guide/learn/snapshots.md
@@ -1,22 +1,22 @@
 ---
-title: Snapshot Testing | Guide
+title: 快照测试 | 指南
 prev:
-  text: Mock Functions
+  text: 模拟函数
   link: /guide/learn/mock-functions
 next:
-  text: Testing in Practice
+  text: 测试实操
   link: /guide/learn/testing-in-practice
 ---
 
-# Snapshot Testing
+# 快照测试 {#snapshot-testing}
 
-Snapshot tests capture the output of a piece of code and save it to a file. On subsequent runs, the output is compared against the saved snapshot. If the output changes, the test fails. Either the change is a bug, or the snapshot needs to be updated.
+快照测试会捕获一段代码的输出并将其保存到文件中。在后续运行时，将输出结果与已保存的快照进行比较。如果输出发生变化，测试就会失败。这种变化可能是 bug，也可能是快照需要更新。
 
-This approach is particularly useful when you're testing something that produces structured output: a function that returns a complex object, a component that renders HTML, or an error formatter that produces multi-line messages. Writing manual assertions for every field or line would be tedious and fragile. Instead, you capture the entire output once, and let Vitest tell you if it ever changes.
+这种方法特别适合测试会产生结构化输出的场景：例如返回复杂对象的函数、渲染 HTML 的组件，或是生成多行消息的错误格式化器。为每个字段或每行代码手动编写断言既繁琐又脆弱。相反，你可以一次性捕获整个输出，然后由 Vitest 来告诉你输出是否发生了变化。
 
-## Your First Snapshot
+## 你的第一个快照 {#your-first-snapshot}
 
-To create a snapshot test, pass a value to [`toMatchSnapshot()`](/api/expect#tomatchsnapshot):
+要创建快照测试，只需将值传递给 [`toMatchSnapshot()`](/api/expect#tomatchsnapshot) 方法即可：
 
 ```js
 import { expect, test } from 'vitest'
@@ -34,14 +34,14 @@ test('generates a greeting', () => {
 })
 ```
 
-The first time you run this test, there's no existing snapshot to compare against, so Vitest creates one. It stores the snapshot in a `__snapshots__` directory next to your test file:
+首次运行此测试时，由于不存在可比较的现有快照，Vitest 会自动创建一个。它会将快照存储在与测试文件相邻的 `__snapshots__` 目录中：
 
 ```
 __snapshots__/
   example.test.js.snap
 ```
 
-If you open that file, you'll see a serialized representation of the value:
+如果打开该文件，你会看到该值的序列化表示：
 
 ```js
 exports['generates a greeting 1'] = `
@@ -53,17 +53,17 @@ exports['generates a greeting 1'] = `
 `
 ```
 
-From now on, every time you run this test, Vitest serializes the output of `generateGreeting('Alice')` and compares it character-by-character against this stored snapshot. If the output changes (say, someone modifies the message format or bumps the version number), the test fails and shows a clear diff of what changed.
+从此以后，每次运行此测试时，Vitest 都会将 `generateGreeting('Alice')` 的输出序列化，并与存储的快照进行逐字符比较。如果输出发生变化（比如有人修改了消息格式或更新了版本号），测试就会失败，并清晰地显示变更的差异。
 
 ::: tip
-Commit your snapshot files to version control. They serve as a record of the expected output and should be reviewed in code review just like any other test assertion.
+请将快照文件提交到版本控制系统。它们作为预期输出的记录，应该像其他测试断言一样在代码审查中进行检查。
 :::
 
-## Inline Snapshots
+## 内联快照 {#inline-snapshots}
 
-External snapshot files work well, but they mean you have to jump to a different file to see what the expected output actually looks like. For smaller values, it's often more convenient to keep the snapshot right in your test file with [`toMatchInlineSnapshot()`](/api/expect#tomatchinlinesnapshot).
+外部快照文件虽然好用，但意味着你必须跳转到另一个文件才能查看预期输出的实际内容。对于较小的值，使用 [`toMatchInlineSnapshot()`](/api/expect#tomatchinlinesnapshot) 将快照直接保留在测试文件中通常更为方便。
 
-Start by writing the assertion without any argument:
+首先，在没有任何参数的情况下编写断言：
 
 ```js
 test('generates a greeting', () => {
@@ -71,7 +71,7 @@ test('generates a greeting', () => {
 })
 ```
 
-When you run the test, Vitest will **automatically fill in** the snapshot as a string argument:
+当你运行测试时，Vitest 将 **自动填充** 快照作为字符串参数：
 
 ```js
 test('generates a greeting', () => {
@@ -85,37 +85,37 @@ test('generates a greeting', () => {
 })
 ```
 
-Now the expected output lives right next to the code that produces it. You can read the test and immediately understand what `generateGreeting` is expected to return. When the output changes, Vitest updates the string in place, so you don't need to manage separate snapshot files.
+现在，预期输出就紧挨着生成它的代码。你可以阅读测试并立即理解 `generateGreeting` 应该返回什么。当输出发生变化时，Vitest 会原地更新字符串，因此你无需管理单独的快照文件。
 
-Inline snapshots are great for small, focused values. For large outputs (like a full HTML page), external snapshots or file snapshots are a better fit.
+内联快照非常适合小型、关注点明确。对于大型输出（如完整的 HTML 页面），外部快照或文件快照更为合适。
 
 ::: tip
-Unlike external snapshots, inline snapshots don't create separate `.snap` files. The expected value is stored directly in your test file as the argument to `toMatchInlineSnapshot()`, so there's nothing extra to commit.
+与外部快照不同，内联快照不会创建单独的 `.snap` 文件。预期值直接作为 `toMatchInlineSnapshot()` 的参数存储在测试文件中，因此无需额外提交任何内容。
 :::
 
-## Updating Snapshots
+## 更新快照 {#updating-snapshots}
 
-When you intentionally change the output of your code, existing snapshots will be outdated and the tests will fail. This is by design; it's the whole point of snapshot testing. But once you've verified that the new output is correct, you need to update the snapshots.
+当你故意更改代码的输出时，现有的快照将过时，测试也会失败。这是设计使然；这正是快照测试的全部意义所在。但一旦你确认新输出是正确的，就需要更新快照。
 
-There are several ways to do this:
+有几种方法可以做到这一点：
 
-- **In watch mode**: press `u` in the terminal to update all failed snapshots
-- **From the CLI**: run `vitest -u` or `vitest --update` to update snapshots and exit
-- **In VS Code**: use the "Update Snapshots" command on the test gutter icon from the [Vitest extension](https://vitest.dev/vscode)
+- **在 watch 模式下**：在终端中按 `u` 键更新所有失败的快照
+- **通过命令行界面**：运行 `vitest -u` 或 `vitest --update` 来更新快照并退出
+- **在 VS Code 中**：使用 [Vitest 扩展](https://vitest.dev/vscode) 在测试面板上选择 “更新快照” 命令
 
 ```bash
 vitest -u
 ```
 
-For inline snapshots, Vitest modifies your test file directly with the new values. For external snapshots, it rewrites the `.snap` file.
+对于内联快照，Vitest 会直接用新值修改你的测试文件。对于外部快照，它会重写 `.snap` 文件。
 
 ::: warning
-Be careful when updating snapshots. Always review the diff to confirm the changes are intentional and not a bug. It's easy to accidentally accept a broken output by blindly pressing `u`.
+更新快照时要小心。务必仔细检查差异，以确认更改是有意为之，而非缺陷。盲目按 `u` 键很容易意外接受一个错误的输出。
 :::
 
-## File Snapshots
+## 文件快照 {#file-snapshots}
 
-Sometimes the output you're testing is large enough that even an external `.snap` file feels awkward, or you want to view the snapshot with proper syntax highlighting in your editor. [`toMatchFileSnapshot()`](/api/expect#tomatchfilesnapshot) lets you save the snapshot to a file with any extension you want:
+有时你测试的输出非常大，以至于即使是外部的 `.snap` 文件也显得笨拙，或者你希望在编辑器中以正确的语法高亮查看快照。[`toMatchFileSnapshot()`](/api/expect#tomatchfilesnapshot) 允许你将快照保存为任意扩展名的文件：
 
 ```js
 test('renders the component', async () => {
@@ -124,25 +124,25 @@ test('renders the component', async () => {
 })
 ```
 
-The snapshot is stored as a plain `.html` file that you can open in a browser, view with syntax highlighting, or diff with standard tools. This works well for HTML, SVG, CSS, generated code, or any output where the file format matters for readability.
+快照以普通的 `.html` 文件形式存储，你可以用浏览器打开、以语法高亮查看，或用标准工具进行差异对比。对于 HTML、SVG、CSS、生成代码等这类可读性很重要的输出格式，这种方式都很有效。
 
-## When to Use Snapshots
+## 何时使用快照 {#when-to-use-snapshots}
 
-Snapshots shine when you're working with structured, serializable output that would be painful to assert on manually. Some common use cases:
+当你处理结构化、可序列化的输出，并且手动断言会非常痛苦时，快照测试就可以大放异彩。一些常见的用例包括：
 
-- A function that returns a complex configuration object with many nested fields
-- HTML or markup generated by a rendering function or template engine
-- Error messages that include formatted stack traces or context information
-- CLI output or log messages with specific formatting
-- JSON API responses where you want to catch any unexpected field changes
+- 返回具有许多嵌套字段的复杂配置对象的函数
+- 由渲染函数或模板引擎生成的 HTML 或标记
+- 包含格式化堆栈跟踪或上下文信息的错误消息
+- 具有特定格式的 CLI 输出或日志消息
+- JSON API 响应，你希望捕获所有意外的字段更改
 
-On the other hand, snapshots are not always the best tool. If the output changes frequently (for instance, it includes timestamps or random IDs), you'll spend more time updating snapshots than they save you. And if you only care about one or two specific fields, a targeted assertion like [`toMatchObject`](/api/expect#tomatchobject) or [`toHaveProperty`](/api/expect#tohaveproperty) expresses your intent more clearly than a snapshot that captures everything.
+另一方面，快照并不总是最佳工具。如果输出频繁变化（例如，包含时间戳或随机 ID），你花在更新快照上的时间将比它们为你节省的时间更多。如果你只关心一两个特定字段，像 [`toMatchObject`](/api/expect#tomatchobject) 或 [`toHaveProperty`](/api/expect#tohaveproperty) 这样的针对性断言，比捕获所有内容的快照更能清晰地表达你的意图。
 
-The general rule: use snapshots when you want to protect against *any* change in the output, and use targeted assertions when you only care about *specific* properties.
+一般的规则是：当你希望防止输出发生 _任何_ 变化时，使用快照；当你只关心 _特定_ 属性时，使用针对性断言。
 
-## Handling Dynamic Values
+## 处理动态值 {#handling-dynamic-values}
 
-If your output includes values that change every run (like timestamps or IDs), you can use property matchers to pin the structure while ignoring volatile fields. Pass an object with asymmetric matchers as the first argument to `toMatchSnapshot()` or `toMatchInlineSnapshot()`:
+如果你的输出包含每次运行都会变化的值（如时间戳或 ID），你可以使用属性匹配器来固定结构，同时忽略易变字段。将一个包含非对称匹配器的对象作为第一个参数传递给 `toMatchSnapshot()` 或 `toMatchInlineSnapshot()`：
 
 ```js
 test('user snapshot with dynamic fields', () => {
@@ -155,11 +155,11 @@ test('user snapshot with dynamic fields', () => {
 })
 ```
 
-The `id` and `createdAt` fields are checked against the matchers (any number, any date) instead of being compared to a stored value. All other fields are snapshotted as usual.
+`id` 和 `createdAt` 字段将根据匹配器（任意数字、任意日期）进行检查，而不是与存储的值进行比较。其他字段则像往常一样进行快照对比。
 
-## Error Snapshots
+## 错误快照 {#error-snapshots}
 
-A common use of inline snapshots is capturing error messages. [`toThrowErrorMatchingInlineSnapshot`](/api/expect#tothrowerrormatchinginlinesnapshot) combines `toThrow` with `toMatchInlineSnapshot` so you can snapshot the error message without a separate `.snap` file:
+内联快照的一个常见用法是捕获错误消息。[`toThrowErrorMatchingInlineSnapshot`](/api/expect#tothrowerrormatchinginlinesnapshot) 将 `toThrow` 与 `toMatchInlineSnapshot` 结合，这样你就可以在不使用单独 `.snap` 文件的情况下对错误消息进行快照：
 
 ```js
 test('throws on invalid input', () => {
@@ -169,8 +169,8 @@ test('throws on invalid input', () => {
 })
 ```
 
-This is especially handy for verifying that error messages are clear and don't accidentally change. Like other inline snapshots, Vitest fills in the string on the first run and updates it when you press `u`.
+这对于验证错误消息是否清晰且不会意外更改非常方便。与其他内联快照一样，Vitest 在首次运行时填充字符串，并在你按下 `u` 时更新它。
 
 ::: tip
-For custom snapshot serializers, snapshot matchers, and advanced configuration, see the [Snapshot](/guide/snapshot) guide.
+关于自定义快照序列化器、快照匹配器和高级配置，请参阅 [快照](/guide/snapshot)。
 :::
diff --git a/guide/learn/snippets/debug-output-fail.ansi b/guide/learn/snippets/debug-output-fail.ansi
index ee3d9d8e..2275c0e2 100644
--- a/guide/learn/snippets/debug-output-fail.ansi
+++ b/guide/learn/snippets/debug-output-fail.ansi
@@ -1,4 +1,4 @@
- FAIL src/user.test.js > createUser > sets the default role
+FAIL src/user.test.js > createUser > sets the default role
 AssertionError: expected { name: 'Alice', role: 'viewer' } to deeply equal { name: 'Alice', role: 'member' }
 
 - Expected
diff --git a/guide/learn/snippets/test-output-fail.ansi b/guide/learn/snippets/test-output-fail.ansi
index 257515ee..88fef342 100644
--- a/guide/learn/snippets/test-output-fail.ansi
+++ b/guide/learn/snippets/test-output-fail.ansi
@@ -1,4 +1,4 @@
- FAIL src/utils.test.js > Math.sqrt > returns the square root of perfect squares
+FAIL src/utils.test.js > Math.sqrt > returns the square root of perfect squares
 AssertionError: expected 3 to be 2
 
 - Expected
diff --git a/guide/learn/testing-in-practice.md b/guide/learn/testing-in-practice.md
index d622e6aa..828e6321 100644
--- a/guide/learn/testing-in-practice.md
+++ b/guide/learn/testing-in-practice.md
@@ -1,22 +1,22 @@
 ---
-title: Testing in Practice | Guide
+title: 测试实操 | 指南
 prev:
-  text: Snapshot Testing
+  text: 快照测试
   link: /guide/learn/snapshots
 next:
-  text: Debugging Tests
+  text: 调试测试
   link: /guide/learn/debugging-tests
 ---
 
-# Testing in Practice
+# 测试实践 {#testing-in-practice}
 
-The previous pages covered the Vitest API: assertions, mocking, snapshots, and test lifecycle hooks. This page focuses on applying those tools to real code. It covers how to decide what to test, how to structure tests effectively, and how to organize test files as a project grows.
+前面的章节介绍了 Vitest API：断言、模拟、快照和测试生命周期钩子。本章重点介绍如何将这些工具应用到实际代码中，包括如何确定测试内容、如何组织测试结构，以及如何在项目增长时有效组织测试文件。
 
-## What to Test
+## 哪些需要测试 {#what-to-test}
 
-When you sit down to write tests for a function or module, start by thinking about its **contract**: what does it promise to do for the code that calls it? The contract is defined by its inputs (arguments, configuration) and its outputs (return values, side effects, errors). These are the things your tests should verify.
+当你开始为函数或模块编写测试时，首先要思考它的 **约定**：它对调用方作出了哪些保证？约定由其输入（参数、配置）和输出（返回值、副作用、错误）定义。这些正是你的测试需要验证的内容。
 
-Consider a `formatPrice` function:
+以 `formatPrice` 函数为例：
 
 ```js [formatPrice.js]
 export function formatPrice(amount, currency) {
@@ -27,7 +27,7 @@ export function formatPrice(amount, currency) {
 }
 ```
 
-The contract here is: given an amount and a currency code, return a formatted price string. Good tests for this function would cover:
+这里的约定是：给定金额和货币代码，返回格式化的价格字符串。针对此函数的良好测试应涵盖：
 
 ```js [formatPrice.test.js]
 import { expect, test } from 'vitest'
@@ -54,50 +54,50 @@ test('rounds to two decimal places', () => {
 })
 ```
 
-Notice what these tests *don't* do. They don't check which internal `Intl.NumberFormat` options were passed, or whether an intermediate variable was set. They only check the output.
+请注意这些测试 _不做什么_。它们不检查传递了哪些内部的 `Intl.NumberFormat` 选项，或者是否设置了中间变量。它们只检查输出。
 
 ::: tip
-A good rule of thumb: if someone refactors the internals but the output stays the same, should the test break? If it would, you're probably testing implementation details rather than behavior.
+一个好的做法：如果有人重构了内部实现但输出保持不变，测试应该失败吗？如果会失败，那么你很可能是在测试实现细节而非行为。
 :::
 
-## Structuring a Test
+## 测试结构 {#structuring-a-test}
 
-Most tests follow a natural three-part structure, sometimes called "Arrange, Act, Assert":
+大多数测试遵循一个自然的三段式结构，有时被称为“准备、执行、断言”：
 
-1. **Set up** the data your test needs
-2. **Call** the function or perform the action you're testing
-3. **Check** that the result matches your expectations
+1. **初始化** 测试所需的数据
+2. **调用** 要测试的函数或执行操作
+3. **检查** 结果是否符合预期
 
 ```js
 test('removes an item from the list', () => {
-  // Set up
+  // 初始化
   const list = new ShoppingList()
   list.add('milk')
   list.add('bread')
 
-  // Act
+  // 调用
   list.remove('milk')
 
-  // Check
+  // 检查
   expect(list.getItems()).toEqual(['bread'])
 })
 ```
 
-You don't need comments labeling each section. The structure becomes natural once you've written a few tests. The important thing is keeping each test focused on one behavior.
+你不需要用注释标注每个部分。写过几个测试后，这种结构就会变得很自然。重要的是让每个测试专注于一个行为。
 
-### One Behavior Per Test
+### 每个测试一个行为 {#one-behavior-per-test}
 
-If you find yourself writing "and" in a test name ("formats price and handles errors and logs the result"), that's a sign you should split it into separate tests.
+如果你发现自己在测试名中写 “和”（例如 “格式化价格并处理错误并记录结果”），这表明你应该将其拆分为多个独立的测试。
 
-### Descriptive Names
+### 描述性测试名 {#descriptive-names}
 
-Write test names that describe the behavior, not the implementation. "returns formatted price for USD" is better than "calls Intl.NumberFormat with correct options". When a test fails, the name should tell you what broke without having to read the test body.
+编写描述行为而非实现的测试名。“返回 USD 的格式化价格” 比 “使用正确选项调用 Intl.NumberFormat” 更好。当测试失败时，名称应该能告诉你哪里出了问题，而无需阅读测试体。
 
-## Testing Edge Cases
+## 测试边界情况 {#testing-edge-cases}
 
-After covering the main behavior, think about the boundaries. What happens at the edges? What inputs are unusual but valid? What should happen when things go wrong?
+覆盖主要行为后，考虑边界情况。在边界处会发生什么？哪些输入不常见但有效？出错时应该发生什么？
 
-Here's an example with a `parseAge` function that takes user input and returns a number:
+以下是一个 `parseAge` 函数的示例，它接收用户输入并返回一个数字：
 
 ```js [parseAge.js]
 export function parseAge(input) {
@@ -109,7 +109,7 @@ export function parseAge(input) {
 }
 ```
 
-The happy path is straightforward, but the edge cases are where bugs hide:
+主要流程是显而易见的，但边界情况才是真正隐藏错误的地方：
 
 ```js [parseAge.test.js]
 import { expect, test } from 'vitest'
@@ -148,49 +148,49 @@ test('throws for empty string', () => {
 })
 ```
 
-You don't need to test every possible input. Focus on the boundaries (0, 150, 151, -1), the error paths, and the types of inputs your function might realistically receive.
+你不需要测试所有可能的输入。重点关注边界值（0、150、151、-1）、错误路径，以及你的函数可能实际接收到的输入类型。
 
 ::: tip
-If you're unsure whether an edge case matters, ask yourself: could a real user or a real caller trigger this? If yes, test it.
+如果你不确定某个边界情况是否重要，可以问自己一句：真实用户或真实调用方是否可能触发它？如果答案是肯定的，那就应该为它编写测试。
 :::
 
-### Property-Based Testing
+### 基于属性的测试 {#property-based-testing}
 
-For functions with a wide range of valid inputs, manually choosing edge cases can only go so far. **Property-based testing** is a technique where you describe the *properties* that should hold for any input, and the testing framework generates hundreds of random inputs to try to find one that breaks.
+对于那些有效输入范围很广的函数，手动挑选边界情况终究是有限的。**基于属性的测试** 是一种技术，你描述任何输入都应该成立的 _属性_，测试框架会生成数百个随机输入，尝试找到破坏这些属性的情况。
 
-For example, you might say "for any valid age string, `parseAge` should return a non-negative integer" and let the tool find the counterexample. [fast-check](https://fast-check.dev/) is a popular property-based testing library that integrates well with Vitest. It's an advanced technique, but worth knowing about as your testing needs grow.
+例如，你可以描述 “对于任何有效的年龄字符串，`parseAge` 都应返回一个非负整数”，然后让工具寻找反例。[fast-check](https://fast-check.dev/) 是一款流行的基于属性测试库，并且能很好地与 Vitest 集成。这是一种更进阶的技术，但随着你的测试需求增长，它非常值得了解。
 
-## When to Mock
+## 何时使用模拟 {#when-to-mock}
 
-Mocking is a powerful tool, but it's easy to overuse.
+模拟是一个强大的工具，但很容易被过度使用。
 
-### Slow Dependencies
+### 慢速依赖项 {#slow-dependencies}
 
-Network requests, file system operations, and database calls can make your tests take seconds instead of milliseconds. Replace them with mocks to keep the feedback loop fast.
+网络请求、文件系统操作和数据库调用可能使你的测试需要数秒而非毫秒完成。使用模拟替换它们以保持快速反馈循环。
 
-For HTTP requests specifically, consider using [Mock Service Worker](https://mswjs.io/) instead of mocking fetch directly. See the [Mocking Requests](/guide/mocking/requests) guide for setup instructions.
+特别是对于 HTTP 请求，考虑使用 [Mock Service Worker](https://mswjs.io/) 而不是直接模拟 fetch。有关设置说明，请参阅 [模拟请求](/guide/mocking/requests)。
 
-### Non-Deterministic Values
+### 非确定性值 {#non-deterministic-values}
 
-If your code depends on the current date, a random number, or a UUID generator, mock those to make your tests predictable. Vitest provides [`vi.useFakeTimers()`](/api/vi#vi-usefaketimers) and [`vi.setSystemTime()`](/api/vi#vi-setsystemtime) for controlling time in tests.
+如果你的代码依赖于当前日期、随机数或 UUID 生成器，模拟这些值以使测试可预测。Vitest 提供了 [`vi.useFakeTimers()`](/api/vi#vi-usefaketimers) 和 [`vi.setSystemTime()`](/api/vi#vi-setsystemtime) 用于在测试中控制时间。
 
-### What Not to Mock
+### 不应模拟的内容 {#what-not-to-mock}
 
-Don't mock the thing you're testing. If you're testing a `UserService`, don't mock the `UserService`. Mock its *dependencies* (the database, the email sender) and let the service itself run for real.
+不要模拟你正在测试的对象。如果你正在测试 `UserService`，不要模拟 `UserService`。模拟它的 _依赖项_（数据库、邮件发送器）并让服务本身真实运行。
 
-Also, prefer real implementations when they're fast and reliable. If a dependency is a simple in-memory data structure or a pure function, there's no reason to mock it. The closer your tests are to real usage, the more confidence they give you.
+此外，当真实实现快速且可靠时，应优先使用真实实现。如果依赖项是简单的内存数据结构或纯函数，则没有理由模拟它。你的测试越接近真实使用场景，它们给你的底气就越足。
 
 ::: tip
-Only reach for mocks when the real thing is slow, flaky, or has side effects you can't control in a test.
+仅当真实对象速度慢、不稳定或具有你无法在测试中控制的副作用时，才使用模拟。
 :::
 
-## Fixing Bugs with Tests
+## 通过测试修复错误 {#fixing-bugs-with-tests}
 
-When you find a bug, it's tempting to jump straight into the code and fix it. A better approach is to write a failing test first that reproduces the bug, then fix the code and watch the test turn green.
+当你发现一个 bug 时，很容易直接跳入代码并修复它。更好的方法是先编写一个能重现该 bug 的失败用例，然后修复代码并观察测试变为通过状态。
 
-This has several benefits. The test proves the bug is real and not just a misunderstanding. It documents exactly what was broken. And it prevents the same bug from coming back later, because the test will catch it if someone accidentally reintroduces the same problem.
+这样做有几个好处。测试证明了错误是真实存在的，而不仅仅是误解。它准确记录了哪里出了问题。并且它防止了同一错误以后再次出现，因为如果有人不小心重新引入了相同问题，测试会捕获它。
 
-Here's what this looks like in practice. Suppose users report that `parseAge` crashes when given a string with leading spaces like `" 25"`. First, write a test that reproduces the problem:
+以下是实际操作的示例。假设用户报告 `parseAge` 在接收带有前导空格的字符串（如 `" 25"`）时崩溃。首先，编写一个重现问题的测试：
 
 ```js
 test('handles leading spaces', () => {
@@ -198,7 +198,7 @@ test('handles leading spaces', () => {
 })
 ```
 
-Run it and confirm it fails. Now you know exactly what's broken and have a clear target. Fix the implementation:
+运行它并确认失败。现在你确切知道哪里出了问题，并有了明确的目标。修复实现：
 
 ```js
 export function parseAge(input) {
@@ -207,19 +207,19 @@ export function parseAge(input) {
 }
 ```
 
-Run the test again. It passes. The bug is fixed, and you have a regression test that will catch it if someone removes the `.trim()` call later.
+再次运行测试。它通过了。bug 已修复，并且你有了一个回归测试，如果以后有人移除 `.trim()` 调用，它将捕获该 bug。
 
 ::: tip
-If you use AI agents to fix bugs, configure them to follow the same principle: reproduce the issue with a failing test first, then fix the code. This prevents the agent from "fixing" a bug by changing the test instead of the code, and gives you confidence that the fix actually works.
+如果你使用智能体来修复错误，请配置它们遵循相同原则：先用失败测试重现问题，然后修复代码。这可以防止智能体通过更改测试而非代码来 “修复” bug，并让你确信修复确实有效。
 :::
 
-## Organizing Test Files
+## 组织测试文件 {#organizing-test-files}
 
-There's no single right way to organize tests, but some patterns scale better than others.
+没有唯一正确的组织测试方式，但某些形式比其他形式更具扩展性。
 
-### File Layout
+### 文件布局 {#file-layout}
 
-The simplest starting point is one test file per source file. For every `utils.js`, there's a `utils.test.js` right next to it. This makes it easy to find the tests for any given piece of code, and most editors will show them side by side in the file tree:
+最简单的起点是为每个源文件创建一个测试文件。对于每个 `utils.js`，旁边都有一个 `utils.test.js`。这使得查找任何给定代码的测试变得容易，并且大多数编辑器会在文件树中并排显示它们：
 
 ```
 src/
@@ -229,11 +229,11 @@ src/
   formatPrice.test.js
 ```
 
-Some teams prefer a separate `__tests__` or `test` directory instead. Either approach works. The important thing is consistency across the project. Vitest's [`include`](/config/include) pattern matches both layouts by default.
+有些团队更喜欢使用单独的 `__tests__` 或 `test` 目录。两种方法都有效。重要的是项目内的一致性。Vitest 的 [`include`](/config/include) 默认匹配这两种布局。
 
-### Grouping with `describe`
+### 使用 `describe` 进行分组 {#grouping-with-describe}
 
-When a module exports multiple functions, use `describe` blocks to group the tests for each one. This keeps the test output organized and makes it clear which function a failing test belongs to:
+当一个模块导出多个函数时，使用 `describe` 块来分组每个函数的测试。这使测试输出保持有序，并清楚表明失败测试属于哪个函数：
 
 ```js
 describe('formatPrice', () => {
@@ -247,21 +247,21 @@ describe('parseAmount', () => {
 })
 ```
 
-Avoid nesting `describe` blocks more than one or two levels deep. Deeply nested test trees are hard to read and usually mean the source module is doing too many things at once.
+避免嵌套 `describe` 块超过一或两层深度。深度嵌套的测试树难以阅读，通常意味着源模块一次做了太多事情。
 
-### Splitting Large Files
+### 拆分大文件 {#splitting-large-files}
 
-As a project grows, some test files will inevitably get long. If a test file grows beyond a few hundred lines, consider splitting it by theme or feature area. For example, `userService.test.js` might become `userService.creation.test.js` and `userService.auth.test.js`. This also makes it faster to run a subset of tests during development.
+随着项目增长，一些测试文件不可避免地会变得很长。如果一个测试文件超过几百行，考虑按主题或功能区域拆分它。例如，`userService.test.js` 可能变成 `userService.creation.test.js` 和 `userService.auth.test.js`。这也使得在开发过程中运行测试子集更快。
 
-### Naming Tests
+### 命名测试 {#naming-tests}
 
-Test names matter more than you might expect. When a test fails in CI, the name is often the first thing someone reads. Names like "works correctly" or "handles edge case" don't tell you what broke.
+测试名称比你想象的更重要。当测试在 CI 中失败时，名称往往是有人阅读的第一件事。像 “正常工作” 或 “处理边界情况” 这样的名称无法告诉你哪里出了问题。
 
-Prefer names that describe the specific behavior: "returns 0 for an empty cart", "throws if the email format is invalid", "preserves existing items when adding a new one". The test output should read like a specification of what the module does.
+优先使用描述特定行为的名称：“空购物车返回 0”、“电子邮件格式无效时抛出错误”、“添加新项目时保留现有项目”。测试输出应该像模块功能的规范说明一样可读。
 
-## A Worked Example
+## 完整示例 {#a-worked-example}
 
-Let's put it all together. Here's a small `TodoList` module:
+让我们把所有内容整合起来。以下是一个小的 `TodoList` 模块：
 
 ```js [todoList.js]
 let nextId = 1
@@ -306,16 +306,16 @@ export function createTodoList() {
 }
 ```
 
-Looking at this code, we can identify the behaviors to test:
+查看这段代码，我们可以识别出需要测试的行为：
 
-- Adding items (the main purpose)
-- Adding empty items (should fail)
-- Removing items by ID
-- Removing items that don't exist (should fail)
-- Toggling completion status
-- Getting all items vs. completed items
+- 添加项目（主要目的）
+- 添加空项目（应该失败）
+- 按 ID 移除项目
+- 移除不存在的项目（应该失败）
+- 切换完成状态
+- 获取所有项目与已完成项目
 
-Here's how the test file might look:
+以下是测试文件可能的样子：
 
 ```js [todoList.test.js]
 import { describe, expect, test } from 'vitest'
@@ -425,16 +425,16 @@ describe('getCompleted', () => {
 })
 ```
 
-Each `describe` block focuses on one method. Each test verifies one specific behavior. The test names read like a specification of what the module does. And if any of these tests fail, the name and the assertion will tell you exactly what broke.
+每个 `describe` 块专注于一个方法。每个测试验证一个特定的行为。测试名称读起来就像模块功能的规范说明。如果其中任何一个测试失败，名称和断言会准确告诉你哪里出了问题。
 
 ::: tip
-Notice that we create a fresh `createTodoList()` in every test. This keeps tests independent, which means they can run in any order without affecting each other. If you find yourself repeating the same setup in every test, that's a good candidate for [`beforeEach`](/api/hooks#beforeeach) or a [`test.extend`](/guide/test-context#extend-test-context) fixture.
+注意我们在每个测试中都创建一个新的 `createTodoList()`。这保持了测试的独立性，意味着它们可以按任意顺序运行而不会相互影响。如果你发现自己在每个测试中重复相同的设置，那可能是使用 [`beforeEach`](/api/hooks#beforeeach) 或 [`test.extend`](/guide/test-context#extend-test-context) fixture 的好时机。
 :::
 
-::: details What about `nextId`?
-The `nextId` counter at the top of the module is shared across all calls to `createTodoList()`, including across tests. This means IDs aren't predictable: one test might get IDs 1 and 2, while another gets 3 and 4 depending on execution order. This works fine here because the tests only check *relative* uniqueness (`first.id !== second.id`), not specific ID values. If a test asserted `expect(todo.id).toBe(1)`, it would break depending on which tests ran before it. When you have shared module-level state like this, make sure your tests don't depend on its specific value.
+::: details `nextId` 怎么办？
+模块顶部的 `nextId` 计数器在所有对 `createTodoList()` 的调用中共享，包括跨测试。这意味着 ID 不可预测：一个测试可能获得 ID 1 和 2，而另一个测试获得 3 和 4，具体取决于执行顺序。这在这里没问题，因为测试只检查 _相对_ 唯一性（`first.id !== second.id`），而不是特定的 ID 值。如果测试断言了 `expect(todo.id).toBe(1)`，那么根据之前运行了哪些测试，它可能会失败。当你有像这样的共享模块级状态时，请确保你的测试不依赖于其具体值。
 :::
 
 ---
 
-If you're building a web application and want to test components in a real browser environment, check out [Component Testing](/guide/browser/component-testing) for testing React, Vue, Svelte, and other UI frameworks.
+如果你正在构建 Web 应用程序，并希望在真实的浏览器环境中测试组件，请查看 [组件测试](/guide/browser/component-testing)，了解如何测试 React、Vue、Svelte 和其他 UI 框架。
diff --git a/guide/learn/writing-tests-with-ai.md b/guide/learn/writing-tests-with-ai.md
index ae3c59f4..c36a93e4 100644
--- a/guide/learn/writing-tests-with-ai.md
+++ b/guide/learn/writing-tests-with-ai.md
@@ -1,73 +1,73 @@
 ---
-title: Writing Tests with AI | Guide
+title: 使用 AI 编写测试 | 指南
 prev:
-  text: Debugging Tests
+  text: 调试测试
   link: /guide/learn/debugging-tests
 next:
-  text: Why Browser Mode
+  text: 什么是浏览器模式？
   link: /guide/browser/why
 ---
 
-# Writing Tests with AI
+# 使用 AI 编写测试 {#writing-tests-with-ai}
 
-AI coding assistants can help you write tests faster, but the quality of the output depends heavily on what you put in. A vague prompt produces vague tests. A specific prompt with the right context produces tests that are actually worth keeping.
+AI 编码助手能帮助你更快地编写测试，但输出质量很大程度上取决于你的输入。模糊的提示词会产生模糊的测试。提供正确上下文的具体提示词才能生成真正值得保留的测试。
 
-This page covers how to get good test code from AI tools, and what to watch for when reviewing the results.
+本章将介绍如何从 AI 工具生成优质的测试代码，以及在审查结果时需要关注哪些要点。
 
-## Providing Context
+## 提供足够的上下文 {#providing-context}
 
-The single most important thing you can do is give the AI enough context to understand what it's testing.
+你能做的最重要的一件事，就是给 AI 提供足够的上下文，让它理解自己正在测试什么。
 
-Start with the source file itself. The AI needs to see the actual implementation, not just a description of what the function does. Include the full file, or at least the function you want tested along with its imports and types.
+首先从源码本身开始。AI 需要看到具体的实现，而不仅仅是函数功能的描述。提供完整文件，或者至少提供你想测试的函数，以及它相关的导入和类型定义。
 
-Share existing test files from the same project. This helps the AI match your conventions: whether you use `test` or `it`, how you structure `describe` blocks, whether you prefer `test.extend` fixtures or `beforeEach`, and how you name your tests. AI tools are good at pattern matching, but they need patterns to match against.
+共享同一项目中现有的测试文件。这有助于 AI 遵循你的约定：是使用 `test` 还是 `it`、如何组织 `describe` 块、是更偏好使用 `test.extend` 的 fixture，还是 `beforeEach`，以及如何命名测试。AI 工具擅长遵循约定，但它们需要有可遵循的约定。
 
-Include your Vitest config, especially if you've enabled [`globals`](/config/globals), set a custom [`environment`](/config/environment), or configured [`setupFiles`](/config/setupfiles). Without this context, the AI might generate unnecessary imports, use the wrong test environment, or miss setup that your tests depend on.
+提供你的 Vitest 配置，特别是如果你启用了 [`globals`](/config/globals)、设置了自定义 [`environment`](/config/environment) 或配置了 [`setupFiles`](/config/setupfiles)。没有这些上下文，AI 可能会生成不必要的导入、使用错误的测试环境，或者遗漏测试依赖的初始化。
 
-If the code under test has dependencies that need mocking, share those files too (or at least their type signatures). The AI can't write a useful mock for a database client it's never seen.
+如果被测试的代码有需要模拟的依赖项，也要共享这些文件（或至少它们的类型签名）。AI 无法为它从未见过的数据库客户端编写有效的模拟。
 
 ::: tip
-If your project has an `AGENTS.md` or similar file with coding conventions, include that as well. Many AI tools pick up on these automatically and will follow the rules defined there.
+如果你的项目有 `AGENTS.md` 或包含编码约定的类似文件，也提供进去。许多 AI 工具会自动识别这些文件并遵循其中定义的约定。
 :::
 
-## Writing Good Prompts
+## 编写优质提示词 {#writing-good-prompts}
 
-Specific prompts produce better tests than generic ones. Compare these two:
+具体的提示词比泛泛的提示词能生成更好的测试。比较以下两个示例：
 
-**Vague:** "Write tests for `userService.js`"
+**模糊提示词:**“为 `userService.js` 编写测试”
 
-This will produce tests, but they'll likely be shallow: one happy-path test per function, minimal edge case coverage, and generic test names.
+这很可能会生成很粗略的测试：每个函数一个成功路径测试，边缘情况覆盖最少，测试名称也很通用。
 
-**Better:** "Write tests for the `createUser` function in `userService.js`. Cover validation errors (missing name, invalid email format, duplicate email), the successful creation path, and verify that the password is hashed before being stored."
+**优质提示词:**“为 `userService.js` 中的 `createUser` 函数编写测试。覆盖验证错误（缺失姓名、无效邮箱格式、重复邮箱）、成功创建路径，并验证密码在存储前是否经过哈希处理。”
 
-This tells the AI exactly which function to focus on, which scenarios matter, and what behavior to verify. The output will be more thorough and more relevant.
+这明确告诉 AI 要关注哪个函数、哪些场景重要、需要验证什么行为。输出结果会更全面、更有关联性。
 
-### Tips for Better Prompts
+### 编写优质提示词的技巧 {#tips-for-better-prompts}
 
-- Ask for edge cases explicitly. "Include tests for empty inputs, boundary values, and error handling" produces more comprehensive coverage than leaving it to the AI's judgment. Without this nudge, most tools will generate a handful of happy-path tests and stop there.
-- Mention specific Vitest features if you want them used. "Use `toMatchInlineSnapshot` for the error messages" or "use `test.each` for the different currency formats" guides the AI toward the right tools instead of letting it fall back to repetitive copy-paste tests.
-- If you're testing async code, say so. "The function returns a Promise" or "this calls an external API" helps the AI use `async`/`await` and appropriate matchers like `.resolves` and `.rejects`.
-- Tell the AI what *not* to do. "Test against the real implementation, don't mock any modules" or "don't use snapshot tests" prevents common defaults you don't want. AI tools tend to over-mock, and an explicit constraint prevents that.
-- Describe the test structure you want. "Group tests by method using `describe` blocks" or "use `test.extend` fixtures for the database connection instead of `beforeEach`" saves you from restructuring the output afterwards.
-- Reference existing tests when asking for additions. "Follow the same style as the tests in `auth.test.js`" is more effective than describing the style from scratch. The AI will pick up on naming conventions, assertion patterns, and import styles from the example.
-- If the first result isn't right, iterate. "These tests are too focused on implementation details. Rewrite them to only assert on the return values and thrown errors" is a valid follow-up. Refining through conversation often produces better results than trying to write the perfect prompt upfront.
+- 明确要求边缘情况测试。“包含对空输入、边界值和错误处理的测试” 比让 AI 自行判断能产生更全面的覆盖。没有这个提示，大多数工具只会生成少量成功路径测试就停止。
+- 提及你希望使用的特定 Vitest 功能。“使用 `toMatchInlineSnapshot` 处理错误信息” 或 “使用 `test.each` 处理不同的货币格式”，引导 AI 使用正确的工具，而不是让它退回到重复的复制粘贴测试。
+- 如果测试异步代码，请明确说明。“该函数返回 Promise” 或 “这会调用外部 API” 有助于 AI 使用 `async`/`await` 和合适的匹配器，如 `.resolves` 和 `.rejects`。
+- 告诉 AI _不要做_ 什么。“针对真实实现进行测试，不要模拟任何模块” 或 “不要使用快照测试”，可以避免你不想要的常见默认设置。AI 工具倾向于过度模拟，明确的约束可以防止这种情况。
+- 描述你想要的测试结构。“使用 `describe` 块按方法分组测试” 或 “对数据库连接使用 `test.extend` fixture 而不是 `beforeEach`”，可以省去你事后重构的麻烦。
+- 在要求添加测试时参考现有测试。“遵循 `auth.test.js` 中测试的相同风格” 比从头描述风格更有效。AI 会从示例中学习命名约定、断言形式和导入风格。
+- 如果第一次结果不理想，请迭代优化。“这些测试过于关注实现细节。重写它们，只对返回值和抛出的错误进行断言” 是一个有效的后续提示。通过对话逐步完善通常比试图一次性写出完美提示词能产生更好的结果。
 
-## Reviewing AI-Generated Tests
+## 审查 AI 生成的测试 {#reviewing-ai-generated-tests}
 
-AI-generated tests can look convincing at first glance but still have problems. Here's what to check before committing them.
+AI 生成的测试乍一看可能很令人信服，但仍然存在问题。在提交之前，请检查以下内容。
 
-### Do the tests actually assert something meaningful?
+### 测试是否真正断言了有意义的内容？ {#do-the-tests-actually-assert-something-meaningful}
 
-Watch for tests that call a function but only check that it doesn't throw, or tests that assert on the mock itself rather than the behavior. A test like this gives false confidence:
+注意那些调用函数但只检查它是否没有抛出异常的测试，或者断言模拟对象本身而不是行为的测试。这样的测试会给你虚假的信心：
 
 ```js
 test('creates a user', () => {
   const user = createUser('Alice', 'alice@example.com')
-  expect(user).toBeDefined() // this passes for almost anything
+  expect(user).toBeDefined() // 这对几乎所有情况都会通过
 })
 ```
 
-A better assertion checks the actual properties:
+更好的做法是断言实际属性：
 
 ```js
 test('creates a user with the correct fields', () => {
@@ -80,58 +80,58 @@ test('creates a user with the correct fields', () => {
 })
 ```
 
-### Are they testing behavior or implementation?
+### 它们是在测试行为还是具体实现？ {#are-they-testing-behavior-or-implementation}
 
-AI tends to over-mock. If you see a test that mocks every dependency and then asserts that specific internal methods were called in a specific order, that's testing implementation details. These tests break every time you refactor, even if the behavior stays the same.
+AI 倾向于过度模拟。如果你看到一个测试模拟了每个依赖项，然后断言特定的内部方法以特定顺序被调用，那是在测试实现细节。即使行为保持不变，这些测试在你每次重构时都会失败。
 
-Ask yourself: if someone changed the internals but the function still returned the correct result, would this test break? If yes, it's probably too coupled to the implementation. See [Testing in Practice](/guide/learn/testing-in-practice#what-to-test) for more on this distinction.
+问问自己：如果有人改变了内部实现但函数仍然返回正确结果，这个测试会失败吗？如果答案是肯定的，那它可能过于耦合到实现细节了。关于这个区别的更多信息，请参阅 [测试实践](/guide/learn/testing-in-practice#what-to-test)。
 
-### Do the tests actually run?
+### 测试真的能运行吗？ {#do-the-tests-actually-run}
 
-Always run the tests before committing. AI-generated tests can have import errors, reference functions that don't exist, or use APIs incorrectly. A test that looks correct in a chat window might fail immediately when you actually execute it:
+在提交之前，一定要运行测试。AI 生成的测试可能存在导入错误、引用不存在的函数或 API 使用不当的问题。在聊天窗口中看起来正确的测试，在实际执行时可能立即失败：
 
 ```bash
 vitest run src/userService.test.js
 ```
 
-### Are there real edge cases?
+### 是否包含真正的边缘情况？ {#are-there-real-edge-cases}
 
-AI tools tend to generate happy-path tests and skip the hard cases. After reviewing the generated tests, ask yourself: what happens with empty input? What about `null` or `undefined`? What if the network request fails? What if the list is empty?
+AI 工具往往倾向于生成 “理想路径” 的测试，而跳过那些棘手的情况。在审查生成的测试后，问问自己：空输入会发生什么？输入 `null` 或 `undefined` 呢？网络请求失败怎么办？列表为空的情况呢？
 
-If these scenarios aren't covered, ask the AI to add them, or write them yourself.
+如果这些场景没有被覆盖，请要求 AI 添加这些情况，或者自己手动编写。
 
-## Iterating on the Output
+## 迭代优化输出 {#iterating-on-the-output}
 
-Treat AI-generated tests as a first draft, not a finished product. A good workflow looks like:
+将 AI 生成的测试视为初稿，而非成品。一个良好的工作流程如下：
 
-1. **Generate** the initial tests with a specific prompt and good context
-2. **Run** them immediately to catch errors
-3. **Review** each test for the issues described above
-4. **Ask for revisions** if entire sections need improvement ("these tests mock too much, rewrite them to test the actual integration with the database module")
-5. **Edit manually** for small fixes rather than re-prompting for every detail
+1. 使用具体的提示词和良好的上下文 **生成** 初版测试
+2. 立即 **运行** 测试以发现错误
+3. 针对上述问题 **审查** 每个测试
+4. 如果整个部分需要改进，**提出修改建议**（“这些测试模拟过多，重写它们以测试与数据库模块的实际集成”）
+5. 对于小修改进行 **手动编辑**，而不是为每个细节重新写提示词
 
-Over time, as the AI sees more of your codebase and test patterns, its output will improve. The earlier tests in your project set the pattern for everything that follows, so it's worth getting those right.
+随着时间的推移，当 AI 看到更多你的代码库和测试范例后，其输出质量会提高。在项目中早期，值得花时间为后续所有测试内容设定好约定。
 
-## Common Pitfalls
+## 常见陷阱 {#common-pitfalls}
 
-### Wrong APIs
+### 错误的 API {#wrong-apis}
 
-The most frequent issue with AI-generated Vitest tests is using the wrong API surface. AI models are trained on a lot of Jest code, so they sometimes generate `jest.fn()` instead of `vi.fn()`, or `jest.mock` instead of `vi.mock`. These will fail immediately.
+AI 生成的 Vitest 测试最常见的问题是使用了错误的 API。AI 模型基于大量 Jest 代码进行训练，因此有时会生成 `jest.fn()` 而不是 `vi.fn()`，或者 `jest.mock` 而不是 `vi.mock`。这些会立即失败。
 
-A related problem is imports: if your config has `globals: true`, the AI might still add `import { test, expect } from 'vitest'` (harmless but unnecessary), or the reverse, generating tests without imports when globals aren't enabled. If you keep seeing Jest APIs, point the AI to the [Vitest API reference](/api/vi) or include it in the context.
+导入相关问题：如果你的配置有 `globals: true`，AI 可能仍然会添加 `import { test, expect } from 'vitest'`（无害但没必要），或者反过来，在全局变量未启用时生成没有导入语句。如果你一直看到 Jest API，请引导 AI 查看 [Vitest API](/api/vi) 或将其包含在上下文中。
 
-### Mock Cleanup
+### 模拟清理 {#mock-cleanup}
 
-AI-generated tests often set up spies with `vi.spyOn` or replace modules with `vi.mock` but never restore them. If your config doesn't have [`restoreMocks: true`](/config/restoremocks), these mocks leak between tests and cause confusing failures. The easiest fix is enabling that config option globally.
+AI 生成的测试经常使用 `vi.spyOn` 设置 spy 或使用 `vi.mock` 替换模块，但从不恢复它们。如果你的配置没有设置 [`restoreMocks: true`](/config/restoremocks)，这些模拟会在测试之间泄漏并导致难以理解的失败。最简单的修复方法是在全局启用该配置选项。
 
-On a related note, AI tools tend to mock modules using string paths (`vi.mock('./module.js')`) when the `import()` form (`vi.mock(import('./module.js'))`) is preferable for type safety and automatic refactoring. See [Mock Functions](/guide/learn/mock-functions#mocking-modules) for why this matters.
+相关说明：AI 工具倾向于使用字符串路径（`vi.mock('./module.js')`）来模拟模块，而 `import()` 形式（`vi.mock(import('./module.js'))`）更受青睐，因为它提供类型安全和自动重构。请参阅 [模拟函数](/guide/learn/mock-functions#mocking-modules) 了解为什么这么重要。
 
-### Verbose Test Names
+### 冗长的测试名称 {#verbose-test-names}
 
-AI tends to produce names like "should correctly return the formatted price string when given a valid positive number and a supported currency code." These are hard to scan when you have dozens of tests. Shorter names that describe the behavior work better: "formats USD prices", "throws for negative amounts", "returns empty array when no items match."
+AI 倾向于生成像 “当给定有效的正数和支持的货币代码时，应正确返回格式化的价格字符串” 这样的名称。当你有几十个测试时，这些名称很难快速浏览。描述行为的简短名称效果更好：“格式化美元价格”、“对负数金额抛出错误”、“无匹配项时返回空数组”。
 
-### Watch Mode
+### 监视 (Watch) 模式 {#watch-mode}
 
-Vitest runs in watch mode by default, waiting for file changes and re-running tests interactively. Vitest tries to detect CI and non-interactive or agent environments and disable watch mode automatically, but this detection can be fragile.
+Vitest 默认在 watch 模式下运行，等待文件更改并交互式地重新运行测试。Vitest 尝试检测 CI 和非交互或 Agent 环境并自动禁用监视模式，但这种检测机制可能不够可靠。
 
-When telling an AI agent to run tests, always use `vitest run` or `vitest --no-watch` to ensure the process exits after the tests finish.
+当告诉智能体运行测试时，始终使用 `vitest run` 或 `vitest --no-watch` 以确保测试完成后进程退出。
diff --git a/guide/learn/writing-tests.md b/guide/learn/writing-tests.md
index 0eeca074..e579ada4 100644
--- a/guide/learn/writing-tests.md
+++ b/guide/learn/writing-tests.md
@@ -1,20 +1,20 @@
 ---
-title: Writing Tests | Guide
+title: 编写测试用例 | 指南
 prev:
-  text: Getting Started
+  text: 快速起步
   link: /guide/
 next:
-  text: Using Matchers
+  text: 使用匹配器
   link: /guide/learn/matchers
 ---
-<!-- TODO: translation -->
-# Writing Tests
 
-In the [Getting Started](/guide/) guide, you installed Vitest and ran your first test. This page dives deeper into how to write and organize tests in Vitest.
+# 编写测试 {#writing-tests}
 
-## Your First Test
+在 [入门指南](/guide/) 中，你安装了 Vitest 并运行了第一个测试。本章将深入探讨如何在 Vitest 中编写和组织测试。
 
-A test verifies that a piece of code produces the expected result. In Vitest, you use the [`test`](/api/test) function to define a test, and [`expect`](/api/expect) to make assertions. Each test has a name (a string describing what it checks) and a function that contains one or more assertions. If any assertion fails, the test fails.
+## 你的第一个测试 {#your-first-test}
+
+测试用于验证某段代码是否产生预期结果。在 Vitest 中，你使用 [`test`](/api/test) 函数来定义测试，使用 [`expect`](/api/expect) 来进行断言。每个测试都有一个名称（描述其检查内容的字符串）和一个包含一个或多个断言的函数。如果任何断言失败，则该测试失败。
 
 ```js
 import { expect, test } from 'vitest'
@@ -26,8 +26,8 @@ test('Math.sqrt works for perfect squares', () => {
 })
 ```
 
-::: details Use `test` or `it`?
-You might also see tests written with [`it`](/api/test) instead of `test`. They behave identically. `it` is just an alias that some people prefer because it reads more naturally with a descriptive name:
+::: details 使用 `test` 还是 `it`？
+你可能也会看到使用 [`it`](/api/test) 而非 `test` 编写的测试。它们的行为完全相同。`it` 只是一个别名，有些人更喜欢它，因为它在配合描述性名称时读起来更自然：
 
 ```js
 import { expect, it } from 'vitest'
@@ -37,12 +37,12 @@ it('should compute square roots', () => {
 })
 ```
 
-Use whichever you prefer. Both work the same way, and you can mix them freely in a project. If you want to enforce a consistent choice across your codebase, the [`consistent-test-it`](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/consistent-test-it.md) ESLint rule (also available in [oxlint](https://oxc.rs/docs/guide/usage/linter/rules/jest/consistent-test-it.html)) can help with that.
+两者的工作方式相同，使用你喜欢的那个。你可以在项目中自由混合使用它们。如果你想在代码库中强制执行一致的选择，[`consistent-test-it`](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/consistent-test-it.md) ESLint 规则（在 [oxlint](https://oxc.rs/docs/guide/usage/linter/rules/jest/consistent-test-it.html) 中也可用）可以提供帮助。
 :::
 
-## Grouping Tests with `describe`
+## 使用 `describe` 分组测试 {#grouping-tests-with-describe}
 
-As your test files grow, you'll want to organize related tests together. [`describe`](/api/describe) creates a test suite, which is a named group of tests:
+随着测试文件的增长，你会希望将相关的测试组织在一起。[`describe`](/api/describe) 创建一个测试套件，这是一个命名的测试组：
 
 ```js
 import { describe, expect, test } from 'vitest'
@@ -63,32 +63,32 @@ describe('Math.sqrt', () => {
 })
 ```
 
-You can nest `describe` blocks for further organization, but keep nesting shallow. Deeply nested tests are harder to read. A flat list of tests is often enough for simple modules, and `describe` becomes more useful when a file tests multiple functions or methods that each need their own group.
+你可以嵌套 `describe` 块以进一步组织，但请保持嵌套层次较浅。深层嵌套的测试更难阅读。对于简单模块，一个扁平的测试列表通常就足够了，`describe` 适用于当文件测试多个函数或方法且每个都需要自己的分组。
 
-## Test Files
+## 测试文件 {#test-files}
 
-By default, Vitest looks for any file that contains `.test.` or `.spec.` in its name, such as `utils.test.js`, `app.spec.js`, or `math.test.jsx`. It searches in all subdirectories, so it doesn't matter where you place them.
+默认情况下，Vitest 会查找文件名中包含 `.test.` 或 `.spec.` 的任何文件，例如 `utils.test.js`、`app.spec.js` 或 `math.test.jsx`。它会在所有子目录中搜索，因此你将它们放在哪里并不重要。
 
-The exact patterns are:
+确切的匹配规则是：
 
 - `**/*.test.{ts,js,mjs,cjs,tsx,jsx}`
 - `**/*.spec.{ts,js,mjs,cjs,tsx,jsx}`
 
-There's no single "right" way to organize your test files. Some teams prefer placing tests right next to the source code they test, while others keep them in a dedicated directory. Vitest will find them either way:
+组织测试文件没有单一的 “正确” 方法。有些团队喜欢将测试放在它们所测试的源代码旁边，而另一些团队则将它们保存在一个专用目录中。这两种方式 Vitest 都能找到：
 
 ```
 src/
   utils.js
-  utils.test.js       # co-located with the source
+  utils.test.js       # 与源代码放在一起
   __tests__/
-    utils.test.js      # in a test directory
+    utils.test.js     # 在测试目录中
 ```
 
-If the default patterns don't work for your project, you can customize which files are included with the [`include`](/config/include) and [`exclude`](/config/exclude) config options.
+如果默认匹配规则不适合你的项目，你可以使用 [`include`](/config/include) 和 [`exclude`](/config/exclude) 配置选项来自定义包含哪些文件。
 
-## Testing TypeScript
+## 测试 TypeScript {#testing-typescript}
 
-Because Vitest runs on top of Vite, TypeScript works out of the box. There's no extra compiler to install, no `ts-jest` to configure, and no separate build step for your tests. Just name your test file `.test.ts` instead of `.test.js` and start writing:
+由于 Vitest 构建于 Vite 之上，TypeScript 可以开箱即用。无需安装额外的编译器，无需配置 `ts-jest`，也无需为测试进行单独的构建步骤。只需将测试文件命名为 `.test.ts` 而不是 `.test.js`，然后开始编写：
 
 ```ts
 import { expect, test } from 'vitest'
@@ -110,59 +110,59 @@ test('creates a user with the correct fields', () => {
 })
 ```
 
-You can import your production types, use generics, and write typed test utilities exactly as you would in the rest of your codebase. Vite transforms TypeScript on the fly, so tests start fast even in large projects.
+你可以像在代码库的其他部分一样，导入类型、使用泛型并编写类型化的测试工具。Vite 会即时转换 TypeScript，即使在大型项目中测试也能快速启动。
 
 ::: tip
-Vitest transforms TypeScript for execution but does **not** type-check your tests during the test run. This is the same trade-off Vite makes for speed: you get fast feedback in the terminal, and run `tsc` or `vitest typecheck` separately when you want full type checking. See the [Testing Types](/guide/testing-types) guide for more details.
+Vitest 会转换 TypeScript 以供执行，但在测试运行期间 **不会** 对你的测试进行类型检查。你在终端中能够快速获得反馈，这是 Vite 为速度所做的权衡。当你需要完整的类型检查时，可以单独运行 `tsc` 或 `vitest typecheck`。更多详情请参阅 [测试类型](/guide/testing-types) 指南。
 :::
 
-## Reading Test Output
+## 阅读测试输出 {#reading-test-output}
 
-When you run `vitest` and only a single test file matches, the output is expanded into a tree structure showing `describe` groups and individual tests along with their duration:
+当你运行 `vitest` 且只有一个测试文件匹配时，输出会以树状结构展开显示，显示 `describe` 分组、各个测试及其耗时：
 
 <<< ./snippets/test-output-single.ansi
 
-When multiple test files run, Vitest collapses each file into a single line to keep the output manageable:
+当多个测试文件运行时，Vitest 会将每个文件折叠为单行，以保持输出可控：
 
 <<< ./snippets/test-output-multiple.ansi
 
-When a test fails, Vitest shows you exactly what went wrong. You'll see the expected value, the actual value, a diff highlighting the difference, and a code snippet of the surrounding lines with the failing assertion highlighted. It also includes the file and line number so you can jump straight to the source:
+当测试失败时，Vitest 会准确地告诉你问题出在哪里。你将看到期望值、实际值、突出显示差异的差异对比，以及包含失败断言的周围行代码片段。它还包括文件和行号，以便你可以直接跳转到源代码：
 
 <<< ./snippets/test-output-fail.ansi
 
-Between the diff and the code snippet, you can usually understand what went wrong without needing to add extra `console.log` statements or open the file yourself.
+通过差异对比和代码片段，你通常就能看出问题出在哪里，而无需添加额外的 `console.log` 语句或自己打开文件。
 
-## Skipping and Focusing Tests
+## 跳过和聚焦测试 {#skipping-and-focusing-tests}
 
-While developing, you'll often want to run only a subset of tests. Vitest provides modifiers for this:
+在开发过程中，你通常只想运行一部分测试。Vitest 为此提供了修饰符：
 
-[`.only`](/api/test#only) tells Vitest to run only this test (or suite) and skip everything else in the file. This is useful when you're working on a specific test and don't want to wait for the entire suite to finish:
+[`.only`](/api/test#only) 告诉 Vitest 只运行此测试（或套件），并跳过文件中的所有其他测试。适用于正在处理特定测试并且不想等待整个套件完成的场景：
 
 ```js
 test.only('focus on this test', () => {
-  // only this test runs in the file
+  // 文件中只运行此测试
 })
 ```
 
-[`.skip`](/api/test#skip) does the opposite. It skips a test without removing it, which is handy when a test is temporarily broken or you want to ignore it while you work on something else:
+[`.skip`](/api/test#skip) 则相反。它跳过一个测试而不删除它，适用于测试暂时损坏或你在处理其他事情时想要忽略它的场景：
 
 ```js
 test.skip('not ready yet', () => {
-  // this test is skipped
+  // 此测试被跳过
 })
 ```
 
-[`.todo`](/api/test#todo) lets you mark a placeholder for a test you haven't written yet. Vitest will list it in the output so you won't forget about it:
+[`.todo`](/api/test#todo) 让你为尚未编写的测试标记一个占位符。Vitest 会在输出中列出它，这样你就不会忘记：
 
 ```js
 test.todo('implement validation later')
 ```
 
-These modifiers are great for quick, local changes while developing. For more permanent ways to filter tests (by filename, line number, or tags), see the [Test Filtering](/guide/filtering) guide.
+这些修饰符非常适合开发过程中的快速本地更改。对于更永久的测试过滤方式（按文件名、行号或标签），请参阅 [测试过滤](/guide/filtering) 指南。
 
-## Parameterized Tests
+## 参数化测试 {#parameterized-tests}
 
-When you have several test cases that only differ in their inputs and expected outputs, writing a separate `test` for each one gets repetitive. [`test.for`](/api/test#test-for) lets you define the cases as data and run the same test logic for all of them:
+当你有多个测试用例，仅输入和预期输出不同时，为每个用例编写单独的 `test` 会显得重复。[`test.for`](/api/test#test-for) 允许你将用例定义为数据，并为所有用例运行相同的测试逻辑：
 
 ```js
 import { expect, test } from 'vitest'
@@ -176,9 +176,9 @@ test.for([
 })
 ```
 
-The placeholders `%i`, `%s`, and `%f` in the test name are replaced with the corresponding values from each row, so the output shows `add(1, 1) -> 2`, `add(1, 2) -> 3`, and so on.
+测试名称中的占位符 `%i`、`%s` 和 `%f` 会被每行中对应的值替换，因此输出会显示 `add(1, 1) -> 2`、`add(1, 2) -> 3` 等。
 
-If your cases have more than two or three values, passing objects is more readable. Use `$property` in the name to interpolate fields:
+如果你的用例包含两个或三个以上的值，传递对象更具可读性。在名称中使用 `$property` 来插入字段：
 
 ```js
 test.for([
@@ -190,7 +190,7 @@ test.for([
 })
 ```
 
-The second argument to the test function is the [Test Context](/guide/test-context), which gives you access to fixtures, per-test `expect`, and other utilities. This is especially useful with [`test.concurrent`](/api/test#concurrent), where concurrent tests run in parallel and the global `expect` can't reliably associate a snapshot with the right test. The context-scoped `expect` solves this:
+测试函数的第二个参数是 [测试上下文](/guide/test-context)，它让你可以访问 fixtures、每个测试的 `expect` 和其他工具函数。[`test.concurrent`](/api/test#concurrent) 适用于并发测试，因为并发测试会并行运行，而全局的 `expect` 无法可靠地将快照与正确的测试关联起来。上下文作用域的 `expect` 正好解决了这个问题：
 
 ```js
 test.concurrent.for([
@@ -202,15 +202,15 @@ test.concurrent.for([
 })
 ```
 
-[`describe.for`](/api/describe#describe-for) works the same way but creates a suite for each set of parameters, which is useful when multiple tests share the same parameterized setup.
+[`describe.for`](/api/describe#describe-for) 的工作方式相同，但会为每组参数创建一个套件。适用于多个测试共享相同的参数化设置。
 
 ::: tip
-Vitest also provides [`test.each`](/api/test#each), which you may recognize from Jest. It works similarly but spreads array arguments instead of passing them as a single value, and doesn't provide access to the Test Context. It exists mainly for Jest compatibility. Prefer `test.for` in new code.
+Vitest 还提供了 [`test.each`](/api/test#each)，熟悉 Jest 的用户可能会认出它。它的工作方式类似，但会将数组参数展开传递，而不是作为单个值传递，并且不提供对测试上下文的访问。它主要为了与 Jest 兼容而存在。在新代码中，建议优先使用 `test.for`。
 :::
 
-## Using Global Imports
+## 使用全局导入 {#using-global-imports}
 
-By default, you import `test`, `expect`, `describe`, and other functions from `vitest` at the top of every test file. If you'd rather use them as globals without importing (similar to how Jest works), you can enable the [`globals`](/config/globals) option in your config:
+默认情况下，你需要在每个测试文件的顶部从 `vitest` 导入 `test`、`expect`、`describe` 和其他函数。如果你希望将它们作为全局变量使用而无需导入（类似于 Jest 的工作方式），可以在配置中启用 [`globals`](/config/globals) 选项：
 
 ```js [vitest.config.js]
 import { defineConfig } from 'vitest/config'
@@ -222,7 +222,7 @@ export default defineConfig({
 })
 ```
 
-With this enabled, you can write tests without the import line:
+启用此选项后，你可以在没有导入的情况下直接编写测试：
 
 ```js
 test('no import needed', () => {
@@ -231,11 +231,11 @@ test('no import needed', () => {
 ```
 
 ::: tip
-If you use TypeScript, add `"types": ["vitest/globals"]` to your `tsconfig.json` `compilerOptions` for proper type support.
+如果你使用 TypeScript，请在 `tsconfig.json` 的 `compilerOptions` 中添加 `"types": ["vitest/globals"]` 以获得正确的类型支持。
 :::
 
-## Running Tests
+## 运行测试 {#running-tests}
 
-Vitest runs all test files **in parallel** by default, using [child processes](/config/pool). Each test file runs in its own isolated context, so your test files don't share state with each other. This prevents tests in different files from accidentally interfering.
+Vitest 默认使用 [子进程](/config/pool) **并行** 运行所有测试文件。每个测试文件都在其独立的上下文中运行，因此你的测试文件不会彼此共享状态。这可以防止不同文件中的测试意外相互干扰。
 
-Tests **within** a single file run sequentially by default, which is usually what you want since tests in the same file often share setup code. If your tests are truly independent, you can opt into running them concurrently with [`test.concurrent`](/api/test#concurrent) to speed things up. See the [Parallelism](/guide/parallelism) guide for more details on controlling test execution.
+同一个文件内的测试默认按顺序运行。由于同一文件中的测试往往共享初始化代码，这种按顺序执行通常是合理的。如果你的测试是真正独立的，你可以选择使用 [`test.concurrent`](/api/test#concurrent) 并发运行它们以加快速度。有关控制测试执行的更多详情，请参阅 [并行性](/guide/parallelism) 指南。
diff --git a/guide/snapshot.md b/guide/snapshot.md
index b990e4a9..c4352b09 100644
--- a/guide/snapshot.md
+++ b/guide/snapshot.md
@@ -123,12 +123,12 @@ test('button looks correct', async () => {
 ```
 
 它会捕获屏幕截图并与参考图像进行比较，以检测意外的视觉变化。在 [视觉回归测试指南](/guide/browser/visual-regression-testing)中了解更多内容。
-<!-- TODO: translation -->
-## ARIA Snapshots <Badge type="warning">experimental</Badge> <Version>4.1.4</Version>
 
-ARIA snapshots capture the accessibility tree of a DOM element and compare it against a stored template. Based on [Playwright's ARIA snapshots](https://playwright.dev/docs/aria-snapshots), they provide a semantic alternative to visual regression testing — asserting structure and meaning rather than pixels.
+## ARIA 快照 <Badge type="warning">实验性</Badge> <Version>4.1.4</Version> {#aria-snapshots}
 
-For example, given this HTML:
+ARIA 快照会捕获 DOM 元素的无障碍访问树，并与存储的模板进行比对。基于 [Playwright 的 ARIA 快照](https://playwright.dev/docs/aria-snapshots) 实现，它提供了视觉回归测试之外的语义化替代方案，断言结构和含义而非像素。
+
+例如，以下 HTML：
 
 ```html
 <nav aria-label="Main">
@@ -137,7 +137,7 @@ For example, given this HTML:
 </nav>
 ```
 
-You can assert its accessibility tree:
+你可以断言其无障碍访问树结构：
 
 ```ts
 import { expect, test } from 'vitest'
@@ -154,7 +154,7 @@ test('navigation structure', async () => {
 })
 ```
 
-See the dedicated [ARIA Snapshots guide](/guide/browser/aria-snapshots) for syntax details, retry behavior in Browser Mode, and file vs. inline snapshot examples. See [`toMatchAriaSnapshot`](/api/expect#tomatcharisnapshot) and [`toMatchAriaInlineSnapshot`](/api/expect#tomatchariainlinesnapshot) for the full API reference.
+语法细节、浏览器模式下的重试行为以及文件快照与内联快照的对比示例，请参阅专门的 [ARIA 快照指南](/guide/browser/aria-snapshots)。完整 API 请参阅 [`toMatchAriaSnapshot`](/api/expect#tomatcharisnapshot) 和 [`toMatchAriaInlineSnapshot`](/api/expect#tomatchariainlinesnapshot)。
 
 ## 自定义序列化器 {#custom-serializer}
 
@@ -175,10 +175,11 @@ expect.addSnapshotSerializer({
     )}`
   },
   test(val) {
-    return val && Object.prototype.hasOwnProperty.call(val, 'foo')
+    return val && Object.hasOwn(val, 'foo')
   },
 })
 ```
+
 我们还支持 [snapshotSerializers](/config/snapshotserializers) 选项，可以隐式添加自定义序列化器。
 
 ```ts [path/to/custom-serializer.ts]
@@ -192,7 +193,7 @@ export default {
   test(val) {
     return val && Object.prototype.hasOwnProperty.call(val, 'foo')
   },
-} satisfies SnapshotSerializer
+} satisfies SnapshotSerializ:er
 ```
 
 ```ts [vitest.config.ts]
@@ -228,10 +229,10 @@ Pretty foo: Object {
   "y": 2,
 }
 ```
-<!-- TODO: translation -->
-## Custom Snapshot Matchers <Badge type="warning">experimental</Badge> <Version>4.1.3</Version> {#custom-snapshot-matchers}
 
-You can build custom snapshot matchers using the composable functions exposed on `Snapshots` from `vitest`. These let you transform values before snapshotting while preserving full snapshot lifecycle support (creation, update, inline rewriting).
+## 自定义快照匹配器 <Badge type="warning">实验性</Badge> <Version>4.1.3</Version> {#custom-snapshot-matchers}
+
+可通过 `vitest` 提供的 `Snapshots` 组合式函数构建自定义快照匹配器。这些函数允许你在生成快照前对值进行转换，同时完整保留快照生命周期支持（创建、更新、内联重写）。
 
 ```ts
 import { expect, test, Snapshots } from 'vitest'
@@ -267,7 +268,7 @@ test('raw file snapshot', async () => {
 })
 ```
 
-The composables return `{ pass, message }` so you can further customize the error:
+这些组合式函数会返回 `{ pass, message }` 对象，方便你进一步自定义错误提示：
 
 ```ts
 import { Snapshots } from 'vitest'
@@ -283,24 +284,24 @@ expect.extend({
 ```
 
 ::: warning
-For inline snapshot matchers, the snapshot argument must be the last parameter (or second-to-last when using property matchers). Vitest rewrites the last string argument in the source code, so custom arguments before the snapshot work, but custom arguments after it are not supported.
+对于内联快照匹配器，快照参数必须是最后一个参数（使用属性匹配器时则为倒数第二个）。Vitest 会重写源代码中的最后一个字符串参数，因此快照前的自定义参数有效，但不支持快照后的自定义参数。
 :::
 
 ::: tip
-File snapshot matchers must be `async` — `toMatchFileSnapshot` returns a `Promise`. Remember to `await` the result in the matcher and in your test.
+文件快照匹配器必须是 `async` 的 — `toMatchFileSnapshot` 会返回一个 `Promise`。请确保在匹配器和测试中都使用 `await` 处理返回结果。
 :::
 
 ::: warning
-When custom inline snapshot matcher is aynchronous, Vitest cannot automatically infer the call location for inline snapshot rewriting. You must capture the call site by setting the `'error'` flag on the chai assertion object:
+当自定义内联快照匹配器为异步时，Vitest 无法自动推断内联快照重写的调用位置。你必须通过在 chai 断言对象上设置 `'error'` 标志来捕获调用点：
 
 ```ts
-import { expect, chai, Snapshots } from 'vitest'
+import { chai, expect, Snapshots } from 'vitest'
 
 const { toMatchInlineSnapshot } = Snapshots
 
 expect.extend({
   async toMatchTransformedInlineSnapshot(received: string, inlineSnapshot?: string) {
-    // capture call site synchronously at the top of matcher implementation
+    // 在匹配器实现顶部同步捕获调用点
     chai.util.flag(this.assertion, 'error', new Error())
     const transformed = await transform(received)
     return toMatchInlineSnapshot.call(this, transformed, inlineSnapshot)
@@ -310,7 +311,7 @@ expect.extend({
 
 :::
 
-For TypeScript, extend the `Assertion` interface:
+对于 TypeScript，需扩展 `Assertion` 接口：
 
 ```ts
 import 'vitest'
@@ -325,16 +326,16 @@ declare module 'vitest' {
 ```
 
 ::: tip
-See [Extending Matchers](/guide/extending-matchers) for more on `expect.extend` and custom matcher conventions.
+更多关于 `expect.extend` 和自定义匹配器约定的内容，请参阅 [扩展匹配器](/guide/extending-matchers)。
 :::
-<!-- TODO: translation -->
-## Custom Snapshot Domain <Badge type="warning">experimental</Badge> <Version>4.1.4</Version> {#custom-snapshot-domain}
 
-Custom serializers control how values are _rendered_ into snapshot strings, but comparison is still string equality. A **domain snapshot adapter** goes further: it owns the entire comparison pipeline for a custom matcher, including how to capture a value, render it, parse a stored snapshot, and match them semantically.
+## 自定义领域快照 <Badge type="warning">experimental</Badge> <Version>4.1.4</Version> {#custom-snapshot-domain}
+
+自定义序列化器控制值如何被 **渲染** 成快照字符串，但比较过程仍然基于字符串相等。**领域快照适配器** 则更进一步：它拥有自定义匹配器的整个比较流水线，包括如何捕获值、渲染值、解析存储的快照，以及如何对它们进行语义匹配。
 
-### The adapter interface
+### 适配器接口 {#the-adapter-interface}
 
-A domain adapter implements four methods and is generic over two types — `Captured` (what the value actually is) and `Expected` (what the stored snapshot parses into):
+领域适配器需实现四个方法和两个泛型 - `Captured`（值的实际类型）和 `Expected`（存储的快照解析后的类型）：
 
 ```ts
 import type { DomainMatchResult, DomainSnapshotAdapter } from 'vitest'
@@ -342,46 +343,46 @@ import type { DomainMatchResult, DomainSnapshotAdapter } from 'vitest'
 const myAdapter: DomainSnapshotAdapter<Captured, Expected> = {
   name: 'my-domain',
 
-  // Extract structured data from the received value
+  // 从接收值中提取结构化数据
   capture(received: unknown): Captured { /* ... */ },
 
-  // Render captured data as the snapshot string (what gets stored)
+  // 将捕获的数据渲染为快照字符串（即存储的内容）
   render(captured: Captured): string { /* ... */ },
 
-  // Parse a stored snapshot string into a structured expected value
+  // 将存储的快照字符串解析为结构化的期望值
   parseExpected(input: string): Expected { /* ... */ },
 
-  // Compare captured vs expected, return pass/fail and resolved output
+  // 比较捕获值与期望值，返回通过 / 失败结果及解析后的输出
   match(captured: Captured, expected: Expected): DomainMatchResult { /* ... */ },
 }
 ```
 
 #### `DomainMatchResult`
 
-The `match` method returns a `DomainMatchResult` with two optional string fields beyond `pass`:
+`match` 方法返回一个 `DomainMatchResult`，除了 `pass` 之外还有两个可选的字符串字段：
 
-- **`resolved`** — the captured value viewed through the template's lens. Where the template uses patterns (e.g. regexes) or omits details, the resolved string adopts those patterns. Where the template doesn't match, it uses literal captured values. This serves as both the actual side of diffs and the value written on `--update`. When omitted, falls back to `render(capture(received))`.
+- **`resolved`** — 通过模板视角观察到的捕获值。当模板使用匹配模式（例如正则表达式）或省略细节时，解析字符串会采用这些匹配模式。模板未匹配到的地方，则使用字面量的捕获值。这既用作差异对比的实际一侧，也是在执行 `--update` 时写入的值。如果省略，则回退到 `render(capture(received))`。
 
-- **`expected`** — the stored template re-rendered as a string. Used as the expected side of diffs. When omitted, falls back to the raw snapshot string from the snap file or inline snapshot.
+- **`expected`** — 将存储的模板重新渲染为字符串。用作差异对比的期望一侧。如果省略，则回退到快照文件或内联快照中的原始快照字符串。
 
-:::details Why are `Captured` and `Expected` separate types?
+:::details 为什么 `Captured` 和 `Expected` 是单独的类型？
 
-When a snapshot is first generated, `render(captured)` produces a plain string that gets stored. But once stored, the user can **hand-edit** it — replacing literals with regex patterns, relaxing assertions, or adding domain-specific query syntax. After editing, `parseExpected(input)` parses this modified string into a type that is _richer_ than what `capture` produces.
+首次生成快照时，`render(captured)` 会生成一个纯字符串并存储起来。但一旦存储后，用户可以 **手动编辑** 它。用正则表达式模式替换字面值、放宽断言或添加特定领域的查询语法。编辑后，`parseExpected(input)` 将这个修改后的字符串解析成一种比 `capture` 生成的类型 _更丰富_ 的类型。
 
-For example, in the [key-value adapter](#example-key-value-adapter) below, `Captured` values are always `string`, but `Expected` values can be `string | RegExp`:
+例如，在下面的 [键值适配器](#example-key-value-adapter) 中，`Captured` 值始终是 `string`，但 `Expected` 值可以是 `string | RegExp`：
 
 ```ts
 type KVCaptured = Record<string, string>
 type KVExpected = Record<string, string | RegExp>
 ```
 
-This asymmetry is what makes `--update` work correctly: `match` returns a `resolved` string that updates changed literal parts while **preserving** the user's hand-edited patterns. If both sides were the same type, there would be no way to distinguish "what the value actually is" from "what the user chose to assert" — and every update would overwrite the user's patterns.
+这种不对称性正是 `--update` 能正确工作的原因：`match` 返回一个 `resolved` 字符串，它在更新变化的字面部分的同时 **保留** 了用户手动编辑的模式。如果双方是同一类型，就无法区分 “值的实际内容” 和 “用户选择断言的内容”，每次更新都会覆盖用户的匹配模式。
 
 :::
 
-### Build a matcher from the adapter
+### 从适配器构建匹配器 {#build-a-matcher-from-the-adapte}
 
-Register a custom matcher with `expect.extend(...)` and call the snapshot composables from `vitest`:
+使用 `expect.extend(...)` 注册自定义匹配器，并从 `vitest` 调用快照组合函数：
 
 ```ts [setup.ts]
 import { expect, Snaphsots } from 'vitest'
@@ -401,16 +402,16 @@ expect.extend({
 })
 ```
 
-Then use your matcher in tests:
+然后在测试中使用你的匹配器：
 
 ```ts
 expect(value).toMatchMyDomainSnapshot()
 expect(value).toMatchMyDomainInlineSnapshot(`key=value`)
 ```
 
-### Example: key-value adapter
+### 示例：键值适配器 {#example-key-value-adapter}
 
-A minimal adapter that stores objects as `key=value` lines, with regex pattern and subset key match support ([full source](https://github.com/vitest-dev/vitest/blob/main/test/snapshots/test/fixtures/domain/basic.ts)):
+一个最小化的适配器，将对象存储为 `key=value` 行，支持正则表达式匹配和子集键匹配（[完整源码](https://github.com/vitest-dev/vitest/blob/main/test/snapshots/test/fixtures/domain/basic.ts)）：
 
 ```ts [kv-adapter.ts]
 import type { DomainMatchResult, DomainSnapshotAdapter } from 'vitest'
@@ -458,12 +459,12 @@ export const kvAdapter: DomainSnapshotAdapter<KVCaptured, KVExpected> = {
     for (const [key, actualValue] of Object.entries(captured)) {
       const expectedValue = expected[key]
 
-      // non-asserted keys are skipped (works as subset match)
+      // 未断言键会被跳过（实现子集匹配）
       if (typeof expectedValue === 'undefined') {
         continue
       }
 
-      // preserve matched pattern for normalized diff and partial update
+      // 保留匹配模式用于标准化差异比较和局部更新
       if (expectedValue instanceof RegExp && expectedValue.test(actualValue)) {
         resolvedLines.push(`${key}=/${expectedValue.source}/`)
         continue
@@ -518,7 +519,7 @@ test('user data inline', () => {
 
 Vitest 提供了与 [Jest](https://jestjs.io/docs/snapshot-testing) 几乎兼容的快照功能，除少数例外:
 
-#### 1. 快照文件中的注释标头不同 {#_1-comment-header-in-the-snapshot-file-is-different}
+### 1. 快照文件中的注释标头不同 {#_1-comment-header-in-the-snapshot-file-is-different}
 
 ```diff
 - // Jest Snapshot v1, https://goo.gl/fbAQLP
@@ -527,7 +528,7 @@ Vitest 提供了与 [Jest](https://jestjs.io/docs/snapshot-testing) 几乎兼容
 
 这实际上不会影响功能，但在从 Jest 迁移时可能会影响提交差异。
 
-#### 2. `printBasicPrototype` 默认为 `false` {#_2-printbasicprototype-is-default-to-false}
+### 2. `printBasicPrototype` 默认为 `false` {#_2-printbasicprototype-is-default-to-false}
 
 Jest 和 Vitest的快照功能均基于 `pretty-format` 实现，但 Vitest 在 [`@vitest/pretty-format`](https://npmx.dev/package/@vitest/pretty-format) 基础上应用了自定义的快照默认配置。具体而言，Vitest将 `printBasicPrototype` 设为 `false` 以生成更简洁的快照输出，而 Jest 29.0.0 以下版本默认将该值设为 `true`。
 
@@ -575,7 +576,7 @@ export default defineConfig({
 })
 ```
 
-#### 3. 使用 V 形 `>` 而非冒号 `:` 作为自定义消息的分隔符 {#_3-chevron-is-used-as-a-separator-instead-of-colon-for-custom-messages}
+### 3. 使用 V 形 `>` 而非冒号 `:` 作为自定义消息的分隔符 {#_3-chevron-is-used-as-a-separator-instead-of-colon-for-custom-messages}
 
 当创建快照文件期间传递自定义消息时，Vitest 使用 V 形 `>` 作为分隔符而不是冒号 `:` 以提高自定义消息可读性。
 
@@ -601,7 +602,7 @@ exports[`toThrowErrorMatchingSnapshot: hint 1`] = `"error"`;
 exports[`toThrowErrorMatchingSnapshot > hint 1`] = `[Error: error]`;
 ```
 
-#### 4. `toThrowErrorMatchingSnapshot` 和 `toThrowErrorMatchingInlineSnapshot` 的默认 `Error` 快照不同 {#_4-default-error-snapshot-is-different-for-tothrowerrormatchingsnapshot-and-tothrowerrormatchinginlinesnapshot}
+### 4. `toThrowErrorMatchingSnapshot` 和 `toThrowErrorMatchingInlineSnapshot` 的默认 `Error` 快照不同 {#_4-default-error-snapshot-is-different-for-tothrowerrormatchingsnapshot-and-tothrowerrormatchinginlinesnapshot}
 
 ```js
 import { expect, test } from 'vitest'
diff --git a/guide/test-tags.md b/guide/test-tags.md
index 61bf9752..e2b8f87d 100644
--- a/guide/test-tags.md
+++ b/guide/test-tags.md
@@ -9,7 +9,7 @@ outline: deep
 
 ## 定义标签 {#defining-tags}
 
- Vitest 并未提供任何的内置标签，标签必须在配置文件中提前进行定义。如果在测试中使用了未在配置文件中定义的标签，测试运行器将会抛出错误。这一行为可以防止因标签名称拼写错误而导致的意外行为。当然你可以修改 [`strictTags`](/config/stricttags) 选项进行禁用。
+Vitest 并未提供任何的内置标签，标签必须在配置文件中提前进行定义。如果在测试中使用了未在配置文件中定义的标签，测试运行器将会抛出错误。这一行为可以防止因标签名称拼写错误而导致的意外行为。当然你可以修改 [`strictTags`](/config/stricttags) 选项进行禁用。
 
 在标签定义时至少必须包含 `name` 参数，与此同时你还可以定义其他配置参数如 `timeout` 或 `retry`，这些配置参数将应用于使用该标签的所有测试。完整的可用配置参数，参见 [`tags`](/config/tags)。
 
@@ -60,6 +60,7 @@ test('flaky database test', { tags: ['flaky', 'db'] })
 test('flaky database test', { tags: ['flaky', 'db'], timeout: 120_000 })
 // { timeout: 120_000, retry: 3 }
 ```
+
 :::
 
 如果你正在使用 TypeScript，可以扩展 `TestTags` 类型添加一个包含字符串的联合类型来限定的标签可用范围，请确保该文件被包含在 `tsconfig` 中：
@@ -193,6 +194,7 @@ describe('forms', () => {
   })
 })
 ```
+
 :::
 
 ## 按标签筛选用例 {#filtering-tests-by-tag}