企业官网建设流程全解析

用 Markdown 写带数学符号的内容，最尴尬的不是不会写，而是写完发现它不渲染。我见过太多人把\frac{a}{b}直接敲进笔记，预览出来还是一串反斜杠，然后转头去截图贴在文档里——半年后回头想改一个下标，只能重新截一张。Markdown 的数学公式和符号这件事，表面上是"记几个 LaTeX 命令"的问题，实际上牵扯到渲染引擎方言、分隔符开关、行内基线对齐、公式编号、跨格式导出一整条链路，任何一环出问题都会让你前功尽弃。

这篇内容把这件事从头到尾捋一遍。核心围绕 Markdown 里的数学符号与公式写法展开：为什么同样的写法换个平台就废掉，行内公式和中文混排时基线为什么会错位，矩阵、分段函数、多行对齐这些稍微复杂一点的排版怎么落地，最后成稿要导成 PDF 或 Word 时公式怎么才能不丢。写技术笔记、论文草稿、教学讲义、项目设计文档的人都能用上，新手可以当成速查手册直接抄，写过几年的老手也能从排查和导出那两节里挑几条细节回去改自己的模板。

我自己的习惯是：符号速查表常驻编辑器侧边栏，遇到没见过的符号先查再写，绝不凭记忆硬敲。下面按"为什么这样设计—环境怎么配—符号怎么写—排版怎么调—成稿怎么导出—出错怎么查"的顺序展开，每一节都能独立拎出来用。

1. 先说清楚：Markdown 里的公式为什么容易翻车

1.1 三条技术路线的取舍：纯文本字符、图片、LaTeX

把公式放进 Markdown，实际只有三种做法，每一种都有自己的舒适区和死穴。

第一种是直接用 Unicode 字符凑，比如αβ∑∫√≈≤。这条路的好处是零依赖，任何编辑器、任何聊天窗口、任何邮件客户端打开都是原样，不会因为渲染器缺失而变成乱码。但它的表达能力极其有限：分数写不出来，只能写成a/b；上下标只能靠 Unicode 里那几个可怜的字符（²³₁）硬充，一旦是x^{n+1}这种复合形式就彻底没辙；矩阵、分段函数、多行对齐更是想都别想。它适合的场景只有一种——一句话里插一个简单符号，且你确定接收方不会用渲染器。

第二种是截图贴图片。这是最省事也最贵的做法。省事在于所见即所得，任何平台都能显示，不依赖对方有没有数学渲染能力；贵在于它的代价是复利式的。图片进版本控制后没法做差异对比，改一个下标要重新截图，文件体积膨胀，全文搜索搜不到，深色模式下列表会被反色搞得难看，论文排版时缩放还会糊。如果这份文档只活三天，图片没问题；如果要活三年，图片就是负债。

第三种是写 LaTeX 表达式。它本质上是纯文本，所以能被 Git 追踪、能全文检索、能跨平台复用，改一个字符就是改一个字符。代价是它必须依赖渲染器：平台认识它，它就是漂亮的数学排版；平台不认识它，它就是一堆反斜杠。这也正是大多数人卡住的地方。

我的判断标准很粗暴：这份内容我三个月内会不会再改？会改就写 LaTeX，不改才考虑截图。

1.2 渲染引擎决定了你能用哪些语法，而不是你想用哪些

同一个 LaTeX 表达式在不同平台表现不一样，根因是底层渲染引擎不同。目前主流就两个：KaTeX和MathJax。

KaTeX 的设计目标是快，走同步渲染，页面加载时公式就已经排好了，不会有"先出现源码再闪一下变成公式"的跳变感。代价是它只实现了 LaTeX 数学语法的一个子集，一些依赖宏包的高级写法它不认。MathJax 走的是完整路线，AMS 数学环境、自动编号、自定义宏基本都能覆盖，但渲染是异步的，首次加载会有明显的延迟和重排。

这个差异带来的实际后果是：你在 A 平台写顺手的写法，搬到 B 平台可能直接报红或者原样显示。常见的分界线有这么几条：

• 自动编号和交叉引用：MathJax 配好之后支持\label配合引用，KaTeX 基本只支持手动\tag，且部分平台会把\tag屏蔽掉。
• 某些多行环境：像split、multline这类，支持的广度不一，aligned和gathered的兼容性明显更好。
• 自定义宏：\newcommand在多数托管平台上是被禁用的，因为怕你定义出影响全局的东西。
• 中文：\text{}里放中文，部分渲染器会因为字体缺字显示成方块。

