文档贡献指南

欢迎阅读 Next.js 文档贡献指南！我们很高兴您能加入。

本页面提供了如何编辑 Next.js 文档的说明。我们的目标是确保社区中的每个人都能积极贡献并改进我们的文档。

为何贡献？

开源工作永无止境，文档工作亦是如此。贡献文档是初学者参与开源项目的好方法，也是经验丰富的开发者在向社区分享知识的同时澄清复杂主题的途径。

通过贡献 Next.js 文档，您正在帮助我们为所有开发者构建更强大的学习资源。无论您是发现了错别字、令人困惑的章节，还是意识到某个特定主题缺失，我们都欢迎并感谢您的贡献。

如何贡献

文档内容可在 Next.js 仓库中找到。要贡献，您可以直接在 GitHub 上编辑文件，或者克隆仓库并在本地编辑文件。

GitHub 工作流程

如果您不熟悉 GitHub，我们建议您阅读 GitHub 开源指南，了解如何派生仓库、创建分支并提交拉取请求。

须知：底层文档代码存在于一个私有代码库中，该代码库与 Next.js 公共仓库同步。这意味着您无法在本地预览文档。但是，在合并拉取请求后，您将在 nextjs.org 上看到您的更改。

编写 MDX

文档以 MDX 编写，这是一种支持 JSX 语法的 Markdown 格式。这使我们能够在文档中嵌入 React 组件。有关 Markdown 语法的快速概述，请参阅 GitHub Markdown 指南。

VSCode

在本地预览更改

VSCode 内置了 Markdown 预览器，您可以使用它在本地查看您的编辑。要为 MDX 文件启用预览器，您需要向用户设置添加一个配置选项。

打开命令面板（Mac 上是 ⌘ + ⇧ + P，Windows 上是 Ctrl + Shift + P），然后搜索 Preferences: Open User Settings (JSON)。

然后，将以下行添加到您的 settings.json 文件中：

json

{
  "files.associations": {
    "*.mdx": "markdown"
  }
}

接下来，再次打开命令面板，搜索 Markdown: Preview File 或 Markdown: Open Preview to the Side。这将打开一个预览窗口，您可以在其中看到格式化后的更改。

扩展

我们还为 VSCode 用户推荐以下扩展：

MDX：MDX 的智能感知和语法高亮。
Prettier：保存时格式化 MDX 文件。

审查流程

一旦您提交了贡献，Next.js 或开发者体验团队将审查您的更改，提供反馈，并在准备就绪时合并拉取请求。

如果您有任何疑问或在 PR 评论中需要进一步帮助，请告诉我们。感谢您为 Next.js 文档做出贡献并成为我们社区的一员！

提示： 在提交 PR 之前运行 pnpm prettier-fix 来执行 Prettier。

文件结构

文档使用文件系统路由。/docs 内部的每个文件夹和文件都代表一个路由段。这些段用于生成 URL 路径、导航和面包屑。

文件结构反映了您在站点上看到的导航，默认情况下，导航项按字母顺序排序。但是，我们可以通过在文件夹或文件名前添加两位数字（00-）来改变项目的顺序。

例如，在函数 API 参考中，页面按字母顺序排序，因为这让开发者更容易找到特定的函数：

txt

04-functions
├── after.mdx
├── cacheLife.mdx
├── cacheTag.mdx
└── ...

但是，在路由部分中，文件以两位数字作为前缀，并按开发者应该学习这些概念的顺序进行排序：

txt

01-routing
├── 01-defining-routes.mdx
├── 02-pages.mdx
├── 03-layouts-and-templates.mdx
└── ...

要快速查找页面，您可以使用 ⌘ + P (Mac) 或 Ctrl + P (Windows) 打开 VSCode 上的搜索栏。然后，键入您要查找的页面的 slug。例如 defining-routes。

为什么不使用 manifest 文件？

我们曾考虑使用 manifest 文件（这是生成文档导航的另一种常用方法），但我们发现 manifest 文件会很快与文件不同步。文件系统路由促使我们思考文档的结构，并且感觉更贴近 Next.js 的原生方式。

元数据

每个页面顶部都有一个元数据块，由三个破折号分隔。

必需字段

以下字段为必需：

字段	描述
`title`	页面的 `<h1>` 标题，用于 SEO 和 OG 图像。
`description`	页面的描述，用于 `<meta name="description">` 标签，进行 SEO。

