企业官网建设流程全解析

很多刚接触 Markdown 的朋友，都会有这样的困惑：我明明需要用字号、颜色来突出重点，翻遍语法手册却只找到加粗、斜体、引用这些基础写法。搜了半天，发现有人用一串看起来像 HTML 的代码把字变红了、变大了，于是更懵了。

这篇文章就把这件事彻底讲清楚。我会先说明为什么标准 Markdown 不支持直接设置字体大小和颜色，再给出跨平台通用、编辑器内置、博客定制这三条路线，配合可复制的代码块和实测效果，让你看完就能在自己的文档、博客、项目 README 里做出想要的排版效果。你要是在 Typora、VS Code、语雀、Hexo 这类环境里被字体问题卡过，这篇文章就是冲着你来的。

1. 先搞清楚边界：标准 Markdown 到底管不了哪些事

Markdown 的设计哲学是"易读易写"，它把精力都花在结构化排版上，比如标题、列表、引用、代码块、表格。至于字体大小、颜色、字体系列这类"视觉表现层"的东西，压根不在它的核心语法范围里。你翻遍 CommonMark 规范也找不到一个font-size关键字，这不是设计缺陷，而是有意为之——纯文本要保持跨平台的一致性。

那为什么有人能在 Markdown 里改字号和颜色？因为绝大多数 Markdown 渲染器在解析文本时，允许内联 HTML 标签和 CSS 样式透传过去。也就是说，你不是在用 Markdown 语法改字体，而是在 Markdown 文档里直接写 HTML 和 CSS，让最终负责渲染的浏览器或编辑器去解释它们。

有一个天然的分工需要记住：

在这张表里，加粗是唯一一个标准语法直接支持的"字体相关"样式，这也是为什么你搜"Markdown 加粗"能搜到明确的答案，而搜"Markdown 颜色"搜出的内容五花八门、说法不一。

有个容易踩的坑必须提醒你：如果你把**加粗**和 HTML 标签混用，比如**<span style="color:red">红色加粗</span>**，在某些平台上会解析失败。更稳妥的写法是<span style="color:red; font-weight:bold;">红色加粗</span>，用 CSS 的font-weight属性来实现加粗，而不是依赖 Markdown 的**符号。

2. 内联 HTML 标签：最通用的字体控制方案

既然标准语法管不了字体，我们就把 HTML 请进来。目前主流 Markdown 渲染器默认允许内联 HTML，所以这套写法在 Typora、VS Code Markdown Preview、语雀、掘金、博客园、Hexo 等绝大多数环境下都能生效。

先说最简单的一招，用<font>标签。虽然 HTML5 里<font>已经标记为过时标签，但 Markdown 渲染器基本都兼容，胜在写法简单、一眼能看懂：

<font color="red">红色文字</font> <font color="#00aaff">十六进制颜色文字</font> <font size="4">四号字</font> <font face="微软雅黑">微软雅黑字体</font>

color属性可以直接填英文颜色名（red、blue、green 等），也可以填十六进制色值（如#ff6600、#2ecc71）。size属性的取值范围是 1 到 7，1 最小、7 最大，它是相对字号，不是精确的像素值。face属性指定字体族，但能不能生效取决于读者设备上是否安装了对应字体。

你要是追求更精细的控制，别用<font>，用<span>配合 style 属性，这是我在实际项目中几乎唯一使用的方案：

<span style="color: #e74c3c; font-size: 20px;">自定义颜色的文字</span> <span style="font-family: 'Courier New', Consolas, monospace;">等宽字体代码风格</span> <span style="color: #333; background-color: #f1c40f; font-weight: bold;"> 带背景色且加粗的重点文字 </span>

style 里的 CSS 属性可以自由组合。font-family后面可以写多个备选字体，用英文逗号隔开，浏览器会按顺序寻找可用字体，这是避免某些设备没有指定字体导致显示异常的常用做法。

还有一类需求经常和字体样式一起出现：把一段文字标成"批注"感觉的样式。可以用mark标签做荧光笔效果：