再说分隔符方言，这是新手最容易踩的一层。行内公式常见写法有$...$和\(...\)，块级公式有$$...$$和\[...\]。不同的 Markdown 处理器对这几个的开关默认值不一样。有的平台为了不误伤金额（比如$100），默认关掉了单美元行内公式，只认$$。有的平台反过来，只认\(...\)，不认单美元。

注意：GitHub 系的渲染器只认$...$、$$...$$和围栏代码块里的math语言标记，不认\(...\)和\[...\]。如果你的文档主要托管在这类平台上，全文统一用美元符号，别混着写。

理解了这一层，后面所有的"为什么我这里不渲染"就都有了解释框架：要么是引擎不支持这个语法，要么是分隔符开关没打开。这两条占了公式故障的八成以上。

2. 环境准备：让编辑器和平台认得你的公式

2.1 编辑器与插件怎么选，看你的交付形态

选工具这件事别跟风，先问自己一句话：最终这份东西交付给谁看？交付形态决定了工具形态。

如果你写的东西最终要变成网页或提交到代码仓库，那就用 VS Code 这类编辑器，装数学预览插件，写作时按Ctrl+Shift+V（部分平台是Ctrl+K再按V）打开预览窗口，边写边看。这类编辑器的优势是纯文本、和 Git 天然合得来，缺点是所见即所得程度低，你得习惯左右分栏。

如果你只是给自己做知识库，那用本地笔记类工具更舒服，它们的数学渲染是内置的，输入即时生效，不用折腾配置。缺点是导出链路往往被工具锁死，格式转换时容易掉东西。

如果你做的是数据分析或教学演示，Jupyter 系的 notebook 值得优先考虑。它的 Markdown 单元格原生支持$...$和$$...$$，公式和代码结果放在一起，讲解类内容非常顺。顺带说一个高频问题：Jupyter 本身没有内置目录功能，需要靠扩展插件来生成可点击的目录，这在写长笔记时几乎必装。

还有一个容易被忽略的坑：浏览器剪藏类插件把网页转成 Markdown 时，公式经常被切碎。网页上的公式在 HTML 里往往是几十个嵌套标签拼出来的，转 Markdown 时要么整体丢掉，要么被拆成一段段零散字符。所以从网页搬运公式，别指望一键转换，准备好手动返工。

2.2 三个必须确认的配置项：分隔符、换行、渲染开关

环境搭好之后，有三件事必须动手确认，否则后面全是玄学问题。

第一件：行内公式的分隔符开关。绝大多数"我写了$x$但它原样显示"的问题，都是因为这个开关默认关闭。很多渲染器出于防止误伤金额的考虑，默认只开$$；你需要显式打开单美元行内模式。VS Code 系的配置大致是这个形状，注意键名以你所装插件的说明为准，不同插件命名差异很大：

{ "markdown.preview.breaks": true, "markdown.extension.math.enabled": true, "markdown.extension.katex.macros": {} }

打开之后立刻会带来一个新的风险：文本里的美元符号会被误当成公式起止符。比如你写"预算是 $100 到 $200 之间"，两个美元之间的内容会被整段当成数学模式吃掉，排版瞬间崩坏。规避方式是在正文里对美元符号做转义，写成\$，或者干脆把金额写成"100 美元"这种中文表述，从源头绕开。

第二件：换行的语义。Markdown 里"换行"和"分段"是两回事。单个回车在多数解析器眼里只是空格，想强制换行有三种做法：行尾留两个空格再回车、行尾加反斜杠再回车、或者直接写 HTML 换行标签。这是段落层面的换行，跟公式内部换行完全是两个概念——公式里换行要用\\，这是 LaTeX 的语法，跟 Markdown 无关。很多人卡在这里，是因为他把"公式不换行"和"文字不换行"当成同一个问题去查，越查越乱。

第三件：确认代码块里的美元符号不被解析。这一点在写教程时尤其重要。你在围栏代码块里演示$x^2$，如果渲染器把代码块里的内容也当公式解析，读者复制到的就是渲染结果而不是源码。标准行为是代码块内不解析数学，但总有实现不严谨的平台会出问题，所以发布前一定用预览窗口实机看一遍。

2.3 一个便宜的验证手法

