企业官网建设流程全解析

在技术社区发帖或写技术方案时，你是不是也遇到过这样的场面：明明在本地编辑器里排好的文档，粘贴到博客平台后，标题变得像正文，正文却突然变得比标题还大，代码块里的字体忽大忽小，整个页面看起来一团乱。有人习惯性说一句“字体忽大忽小是我不熟，等我写多了就好”，但真正的问题往往不在“熟不熟”，而在于格式的来源和处理方式。这篇文章要说的正是这件事：为什么你的技术文档会出现字体忽大忽小，格式从哪里来、到哪里去，以及如何用一套稳定的流程彻底解决。

先说结论：绝大多数“字体忽大忽小”不是平台的问题，也不是你手残，而是三类技术原因的叠加——复制粘贴时残留了 HTML 内联样式、Markdown 语法解析规则被忽略、渲染时 CSS 优先级覆盖了主题样式。这三类问题都可以在发布前用几十秒检查出来，也可以通过规范的文章写作流程从源头避开。读完这篇文章，你会得到一个可复用的排查路径，以及至少三组可以直接执行的清理脚本和验证命令。

这篇文章适合经常写技术博客、维护团队文档、在知识库或论坛发技术方案的开发者。如果你只是偶尔写几句话，可能不太需要关心；但只要你的内容是“给别人看的、要长期维护的、带代码和配置的”，格式稳定性就是一种技术债，越早解决越省事。

1. 这篇文章真正要解决的问题

先问你一个问题：当你按下“发布”的那一刻，你文档里的文字发生了什么？

很多人以为，编辑器里看到的排版就是最终结果。实际上，文字从你的电脑到达读者屏幕，中间经历了至少三层转换：内容来源层的编辑器状态、中间层的 Markdown 或富文本数据、目标层的 HTML 渲染。字体忽大忽小，几乎都是这三层中的某一层出现了格式污染。

“格式污染”这个词比较准确。它不一定是你写错了语法，而更可能是你的文字里藏着你看不见的格式标签。比如你从 Word 里复制了一段需求说明，Word 会把字体大小、颜色、行距全部转成 HTML 标签和 CSS 样式，悄悄塞进文章里。你把这段文字粘贴到博客的富文本编辑器，它原样保留；粘贴到 Markdown 编辑器，它也可能被当成 HTML 原样渲染。结果就是：你看到的是“一段话”，浏览器看到的是“一个带着 24px 字号样式的 span 标签”。

这个问题还会被第二种情况放大：Markdown 语法对格式非常敏感，但多数新手只使用其中 20% 的语法。比如“#”后面没有空格、标题和正文之间没有空行、列表缩进不一致、代码块使用四个空格而不是三个反引号……这些在本地预览时可能因为编辑器容错而看不出来，但换一个渲染引擎就会出问题。字体忽大忽小，很多时候不是字体本身的问题，而是“标题被解析成了普通段落”或“普通段落被解析成了标题”。

所以说，新手写技术文章时遇到格式混乱，不完全是“不熟编辑器”的问题。更稳妥的判断是：输出不稳定，是因为缺少稳定的格式处理流程。这篇文章就是把这条流程拆开给你看。

2. 为什么字体大小会“忽大忽小”：渲染系统的三层机制

要理解字体大小为什么会变，至少要明白一个基本原则：在网页上，文字大小由 CSS 决定，而不是由你在编辑器里按下的“增大字号”按钮决定。你在编辑器里看到的“显示效果”，只是编辑器帮你生成的一段 HTML（或者从 Markdown 转换出来的 HTML）。HTML 里定义了文字内容，CSS 定义了这段文字的字号、颜色、行高和间距。

这里必须区分三样东西：

• HTML 标签：比如<h1>标题、<p>段落、<span>普通行内元素。
• CSS 样式：可以写在单独的样式表里，也可以写在元素的style属性里。
• Markdown 语法：一种轻量级标记语言，最终会被转换成 HTML。

关键点在于：CSDN 博客、GitHub、知识库系统、论坛等平台，都有自己的主题 CSS，它们会规定h1应该多大、p应该多少像素。但当你粘贴内容时，内容里如果带有内联样式，比如style="font-size: 24px"，这个内联样式的优先级通常高于主题 CSS。于是，即使平台希望标题是 28px，你的内联样式可能把标题里的某一部分强行设置成 14px。这就是“为什么我设置了大字号，发布后反而变小了”的技术根源。

我们可以用一个简单的表格来理解不同样式来源的优先级（从高到低）：

所以，当你从 Word、网页、PDF 里复制内容时，那些“最高优先级”的内联样式会被一起带进来。这就像你带了一堆自己的设计稿去别人装修好的房子里，非要贴在墙上，结果整个墙面变得不伦不类。