yaml

---
title: Page Title
description: Page Description
---

最佳实践是将页面标题限制在 2-3 个词（例如 "优化图像"），描述限制在 1-2 句话（例如 "了解如何在 Next.js 中优化图像"）。

可选字段

以下字段为可选：

字段	描述
`nav_title`	覆盖导航中的页面标题。当页面标题过长无法完全显示时非常有用。如果未提供，则使用 `title` 字段。
`source`	将内容拉取到共享页面。请参阅共享页面。
`related`	文档底部的相关页面列表。这些将自动转换为卡片。请参阅相关链接。
`version`	开发阶段。例如 `experimental`、`legacy`、`unstable`、`RC`

yaml

---
nav_title: Nav Item Title
source: app/building-your-application/optimizing/images
related:
  description: See the image component API reference.
  links:
    - app/api-reference/components/image
version: experimental
---

`App` 和 `Pages` 文档

由于 App Router 和 Pages Router 中的大多数功能完全不同，因此它们各自的文档分别保存在不同的部分（02-app 和 03-pages）中。但是，它们之间也存在一些共享功能。

共享页面

为了避免内容重复和内容不同步的风险，我们使用 source 字段将一个页面的内容拉取到另一个页面。例如，<Link> 组件在 App 和 Pages 中的行为_大体上_是相同的。与其复制内容，我们可以将内容从 app/.../link.mdx 拉取到 pages/.../link.mdx：

mdx

---
title: <Link>
description: API reference for the <Link> component.
---

This API reference will help you understand how to use the props
and configuration options available for the Link Component.

mdx

---
title: <Link>
description: API reference for the <Link> component.
source: app/api-reference/components/link
---

{/* DO NOT EDIT THIS PAGE. */}
{/* The content of this page is pulled from the source above. */}

因此，我们可以在一个地方编辑内容，并使其反映在两个部分中。

共享内容

在共享页面中，有时可能会有 App Router 或 Pages Router 特有的内容。例如，<Link> 组件有一个 shallow prop，它只在 Pages 中可用，而在 App 中不可用。

为了确保内容只显示在正确的路由器中，我们可以将内容块包裹在 <AppOnly> 或 <PagesOnly> 组件中：

mdx

This content is shared between App and Pages.

<PagesOnly>

This content will only be shown on the Pages docs.

</PagesOnly>

This content is shared between App and Pages.

您很可能会将这些组件用于示例和代码块。

代码块

代码块应包含一个可复制粘贴的最小工作示例。这意味着代码应该能够在没有任何额外配置的情况下运行。

例如，如果您正在展示如何使用 <Link> 组件，您应该包括 import 语句和 <Link> 组件本身。

tsx

import Link from 'next/link'

export default function Page() {
  return <Link href="/about">About</Link>
}

在提交示例之前，务必在本地运行它们。这将确保代码是最新的且可用的。

语言和文件名

代码块应有一个包含语言和 filename 的标题。添加 filename prop 以渲染一个特殊的终端图标，帮助用户了解在哪里输入命令。例如：

mdx

```bash filename="Terminal"
npx create-next-app
```

文档中的大多数示例是用 tsx 和 jsx 编写的，少数是用 bash 编写的。但是，您可以使用任何支持的语言，这里是完整列表。

编写 JavaScript 代码块时，我们使用以下语言和扩展组合。

	语言	扩展名
包含 JSX 代码的 JavaScript 文件	```jsx	.js
不含 JSX 的 JavaScript 文件	```js	.js
包含 JSX 的 TypeScript 文件	```tsx	.tsx
不含 JSX 的 TypeScript 文件	```ts	.ts

须知：

确保对包含 JSX 代码的 JavaScript 文件使用 .js 扩展名。

例如，```jsx filename="app/layout.js"

TS 和 JS 切换器

添加一个语言切换器以在 TypeScript 和 JavaScript 之间切换。代码块应首先是 TypeScript 版本，并提供一个 JavaScript 版本以适应用户。

目前，我们连续编写 TS 和 JS 示例，并使用 switcher prop 链接它们：

mdx

```tsx filename="app/page.tsx" switcher

```

```jsx filename="app/page.js" switcher