配置完之后别急着写正文，先花两分钟做一次冒烟测试。写四行内容：一行行内公式、一行块级公式、一行带上下标的分式、一行矩阵。如果这四行都能正确渲染，说明环境基本没问题；如果其中某一行失败，问题范围就锁死在具体语法上，而不是环境上。这个习惯能帮你省下大量"到底是环境坏了还是我写错了"的纠结时间。

3. 常用数学符号速查：从上下标到矩阵

这一节是速查表性质的内容，我把它按使用频率和难度分成几组。建议你在自己的笔记工具里建一个"符号速查"页面，把下面这些原样贴进去，以后写公式直接复制，比记命令靠谱。

3.1 基础构件：上下标、分式、根式与括号

上下标是最基础也最容易出错的一环。单字符上下标可以直接连着写，但多字符的上下标必须用花括号包起来，这是新手最高频的错误来源：

x^2 % 上标 x^{n+1} % 多字符上标，必须加花括号 x_1 % 下标 a_{i,j} % 多字符下标 x_i^2 % 上下标同时存在 {}^{14}\text{C} % 左上标，比如同位素

如果你把x^{n+1}写成x^n+1，渲染出来是"x 的 n 次方再加 1"，意思完全变了。这类错误在数学上是致命的，不是排版瑕疵。

分式的标准写法是\frac{分子}{分母}，它会根据所处环境自动伸缩大小。在行内公式里，分式会被压得很扁，看起来和周围文字不协调；这时候可以用\tfrac强制用文本尺寸，或者干脆写成斜杠形式a/b。反过来，在大段推导里想让某个分式显得更醒目，可以用\dfrac强制用展示尺寸。连分式用\cfrac，它不会像\frac那样越套越小：

\frac{a+b}{c-d} \dfrac{\partial u}{\partial t} \cfrac{1}{1+\cfrac{1}{1+x}}

根式的写法是\sqrt{x}，开 n 次方写成\sqrt[n]{x}，那个方括号里的数字是可选参数：

\sqrt{x^2+y^2} \sqrt[3]{8}=2

括号是另一个细节密集区。直接写圆括号在简单场景够用，但只要内容稍微高一点（比如里面有分式），括号就显得太矮，包不住。解决办法是用伸缩括号：

\left( \frac{a}{b} \right) \left[ \frac{a}{b} \right] \left\{ \frac{a}{b} \right\} \left\lvert x \right\rvert % 绝对值 \left\lVert \vec{v} \right\rVert % 范数

注意：\left和\right必须成对出现，只写一个会直接报错。如果确实只需要一边，另一边要写成\right.或\left.，那个点号表示"这边不需要符号但我要配对"。

如果不想让括号自动伸缩，也可以手动指定尺寸，从小到大是\big、\Big、\bigg、\Bigg。什么时候用手动？当你希望整篇文档的括号尺寸保持一致、不被内容高低牵着走的时候。

3.2 希腊字母、关系符、集合与逻辑符号

希腊字母是理工文档的日常。这里有个必须强调的点：同一篇文档里，符号的写法要统一。因为 LaTeX 里有些希腊字母有两个视觉上不同的版本，比如\epsilon和\varepsilon、\phi和\varphi、\theta和\vartheta。你如果在这一段用前者、那一段用后者，读者会以为这是两个不同的量。

需要留意的是，大写希腊字母里有一部分长得和拉丁字母一模一样（比如\Alpha就是 A），这类写法在 LaTeX 里通常不提供，直接用大写拉丁字母即可。

关系符和运算符这一组，日常出场率最高的是这几个：

a \leq b \quad a \geq b \quad a \neq b a \approx b \quad a \equiv b \quad a \sim b a \propto b \quad a \ll b \quad a \gg b a \perp b \quad a \parallel b

集合与逻辑运算：

x \in A \quad x \notin A A \subset B \quad A \subseteq B \quad A \supset B A \cup B \quad A \cap B \quad A \setminus B \emptyset \quad \forall x \quad \exists y \quad \nexists z \neg P \quad P \land Q \quad P \lor Q P \implies Q \quad P \iff Q

箭头这一组经常被忽略，但在描述映射、极限、变换时离不开：

f: X \to Y x \rightarrow 0 A \Rightarrow B \quad A \Leftarrow B \quad A \Leftrightarrow B x \mapsto x^2 f \uparrow \quad f \downarrow