<mark>这是荧光笔标注效果</mark>

mark标签在 Markdown 里会默认渲染出黄色背景，如果你不喜欢默认的黄，用span自己加背景色更可控。

在实际写作里，我习惯把常用的几种样式组合封装成"模板片段"，直接替换文字即可：

<span style="color: #c0392b; font-size: 18px; font-weight: bold;">[重点结论]</span> <span style="color: #2980b9; font-size: 16px;">[补充说明]</span> <span style="color: #27ae60; font-size: 15px;">[操作提示]</span>

这套配色方案选的是蓝色系和绿色系，适合技术文档里的"备注"和"成功提示"语义，红字留给警告性内容。你可以根据自己博客的配色风格调色。

讲一个细节：很多编辑器里，<span>开头的行如果把光标放上去，会触发 HTML 标签自动闭合，容易多出多余的</span>。解决方法是写完标签后把光标移开，或者先写标签再往里填文字，不要依赖编辑器的补全。

3. 用 CSS 统一管理样式：博客和长文档的正道

内联 style 虽然灵活，但有一堆毛病：每个标签都要写一长串，文档一长就是灾难；如果想统一调整某类文字的颜色，你得全文搜索替换。所以只要你的 Markdown 最终会渲染成网页（比如 Hexo、VuePress、Hugo 这类博客站），就应该用 CSS 统一管理字体样式。

方法一：把 CSS 声明写在 Markdown 文档开头的<style>块里。不是所有渲染平台都允许文档内嵌<style>，很多在线平台出于安全考虑会过滤掉 style 标签，但本地编辑器（如 Typora）和自建博客站通常支持：