```

须知：我们计划未来自动将 TypeScript 片段编译为 JavaScript。在此期间，您可以使用 transform.tools。

行高亮

代码行可以被高亮显示。当您想引起对代码特定部分的注意时，这非常有用。您可以通过向 highlight prop 传递数字来高亮显示行。

单行： highlight={1}

tsx

export default function Page() {
  return <Link href="/about">About</Link>
}

多行： highlight={1,3}

tsx

export default function Page() {
  return <Link href="/about">About</Link>
}

行范围： highlight={1-5}

tsx

export default function Page() {
  return <Link href="/about">About</Link>
}

图标

文档中可使用以下图标：

mdx

<Check size={18} />
<Cross size={18} />

输出：

我们不在文档中使用表情符号。

注释

对于重要但不关键的信息，请使用注释。注释是添加信息的好方法，而不会分散用户对主要内容的注意力。

mdx

> **Good to know**: This is a single line note.

> **Good to know**:
>
> - We also use this format for multi-line notes.
> - There are sometimes multiple items worth knowing or keeping in mind.

输出：

须知：这是一个单行注释。

须知：

我们也使用这种格式编写多行注释。

有时会有多个值得了解或记住的项目。

字段	是否必需？	描述
`title`	可选	卡片列表的标题。默认为下一步。
`description`	可选	卡片列表的描述。
`links`	必需	其他文档页面的链接列表。每个列表项应为相对 URL 路径（不带前导斜杠），例如 `app/api-reference/file-conventions/page`

图表

图表是解释复杂概念的好方法。我们使用 Figma 创建图表，遵循 Vercel 的设计指南。

这些图表目前位于我们私有的 Next.js 站点的 /public 文件夹中。如果您想更新或添加图表，请通过 GitHub issue 提出您的想法。

自定义组件和 HTML

以下是文档中可用的 React 组件：<Image /> (next/image)、<PagesOnly />、<AppOnly />、<Cross /> 和 <Check />。除了 <details> 标签外，我们不允许在文档中使用原始 HTML。

如果您有新组件的想法，请提出 GitHub issue。

风格指南

本节包含针对技术写作新手编写文档的指南。

页面模板

虽然我们没有严格的页面模板，但您会在整个文档中看到一些重复的页面部分：

概述： 页面的第一段应告知用户该功能是什么以及其用途。随后是最小工作示例或其 API 参考。
约定： 如果该功能有约定，应在此处解释。
示例： 展示该功能如何在不同的用例中使用。
API 表格： API 页面应在页面顶部有一个概述表格，其中包含跳转到特定部分的链接（如果可能）。
下一步（相关链接）： 添加相关页面的链接，以引导用户的学习旅程。

请随意根据需要添加这些部分。

页面类型

文档页面也分为两类：概念性页面和参考性页面。

概念性页面用于解释概念或功能。它们通常比参考性页面更长，包含更多信息。在 Next.js 文档中，概念性页面位于构建您的应用程序部分。
参考性页面用于解释特定的 API。它们通常更短，更专注。在 Next.js 文档中，参考性页面位于 API 参考部分。

须知：根据您贡献的页面类型，您可能需要遵循不同的语气和风格。例如，概念性页面更具指导性，使用“您”来称呼用户。参考性页面则更技术化，使用更多祈使性词语，如“创建、更新、接受”，并且倾向于省略“您”。

语气

以下是保持文档风格和语气一致的一些指南：

编写清晰、简洁的句子。避免离题。
- 如果您发现自己使用了大量逗号，请考虑将句子拆分为多个句子或使用列表。
- 用更简单的词替换复杂的词。例如，用 “使用” 代替 “利用”。
小心使用“这个”一词。它可能含糊不清，令人困惑；如果句子主语不明确，不要害怕重复。
- 例如，“Next.js 使用 React” 而不是 “Next.js 使用这个”。
使用主动语态而非被动语态。主动句更容易阅读。
- 例如，“Next.js 使用 React” 而不是 “React 被 Next.js 使用”。如果您发现自己使用了“被”等词，您可能正在使用被动语态。
避免使用“简单”、“快速”、“容易”、“只需”等词。这些词语具有主观性，可能会让用户感到气馁。
避免使用“不要”、“不能”、“不会”等否定词。这可能会让读者感到气馁。
- 例如，“您可以使用 <Link> 组件在页面之间创建链接” 而不是 “不要使用 <a> 标签在页面之间创建链接”。
使用第二人称（您/您的）。这更具人情味和吸引力。
使用中性语言。在指代受众时，使用 “开发者”、“用户” 或 “读者”。
如果添加代码示例，请确保它们格式正确且可运行。

尽管这些指南并非详尽无遗，但它们应该能帮助您入门。如果您想深入了解技术写作，请查阅 Google 技术写作课程。

感谢您为文档做出贡献并成为 Next.js 社区的一员！

欢迎阅读 Next.js 文档贡献指南！我们很高兴您能加入。

本页面提供了如何编辑 Next.js 文档的说明。我们的目标是确保社区中的每个人都能积极贡献并改进我们的文档。

为何贡献？

如何贡献

文档内容可在 Next.js 仓库中找到。要贡献，您可以直接在 GitHub 上编辑文件，或者克隆仓库并在本地编辑文件。

GitHub 工作流程

如果您不熟悉 GitHub，我们建议您阅读 GitHub 开源指南，了解如何派生仓库、创建分支并提交拉取请求。

须知：底层文档代码存在于一个私有代码库中，该代码库与 Next.js 公共仓库同步。这意味着您无法在本地预览文档。但是，在合并拉取请求后，您将在 nextjs.org 上看到您的更改。

编写 MDX

VSCode

在本地预览更改

VSCode 内置了 Markdown 预览器，您可以使用它在本地查看您的编辑。要为 MDX 文件启用预览器，您需要向用户设置添加一个配置选项。

打开命令面板（Mac 上是 ⌘ + ⇧ + P，Windows 上是 Ctrl + Shift + P），然后搜索 Preferences: Open User Settings (JSON)。

然后，将以下行添加到您的 settings.json 文件中：

json

{
  "files.associations": {
    "*.mdx": "markdown"
  }
}

接下来，再次打开命令面板，搜索 Markdown: Preview File 或 Markdown: Open Preview to the Side。这将打开一个预览窗口，您可以在其中看到格式化后的更改。

扩展

我们还为 VSCode 用户推荐以下扩展：

MDX：MDX 的智能感知和语法高亮。
Prettier：保存时格式化 MDX 文件。

审查流程

一旦您提交了贡献，Next.js 或开发者体验团队将审查您的更改，提供反馈，并在准备就绪时合并拉取请求。

如果您有任何疑问或在 PR 评论中需要进一步帮助，请告诉我们。感谢您为 Next.js 文档做出贡献并成为我们社区的一员！

提示： 在提交 PR 之前运行 pnpm prettier-fix 来执行 Prettier。

文件结构

文档使用文件系统路由。/docs 内部的每个文件夹和文件都代表一个路由段。这些段用于生成 URL 路径、导航和面包屑。

例如，在函数 API 参考中，页面按字母顺序排序，因为这让开发者更容易找到特定的函数：

txt

04-functions
├── after.mdx
├── cacheLife.mdx
├── cacheTag.mdx
└── ...

但是，在路由部分中，文件以两位数字作为前缀，并按开发者应该学习这些概念的顺序进行排序：

txt

01-routing
├── 01-defining-routes.mdx
├── 02-pages.mdx
├── 03-layouts-and-templates.mdx
└── ...

要快速查找页面，您可以使用 ⌘ + P (Mac) 或 Ctrl + P (Windows) 打开 VSCode 上的搜索栏。然后，键入您要查找的页面的 slug。例如 defining-routes。

为什么不使用 manifest 文件？

我们曾考虑使用 manifest 文件（这是生成文档导航的另一种常用方法），但我们发现 manifest 文件会很快与文件不同步。文件系统路由促使我们思考文档的结构，并且感觉更贴近 Next.js 的原生方式。

元数据

每个页面顶部都有一个元数据块，由三个破折号分隔。

必需字段

以下字段为必需：

字段	描述
`title`	页面的 `<h1>` 标题，用于 SEO 和 OG 图像。
`description`	页面的描述，用于 `<meta name="description">` 标签，进行 SEO。

yaml

---
title: Page Title
description: Page Description
---

最佳实践是将页面标题限制在 2-3 个词（例如 "优化图像"），描述限制在 1-2 句话（例如 "了解如何在 Next.js 中优化图像"）。

可选字段

以下字段为可选：

字段	描述
`nav_title`	覆盖导航中的页面标题。当页面标题过长无法完全显示时非常有用。如果未提供，则使用 `title` 字段。
`source`	将内容拉取到共享页面。请参阅共享页面。
`related`	文档底部的相关页面列表。这些将自动转换为卡片。请参阅相关链接。
`version`	开发阶段。例如 `experimental`、`legacy`、`unstable`、`RC`

yaml

---
nav_title: Nav Item Title
source: app/building-your-application/optimizing/images
related:
  description: See the image component API reference.
  links:
    - app/api-reference/components/image
version: experimental
---

`App` 和 `Pages` 文档

共享页面

mdx

---
title: <Link>
description: API reference for the <Link> component.
---

This API reference will help you understand how to use the props
and configuration options available for the Link Component.

mdx

---
title: <Link>
description: API reference for the <Link> component.
source: app/api-reference/components/link
---

{/* DO NOT EDIT THIS PAGE. */}
{/* The content of this page is pulled from the source above. */}

因此，我们可以在一个地方编辑内容，并使其反映在两个部分中。

共享内容

为了确保内容只显示在正确的路由器中，我们可以将内容块包裹在 <AppOnly> 或 <PagesOnly> 组件中：

mdx

This content is shared between App and Pages.

<PagesOnly>

This content will only be shown on the Pages docs.

</PagesOnly>

This content is shared between App and Pages.

您很可能会将这些组件用于示例和代码块。

代码块

代码块应包含一个可复制粘贴的最小工作示例。这意味着代码应该能够在没有任何额外配置的情况下运行。

例如，如果您正在展示如何使用 <Link> 组件，您应该包括 import 语句和 <Link> 组件本身。

tsx

import Link from 'next/link'

export default function Page() {
  return <Link href="/about">About</Link>
}

在提交示例之前，务必在本地运行它们。这将确保代码是最新的且可用的。

语言和文件名

代码块应有一个包含语言和 filename 的标题。添加 filename prop 以渲染一个特殊的终端图标，帮助用户了解在哪里输入命令。例如：

mdx

```bash filename="Terminal"
npx create-next-app
```

文档中的大多数示例是用 tsx 和 jsx 编写的，少数是用 bash 编写的。但是，您可以使用任何支持的语言，这里是完整列表。

编写 JavaScript 代码块时，我们使用以下语言和扩展组合。

	语言	扩展名
包含 JSX 代码的 JavaScript 文件	```jsx	.js
不含 JSX 的 JavaScript 文件	```js	.js
包含 JSX 的 TypeScript 文件	```tsx	.tsx
不含 JSX 的 TypeScript 文件	```ts	.ts

须知：

确保对包含 JSX 代码的 JavaScript 文件使用 .js 扩展名。

例如，```jsx filename="app/layout.js"