数集符号用黑板粗体，写法是\mathbb{}：

\mathbb{N} \quad \mathbb{Z} \quad \mathbb{Q} \quad \mathbb{R} \quad \mathbb{C}

还有一组装饰符，用来标注向量、估计量、平均值，在统计类文档里几乎是刚需：

\vec{v} \quad \hat{\theta} \quad \bar{x} \quad \tilde{y} \dot{x} \quad \ddot{x} \overline{AB} \quad \underline{z} \overbrace{a+b}^{n} \quad \underbrace{a+b}_{n}

3.3 大运算符、函数名与微积分写法

这一组是写推导过程时的高频区。先说要害：函数名一定要用带反斜杠的命令形式。你直接写sin x，渲染出来是三个斜体字母 s、i、n 相乘；写\sin x，渲染出来才是正体的函数名。这个差别在专业读者眼里非常明显。

\sin \cos \tan \cot \sec \csc \arcsin \arccos \arctan \log \ln \exp \max \min \sup \inf \lim \liminf \limsup \det \dim \gcd \ker \deg

大运算符指的是求和、连乘、积分、极限这一类带上下限的符号：

\sum_{i=1}^{n} a_i \prod_{i=1}^{n} a_i \int_{a}^{b} f(x)\,dx \iint_{D} f(x,y)\,dx\,dy \oint_{C} \vec{F}\cdot d\vec{r} \lim_{x \to 0} \frac{\sin x}{x} = 1

实操心得：\sum、\int这类符号在行内公式里会把上下限挤到右下角，非常难看。如果这个式子比较重要，就把它提成独立的块级公式；如果必须行内，至少要接受它的视觉效果打了折扣。

微积分里的微分符号，有两条常见路线。一种是直接把 d 当变量写，渲染成斜体；另一种是用\mathrm{d}或者\text{d}写成正体。学术期刊对这两者要求不一，关键是一篇文档里只能选一种，别一段斜体一段正体。

\frac{dy}{dx} \frac{\partial f}{\partial x} \frac{\partial^2 u}{\partial x \partial y} \nabla f \Delta x \mathrm{d}u

举个完整例子，把一元二次方程的求根公式写出来：

x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}

再比如最小二乘的解析解，这个式子在数据类笔记里出现频率极高：

\hat{\boldsymbol{\beta}} = (X^{\mathsf{T}} X)^{-1} X^{\mathsf{T}} y

海伦公式求三角形面积，是几何讲义里的常客：

S = \sqrt{p(p-a)(p-b)(p-c)}, \quad p = \frac{a+b+c}{2}

排列组合里的两个计数符号，写起来也各有讲究：

A_n^k = \frac{n!}{(n-k)!} C_n^k = \binom{n}{k} = \frac{n!}{k!\,(n-k)!}

用\binom{n}{k}写出来的组合数是标准的双层括号形式，比手写上下标对齐好看得多，这是排版规范问题，不是口味问题。

3.4 矩阵、分段函数与多行对齐

矩阵用matrix系列环境，外面配不同的括号就得到不同外观：

\begin{pmatrix} a & b \\ c & d \end{pmatrix} \begin{bmatrix} a & b \\ c & d \end{bmatrix} \begin{vmatrix} a & b \\ c & d \end{vmatrix}

pmatrix是小括号，bmatrix是方括号，vmatrix是竖线（行列式）。行与行之间用\\分隔，同一行内的元素用&分隔。元素多起来之后，建议在源码里手动对齐&的位置，虽然渲染结果不受影响，但你自己维护的时候会舒服很多。