<style> .custom-red { color: #c0392b; } .custom-blue { color: #2980b9; font-weight: bold; } .custom-lg { font-size: 20px; } </style> <span class="custom-red">这是红色自定义类</span> <span class="custom-blue">这是蓝色加粗自定义类</span> <span class="custom-lg">这是大号字</span>

这种方式的优势非常明显：你只需要在文档开头维护一小段样式表，后面正文里用 class 名就能反复引用，改一处全篇生效。我在写开发文档时，先把"危险警告""重要提醒""示例代码说明"等几种 class 定义好，正文写作完全没有重复劳动。

方法二：把样式写进主题文件，适合 Hexo 这个场景。在 Hexo 博客里，找到themes/你的主题/source/css/目录下的 main CSS 文件，在末尾追加自定义样式：

.md-font-warn { color: #d35400; font-size: 18px; } .md-font-tip { color: #16a085; border-bottom: 1px dashed #16a085; }

然后在 Markdown 文章里写<span class="md-font-warn">...就能引用。同理，VuePress 可以把样式放进.vuepress/styles/index.styl，Hugo 放进static/css并挂载。

方法三：全局body或标题字体定制。如果你想把博客全文的默认字体都换成系统没有的第三方字体（如 Noto Serif SC、JetBrains Mono），在 CSS 里加：

body { font-family: "Noto Serif SC", "Source Han Serif SC", "Microsoft YaHei", serif; } code, pre { font-family: "JetBrains Mono", "Fira Code", Consolas, monospace; }

这属于"字体类型"层面的定制，比单点修改影响面广得多，适合追求统一视觉风格的博客作者。不过要记得，引入网络字体（如 Google Fonts）会影响页面加载速度，国内访问还需考虑网络环境，稳妥的做法是优先使用读者本机大概率已安装的字体，再在列表里兜底。

关于 CSS 方案，我的经验是优先考虑"维护成本"。如果你只有一篇文章需要特殊样式，用内联 style 就够了；如果是整个站点要统一风格，务必走 CSS。混用两套方案最痛苦，后面改版时要逐个标签去抠。

4. 不同编辑器和平台的行事风格各不相同

同样的 HTML 标签和 style，在不同渲染器里的表现可能是天壤之别。这里我不做平台批评，只用一个实测对比表说明情况，顺便告诉你如何根据目标平台做取舍。下面是我在几个常见环境里验证过的结果：

为什么 GitHub 这种以严格著称的平台反而允许内联 style？因为 GitHub 的 Markdown 渲染做了白名单过滤，它允许常见的表现性样式属性（如color、font-size、font-weight），但限制了危险属性（如position: fixed这类可能影响布局或引发攻击的写法）。这给了我们一个启示：写样式时尽量只写最常规的文本属性，不要搞花活，兼容性会好很多。

再提醒一个反向场景：如果你在 VS Code 里把 Markdown 转 PDF 或 Word，字体颜色和大小能不能保留？实测下来，使用常见的 Markdown PDF 插件转换时，HTML 标签和 CSS 属性都能保留；但转换成 Word 时，很多工具会丢失内联样式，最稳的方案是先把 Markdown 转成带样式的 HTML，再用 Word 打开 HTML 文件另存为 docx。这个技巧我踩了无数次坑才掌握，先分享给你。后续你在不同平台间迁移文档时，最好对每一处颜色和字号做一遍目视检查，代码检测很难覆盖所有渲染差异。

5. 组合拳实战：一段完整的图文排版示例

理论说完了，我们把前面所有方法串起来，写一个完整的实际案例。假设我要在一篇技术教程里做一个"环境配置说明"的小节，里面有警告、命令、版本说明和最终效果，用 Markdown 加 HTML 混合排版如下：

# 环境配置说明 本文要求使用 **Python 3.9+**，如果你还没有安装，请参考官方文档。 > <span style="color: #e74c3c; font-weight: bold;">注意：</span> > <span style="color: #555;">Windows 用户请勿将 Python 安装到含中文或空格的路径下。</span> 推荐使用虚拟环境，创建命令如下： ```bash python -m venv .venv source .venv/bin/activate # Windows 下为 .venv\Scripts\activate

安装依赖后，用以下命令验证版本：

python --version

如果输出Python 3.9.0及以上版本，说明环境就绪。

在这段示例中，我刻意混合了三种能力： - `**Python 3.9+**` 是标准 Markdown 加粗，任何平台都不会出错； - `注意：` 一行用了红色加粗的 `span`，表达强烈的提示语义； - 命令行的内联代码区，用等宽字体加浅灰色背景突出风格，字体类型上的区分让人一眼辨认出"这是可执行命令"； - 引用块 `>` 里嵌套 `span` 标签，在 Typora 里渲染效果比纯引号文本更有层次感。 这类"混排"技巧在真实博客写作里出现频率极高，因为你是在写一篇有信息层级的文章，不是在做一个纯样式演示。掌握组合逻辑比记住单个标签重要得多。 我也测试过把这段内容放到 GitHub README 中展示，颜色和加粗都能正常渲染，只有引号代码块里的 `padding` 和 `border-radius` 这两个属性会被吃掉，但整体视觉效果不受影响。GitHub 用户看到的效果可以接受。 ## 6. 编辑器的专属扩展语法：只能在一处生效的偷懒写法 除了通用的 HTML 方案，不少 Markdown 编辑器或博客平台还提供了自己的扩展语法。这些扩展通常更简洁，但换一个环境就失效，属于"平台锁定的快捷方式"。我举三个有代表性的例子。 Typora 支持一个超好用的语法：要把一段文字标成扩展的"高亮"，可以写 `==高亮==`，它会渲染成黄色背景。这个语法在 GitHub 上扛不住，GitHub 不识别 `==`，会原样显示两个等号。Typora 还支持 `^上标^` 和 `~下标~`，适合写化学式或数学表达式，同样属于 Typora 专属扩展。 语雀是另外一套逻辑。在语雀文档编辑器里，你可以选中文字直接通过工具栏改颜色和字号，它底层存储的也是 HTML，但你在 Markdown 模式下必须使用语雀自己的工具栏，不能纯手写标签然后回切。一旦切换模式，很多手写的标签会被转义。 还有一类是支持"自定义容器"的博客框架，比如 VuePress 和 Docusaurus 都有 `::: tip`、`::: warning` 这类容器语法： ```markdown ::: warning 这里是一段警示文字，主题会赋予它黄色边框和背景色。 :::

这种容器本质上还是套了一层预设 CSS，只是不需要你手写类名。它的字体和颜色由主题决定，你无法在写作时单独指定某个字是红色，适合"不差样式、图省事"的快速排版场景。

这种"平台专属扩展"有一个共同问题：可移植性极差。你要是有一天把文章从 Typora 搬到语雀，==高亮==会全部失效。所以在我的习惯里，凡是需要强调的文字，优先用标准 Markdown 加粗，需要颜色时用通用 HTMLspan，只有纯本地、不迁移的文档里才用平台扩展语法，这个取舍建议适用于绝大多数人。

7. 高频疑难场景排查：为什么你的颜色没生效？

最后一部分，直接给结论。我整理了几个反复被问到的高频问题和对应的排查思路，全是从实际使用中总结出来的。

第一个：颜色标签明明写了，但页面上没有任何变化。最常见的原因是渲染器过滤了 HTML 标签，或者你用的平台要求先切换到"源代码模式"再写标签。排查思路很简单，先用一个最简例子测试：<span style="color:red;">test</span>。如果红色都不出来，那说明平台压根不允许内联 HTML，后面做什么都白搭；如果红色出来，再逐步加其他属性，用二分法定位是哪个属性出了问题。

第二个：字号设置了font-size: 20px，显示却奇大无比。这种情况一般是你在标签里同时写了size属性和font-size样式，两者叠加导致字号膨胀。size="4"大约等于medium，再接一个20px可能就到large以上了。建议只保留一种方式，个人推荐只用 CSS 的font-size，因为它可以精确到像素，size的 1 到 7 档位太粗。

第三个：导出 PDF 后字体变了。渲染 Markdown 预览时用的是编辑器的网页字体，导出 PDF 则是重新排版，如果目标 PDF 生成器不认识你指定的字体族，就会回退到默认字体。解决办法是导出的主题中显式声明字体族和字号，比如 VS Code 的 Markdown PDF 插件可以在配置里设置markdown-pdf.styles指定一个额外的 CSS 文件。

第四个：加粗和颜色同时失效。遇到这种"复合样式翻车"场景，先把加粗从**改成font-weight: bold再测试。很多平台解析**时会在 HTML 标签前后插入额外的strong包裹，最终生成不规范的嵌套结构，导致样式被忽略。纯 CSS 写法虽然啰嗦，但规避了 Markdown 解析器与 HTML 解析器的冲突，属于最稳的写法。

第五个：代码块里的 Markdown 标签不被解析。这是因为代码块本身就会转义 Markdown 符号，这是设计行为，不是 bug。你想要在代码示例里展示带颜色的内容，只能靠行内代码配合 HTML 标签，不能指望代码块内部用 Markdown 做样式。

日常写作的个人经验

我在实际操作中形成了一套固定的取舍习惯：优先用 Markdown 自身的加粗和引用表达语义；需要精确配色时，一律使用<span style="...">而不用<font>；颜色只用十六进制，不靠感觉记颜色名；正文里的颜色不超过三种，保持"警示红、信息蓝、成功绿"的基本盘。

最后分享一个能明显提高效率的小技巧：在 VS Code 或 Typora 里配置自定义代码片段（snippet）。比如我在 VS Code 里敲red加 Tab 就会自动展开成<span style="color: #c0392b;">${1}</span>，敲blue展开成<span style="color: #2980b9;">${1}</span>。这样写样式标签的速度几乎和写纯 Markdown 一样快，不用每次手动敲一长串属性。配置方法是在 VS Code 的用户代码片段里新增一个 markdown.json，定义若干个前缀即可。这套流程跑顺之后，你会发现 Markdown 里调整字体样式其实一点都不繁琐。