TS 和 JS 切换器

添加一个语言切换器以在 TypeScript 和 JavaScript 之间切换。代码块应首先是 TypeScript 版本，并提供一个 JavaScript 版本以适应用户。

目前，我们连续编写 TS 和 JS 示例，并使用 switcher prop 链接它们：

mdx

```tsx filename="app/page.tsx" switcher

```

```jsx filename="app/page.js" switcher

```

须知：我们计划未来自动将 TypeScript 片段编译为 JavaScript。在此期间，您可以使用 transform.tools。

行高亮

代码行可以被高亮显示。当您想引起对代码特定部分的注意时，这非常有用。您可以通过向 highlight prop 传递数字来高亮显示行。

单行： highlight={1}

tsx

export default function Page() {
  return <Link href="/about">About</Link>
}

多行： highlight={1,3}

tsx

export default function Page() {
  return <Link href="/about">About</Link>
}

行范围： highlight={1-5}

tsx

export default function Page() {
  return <Link href="/about">About</Link>
}

图标

文档中可使用以下图标：

mdx

<Check size={18} />
<Cross size={18} />

输出：

我们不在文档中使用表情符号。

注释

对于重要但不关键的信息，请使用注释。注释是添加信息的好方法，而不会分散用户对主要内容的注意力。

mdx