分段函数用cases环境，它自带一个左侧大括号，但注意这个括号不会随内容高度自动伸缩，如果每个分支都很高，需要改用\left\{配合array手动搭：

f(x) = \begin{cases} 1, & x > 0 \\ 0, & x = 0 \\ -1, & x < 0 \end{cases}

多行对齐是写推导过程的核心技能，用aligned环境，&标出对齐位置，\\换行：

\begin{aligned} (a+b)^2 &= (a+b)(a+b) \\ &= a^2 + ab + ba + b^2 \\ &= a^2 + 2ab + b^2 \end{aligned}

这里&=的意思是"第二个及以后的等号要和第一个等号对齐"，视觉上所有等号排成一列，读起来非常顺。如果你想让多个等式都对齐在等号上，每一行都写&=。

一个真实例子，把贝叶斯公式展开写清楚：

P(A \mid B) = \frac{P(B \mid A)\,P(A)}{P(B)}

条件概率里的竖线要用\mid，它会自动处理左右间距。如果你直接敲键盘上的竖线字符，多数渲染器会把它当成普通符号，间距会很难看，甚至在 Markdown 表格里还会破坏表格结构。这一点后面排查那节还会再提。

欧拉公式这种"一句话经典"，用块级公式呈现最合适：

e^{i\pi} + 1 = 0

还有一个常见的符号疑问：交叉熵和 KL 散度里的负号到底该不该有。这件事的本质是方向的约定，不是排版问题。写成H = -\sum p \log q时，负号的作用是把"越小越好"的损失函数变成非负值；写成D_{KL} = \sum p \log(p/q)时，通过交换对数里分子分母的位置来保证非负。两种写法数学上等价，但同一个文档里只能选一种约定，并且要在符号说明表里写明方向，否则读者读到一半会以为你写错了。

4. 排版实战：把公式写进真实文档的六个场景

符号会写了，接下来是把它嵌进真实文档里。这一节讲的全是实际写作中冒出来的问题。

4.1 行内公式和文字基线错位怎么处理

这是被问得最多的一类问题，没有之一。现象是：一段中文里插了一个行内公式，公式明显比周围的汉字高出一截或者低下去一截，整行的行高被撑开，看起来像排版事故。

原因通常有这么几个，按出现频率排：

第一，行内公式里用了分式、根式或者带上下限的求和积分。这些符号天生就比文字高，一个\frac{a}{b}的行内公式，高度能顶两行中文。这不是渲染器有 bug，是它老老实实把分式排出来了，结果就是撑开行高。

第二，行内公式里用了展示环境。有些人习惯写\displaystyle强制让行内公式用大尺寸排版，那当然更对不齐了。

第三，公式是图片。图片的垂直对齐由行内元素的基线规则决定，很多平台默认按图片底边对齐文字基线，视觉上就是偏上，需要额外的样式处理。

第四，中英文字体混排。汉字是方块字，行高比例和拉丁字母差别大，公式里的拉丁字母跟着中文字体走的时候，基线容易飘。

解法按代价从低到高排：

• 把复杂公式从行内提成块级独立公式。这是最有效的一招，也是我最推荐的。凡是带分式、根式、求和上下限的式子，一律独立成行，既好看又好读。
• 行内确实需要分式时，降级写法。\frac{a}{b}改成a/b，或者用\tfrac强制小尺寸。
• 给公式元素加垂直对齐样式，让它按中线对齐。这在 HTML 输出里可以调，但在纯 Markdown 层面通常没法控制。
• 用\vphantom{}占位来统一高度。这个技巧知道的人不多：\vphantom{\frac{a}{b}}本身不显示任何内容，但它占的高度和分式一样，所以你可以用它把同一行里几个原本高低不齐的元素"顶"到一样高。适合在矩阵或者多分支公式里对齐用。

举个实际例子，同一行里既有分式又有普通变量，你可以这样处理：

\text{当 } a>0 \text{ 时，} \quad x_{1,2} = \tfrac{-b \pm \sqrt{b^2-4ac}}{2a}

把\frac换成\tfrac之后，行高明显收敛，跟中文的贴合度好很多。

4.2 公式编号与交叉引用的现实做法

写论文、写规范文档的人一定会遇到公式编号。理想情况是让引擎自动编号、自动引用，可惜在 Markdown 生态里这一块的支持参差不齐。

主流做法有三种。第一种是手动\tag{}，你写多少号就是多少号：

E = mc^2 \tag{1}

这种方式在 KaTeX 和 MathJax 里都能用，前提是它处于块级公式环境，且所在平台没有禁用这个命令。缺点显而易见：你没法自动引用，插一个新公式进去，后面所有编号都得手动改。

第二种是开启渲染引擎的自动编号能力。MathJax 系可以配置成按 AMS 规则自动编号，equation环境自增，\label配合\ref或\eqref做引用。这条路体验最接近专业排版系统，但依赖平台配置，而且在 Markdown 预览器里通常不生效，只有最终发布的页面上才生效。

第三种，也是我在工程文档里最推荐的：在公式旁边维护一张编号表。用 Markdown 表格自己维护，格式是"编号—公式摘要—所在章节"三列。这样做的好处是编号可控、可搜索、可批量改，而且不依赖任何渲染引擎的特殊能力。改编号的时候，你只要改表格里那一行，正文里的引用是基于语义写的，比如"见式 (4.2) 的收敛条件"，语义引用的好处是即使编号变了，读者也能靠上下文找到。

注意：\label和\eqref在绝大多数 Markdown 托管平台是不生效的，别把它当成必选项。写正式文档之前先确认目标平台支持到什么程度，不然等你写了两百个公式才发现引用全废，返工成本极高。

还有一种情况值得单独说：公式编号和章节编号的对齐。如果你用的是"章节号.序号"这种形式（比如式 (4.2)），那么插入或删除一个章节会让全篇编号乱套。我的做法是在文档定稿前最后统一编号，中间过程一律用临时占位，避免反复返工。

4.3 长公式换行与断行位置的选择

公式太长溢出屏幕，这是版面问题里最影响可读性的一类。断行的基本原则是：在关系符或运算符处断开，不要在一个项的内部断开。人类读公式是在读结构，你在a^2 + b^2中间断开，读者会以为那里是一个新项的开始。

具体做法是用aligned环境，把断点放在等号或者加号处，并且用&让断行的位置对齐：

\begin{aligned} f(x) ={}& a_0 + a_1 x + a_2 x^2 \\ &+ a_3 x^3 + a_4 x^4 \end{aligned}

注意={}这个写法。如果只写=&，等号后面的间距会丢失，看起来等号和下一行内容贴在一起。加上一对空花括号{}可以保住正确的间距，这是个很实用的小技巧。

还有几种断行环境，但要留意兼容性。split在多数引擎里能用，multline的支持范围就窄一些，尤其在 KaTeX 系里经常报错。保险的做法是优先用aligned，它的兼容面最广，绝大多数平台都能正确渲染。

断行的另一个坑是在分数里。如果你在\frac{}{}的分子里用\\换行，有的引擎会直接报错，因为分数参数不是多行环境。遇到很长分数的场景，正确的做法是把整个式子改写成乘法形式，或者用\cfrac写成连分式。这是数学表达的重构，不是单纯的排版调整。

4.4 量纲、单位与符号说明表的规范

技术文档和纯数学文档的区别，在于前者要处理物理量和单位。这一块有几条不太写在教科书里但实际很重要的规则。

数值和单位之间要留细空格，用\,控制，不要用普通的空格，因为普通空格在数学模式里会被吃掉：

g = 9.8\,\mathrm{m/s^2} m = 5\,\mathrm{kg}

单位的正斜体约定是：变量斜体，单位正体。所以要写\mathrm{m}而不是m。这条规则在工程类文档里几乎是硬要求，写成斜体会被专业读者一眼挑出来。温度、角度、百分号这些也有各自的写法，关键是全文一致。

再说符号说明表。写数学建模或者算法文档时，几乎一定需要一张"符号—含义—单位—备注"的表格。用 Markdown 表格配合行内公式完全可行，但要留意两点：一是表格单元格里不能出现裸的竖线字符，因为那会破坏表格结构，需要用\mid或者\lvert这类命令代替；二是单元格里的公式不要太复杂，矩阵、多行公式放进表格会撑破列宽。

一个可用的符号说明表长这样：

这类表格的另一个好处是，它可以直接转成电子表格做进一步处理，编辑维护起来比散落在正文里的定义高效得多。

4.5 从网页、论文和 AI 回答里搬运公式的清洗流程

这是实际工作中出现频率极高、但很少被正面讲清楚的环节。你从别处拿到一段带公式的内容，直接粘进自己的文档，十有八九是坏的。下面是我自己用的一套清洗流程。

第一步，剥掉 HTML 外壳。从网页复制的公式，源码里往往包着一堆span标签，带着各种类名和样式属性。你要做的是把这层外壳去掉，只保留数学表达式本身。

第二步，统一分隔符。把所有\(...\)统一替换成$...$，把所有\[...\]统一替换成$$...$$。这一步是机械操作，但必须做，因为混用分隔符会让你后面排查问题时无法判断到底是哪种方言在出错。

第三步，抓不可见字符。这一条最隐蔽。网页和文档软件复制出来的内容里，常常夹着零宽空格、不间断空格、软连字符这类看不见的字符。它们肉眼不可见，但会让公式渲染失败。我的做法是把内容粘进纯文本编辑器，开显示不可见字符的选项看一眼，有异常字符就全局清掉。

第四步，处理不兼容的命令。换行符\\在不同环境里写法不同，有的地方复制过来是双反斜杠，有的是一个；粗体命令\boldsymbol在部分渲染器里不支持，要换成\mathbf；\displaystyle在不需要的地方要删掉，否则行内公式会被撑开。

第五步，检查下划线和星号。这是个真实存在的坑：行内公式里如果出现多个下划线，某些 Markdown 处理器会把它当成强调标记来解析，导致公式后半段莫名其妙变成斜体。是否出现取决于渲染流水线是先切数学节点还是先做强调解析。规避方式很简单：遇到这种情况就把公式从行内升级成块级独立公式，块级公式通常会被完整地保护起来。实在需要行内的，检查渲染结果，不对就换写法。

第六步，处理图片型公式。如果来源是图片，需要走 OCR 识别。现在有不少工具能把公式图片转成 LaTeX 源码，识别之后仍然要走前面五步做清洗，因为识别结果里经常有多余空格和错误的命令名。识别完务必逐个符号对照原图核对，尤其是下标数字和希腊字母，这两类识别错误率最高。

第七步，如果目标格式是 Word。有一个省事的路径：在 Word 的公式编辑区里直接输入 LaTeX 语法，它会自动转换成 Word 原生公式对象。这样得到的公式是可编辑的，缩放不失真，比贴图片强得多。要注意的是这种转换对语法严格，前面清洗不干净的公式会转换失败，所以清洗步骤不能跳。

4.6 几类高频公式的写法示范

把前面讲的拼起来，看几个完整例子。这些式子在技术文档里出现频率很高，可以直接拿去用。

一元二次方程求根公式，注意判别式里的减号和根号：

x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}, \quad \Delta = b^2 - 4ac

