前置知识: Markdown

Markdown 基础文本格式

5 min入门

强调语法精讲：斜体/粗体的星号与下划线差异、词内强调规则、删除线与上标下标等扩展格式。

认知导入（Layer 0 生存层） 前置知识：003 段落与换行。 边界说明：本篇覆盖最常用的行内格式。核心语法只有两组——* 与 _（斜体/粗体）、~~（删除线）；其余（高亮、上下标）都是第三方扩展，本篇会明确标注平台支持。 强制练习：输入 **你好** 和 *你好* 观察粗体与斜体；再输入 snake_case_name 观察下划线标记为何”没反应”。

1. 粗体与斜体

1.1 基本语法

效果星号写法下划线写法HTML 输出
斜体*斜体*_斜体_<em>
粗体**粗体**__粗体__<strong>
粗斜体***粗斜体***___粗斜体___<strong><em>

渲染效果：斜体、粗体、粗斜体。

两组定界符在多数场景等效，但存在一个关键差异（见 1.2）。团队约定通常统一用 * 系（Prettier 等格式化工具也会把 _ 统一改写为 *）。

1.2 词内强调：* 与 _ 的唯一重要差异

CommonMark 规定：* 可以用在单词内部触发强调，_ 不行（_ 只在词边界生效）：

这个*词内*强调会生效        → 词内两个字为斜体
这个_word_强调不会生效      → 原样显示下划线

这条规则是为代码标识符设计的：snake_case_name、__init__ 这类写法中的下划线不会被误解析成斜体/粗体。反过来，如果你确实想让”夹在字母中间的下划线”显示强调，只能改用 *。

实践建议：写代码相关的词（变量名、函数名）时一律放进行内代码 `snake_case`，既避免歧义也符合语义。

1.3 成功触发的条件

强调定界符必须紧贴内容，两侧不能有空格：

* 有效强调 *

上面这种”星号内侧有空格”的写法会原样显示星号。此外，只写一侧定界符（**粗体）不会生效——成对是底线。

2. 删除线（GFM 扩展）

用双波浪号 ~~ 包裹：

~~已废弃的写法~~，请改用新接口。

渲染效果：已废弃的写法，请改用新接口。

要点与边界：

  • 删除线不属于 CommonMark 核心，是 GFM 扩展：GitHub、GitLab、Obsidian、Typora 等支持；纯 CommonMark 渲染器原样显示波浪号；
  • 必须恰好两个波浪号且紧贴内容（~~ 文本 ~~ 无效、单个 ~ 在 GitHub 上无效）；
  • 语义是”已失效”而非”不重要”，详细规则与工程用法见 markdown/120-Strikethrough。

3. 下划线、高亮、上下标：没有原生语法

这四种常见排版需求在 CommonMark 与 GFM 中都没有原生语法，可行方案与代价如下。

3.1 下划线：HTML 标签

Markdown 刻意不提供下划线（HTML 时代它与链接的下划线视觉冲突）。需要时用 <u> 标签：

<u>下划线文本</u>

允许内嵌 HTML 的渲染器（GitHub、GitLab、多数站点生成器）均生效。

3.2 高亮：第三方扩展，GitHub 不支持

==高亮== 常见于 Typora、Pandoc（需 mark 扩展）、markdown-it 插件（markdown-it-mark）等工具，但它不是 GFM 语法，GitHub 不渲染，只会原样显示两个等号。跨平台文档需要高亮效果时用 HTML 标签兜底：

<mark>高亮文本</mark>

<mark> 是 HTML5 标准标签，GitHub 允许内嵌，效果可靠。

3.3 上标与下标：HTML 标签或公式

Markdown 没有原生上下标，用 HTML 的 <sup>/<sub>：

2<sup>32</sup> 种组合
H<sub>2</sub>O

数学场景（渲染器支持公式时）用 LaTeX 的 ^ 与 _，排版更专业，详见 markdown/160-SubscriptSuperscript 与 markdown/210-LaTeXMathFormula。

4. 行内代码

用反引号 ` 包裹，内容不解析任何 Markdown：

使用 `npm run build` 构建项目

渲染效果：使用 npm run build 构建项目。

行内代码是”排除法”利器：代码、命令、文件名、快捷键、任何含 * _ # 的字面文本，包进反引号就无需考虑转义（详见 markdown/080-EscapeCharacter）。内容本身含反引号时用双反引号包裹：`代码中有`反引号`。

5. 嵌套与组合

强调可以自由嵌套，先内后外是可靠写法：

**粗体中包含*斜体*文本**
***三层全部生效***
~~删除线中包含**粗体**~~
[链接文字可以**加粗**](https://example.com)

限制：

  • 同层混用两侧定界符（__粗体**__）因实现而异，不要依赖；
  • 代码跨度优先级最高：`**这不是粗体**` 会原样显示星号。

6. 常见陷阱

6.1 定界符与内容之间有空格

** 加粗 **、* 斜体 * 都不生效。成对且紧贴，是强调语法的全部要领。

6.2 下划线变量名被”吃掉一半”

my_var_name 在某些相邻文本组合下（如 文件 my_var_name 的说明 中前后紧贴标点）可能触发意想不到的强调。含下划线的标识符一律放行内代码。

6.3 在 GitHub 上使用 ==高亮==

如 3.2 节所述，GitHub 不支持该语法，发布前会退化成裸等号。跨平台文档用 <mark>。

6.4 特殊字符与强调冲突

正文里的字面星号（乘法 2 * 3）可能被配对解析为斜体，用反斜杠转义 \* 或直接写进行内代码（详见 markdown/080-EscapeCharacter）。

6.5 滥用格式

粗体用于强调关键结论，斜体用于术语或外来语，删除线用于标记失效——一句话里超过两处强调等于没有强调。

小结

  • 初学者要点：**粗体**、*斜体*、~~删除线~~，定界符成对且紧贴内容；变量名等含下划线的词放行内代码；下划线用 <u>、高亮用 <mark>、上下标用 <sup>/<sub>（都是 HTML 兜底）。
  • 进阶注意：* 支持词内强调而 _ 不支持（保护 snake_case），团队统一用 * 系；删除线是 GFM 扩展、==高亮== 连 GFM 都不是（GitHub 不渲染）；行内代码优先级最高，能包进去的字面文本就不要转义。