Merge pull request #745 from 984507092/sync-heming

fix: Optimize the multi-level title problem of the test context

Author: thinkasany

guide/environment.md

@@ -2,7 +2,7 @@
 title: 测试环境 | 指南
 ---
 
-# 测试环境
+# 测试环境 {#test-environment}
 
 Vitest 提供 [`environment`](/config/#environment) 选项以在特定环境中运行代码。你可以使用 [`environmentOptions`](/config/#environmentoptions) 选项修改环境的行为方式。
 
@@ -25,7 +25,7 @@ Vitest 提供 [`environment`](/config/#environment) 选项以在特定环境中
 Vitest 并不将 `browser` 视作一种测试环境。如果你想让部分测试在 [浏览器模式](/guide/browser/) 中执行，可以通过创建一个 [测试项目](/guide/browser/#projects-config) 来实现。
 :::
 
-## 特定文件的环境
+## 特定文件的环境 {#environments-for-specific-files}
 
 如果配置中设置 `environment` 选项时，它将应用于项目中的所有测试文件。要获得更细粒度的控制，你可以使用控制注释为特定文件指定环境。控制注释是以 `@vitest-environment` 开头，后跟环境名称的注释：
 
@@ -39,7 +39,7 @@ test('test', () => {
 })
 ```
 
-## 自定义环境
+## 自定义环境 {#custom-environment}
 
 你可以创建自己的包来扩展 Vitest 环境。为此，请创建一个名为 `vitest-environment-${name}` 的包，或者指定一个有效的 JS/TS 文件路径。该包应该导出一个形状为 `Environment` 的对象。
 

guide/in-source.md

@@ -2,13 +2,14 @@
 title: 源码内联测试 | 指南
 ---
 
-# 源码内联测试
+# 源码内联测试 {#in-source}
 
 Vitest 还提供了一种方式，可以运行与你的代码实现放在一起的测试，就像是 [Rust 语言的模块测试一样](https://doc.rust-lang.org/book/ch11-03-test-organization.html#the-tests-module-and-cfgtest)。
 
 这允许测试与实现共享相同的闭包，并且能够在不导出的情况下针对私有状态进行测试。同时，它也使开发更加接近反馈循环。
 
-## 指引
+## 指引 {#setup}
+
 ::: warning
 本指南介绍如何在源代码中编写测试。如果需要在单独的测试文件中编写测试，请参阅["编写测试"指南](/guide/#writing-tests)。
 :::
@@ -50,7 +51,7 @@ export default defineConfig({
 $ npx vitest
 ```
 
-## 生产环境构建
+## 生产环境构建 {#production-build}
 
 对于生产环境的构建，你需要设置配置文件内的 `define` 选项，让打包器清除无用的代码。例如，在 Vite 中
 
@@ -123,7 +124,7 @@ export default {
 
 完整的示例请参考 [`examples/in-source-test`](https://github.com/vitest-dev/vitest/tree/main/examples/in-source-test)。
 
-## 说明
+## 说明 {#notes}
 
 此功能可用于:
 

guide/test-context.md

@@ -3,24 +3,24 @@ title: 测试上下文 | 指南
 outline: deep
 ---
 
-# 测试上下文
+# 测试上下文 {#test-context}
 
 受 [Playwright Fixtures](https://playwright.dev/docs/test-fixtures) 的启发，Vitest 的测试上下文允许你定义可在测试中使用的工具(utils)、状态(states)和固定装置(fixtures)。
 
-## 用法
+## 用法 {#usage}
 
 第一个参数或每个测试回调是一个测试上下文。
 
 ```ts
 import { it } from 'vitest'
 
 it('should work', ({ task }) => {
-  // prints name of the test
+  // prints name of the testusage
   console.log(task.name)
 })
 ```
 
-## 内置测试上下文
+## 内置测试上下文 {#built-in-test-context}
 
 #### `task`
 
@@ -125,7 +125,7 @@ it('stop request when test times out', async ({ signal }) => {
 
 [`onTestFinished`](/api/#ontestfailed) 与当前测试用例绑定。当你并发执行多个测试并希望只对某个特定测试进行特殊处理时，这个 API 会非常有帮助。
 
-## 扩展测试上下文
+## 扩展测试上下文 {#extend-test-context}
 
 Vitest 提供了两种不同的方式来帮助你扩展测试上下文。
 
@@ -191,7 +191,7 @@ export const test = todosTest.extend({
 })
 ```
 
-#### 固定装置初始化
+#### 固定装置初始化 {#default-fixture}
 
 Vitest 运行器将智能地初始化你的固定装置并根据使用情况将它们注入到测试上下文中。
 
@@ -231,7 +231,7 @@ test('context must be destructured', ({ todos }) => { // [!code ++]
 
 :::
 
-#### 自动化装置
+#### 自动化装置 {#automated-fixture}
 
 Vitest 还支持 fixture 的元组语法，允许你传递每个 fixture 的选项。例如，你可以使用它来显式初始化固定装置，即使它没有在测试中使用。
 
@@ -253,7 +253,7 @@ const test = base.extend({
 test('works correctly')
 ```
 
-#### Default fixture
+#### 默认的装置 {#default-fixture}
 
 Since Vitest 3, you can provide different values in different [projects](/guide/projects). To enable this feature, pass down `{ injected: true }` to the options. If the key is not specified in the [project configuration](/config/#provide), then the default value will be used.
 

guide/testing-types.md

@@ -2,7 +2,7 @@
 title: 类型测试 | 指南
 ---
 
-# 类型测试
+# 类型测试 {#testing-types}
 
 ::: tip Sample Project
 
@@ -41,7 +41,7 @@ test('my types work properly', () => {
 
 你可以在 [API 部分](/api/#expecttypeof) 中查看可能的匹配器列表。
 
-## 读取错误
+## 读取错误 {#reading-errors}
 
 如果使用的是 `expectTypeOf` API，请参阅 [expect-type 关于其错误信息的文档](https://github.com/mmkal/expect-type#error-messages)。
 
@@ -122,7 +122,7 @@ assertType<string>(answr)
 
 :::
 
-## 运行类型检查
+## 运行类型检查 {#run-typechecking}
 
 要启用类型检查，只需在 `package.json` 文件中的 Vitest 命令中添加 [`--typecheck`](/config/#typecheck) 标志：