1.2 强调与转义：让重点跳出来

1.2 强调与转义：让重点跳出来

粗体用双星号包裹，斜体用单星号包裹，这一节还处理它们的孪生写法（下划线）、组合用法，以及当星号本身就想当普通字符时的转义。这是一组"行内记号"——它们不改变文档结构，只装饰文字。

跟着敲：四种强调

**这是粗体**
*这是斜体*
***这是粗斜体***
~~这是删除线~~（GFM 扩展，第 4 章细讲）
​

渲染效果依次是加粗、倾斜、又粗又斜、加删除线。理论上下划线也能干同样的事：

__这也是粗体__
_这也是斜体_
​

两种写法渲染结果完全一样，但我强烈建议只用星号，理由有三：

1. 下划线在单词中间会失效（一支_笔_的价钱 不会被渲染成斜体），星号不会。
2. 星号肉眼更容易识别配对边界。
3. 团队统一一种写法，diff 里不会出现两种风格混排。

组合与嵌套的顺序

强调可以嵌套，但要注意符号的先后：

**粗体里有 *斜体* 很正常**
*斜体里有 **粗体** 也可以*
​

配对原则是"内层符号先闭合"。如果你写 **外层 *内层**内层*，解析器从左到右匹配，结果会和你预期的不一样——遇到奇怪的渲染，先检查配对。

转义：让符号变回普通字符

想在正文里写一个星号或井号，用反斜杠开头：

\*不是斜体\*，就是两个星号
\# 不是标题
\`\` 想显示反引号也可以转义
​

需要转义的常见字符一览：

💡 关键直觉：如果某段文字"本来该是普通字符却被渲染成了格式"，答案几乎总是转义；反过来，"该成格式却没成"，答案通常是配对符号或空格出了问题。

一个真实翻车案例

有人在发布说明里写了"3 * 5 * 7 的连乘结果"，忘了转义，渲染后变成了"3 5 7 的连乘结果"——中间的星号被当成了强调定界符吞掉了。修复办法两个：转义，或者干脆用行内代码把整段式子包起来（下一节的主角）。数学式子我更推荐后者，等宽显示更清晰。

本节要点回顾

• 粗体 **文字**，斜体 *文字*，粗斜体 ***文字***。
• 只选星号：下划线在词内失效且辨识度差。
• 反斜杠转义任何格式字符；不确定就转义，多转无害。
• 替代方案：行内代码可以整体"去格式化"，讲语法时特别好用。

强调的使用配额：少即是清楚

语法会了，更难的是分寸。粗体的视觉权重很高，一段文字里加粗超过三处，读者反而找不到重点——重点太多等于没有重点。给团队定一条可执行的配额：每段最多一处加粗，每屏不超过三处；整句或整段加粗基本总是错的，那是该拆成独立提示块的信号。斜体的适用面更窄：中文排版里斜体其实是伪斜体（字体引擎把正体倾斜），小字号下可读性明显下降，所以中文文档里斜体尽量只用于外文词汇、书名这类约定用法，不用来强调——中文语境的强调交给加粗就够了。

另一个常见误用是"加粗当标题"。有人想突出一行字又不想要目录项，就用加粗顶替三级标题。短期看效果相似，长期看这是结构信息的丢失：标题会进目录、进锚点、进大纲视图，加粗什么也不进。等文档要导出 PDF 或生成站点时，这些"假标题"全部沉底到正文里，找不回来。判断标准一句话：**这行字需不需要出现在目录里？需要就用标题，不需要就让它安静地当正文。**删除线的用法纪律类似——它只该表示"此内容已废弃但留档可查"，比如会议纪要里被否决的方案；拿来当装饰或强调，读者会疑惑这条信息到底还算不算数。

定界符的边界规则：为什么强调会失效

CommonMark 对星号定界有两条硬规则，理解它们能解释九成的"强调不生效"问题。规则一：开定界符左侧、闭定界符右侧不能是标点或空白的错误组合——具体说，* 开头那侧如果左边是标点，需要右侧不是空白；闭合那侧反之。规则二：单词内部的下划线永远不生效（前文提过），而单词内部的星号生效。拿两组对照实验验证：

蛇*形*文字      → 正常斜体（星号允许词内）
蛇_形_文字      → 原样输出（下划线词内失效）
(*强调*)       → 括号内侧的星号仍生效
_a_ b_ c_      → 部分解析器只认第一对
​

第三个高频坑是标点紧贴：**重要！**： 这种闭定界符后面紧跟全角标点的写法，在老版本 marked、某些博客平台里会渲染失败，星号原样露出。稳妥写法是闭星号与后面的标点之间留一个空格，或者把标点挪进强调内部。做跨平台发布的文档，这类"紧贴写法"都值得在目标平台预览一遍再用。

还有一个只在中英混排里出现的怪问题：英文单词后紧跟中文再跟星号，个别渲染器把全角字符判定为"标点"，导致定界失败。遇到时最省事的绕法是改用行内代码或调整空格位置，不必深究解析器源码——记住结论即可：强调失效时，先查定界符两侧的字符类型，再查配对，最后查平台方言。

强调解决了"字"的层面，接下来处理"多条并列信息"的层面——列表。

一分钟自测：预测再验证

拿下面四行做预测练习，先在脑中判断渲染结果再动手验证：

**粗体*混搭*粗体**
*斜体 **内粗** 收尾*
a*b*c*d
5\*3\*2=30
​

第一行的混搭在 CommonMark 里可以成立（内层斜体嵌在粗体内）；第二行同样成立但部分老解析器吃掉内层；第三行四个字母夹三个星号，只有中间一对会被解释为斜体，首尾星号因边界规则原样保留；第四行靠转义输出字面乘号。四行全对说明本节的规则已经内化，错了哪行就回到对应小节再敲一遍——这种"预测再验证"的练法，比单向阅读的留存率高得多，后面章节的小练习也多用这个套路。

转义的失效场景：反斜杠不是万能的

最后补三条转义自身的边界。第一，转义只对** ASCII 标点**有效，\（、\。 这类全角标点前的反斜杠不会被消耗，会原样留在输出里——中文写作里转义只用于半角记号。第二，代码块与行内代码里的反斜杠不做转义（上一节的"转义真空区"），块内想显示反斜杠本身直接写即可。第三，&、; 等与 HTML 实体相关的字符，转义行为各实现不一，涉及 HTML 片段的展示优先整体放进代码块而不是逐字符转义。三条边界记下来，转义就再没有能坑到你的地方。