对数还原关系和换底公式，写清底数是关键：

\log_a (MN) = \log_a M + \log_a N \log_a b = \frac{\ln b}{\ln a}

技术分析或者时序类文档里常用的移动平均定义，是个很典型的求和公式：

\mathrm{MA}_n(t) = \frac{1}{n} \sum_{i=0}^{n-1} P_{t-i}

功率电子或者电路笔记里的基本关系，写清楚每个量的含义即可：

V_o = D \, V_{in}, \quad D \in [0, 1]

仿真类文档里经常需要给出量之间的换算关系，比如导纳和阻抗互为倒数：

Y = \frac{1}{Z} = G + jB

复利和年化增长这类业务口径公式，写进文档的好处是口径被固定下来，不会因为不同人在表格里各写各的而对不上：

\mathrm{CAGR} = \left( \frac{V_{\text{终}}}{V_{\text{始}}} \right)^{\frac{1}{n}} - 1

这些例子的共同点是：结构简单、含义明确、上下标层级不深。真正的难点不在这些公式本身，而在于把它们放进一篇有几百个公式的文档后，如何保持格式一致。

5. 成稿导出：公式不丢的几条链路

5.1 导出 PDF 的现实路径

Markdown 转 PDF 的常见做法有两种，各有各的坑。

一种是用编辑器的预览加浏览器打印。原理是把渲染好的 HTML 页面按打印样式输出成 PDF。这条路的好处是所见即所得，预览里公式长什么样，PDF 里就长什么样；关键前提是你预览的时候公式确实渲染成功了，如果预览里就是一堆反斜杠，导出结果只会更糟。

