内容小部件

将链接列表转换为响应式网格。最适合用于将读者引导至其他位置的索引页和中心页。

• 每个标题都会成为其网格上方的小型大写标签。标题是可选的。
• - [Title](/href) — Description. 会生成一张包含标题和描述的卡片。
• 使用 {icon-name} 结束项目即可添加图标，例如 {rocket}、{book-open}。名称来自 Lucide 图标集。未知名称会被静默丢弃——大括号不会显示在页面上。
• 在项目中放入 ![alt](https://raw.githubusercontent.com/docsbook-io/docs/main/content/features/url) 图片，即可使用真实图片代替图标——它会填充图标原本所占的相同区域。当卡片描述的是你有图片可展示的特定事物时，使用图片比图标更合适。
• 没有链接的项目会呈现为不可点击的卡片。

<!-- widget:cards -->
 
## Start here
 
- [Search](/docsbook-io/docs/content/features/search) — Let readers find a page by keyword {search}
- [Page feedback](/docsbook-io/docs/content/features/feedback) — Ask whether the page helped {thumbs-up}
 
<!-- /widget -->

为卡片添加正文。 在项目后留一个空行，并在其下缩进更多 Markdown 内容——段落、简短列表或代码片段均可。它会呈现在描述下方。当卡片有内容需要解释时，这样做很值得；如果卡片只是标记一个目的地，将其写成一行读起来更好。

为卡片添加独立操作。 如果最后一行缩进内容只有链接，它就会成为卡片的号召性操作行。仅仅包含链接的句子仍会作为普通文本显示。

选择布局。 cols=1、cols=2、cols=3 或 cols=4 可固定列数；horizontal 会将图标放在文本旁边而不是上方，以形成紧凑的行。两者都写在开始标记上，并且可以组合使用。不使用 cols 时，网格会根据页面宽度容纳每行尽可能多的卡片，这通常正是你想要的效果。窄屏始终会显示更少的列。

<!-- widget:cards cols=2 -->
 
- [Full-text search](/docsbook-io/docs/content/features/search) — Match a reader's keyword against your pages {search}
 
  Indexes every markdown file the site publishes and rebuilds itself when the
  repository changes. Nothing to reindex by hand.
 
  [Read the guide](/docsbook-io/docs/content/features/search)
 
- [Page feedback](/docsbook-io/docs/content/features/feedback) — Ask whether the page helped {thumbs-up}
 
  One click from the reader, no form and no email address. Results land per
  page, so you can sort by the pages rated worst.
 
  [Read the guide](/docsbook-io/docs/content/features/feedback)
 
<!-- /widget -->

将带标题的章节转换为包含一个可见面板的选项卡栏。当同一说明存在多个并行版本，而读者只需要其中一个时使用，例如包管理器、操作系统、语言 SDK、托管与自行托管路径。

• 每个标题都会成为一个选项卡；从该标题下方开始，直到下一个相同级别的标题之前的所有内容，都会成为该选项卡的面板。
• 第一个选项卡会默认打开，因此应将大多数读者需要的变体放在最前面。
• 标题可以以 {icon-name} 结尾，例如 ### macOS {apple}。要么为每个选项卡提供图标，要么一个也不要提供——只有部分选项卡带图标的栏看起来像是损坏的。
• 面板内支持任何 Markdown，包括表格和带语法高亮的代码块。
• 第一个标题之前的内容会作为简介显示在选项卡栏上方。用它来写一句适用于所有选项卡的说明。
• 标签应保持为一到两个词。选项卡栏会横向滚动而不是换行，因此句子长度的标签会将其他选项卡推到视野之外。
• 最多可切换 8 个选项卡。第 9 个及之后的章节会作为普通标题显示在选项卡栏下方——不会丢失任何内容，但如此之长的集合更适合使用标题列表。
• 所有面板都存在于页面源代码中，切换仅使用 CSS，因此即使关闭 JavaScript，每个变体仍然可读，爬虫也可以看到它们。

不要用它来隐藏读者需要全部阅读的内容。对于扫描式参考材料，这属于 accordion；对于有先后顺序的内容，应使用普通标题。

将带标题的章节转换为读者可以展开的行。最适合用于人们会扫描而不是通读的材料：常见问题、故障排除、按选项划分的详细信息。

• 每个标题都会成为一行；从该标题下方开始，直到下一个相同级别的标题之前的所有内容，都会成为该行的正文。
• 行内支持任何 Markdown，包括代码块和表格。
• 每一行默认都是折叠的，因此标题应在无需展开的情况下就足以让读者做出选择。
• 第一个标题之前的内容会作为简介显示在手风琴上方。

将带标题的章节转换为一个相互连接、从上到下的序列。当顺序很重要时使用，例如安装、设置或多阶段教程。如果顺序不重要，请改用 accordion。

• 每个标题都会成为一个步骤，按照文档顺序编号。
• 添加或删除步骤后，其余步骤会自动重新编号。

将方案转换为一排可比较的卡片，或将方案表格转换为比较矩阵。在读者需要在不同层级之间做出选择，而不是了解这些层级时使用。

小组件会根据你编写的内容选择形状：存在标题时，每个方案对应一张卡片；如果某个区域本身就是一个普通表格，则会重新渲染为矩阵。页面原本是什么形状，就使用相应的写法。

方案卡片形式。每个标题都是一个方案名称。

• 标题下的第一段是价格，会以大号文字显示：**$20** / month 会突出显示数字，并将单位放在数字旁边。没有数值时，也应以相同方式写出 Free 或 Contact sales。
• 第二段用一行文字说明该方案适合哪些人。它位于价格和列表之间，而这里是卡片最窄的部分。
• 列表会成为该方案包含的内容，每项前带有勾选标记。使用删除线书写的项目——~~Priority support~~——会显示为短横线和弱化文本，用于表明较低价方案不包含哪些内容，而无需再列出第二个列表。
• 紧接标题、且仅包含 **bold text** 的段落会成为该方案的徽章，并将其标记为特色方案：卡片周围显示环形边框，并使用实心按钮。最多只能将它用于一个方案。
• 方案最后一个仅包含链接的段落会成为其按钮，具体形式与 cta 完全相同。特色方案的第一个按钮为实心按钮，其余为幽灵按钮，因此整个区域只有一个最醒目的元素。

矩阵形式。第一列写功能名称，其他每一列代表一个方案。整段文本为 yes、no、✓、—、included 或 none 的单元格会变成勾选标记或短横线，同时保留标记文本以供屏幕阅读器读取。包含其他内容的单元格——3 seats、Unlimited 或脚注——会完全按原样保留。空单元格仍为空：沉默不代表“否”。

在开头标记上使用 cols=1|2|3|4 可将网格固定为指定列数。默认情况下会容纳页面允许的尽可能多的卡片。

切勿在此小组件中写入你没有从源内容中读到的价格、方案名称、限制或服务承诺。这是唯一一个其内容构成商业承诺的小组件。

将 REST 端点章节转换为一个表单，让读者可以使用自己的密钥和参数发送真实请求。

• 由方法和路径组成的标题——## POST /api/v1/chat——会成为一个端点区块。
• 其下方第一个包含 Field（或 Name / Parameter）列的表格会成为请求表单，每行对应一个输入框。存在 Type、Required 和 Description 列时也会使用它们。
• 类似 /project/update/{projectId} 的模板化路径片段始终会获得自己的输入框。
• 始终会添加 Authorization 输入框。读者的密钥会从其自己的浏览器发送，永远不会到达 Docsbook。
• 将 Authorization 作为表格中的一行进行说明没有问题：该行会被上方的请求头输入框占用，同时保留你的说明，而不会再次渲染为一个会将密钥放入 URL 的字段。
• 包含代码块——### Example、### Response——的 ### 子章节会移动到表单旁边的示例窗格中，并保留其标题。其他任何子章节，例如 ### Errors 表格，则会留在文档流中显示在下方。

一种小型带边框区块，用于在页面末尾告诉读者接下来应该做的一件事。

• 第一个标题会成为区块标题。它会以样式化文本行而非真正标题的形式渲染，因此不会出现在页面大纲中。
• 仅包含 **bold text** 的开头段落会成为小型大写眉题。
• 仅包含链接的段落会成为按钮：第一个为实心按钮，其余为描边按钮。仅仅包含链接的句子仍会作为正文显示。
• 每页使用一个，且最多包含两个链接。第二个区块会与第一个竞争，二者的转化效果都会更差。

<!-- widget:cta -->
 
## Publish your docs from GitHub
 
Connect a repository and your markdown is live.
 
[Create a project](https://docsbook.io/start) · [See pricing](https://docsbook.io/pricing)
 
<!-- /widget -->

相同的区块，但主要操作以单字段表单的形式呈现。读者输入的内容会被带入目标 URL，因此他们无需在下一页重新输入即可开始。

• 第一个链接的 URL 是表单目标，其链接文本会作为按钮标签。
• 使用空查询参数为字段命名：?email= 会将读者输入的内容作为 email 提交。不带查询字符串时，字段名为 email。
• 已经有值的参数会原样保留——?email=&ref=docs 会在提交的 URL 中保留 ref=docs，这对归因很有用。
• 使用链接的 Markdown 标题设置占位符：[Join](https://example.io/signup?email= "you@company.com")。
• 键盘类型取决于字段名：email 会调出电子邮件键盘，url / site / domain 会调出 URL 键盘。
• 无法接受表单的目标（例如 mailto: 或页面内锚点）会降级为普通按钮。

仅将其指向确实会读取该参数的 URL。忽略该参数的页面会静默丢弃读者输入的内容，这比普通按钮更糟糕。

将发现的问题列表转换为卡片网格，每张卡片都带有严重性徽章以及可执行操作的链接。用于列出关于你自己的文档的具体且按优先级排序的问题——审计结果、内容健康问题，以及任何“以下是需要修复的事项，已按优先级排序”的列表。对于单纯的目标位置列表，请改用 cards。

• 每个标题都会成为列表上方的小型大写分组标签。标题是可选的——对于单个未分组列表，可以省略标题。
• 每个列表项都会成为一条建议。- [Title](/href) — Explanation. {severity}：链接文本是标题，短横线后的文本说明其重要性以及应采取的措施。
• 每个条目末尾都要添加严重性标记——{urgent}、{worth-doing} 或 {later}。没有可识别标记的条目会呈现为 {worth-doing}，而不会丢失其严重性。
• 不带链接的条目会呈现为不可点击的建议。只有在确实没有可以引导读者前往的位置时，才应这样写。
• 标题与列表之间的段落会作为普通的介绍性文字原样显示。

<!-- widget:recommendations -->
 
- [You are paying to keep the same page twice](/docs/quickstart) — "Quickstart" and "Getting started" are 96% the same and neither links to the other. Keep one, merge the other into it. {urgent}
- [214 people found "Webhooks" the hard way](/docs/webhooks) — No page links to it, yet it still gets visits. Add a link from "Integrations". {worth-doing}
- [Nobody reads "Migration notes"](/docs/migration-notes) — Zero visits although 2 pages link to it. Reword the link text. {later}
 
<!-- /widget -->