明白了这个机制，后续的排查和清理就有了方向：先看内容里有没有残留的 HTML 标签或内联样式，再看 Markdown 语法是否规范，最后再看目标平台的渲染规则。

3. 排查前的基础：Markdown 与富文本编辑器的格式边界

在动手排查之前，建议先把 Markdown 和富文本编辑器的边界搞清楚。很多人在这上面栽跟头，是因为误以为“富文本编辑器里看到的，就是 Markdown 里存的样子”。

Markdown 是一种轻量级标记语言，它的设计初衷是“以纯文本形式写作，用少量符号表达格式”。比如：

• # 一级标题
• ## 二级标题
• **加粗**
• `代码`

它看起来直观，但规则很严格。这里最容易踩坑的有三个点：

第一，井号和标题文字之间必须有一个空格。#标题在某些解析器里也能渲染，但在另一些解析器里可能被当作普通文本。这里的差别不是“渲染器好心与否”，而是语法规范如此。跨平台写作时，最安全的写法是严格遵循 CommonMark 规范：# 标题。

第二，标题、列表、代码块与正文之间要用空行分隔。比如：

## 安装 打开终端运行命令。

如果你写成：

## 安装 打开终端运行命令。

有些渲染器会把“打开终端运行命令。”也视为标题区域内的一部分，或者把它和标题挤到同一块，导致显示异常。这和你设置的字号没有关系，是结构解析出了问题。

第三，Markdown 里的换行不等于段落。在 Markdown 中，普通回车只是“软换行”，渲染时可能被忽略，需要空行才能产生段落分隔。这会导致一种典型的“假字体问题”：你写了很多行，但渲染后发现全挤在一起，标题和正文的大小差异被缩进和间距问题掩盖了。

富文本编辑器则完全是另一套逻辑。你点击“标题”“字号”“加粗”按钮时，编辑器直接生成 HTML。富文本的优点是所见即所得，但最大的问题是“格式来源不透明”。从 Word 复制一段带格式的文字，编辑器会尽量保留原有 HTML，其中包括font标签、span标签和style属性。这时候你看到编辑器里字体很大，其实不是编辑器帮你处理，而是那段 HTML 在“强行指定”自己的大小。

所以，识别自己当前处在哪种写作环境中，是排查格式问题的第一步。如果你的文章是纯 Markdown 文件，那就检查语法；如果是富文本粘贴，那就检查 HTML 残留。最稳妥的写作方式，则是先在本地用 Markdown 写，再统一粘贴到目标平台的 Markdown 编辑器。这样可以避免大量格式污染。

4. 从“不熟”到可复现：搭建一个本地格式检查环境

既然我们要解决的是格式问题，最好有一套可以“复现”和“检查”的工具环境，而不是只靠肉眼盯屏幕。下面给出的工具和版本是通用实践，具体版本请以你自己本地的环境为准，重点在于思路。

推荐三种方式：

方式一：使用 VS Code 写 Markdown，并开启内置预览。VS Code 对 Markdown 的支持比较完整，你可以在.md文件中写作，然后按快捷键打开预览面板。

方式二：使用支持 CommonMark 的在线编辑器，比如 StackEdit、Dillinger 这类纯网页工具。它们的好处是不需要安装环境，缺点是你无法完全控制渲染器细节。

方式三：在本地安装 Node.js 环境，使用 markdownlint 做语法检查。这个更适合想建立工程化写作流程的团队。

不管用哪种方式，核心目标只有一个：让内容先经过一个“严谨的解析器”来渲染，而不是直接在博客编辑框里边写边猜。

下面是一个最基础的 Markdown 文件示例，后续所有排查都可以以这个文件为基准：

# Markdown 格式测试 这是一段普通正文，用于测试段落间距和字体大小。 ## 安装说明 打开终端，执行以下命令： ```bash echo "hello world"

提示：这是引用块。

把这个文件保存为 `format-test.md`，再用 VS Code 的 Markdown 预览打开。你会看到标题、正文、代码块、引用块之间有清晰的层级差异。如果某个部分没有按预期显示，说明该部分的语法有问题。 接着，为了检查复制粘贴是否带入了内联样式，可以准备一个 HTML 文件，把从博客或富文本编辑器里复制出来的内容存成 `.html`，再用后面的脚本或命令检查。这一步是很多开发者在格式问题排查时遗漏的：他们只检查 Markdown 语法，却没检查粘贴进来的原始 HTML。 ## 5. 核心示例：三种“忽大忽小”的典型代码与修复 下面给出三组真实场景下的代码示例。这三组示例涵盖了大多数“字体忽大忽小”的来源。请对照自己的文章排查。 ### 5.1 示例一：复制粘贴带来的 HTML 内联样式 你从某个网页中复制了一段文字，粘贴到编辑器后，看起来正常，但发布后出现了某几个字特别大或特别小。因为复制内容里可能带有类似这样的 HTML： ```html <p>这是一个<span style="font-size: 28px;">关键警告</span>，请务必注意。</p>

