diff --git a/docs/zh/guide/advanced/ssr.md b/docs/zh/guide/advanced/ssr.md
index 0ff77af62..4cf4de42c 100644
--- a/docs/zh/guide/advanced/ssr.md
+++ b/docs/zh/guide/advanced/ssr.md
@@ -1,6 +1,6 @@
 # 测试服务端渲染
 
-Vue Test Utils 提供了 `renderToString` 方法，用于测试使用服务器端渲染 (SSR) 的 Vue 应用程序。本指南将带你了解如何测试使用 SSR 的 Vue 应用程序。
+Vue Test Utils 提供了 `renderToString` 方法，用于测试服务器端渲染 (SSR) 的 Vue 应用程序。本指南将带你了解如何测试 SSR 的 Vue 应用程序。
 
 ## `renderToString`
 
diff --git a/docs/zh/guide/advanced/stubs-shallow-mount.md b/docs/zh/guide/advanced/stubs-shallow-mount.md
index cb177f087..f145808ed 100644
--- a/docs/zh/guide/advanced/stubs-shallow-mount.md
+++ b/docs/zh/guide/advanced/stubs-shallow-mount.md
@@ -1,8 +1,8 @@
-# 桩 (Stubs) 与浅层挂载
+# 测试替身 (stub) 与浅挂载
 
-Vue Test Utils 提供了一些高级功能用于*桩*组件和指令。*桩*是指将自定义组件或指令的现有实现替换为一个不执行任何操作的虚拟实现，这可以简化本来复杂的测试。让我们来看一个例子。
+Vue Test Utils 提供了一些高级功能用于为组件和指令*创建测试替身* (stubbing)。*测试替身* (stub) 是指将自定义组件或指令的现有实现替换为一个不执行任何操作的虚拟实现，这可以简化本来复杂的测试。让我们来看一个例子。
 
-## 桩化单个子组件
+## 为单个子组件创建测试替身
 
 一个常见的例子是当你想要测试一个在组件层级中非常高的组件时。
 