> **Good to know**: This is a single line note.

> **Good to know**:
>
> - We also use this format for multi-line notes.
> - There are sometimes multiple items worth knowing or keeping in mind.

输出：

须知：这是一个单行注释。

须知：

我们也使用这种格式编写多行注释。

有时会有多个值得了解或记住的项目。

字段	是否必需？	描述
`title`	可选	卡片列表的标题。默认为下一步。
`description`	可选	卡片列表的描述。
`links`	必需	其他文档页面的链接列表。每个列表项应为相对 URL 路径（不带前导斜杠），例如 `app/api-reference/file-conventions/page`

图表

图表是解释复杂概念的好方法。我们使用 Figma 创建图表，遵循 Vercel 的设计指南。

这些图表目前位于我们私有的 Next.js 站点的 /public 文件夹中。如果您想更新或添加图表，请通过 GitHub issue 提出您的想法。

自定义组件和 HTML

如果您有新组件的想法，请提出 GitHub issue。

风格指南

本节包含针对技术写作新手编写文档的指南。

页面模板

虽然我们没有严格的页面模板，但您会在整个文档中看到一些重复的页面部分：

概述： 页面的第一段应告知用户该功能是什么以及其用途。随后是最小工作示例或其 API 参考。
约定： 如果该功能有约定，应在此处解释。
示例： 展示该功能如何在不同的用例中使用。
API 表格： API 页面应在页面顶部有一个概述表格，其中包含跳转到特定部分的链接（如果可能）。
下一步（相关链接）： 添加相关页面的链接，以引导用户的学习旅程。