浏览器会优先执行font-size: 28px，而完全忽略平台主题里对正文p标签的字号设置。于是，“关键警告”四个字就会突然变大。

修复方法：粘贴前先清除格式。在大多数编辑器中，可以先用“粘贴为纯文本”功能（快捷键通常是 Ctrl+Shift+V），把文字先变回无格式状态，再重新设置标题和正文样式。

如果你已经粘贴进去了，可以用下面的 Python 脚本清理残留标签。将脚本保存为clean_html.py：

# 文件路径：clean_html.py import re import sys def clean_inline_html(text: str) -> str: # 移除 font 标签 text = re.sub(r'</?font[^>]*>', '', text, flags=re.IGNORECASE) # 移除 span 标签 text = re.sub(r'</?span[^>]*>', '', text, flags=re.IGNORECASE) # 移除 style 属性 text = re.sub(r'\s+style="[^"]*"', '', text, flags=re.IGNORECASE) # 移除 class 属性（根据项目需求决定是否保留） # text = re.sub(r'\s+class="[^"]*"', '', text, flags=re.IGNORECASE) # 压缩多余空白行 text = re.sub(r'\n{3,}', '\n\n', text) return text.strip() if __name__ == "__main__": if len(sys.argv) != 2: print("用法：python clean_html.py <html文件>") sys.exit(1) input_file = sys.argv[1] with open(input_file, encoding="utf-8") as f: content = f.read() cleaned = clean_inline_html(content) print(cleaned)

运行方式：

python clean_html.py article.html > article_clean.html

这段脚本的作用是去掉最常见的格式污染源。在正式使用前，建议先用一个测试文件验证，避免误删你本想要的内容。比如你的代码里恰好有字符串class="highlight"，就要根据实际情况调整正则规则。

5.2 示例二：标题与正文之间缺少空行

下面这种写法，在部分渲染器中不会立刻报错，但发布后容易出现层级混乱：

## 安装步骤 打开终端，执行以下命令。

如果你希望“安装步骤”是明确的二级标题，应在标题与正文之间添加空行：

## 安装步骤 打开终端，执行以下命令。

这个问题在本地预览时不容易发现，因为很多编辑器的“自动容错”会帮你补上。但不同平台的渲染规则不一样，所以最安全的做法是从源头遵守规范。如果你有大量 Markdown 文件需要检查，可以用下面的脚本快速定位“标题后缺少空行”的位置。将脚本保存为check_markdown.py：

# 文件路径：check_markdown.py import re import sys def check_headings(md_path: str): with open(md_path, encoding="utf-8") as f: lines = f.readlines() for i, line in enumerate(lines, 1): # 匹配 # 开头的标题行 if re.match(r'^#{1,6}\s+\S', line): # 如果标题是最后一行，视为正常，但可以提示 if i == len(lines): print(f"第 {i} 行：标题后没有内容") # 如果标题下一行不是空行，说明缺少分隔 elif lines[i].strip() != "": print(f"第 {i} 行：标题后缺少空行 -> {line.strip()}") if __name__ == "__main__": if len(sys.argv) != 2: print("用法：python check_markdown.py <markdown文件>") sys.exit(1) check_headings(sys.argv[1])

运行方式：

python check_markdown.py format-test.md

5.3 示例三：在 Markdown 中混用 HTML 标签

有些新人会在 Markdown 中用<font>标签来调整字号，比如：

<font size="6">警告</font>

这会带来两个问题：一是你在富文本编辑器里看到的效果，换到另一个平台可能完全不生效；二是它会破坏 Markdown 渲染的视觉一致性。更推荐的做法是用 Markdown 自身的语法表达强调或警告：

> **警告**：这里的内容很重要。

如果你确实需要更大的标题、更醒目的提示，应该使用平台提供的提示块语法，或者使用 Markdown 的引用块与加粗组合，而不是手工控制字号。你不需要在每个地方都用像素级控制，排版的一致性比局部强调更重要。

6. 运行结果与验证方法：如何判断格式已经被清理干净

上面的脚本和命令可以帮我们清理和检查，但最后还要解决一个问题：怎么判断格式已经干净了？依赖肉眼显然不够，这里提供两条可执行的验证路径。

第一条路径：检查 HTML 中是否还有残留的内联样式。把要发布的页面内容保存为 HTML 文件后，在终端执行：

grep -nE '<(font|span)[^>]*>' article.html

如果没有任何输出，说明基本没有残留的font或span标签。再检查style属性：

grep -nE 'style="[^"]*font-size' article.html

如果仍然有输出，说明还有个别文字在强制指定字号，需要继续清理。