另一种是用 Pandoc 类工具做转换。基本命令形如：

pandoc input.md -o output.pdf --pdf-engine=xelatex

这条路的能力更强，尤其适合批量转换和自动化。需要留意两点：一是公式能否被正确识别为数学模式，取决于输入格式的扩展开关，默认情况下美元符号包裹的数学是开启的；二是中文支持需要额外指定字体，否则会出现方块或者缺字。转换之前先把中文参数配好，不然得到一堆豆腐块，排查起来很费时间。

5.2 导出 Word 的注意点

转 Word 有一个隐藏优势：主流的转换工具会把公式转成 Word 的原生公式对象，而不是图片。这意味着对方拿到文档后可以直接双击修改，缩放不失真，深色模式下也不会反色。这一点对于需要评审、需要反复修改的文档来说价值巨大。

但要注意，转换后的公式对象和 Word 公式编辑器里的原生公式，在细节上可能略有差异，比如字体、间距、符号字形。发布前一定要在 Word 里从头翻一遍，重点看三类地方：分式的横线长度、矩阵的列对齐、以及长公式有没有溢出页面边距。这三类问题在转换后出现概率最高。

还有一个现实问题：如果文档里的公式量很大，转换时间会明显变长，而且失败时的报错信息通常很含糊。建议的做法是分批转换，比如按章节拆成几个文件分别转，哪个文件出错就缩小到那个章节里排查，比一次性转整篇再靠肉眼找问题高效得多。