@@ -57,9 +57,9 @@ test('stubs component with custom template', () => {
 })
 ```
 
-注意，模板中显示的是 `<span></span>`，而不是 `<fetch-data-from-api />`。我们用一个桩替换了它——在这种情况下，我们通过传入一个 `template` 提供了自己的实现。
+注意，模板中显示的是 `<span></span>`，而不是 `<fetch-data-from-api />`。我们用一个测试替身替换了它，在这种情况下，我们通过传入一个 `template` 提供了自己的实现。
 
-你也可以获取一个默认的桩，而不需要提供自己的实现：
+你也可以获取一个默认的测试替身，而不需要提供自己的实现：
 
 ```js
 test('stubs component', () => {
@@ -81,15 +81,15 @@ test('stubs component', () => {
 })
 ```
 
-这将桩化整个渲染树中的*所有* `<FetchDataFromApi />` 组件，而不管它们出现在哪个层级。这就是为什么它在 `global` 挂载选项中的原因。
+这将为整个渲染树中的*所有* `<FetchDataFromApi />` 组件创建测试替身，而不管它们出现在哪个层级。这就是为什么它在 `global` 挂载选项中的原因。
 
 ::: tip
 要桩化组件，你可以使用 `components` 中的键或组件的名称。如果在 `global.stubs` 中同时给出这两者，将优先使用键。
 :::
 
-## 桩化所有子组件
+## 为所有子组件创建测试替身
 
-有时你可能想要桩化*所有*自定义组件。例如，你可能有这样的组件：
+有时你可能想要为*所有*自定义组件创建测试替身。例如，你可能有这样的组件：
 
 ```js
 const ComplexComponent = {
@@ -103,7 +103,7 @@ const ComplexComponent = {
 }
 ```
 
-想象一下，每个 `<Complex>` 组件都做一些复杂的事情，而你只对测试 `<h1>` 是否渲染正确的问候语感兴趣。你可以这样做：
+想象一下，每个 `<Complex>` 组件都会做一些复杂的事情，而你只对测试 `<h1>` 是否渲染正确的问候语感兴趣。那么你可以这样做：
 
 ```js
 const wrapper = mount(ComplexComponent, {
@@ -117,7 +117,7 @@ const wrapper = mount(ComplexComponent, {
 })
 ```
 
-但这需要很多样板代码。VTU 有一个 `shallow` 挂载选项，可以自动桩化所有子组件：
+但这需要很多样板代码。VTU 有一个 `shallow` 挂载选项，可以自动为所有子组件创建测试替身：
 
 ```js {3}
 test('shallow stubs out all child components', () => {
@@ -136,12 +136,12 @@ test('shallow stubs out all child components', () => {
 ```
 
 ::: tip
-如果你使用的是 VTU V1，你可能记得这个方法叫 `shallowMount`。这个方法仍然可用——它与写 `shallow: true` 是一样的。
+如果你使用的是 VTU V1，你可能记得这个方法叫 `shallowMount`。这个方法仍然可用，它与写 `shallow: true` 是一样的。
 :::
 
-## 桩化所有子组件但有例外
+## 为所有子组件创建测试替身同时接受例外
 
-有时你想要桩化*所有*自定义组件，除了特定的一个。让我们考虑一个例子：
+有时你想要为*所有*自定义组件创建测试替身，但除了特定的一个。让我们考虑一个例子：
 
 ```js
 const ComplexA = {
@@ -159,7 +159,7 @@ const ComplexComponent = {
 }
 ```
 
-通过使用 `shallow` 挂载选项，可以自动桩化所有子组件。如果我们想要明确选择不桩化特定组件，可以在 `stubs` 中提供其名称，值设置为 `false。`
+通过使用 `shallow` 挂载选项，可以自动为所有子组件创建测试替身。如果我们想要明确选择不为某个特定组件创建测试替身，可以在 `stubs` 中提供其名称，值设置为 `false。`
 
 ```js {3}
 test('shallow allows opt-out of stubbing specific component', () => {
@@ -180,9 +180,9 @@ test('shallow allows opt-out of stubbing specific component', () => {
 })
 ```
 
-## 桩化异步组件
+## 为异步组件创建测试替身
 
-如果你想要桩化一个异步组件，则有两种行为。例如，你可能有这样的组件：
+如果你想要为一个异步组件创建测试替身，则有两种做法。例如，你可能有这样的组件：
 
 ```js
 // AsyncComponent.js
@@ -200,8 +200,7 @@ const App = defineComponent({
 })
 ```
 
-第一种行为是使用你在组件中定义的键来加载异步组件。在这个例子中，我们使用了键 “MyComponent”。
-在测试用例中不需要使用 `async/await`，因为组件在解析之前已经被桩化。
+第一种做法是使用你在组件中定义的键来加载异步组件。在这个例子中，我们使用了键 “MyComponent”。在测试用例中不需要使用 `async/await`，因为组件在解析之前已经被创建了测试替身。
 
 ```js
 test('stubs async component without resolving', () => {
@@ -217,8 +216,7 @@ test('stubs async component without resolving', () => {
 })
 ```
 
-第二种行为是使用异步组件的名称。在这个例子中，我们使用了名称 “AsyncComponent”。
-现在需要使用 `async/await`，因为异步组件需要解析，然后才能通过在异步组件中定义的名称进行桩化。
+第二种做法是使用异步组件的名称。在这个例子中，我们使用了名称 “AsyncComponent”。现在需要使用 `async/await`，因为异步组件需要解析，然后才能通过在异步组件中定义的名称创建测试替身。
 
 **确保在异步组件中定义名称！**
 
@@ -238,7 +236,7 @@ test('stubs async component with resolving', async () => {
 })
 ```
 
-## 桩化指令
+## 为指令创建测试替身
 
 有时指令会执行非常复杂的操作，比如进行大量的 DOM 操作，这可能导致测试中的错误 (由于 JSDOM 与整个 DOM 行为不相似)。一个常见的例子是来自各种库的工具提示指令，它们通常严重依赖于测量 DOM 节点的位置/大小。
 
@@ -275,10 +273,10 @@ test('stubs component with custom template', () => {
 ```
 
 ::: tip
-使用 `vCustomDirective` 命名方案来区分组件和指令，灵感来自于[相同方法](https://vuejs.org/api/sfc-script-setup.html#using-custom-directives)在 `<script setup>` 中的使用。
+使用 `vCustomDirective` 命名方案来区分组件和指令，灵感来自于[同一方案](https://vuejs.org/api/sfc-script-setup.html#using-custom-directives)在 `<script setup>` 中的使用。
 :::
 
-有时，我们需要指令功能的一部分 (通常是因为某些代码依赖于它)。假设我们的指令在执行时添加 `with-tooltip` CSS 类，而这对我们的代码是重要的行为。在这种情况下，我们可以用我们的模拟指令实现替换 `true`。
+有时，我们需要指令功能的一部分 (通常是因为某些代码依赖于它)。假设我们的指令在执行时添加 `with-tooltip` CSS 类，而这一行为对于我们的代码至关重要。这时我们可以用模拟指令实现替换 `true`。
 
 ```js
 test('stubs component with custom template', () => {
@@ -307,12 +305,12 @@ test('stubs component with custom template', () => {
 我们刚刚用自己的实现替换了指令的实现！
 
 ::: warning
-桩化指令在功能组件或 `<script setup>` 中不起作用，因为在 [withDirectives](https://vuejs.org/api/render-function.html#withdirectives) 函数中缺少指令名称。如果你需要模拟在功能组件中使用的指令，请考虑通过你的测试框架模拟指令模块。请参见 <https://github.com/vuejs/core/issues/6887> 以解锁此功能。
+为指令创建测试替身在函数式组件或 `<script setup>` 中不起作用，因为在 [withDirectives](https://vuejs.org/api/render-function.html#withdirectives) 函数中缺少指令名称。如果你需要模拟在函数式组件中使用的指令，请考虑通过你的测试框架模拟指令模块。请参见 https://github.com/vuejs/core/issues/6887 以解锁此功能。
 :::
 
 ## 默认插槽和 `shallow`
 
-由于 `shallow` 会桩化组件的所有内容，因此在使用 `shallow` 时，任何 `<slot>` 都不会被渲染。虽然在大多数情况下这不是问题，但在某些场景下这并不理想。
+由于 `shallow` 会为组件的所有内容创建测试替身，因此在使用 `shallow` 时，任何 `<slot>` 都不会被渲染。虽然在大多数情况下这不是问题，但在某些场景下这并不理想。
 
 ```js
 const CustomButton = {
@@ -339,9 +337,9 @@ const App = {
 }
 ```
 
-如果你使用 `shallow`，插槽将不会被渲染，因为 `<custom-button />` 中的渲染函数被桩化了。这意味着你将无法验证是否渲染了正确的文本！
+如果你使用 `shallow`，插槽将不会被渲染，因为我们为 `<custom-button />` 中的渲染函数创建了测试替身。这意味着你将无法验证是否渲染了正确的文本！
 
-对于这种用例，你可以使用 `config.renderStubDefaultSlot`，即使在使用 `shallow` 时也会渲染默认插槽内容：
+这时，你可以使用 `config.renderStubDefaultSlot`，即使在使用 `shallow` 时也会渲染默认插槽内容：
 
 ```js {1,4,8}
 import { config, mount } from '@vue/test-utils'
@@ -366,19 +364,19 @@ test('shallow with stubs', () => {
 })
 ```
 
-由于此行为是全局的，而不是逐个 `mount` 的基础上，你需要记得在每个测试之前和之后启用/禁用它。
+由于此行为是全局的，而不是基于某个 `mount`，你需要记得在每个测试之前和之后启用/禁用它。
 
 ::: tip
-你也可以通过在测试设置文件中导入 `config` 并将 `renderStubDefaultSlot` 设置为 `true` 来全局启用此功能。不幸的是，由于技术限制，此行为不扩展到默认插槽以外的插槽。
+你也可以通过在测试设置文件中导入 `config` 并将 `renderStubDefaultSlot` 设置为 `true` 来全局启用此功能。不幸的是，由于技术限制，此行为无法扩展到非默认插槽。
 :::
 
-## `mount`、`shallow` 和 `stubs`：选择哪个，何时使用？
+## `mount`、`shallow` 和 `stubs`：如何选择？何时使用？
 
-根据经验，**你的测试越像软件的使用方式**，它们就能给你提供越多的信心。
+根据经验，**你的测试越接近软件的真实使用方式**，它们就能给你提供越多的信心。
 
 使用 `mount` 的测试将渲染整个组件层次结构，这与用户在真实浏览器中的体验更接近。
 
-另一方面，使用 `shallow` 的测试则专注于特定组件。`shallow` 对于在完全隔离的情况下测试高级组件非常有用。如果你只有一两个与测试无关的组件，考虑使用 `mount` 结合 `stubs` 而不是 `shallow`。你桩化得越多，测试就越不具备生产环境的特性。
+另一方面，使用 `shallow` 的测试则专注于特定组件。`shallow` 对于在完全隔离的情况下测试高级组件非常有用。如果你只有一两个与测试无关的组件，考虑使用 `mount` 结合 `stubs` 而不是 `shallow`。你创建的测试替身越多，测试就越不具备生产环境的特性。
 
 请记住，无论你选择全挂载还是浅层渲染 (shallow render)，好的测试都应专注于输入 (`props` 和用户交互，如使用 `trigger`) 和输出 (渲染的 DOM 元素和事件)，而不是实现细节。
 
@@ -387,5 +385,5 @@ test('shallow with stubs', () => {
 ## 结论
 
 - 使用 `global.stubs` 将组件或指令替换为虚拟实现，以简化测试
-- 使用 `shallow: true` (或 `shallowMount`) 来桩化所有子组件
-- 使用 `global.renderStubDefaultSlot` 渲染桩化组件的默认 `<slot>`
+- 使用 `shallow: true` (或 `shallowMount`) 为所有子组件创建测试替身
+- 使用 `global.renderStubDefaultSlot` 渲染组件测试替身的默认 `<slot>`
diff --git a/docs/zh/guide/advanced/teleport.md b/docs/zh/guide/advanced/teleport.md
index d492e8aad..1913c436b 100644
--- a/docs/zh/guide/advanced/teleport.md
+++ b/docs/zh/guide/advanced/teleport.md
@@ -1,16 +1,16 @@
 # 测试 Teleport
 
-Vue 3 引入了一个新的内置组件：`<Teleport>`，它允许组件将其内容 “传送” 到其 `<template>` 之外的某处。大多数使用 Vue Test Utils 编写的测试都是针对传递给 `mount` 的组件，这在测试被传送到最初渲染组件之外的组件时引入了一些复杂性。
+Vue 3 新引入了一个内置组件：`<Teleport>`，它允许组件将其内容“传送”到其 `<template>` 之外的某处。大多数使用 Vue Test Utils 编写的测试都是针对传递给 `mount` 的组件，当被测试的组件被传送到最初渲染的组件之外时，就引入了一些复杂性。
 
-以下是一些使用 `<Teleport>` 测试组件的策略和技术。
+以下是一些使用 `<Teleport>` 测试组件的策略和技巧。
 
 ::: tip
-如果你想测试组件的其余部分，而忽略 `teleport`，可以通过在[全局 stubs 选项](../../api/#global-stubs)中传递 `teleport: true` 来 stub `teleport`。
+如果你想测试组件的其余部分，而忽略 `teleport`，可以通过在[全局测试替身选项](../../api/#global-stubs)中传递 `teleport: true` 来创建 `teleport` 的测试替身。
 :::
 
 ## 示例
 
-在这个示例中，我们正在测试一个 `<Navbar>` 组件。它在 `<Teleport>` 中渲染一个 `<Signup>` 组件。`<Teleport>` 的 `target` 属性是位于 `<Navbar>` 组件之外的一个元素。
+在这个示例中，我们会测试一个 `<Navbar>` 组件。它会在 `<Teleport>` 中渲染一个 `<Signup>` 组件。`<Teleport>` 的 `target` 属性是位于 `<Navbar>` 组件之外的一个元素。
 
 这是 `Navbar.vue` 组件：
 
@@ -33,9 +33,9 @@ export default defineComponent({
 </script>
 ```
 
-它简单地将一个 `<Signup>` 传送到其他地方。这对于此示例的目的来说很简单。
+它单纯地将一个 `<Signup>` 传送到其他地方。此示例的目的很简单。
 
-`Signup.vue` 是一个表单，用于验证 `username` 是否大于 8 个字符。如果是，当提交时，它会发出一个 `signup` 事件，并将 `username` 作为有效载荷。测试这个将是我们的目标。
+`Signup.vue` 是一个表单，用于验证 `username` 是否大于 8 个字符。如果是，它在提交时会发出一个 `signup` 事件，并将 `username` 作为有效载荷。我们的目标就是测试这个。
 
 ```vue
 <template>
@@ -110,16 +110,16 @@ test('teleport', async () => {
 
 我们在这个示例中使用 Jest，它不会在每个测试中重置 DOM。因此，在每个测试后使用 `afterEach` 进行清理是一个好主意。
 
-## 与 Teleport 组件交互
+## 与被传送的组件交互
 
-接下来要做的是填写用户名输入。不幸的是，我们无法使用 `wrapper.find('input')`。为什么呢？执行 `console.log(wrapper.html())` 显示给我们以下内容：
+接下来要做的是填写用户名输入。不幸的是，我们无法使用 `wrapper.find('input')`。为什么呢？执行 `console.log(wrapper.html())` 会显示以下内容：
 
 ```html
 <!--teleport start-->
 <!--teleport end-->
 ```
 
-我们看到 Vue 用于处理 `<Teleport>` 的一些注释——但没有 `<input>`。这是因为 `<Signup>` 组件 (及其 HTML) 不再渲染在 `<Navbar>` 内部——它被传送到了外面。
+我们看到了 Vue 用于处理 `<Teleport>` 的一些注释，但没有 `<input>`。这是因为 `<Signup>` 组件 (及其 HTML) 不再渲染在 `<Navbar>` 内部，它被传送到了外面。
 
 尽管实际的 HTML 被传送到外部，但与 `<Navbar>` 相关的虚拟 DOM 仍然保持对原始组件的引用。这意味着你可以使用 `getComponent` 和 `findComponent`，它们在虚拟 DOM 上操作，而不是常规 DOM。
 
@@ -139,9 +139,9 @@ test('teleport', async () => {
 })
 ```
 
-`getComponent` 返回一个 `VueWrapper`。现在你可以使用 `get`、`find` 和 `trigger` 等方法。
+`getComponent` 会返回一个 `VueWrapper`。现在你可以使用 `get`、`find` 和 `trigger` 等方法。
 
-让我们完成测试：
+让我们完成这个测试：
 
 ```ts {4-8}
 test('teleport', async () => {
@@ -187,7 +187,7 @@ test('teleport', async () => {
 })
 ```
 
-你可以通过使用 `teleport: true` 来 stub teleport：
+你可以通过使用 `teleport: true` 来创建 teleport 的测试替身：
 
 ```ts
 import { mount } from '@vue/test-utils'
@@ -207,4 +207,4 @@ test('teleport', async () => {
 ## 结论
 
 - 使用 `document.createElement` 创建一个 teleport 目标。
-- 使用 `getComponent` 或 `findComponent` 查找传送的组件，这些方法在虚拟 DOM 层面上操作
+- 使用 `getComponent` 或 `findComponent` 查找传送的组件，这些方法会在虚拟 DOM 层面上操作。
diff --git a/docs/zh/guide/advanced/vue-router.md b/docs/zh/guide/advanced/vue-router.md
index 921837545..163f4d920 100644
--- a/docs/zh/guide/advanced/vue-router.md
+++ b/docs/zh/guide/advanced/vue-router.md
@@ -1,8 +1,8 @@
 # 测试 Vue Router
 
-本文将介绍两种方法测试使用 Vue Router 的应用程序：
+本文将介绍两种测试带有 Vue Router 的应用的方法：
 
-1. 使用真实的 Vue Router，这种方法更接近生产环境，但在测试较大应用时可能会导致复杂性。
+1. 使用真实的 Vue Router，这种方法更接近生产环境，但测试较大应用时会引入复杂度。
 2. 使用模拟的路由器，允许对测试环境进行更细粒度的控制。
 
 请注意，Vue Test Utils 并未提供任何特殊函数来辅助测试依赖于 Vue Router 的组件。
@@ -11,11 +11,11 @@
 
 使用模拟路由器可以避免在单元测试中关注 Vue Router 的实现细节。
 
-我们可以创建一个仅实现我们感兴趣的功能的模拟版本，而不是使用真实的 Vue Router 实例。可以使用 `jest.mock` (如果你使用 Jest) 和 `global.components` 的组合来实现。
+我们可以创建一个模拟的 Vue Router 实例，仅实现我们感兴趣的功能，而不是使用真实的实例。这可以通过 `jest.mock` (如果你使用 Jest) 和 `global.components` 的组合来实现。
 
-在模拟依赖时，通常是因为**我们不关心测试其行为**。我们不想测试点击 `<router-link>` 是否导航到正确的页面，我们可能更关心的是确保 `<a>` 拥有正确的 `to` 属性。
+在我们模拟一个依赖时，通常是因为**我们不测试它的行为**。我们不想测试点击 `<router-link>` 是否会导航到正确的页面，它显然是会的。我们可能更关心的是确保 `<a>` 拥有正确的 `to` 属性。
 
-让我们来看一个更实际的例子！这个组件展示了一个按钮，当用户经过身份验证时，会将其重定向到编辑帖子页面 (基于当前路由参数)。未经过身份验证的用户则会被重定向到 `/404` 路由。
+让我们来看一个更实际的例子！这个组件展示了一个按钮，当用户通过身份验证时，会将其重定向到编辑帖子的页面 (基于当前路由参数)。未经过身份验证的用户则会被重定向到 `/404` 路由。
 
 ```js
 const Component = {
@@ -33,7 +33,7 @@ const Component = {
 }
 ```
 
-我们可以使用真实的路由器，然后导航到该组件的正确路由，点击按钮后断言正确的页面是否被渲染……然而，对于相对简单的测试来说，这需要很多设置。我们想要编写的测试核心是 “如果经过身份验证，则重定向到 X，否则重定向到 Y”。下面是如何使用 `global.mocks` 属性模拟路由的示例：
+我们可以使用真实的路由器，然后导航到该组件的正确路由，然后点击按钮后断言正确的页面被渲染……然而，对于相对简单的测试来说，这需要很多设置。我们想要编写的测试核心是 “如果经过身份验证，则重定向到 X，否则重定向到 Y”。下面是如何使用 `global.mocks` 属性模拟路由的示例：
 
 ```js
 import { mount } from '@vue/test-utils'
@@ -95,19 +95,19 @@ test('redirect an unauthenticated user to 404', async () => {
 })
 ```
 
-我们使用 `global.mocks` 提供了必要的依赖 (`this.$route` 和 `this.$router`)，为每个测试设置了理想状态。
+我们使用 `global.mocks` 提供了必要的依赖 (`this.$route` 和 `this.$router`)，为每个测试设置了理想的状态。
 
 然后，我们能够使用 `jest.fn()` 监控 `this.$router.push` 被调用的次数和参数。最重要的是，我们不必在测试中处理 Vue Router 的复杂性或注意事项！我们只关注测试应用逻辑。
 
 :::tip
-你可能想以端到端的方式测试整个系统。可以考虑使用 [Cypress](https://www.cypress.io/) 进行使用真实浏览器的完整系统测试。
+你可能想以端到端 (end-to-end) 的方式测试整个系统。可以考虑使用 [Cypress](https://www.cypress.io/) 通过真实浏览器进行完整的系统测试。
 :::
 
 ## 使用真实路由器
 
-现在我们已经看到了如何使用模拟路由器，让我们看看如何使用真实的 Vue Router。
+我们已经看到了如何使用模拟路由器，现在让我们看看如何使用真实的 Vue Router。
 
-我们来创建一个基本的博客应用程序，使用 Vue Router。帖子在 `/posts` 路由上列出：
+我们来创建一个基本的使用 Vue Router 的博客应用程序。帖子会在 `/posts` 路由上列出：
 
 ```js
 const App = {
@@ -134,7 +134,7 @@ const Posts = {
 }
 ```
 
-应用程序显示一个指向 `/posts` 的 `<router-link>`，在该路由下我们列出帖子。
+应用程序根页面会显示一个 `<router-link>` 指向列出帖子的路由 `/posts`。
 
 真实路由器如下所示。请注意，我们将路由单独导出，以便可以为每个单独的测试实例化一个新的路由器。
 
@@ -164,7 +164,7 @@ export { routes }
 export default router
 ```
 
-验证使用 Vue Router 测试应用程序的最佳方法是让警告引导我们。以下最小测试足以让我们开始：
+使用 Vue Router 测试一个应用的最佳展示方法是通过警告引导我们。以下最小化的测试足以让我们起步：
 
 ```js
 import { mount } from '@vue/test-utils'
@@ -175,7 +175,7 @@ test('routing', () => {
 })
 ```
 
-测试失败。它还打印了两个警告：
+这个测试失败了，且它还打印了两个警告：
 
 ```bash
 console.warn node_modules/@vue/runtime-core/dist/runtime-core.cjs.js:39
@@ -185,7 +185,7 @@ console.warn node_modules/@vue/runtime-core/dist/runtime-core.cjs.js:39
   [Vue warn]: Failed to resolve component: router-view
 ```
 
-找不到 `<router-link>` 和 `<router-view>` 组件。我们需要安装 Vue Router！由于 Vue Router 是一个插件，我们使用 `global.plugins` 挂载选项来安装它：
+`<router-link>` 和 `<router-view>` 组件未找到。我们需要安装 Vue Router！由于 Vue Router 是一个插件，我们通过 `global.plugins` 挂载选项来安装它：
 
 ```js {12,13,14}
 import { mount } from '@vue/test-utils'
@@ -207,16 +207,16 @@ test('routing', () => {
 })
 ```
 
-这两个警告现在消失了——但现在我们又有了另一个警告：
+这两个警告现在消失了，但现在我们又有了另一个警告：
 
 ```js
 console.warn node_modules/vue-router/dist/vue-router.cjs.js:225
   [Vue Router warn]: Unexpected error when starting the router: TypeError: Cannot read property '_history' of null
 ```
 
-虽然警告的内容并不完全明确，但它与 Vue Router 4 **处理路由是异步的**有关。
+虽然警告的内容并不完全明确，但它与 **Vue Router 4 异步处理路由**的事实有关。
 
-Vue Router 提供了一个 `isReady` 函数，告诉我们路由器何时准备就绪。然后我们可以 `await` 它，以确保初始导航已发生。
+Vue Router 提供了一个 `isReady` 函数，告诉我们路由器何时准备就绪。然后我们可以 `await` 它，以确保初始导航已生效。
 
 ```js {13,14}
 import { mount } from '@vue/test-utils'
@@ -243,9 +243,9 @@ test('routing', async () => {
 })
 ```
 
-测试现在通过了！这确实需要一些工作，但现在我们确保应用程序正确导航到初始路由。
+测试现在通过了！这确实需要一些工作，但现在我们确保了应用程序正确导航到初始路由。
 
-现在让我们导航到 `/posts`，确保路由按预期工作：
+现在让我们导航到 `/posts` 并确保路由如预期工作：
 
 ```js {21,22}
 import { mount } from '@vue/test-utils'
@@ -284,9 +284,9 @@ console.error node_modules/@vue/runtime-core/dist/runtime-core.cjs.js:211
   TypeError: Cannot read property '_history' of null
 ```
 
-同样，由于 Vue Router 4 的新异步特性，我们需要在进行任何断言之前 `await` 路由完成。
+同样，由于 Vue Router 4 新的异步特性，我们需要在进行任何断言之前 `await` 路由完成。
 
-然而，在这种情况下，我们没有可以等待的 *hasNavigated* 钩子。一种替代方法是使用从 Vue Test Utils 导出的 `flushPromises` 函数：
+然而，在这种情况下，我们没有可以 await 的 *hasNavigated* 钩子。一种替代方法是使用从 Vue Test Utils 导出的 `flushPromises` 函数：
 
 ```js {1,22}
 import { mount, flushPromises } from '@vue/test-utils'
@@ -315,7 +315,7 @@ test('routing', async () => {
 })
 ```
 
-它*终于*通过了。太好了！然而，这一切都非常手动——而且这是针对一个微小且无关紧要的应用程序。这就是在使用 Vue Test Utils 测试 Vue 组件时，使用模拟路由器是一种常见方法的原因。如果你倾向于继续使用真实的路由器，请记住每个测试都应该使用自己实例化的路由器，如下所示：
+它*终于*通过了。太好了！然而，这一切都非常手动，而且这是针对一个微小且无关紧要的应用程序。这就是在为什么使用 Vue Test Utils 测试 Vue 组件时，使用模拟路由器是一种常见方法。如果你倾向于继续使用真实的路由器，请记住每个测试都应该使用自己实例化的路由器，如下所示：
 
 ```js {1,19}
 import { mount, flushPromises } from '@vue/test-utils'
@@ -347,11 +347,11 @@ test('routing', async () => {
 })
 ```
 
-## 在组合式 API 中使用模拟路由器
+## 在模拟路由器中使用组合式 API
 
 Vue Router 4 允许在组合式 API 的 `setup` 函数中使用路由器和路由。
 
-考虑将相同的示例组件重写为组合式 API。
+设想通过组合式 API 重写一个相同的 demo 组件。
 
 ```js
 import { useRouter, useRoute } from 'vue-router'
@@ -378,7 +378,7 @@ const Component = {
 }
 ```
 
-这次为了测试组件，我们将使用 Jest 模拟导入的资源 `vue-router`，并直接模拟路由器和路由。
+这次为了测试该组件，我们将使用 Jest 模拟导入的资源 `vue-router`，并直接模拟路由器和路由。
 
 ```js
 import { useRouter, useRoute } from 'vue-router'
@@ -407,7 +407,7 @@ test('allows authenticated user to edit a post', () => {
       isAuthenticated: true
     },
     global: {
-      stubs: ["router-link", "router-view"], // 为可能在模板中渲染的 router-link 和 router-view 提供 Stubs
+      stubs: ["router-link", "router-view"], // 为可能在模板中渲染的 router-link 和 router-view 提供测试替身
     }
   })
 
@@ -434,7 +434,7 @@ test('redirect an unauthenticated user to 404', () => {
       isAuthenticated: false
     }
     global: {
-      stubs: ["router-link", "router-view"], // 为可能在模板中渲染的 router-link 和 router-view 提供 Stubs
+      stubs: ["router-link", "router-view"], // 为可能在模板中渲染的 router-link 和 router-view 提供测试替身
     }
   })
 
@@ -445,9 +445,9 @@ test('redirect an unauthenticated user to 404', () => {
 })
 ```
 
-## 使用真实路由器与组合式 API
+## 在真实路由器中使用组合式 API
 
-使用真实路由器与组合式 API 的方式与使用选项 API 时相同。请记住，和选项 API 一样，建议为每个测试实例化一个新的路由器对象，而不是直接从应用程序中导入路由器。
+使用真实路由器与组合式 API 的方式与使用选项式 API 时相同。请记住，和选项式 API 一样，我们建议为每个测试实例化一个新的路由器对象，而不是直接从应用程序中导入路由器。
 
 ```js
 import { mount } from '@vue/test-utils'
@@ -490,6 +490,6 @@ test('allows authenticated user to edit a post', async () => {
 
 - 你可以在测试中使用真实的路由器实例。
 - 但是有一些注意事项：Vue Router 4 是异步的，我们需要在编写测试时考虑这一点。
-- 对于更复杂的应用程序，考虑模拟路由器依赖项，专注于测试底层逻辑。
-- 尽可能利用测试运行器的桩 (stub)/模拟功能。
+- 对于更复杂的应用程序，请考虑模拟路由器的依赖项，且专注于测试底层逻辑。
+- 尽可能利用测试运行器的测试替身来模拟功能。
 - 使用 `global.mocks` 来模拟全局依赖项，例如 `this.$route` 和 `this.$router`。