第二条路径：使用 markdownlint 检查 Markdown 语法。在项目目录中执行常见的 lint 命令（具体命令以实际安装的工具为准）：

npx markdownlint-cli2 "*.md"

这个工具会找出标题格式、空行、列表缩进等问题，比人工检查快很多。如果项目里没有现成的 markdownlint，也可以用前面简单的 Python 脚本先跑一遍，把基础问题暴露出来。

验证成功的标准可以定得很明确：

• 页面里没有任何内联的font-size样式。
• 标题层级清晰，一级标题、二级标题与正文在视觉上有明显区分。
• 代码块与正文的间距正常。
• 在本地预览和平台发布后的效果基本一致。

如果上述某项不满足，不要急着改字号，先看是不是 HTML 残留或语法问题。因为“改字号”只是视觉效果，格式污染可能依然存在。

7. 常见问题与排查思路

下面这组问题汇总，覆盖了大部分“字体忽大忽小”的常见场景。遇到问题时，可以先按表格顺序排查。

这里需要提醒一点：平台主题差异导致的效果不一致非常常见，但这是“渲染层”的差异，不是内容损坏。只要你的内容符合 Markdown 规范，在没有残留 HTML 的情况下，即使在不同平台显示不完全一样，也不会出现严重的字体忽大忽小。所以排查重点仍然是内容和格式，而不是去跟平台较劲。

8. 最佳实践与工程建议

如果你已经受够了每次发文章都要调半天格式，下面的建议可以直接用到日常写作流程里。

8.1 统一内容源：从本地 Markdown 开始

不要直接在博客后台的富文本编辑框里写长文。更推荐的做法是：在本地用 VS Code 或其他 Markdown 编辑器写，写完后复制 Markdown 源码，粘贴到目标平台的 Markdown 编辑器。这样做的意义在于，本地 Markdown 文件的格式是可以被 lint 工具检查的，而富文本编辑框里的格式是不透明的。

8.2 坚持“粘贴为纯文本”原则

如果你必须从其他网页、Word 文档或 PDF 中复制素材，第一遍请粘贴为纯文本（快捷键 Ctrl+Shift+V），然后再在目标编辑器中设置标题和正文。这个习惯能帮你规避 80% 的内联样式污染。很多人问“为什么我复制过来的文字字体总是对不上”，答案就藏在这里。

8.3 给团队建立文档模板与样式指南

团队知识库最怕的不是内容没人写，而是每个人写出来的格式都不一样：有人用一级标题当大标题，有人用三级标题；有人直接在正文里调字号，有人用引用来强调。长期来看，这会造成维护成本急剧上升。建议团队维护一个 Markdown 模板文件，规定：

• 标题最多使用几级
• 标题与正文之间是否必须空行
• 代码块是否必须指定语言
• 强调统一使用**加粗**还是> 引用
• 截图统一使用什么样的命名和路径

样式指南不一定要很复杂，一页纸就够。关键是让团队形成统一的写作习惯。

8.4 在文章入库或发布前加入自动检查

对于维护技术方案的团队，可以考虑在 CI 流程中加入 Markdown lint 检查。每次文档更新时自动跑一遍，格式不规范就直接阻止合并，让问题在进入知识库之前就被消灭。这个成本不高，收益却很明显。

8.5 不要依赖手工<font>或style

很多“字体忽大忽小”的根源，都是某个历史版本的作者手动加了<font size="5">。这种写法不仅不符合 Markdown 的维护理念，而且在换平台时会原样保留，带来极大的样式冲突。正确的做法是：用 Markdown 语义符号表达结构，用平台主题控制视觉呈现。如果平台主题无法满足需求，优先使用平台提供的提示块、代码块、引用块等组件，而不是用像素级控制。

9. 总结与后续学习方向

回头再看“字体忽大忽小”这件事，它可以被简单归结于“格式来源不干净”或“渲染规则不熟悉”。但如果你愿意多走一步，把它当作一个技术问题去解决，你其实会学到三件更有价值的事：一是 HTML 与 CSS 优先级的基本原理，二是 Markdown 语法规范比想象中严格，三是“可复现的格式检查”比“人工盯着屏幕调”更可靠。

这篇文章提供的清理脚本和检查命令，建议先复制到一个测试目录里，用你自己的文章试一遍。第一次跑通之后，你可能会发现，很多排版问题在你粘贴到博客之前就已经注定要发生了。下次再遇到标题忽大忽小的情况，先做两件事：用 Ctrl+Shift+V 粘贴纯文本，再检查源码里有没有style和font标签，问题基本就解决了一半。如果还想深入，后面可以从 CommonMark 规范、markdownlint 规则集、HTML 渲染原理这几个方向继续研究。格式问题不是“写多了自然就好”，而是“规则清楚了就一定好”。