5.3 平台不渲染公式时的降级方案

不是所有交付场景都有数学渲染能力。邮件、某些内部系统、代码评审界面，都可能把你的公式原样显示成一堆反斜杠。这时候需要准备降级方案。

最省事的是把公式包进带语言标记的代码块里，读者看到的是干净的 LaTeX 源码，至少能复制到别处去渲染：

x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}

第二种是给公式配一段文字说明。尤其在沟通场景里，把公式的含义用一句话讲清楚，比让人盯着一个渲染失败的符号强得多。

第三种是用 Unicode 近似表达简单式子。比如x²代替x^2，a/b代替分式。这招只对简单式有效，复杂式强行降级会变成天书，不如不降。

第四种是图片加替代文本。图片保证显示，替代文本保证可访问性和可搜索性。这种做法适合最终交付物，不适合需要长期维护的源文档。

我的经验是：同一份内容，源文档永远用 LaTeX，交付副本按接收方的能力再做降级。别为了迁就某一个不支持的平台，把源文档本身改坏。

6. 常见问题与排查速查

6.1 公式不渲染，八成是这几个原因

这一节做成速查表，出问题的时候按顺序对照。

这张表我建议你贴在笔记里，出问题的时候先扫一遍，绝大多数情况三十秒内能定位。

6.2 三个反直觉的排查经验

第一个经验：先怀疑内容，再怀疑环境。很多人一遇到公式不渲染就去翻设置、重装插件、换编辑器，折腾半小时之后发现是自己在公式里多打了一个花括号。正确的顺序是：先把出问题的公式单独拎出来，用最小化的方式测一遍——只留一个x^2，看它渲染不渲染。如果这个最简单的能渲染，问题就在你的公式内容里，跟环境无关。

第二个经验：对照组比反复试验有用。准备一个"已知能正常渲染"的公式作为对照，出问题的时候和它并排放。如果你的公式不渲染而对照的渲染，那就是写法问题；如果两个都不渲染，那就是环境问题。这个方法能省掉大量猜测。

第三个经验：别在行内公式里塞复杂结构。我统计过自己文档里的格式问题，超过一半来自行内公式。带分式的、带上下限的、带矩阵的，全部提成块级公式之后，问题数量断崖式下降。块级公式在绝大多数渲染流水线里都会被单独保护起来，不容易被 Markdown 的其他规则干扰。

6.3 复制粘贴与深色模式下的细节

还有几个零散但很实际的点。

复制公式给别人时，如果你复制的是渲染后的结果，粘贴到纯文本环境里通常会变成乱码或者一串无意义的符号。正确做法是复制源码。如果平台不支持源码视图，就在文档里额外保留一份源码版本，或者把公式放进代码块。这是个习惯问题，但能省下大量沟通成本。

深色模式下面，如果用图片公式，透明底色的图在深色背景上会很难看，黑字的图直接消失。这是图片方案的固有问题，换成 LaTeX 渲染就消失了，因为文字颜色会跟随主题。

打印场景下，块级公式居中还是左对齐，行内公式的基线偏移是否明显，页边距会不会把长公式切断，这三件事一定要在 PDF 里实机翻一遍。屏幕上看着没问题的公式，打印出来后经常会有几个字符被切到页外。我的习惯是导出后按页快速浏览，专挑最长的三五个公式看断行位置，这几处最容易出问题。

最后再分享一个我自己一直在用的小技巧：给文档建一个"公式定义区"。把所有重复出现的组合符号，比如某个常见的矩阵形式、某个反复使用的算子，统一写在一个区域里，然后用引用或者复制的方式使用。这样改一次就能全篇同步，不用在几百个公式里挨个找。这个习惯听起来很小，但在写超过二十页的文档时，能省下的时间是以小时计的。