请随意根据需要添加这些部分。

页面类型

文档页面也分为两类：概念性页面和参考性页面。

概念性页面用于解释概念或功能。它们通常比参考性页面更长，包含更多信息。在 Next.js 文档中，概念性页面位于构建您的应用程序部分。
参考性页面用于解释特定的 API。它们通常更短，更专注。在 Next.js 文档中，参考性页面位于 API 参考部分。

须知：根据您贡献的页面类型，您可能需要遵循不同的语气和风格。例如，概念性页面更具指导性，使用“您”来称呼用户。参考性页面则更技术化，使用更多祈使性词语，如“创建、更新、接受”，并且倾向于省略“您”。

语气

以下是保持文档风格和语气一致的一些指南：

编写清晰、简洁的句子。避免离题。
- 如果您发现自己使用了大量逗号，请考虑将句子拆分为多个句子或使用列表。
- 用更简单的词替换复杂的词。例如，用 “使用” 代替 “利用”。
小心使用“这个”一词。它可能含糊不清，令人困惑；如果句子主语不明确，不要害怕重复。
- 例如，“Next.js 使用 React” 而不是 “Next.js 使用这个”。
使用主动语态而非被动语态。主动句更容易阅读。
- 例如，“Next.js 使用 React” 而不是 “React 被 Next.js 使用”。如果您发现自己使用了“被”等词，您可能正在使用被动语态。
避免使用“简单”、“快速”、“容易”、“只需”等词。这些词语具有主观性，可能会让用户感到气馁。
避免使用“不要”、“不能”、“不会”等否定词。这可能会让读者感到气馁。
- 例如，“您可以使用 <Link> 组件在页面之间创建链接” 而不是 “不要使用 <a> 标签在页面之间创建链接”。
使用第二人称（您/您的）。这更具人情味和吸引力。
使用中性语言。在指代受众时，使用 “开发者”、“用户” 或 “读者”。
如果添加代码示例，请确保它们格式正确且可运行。

尽管这些指南并非详尽无遗，但它们应该能帮助您入门。如果您想深入了解技术写作，请查阅 Google 技术写作课程。

感谢您为文档做出贡献并成为 Next.js 社区的一员！

文档导航

为何贡献？

如何贡献

GitHub 工作流程

编写 MDX

VSCode

在本地预览更改

扩展

审查流程

文件结构

元数据

必需字段

可选字段

App 和 Pages 文档

共享页面

共享内容

代码块

语言和文件名

TS 和 JS 切换器

行高亮

图标

注释

相关链接

嵌套字段

图表

自定义组件和 HTML

风格指南

页面模板

页面类型

语气

为何贡献？

如何贡献

GitHub 工作流程

编写 MDX

VSCode

在本地预览更改

扩展

审查流程

文件结构

元数据

必需字段

可选字段

App 和 Pages 文档

共享页面

共享内容

代码块

语言和文件名

TS 和 JS 切换器

行高亮

图标

注释

相关链接

嵌套字段

图表

自定义组件和 HTML

风格指南

页面模板

页面类型

语气

`App` 和 `Pages` 文档

`App` 和 `Pages` 文档