1. 为什么写技术文档的人迟早要碰LaTeX我刚开始写技术博客那会儿最烦的就是在Markdown里敲公式。明明一段话讲得好好的突然要插一个带上下标的表达式整个排版就崩了。那时候我的做法很蠢——直接截图贴上去。结果文章发出去读者在手机上一放大图糊得跟马赛克似的评论区全是“能不能给个文字版”。后来被逼得没办法才认真去啃Markdown里的数学符号写法也就是大家常说的LaTeX数学模式。这件事的本质其实很简单Markdown本身是纯文本标记语言它的设计初衷是让写作者专注于内容结构而不是排版细节。但数学公式天然需要二维排版——分数要上下叠、积分号要拉长、矩阵要成块对齐这些用纯文本根本表达不了。LaTeX数学模式就是在这个缝隙里补进来的方案它用一套基于反斜杠命令的语法把二维数学结构“降维”成一行文本再由渲染引擎还原成漂亮的公式。你如果写过技术文档、算法笔记、论文草稿或者只是想在博客里把“时间复杂度O(n log n)”写得专业一点那这套东西就是绕不过去的。它不要求你成为排版专家但至少得知道分数怎么写、希腊字母怎么打、多行公式怎么对齐。这篇文章就是把我这些年踩过的坑、总结出来的写法按实际使用频率从高到低捋一遍让你看完就能直接上手敲。2. 行内公式与块级公式先搞清楚两种模式的边界2.1 行内公式的触发方式与常见误用行内公式指的是嵌在正文句子中间的数学表达式比如“当x趋近于0时sin x与x的比值趋近于1”。在Markdown里行内公式通常用单个美元符号包裹写成$...$的形式。渲染之后公式会和文字在同一行内显示字号也会自动缩小以适配行高。这里有个新手最容易犯的错把美元符号和中文标点混在一起写。比如$x0$则...这种写法在某些渲染器里会因为标点符号的字符编码问题导致公式解析失败。我的习惯是在公式和中文之间留一个半角空格写成$x0$ 则...虽然看起来多了一点空隙但兼容性会好很多。另一个高频问题是行内公式里出现下划线。比如你想写变量名my_var直接敲$my_var$会被解析成“my”下标“var”显示成 (my_{var})。正确的做法是用\text{}包起来写成$\text{my\_var}$这样下划线才会作为普通字符显示。这个坑我在写数据库字段说明的时候踩过不止一次后来养成了习惯只要公式里出现多字母变量名一律用\text{}包住。2.2 块级公式的独立成行逻辑块级公式用双美元符号包裹写成$$...$$它会单独占一行并居中显示字号保持正常大小。适合用来展示需要强调的核心公式比如损失函数、物理定律、递推关系。块级公式有一个很实用的特性它内部的空格和换行会被保留。这意味着你可以在$$里面直接换行写长公式渲染器会自动处理对齐。比如写一个分段函数$$ f(x) \begin{cases} x^2, x \geq 0 \\ -x, x 0 \end{cases} $$这种写法在行内模式里是做不到的因为行内模式会把换行压成空格。所以我的判断标准很简单公式超过一个屏幕宽度或者需要多行对齐就用块级否则一律行内避免文章被公式切得太碎。注意不同平台对$$的解析规则有差异。有些要求$$必须独占一行有些允许和文字同行。最稳妥的写法是让$$前后都留空行这样在绝大多数渲染器里都不会出问题。3. 上下标、分数与根号高频结构的写法与避坑3.1 上下标的嵌套陷阱上标用^下标用_这个大家都知道。但嵌套的时候问题就来了。比如你想写 (a^{b^c})直接敲$a^b^c$会报错因为^后面只能跟一个字符或一个用花括号包起来的组。正确写法是$a^{b^c}$用花括号把b^c整体括起来。下标同理$x_{i,j}$里的逗号如果不包在花括号里渲染器可能只把i当作下标。我见过有人写$x_i,j$结果显示成 (x_i,j)逗号和j都跑到正常位置去了。这种错误在矩阵元素、序列下标里特别常见检查的时候要格外留意。还有一个组合场景同时有上下标。$x_i^2$和$x^2_i$渲染结果一样都是 (x_i^2)。但如果上下标内容复杂建议分开写清楚比如$x_{i}^{2}$可读性更好也方便后期修改。3.2 分数与根号的尺寸控制分数用\frac{分子}{分母}根号用\sqrt{被开方数}n次根号用\sqrt[n]{被开方数}。这几个命令本身不难难的是控制尺寸。行内公式里的分数会被压得很扁比如$\frac{a}{b}$显示出来就是 (a/b) 那种小号分数分子分母挤在一起。如果这个分数是句子的核心内容建议改成块级公式或者用\dfrac强制显示为大号分数。反过来块级公式里如果分数嵌套太多层会撑得特别高这时候可以用\tfrac压回小号。根号也有类似问题。$\sqrt{x}$在行内显示时根号的那个勾会变得很小有时候几乎看不清。我的经验是行内公式尽量用指数形式代替根号比如把 (\sqrt{x}) 写成 (x^{1/2})除非是二次根号这种约定俗成的写法。块级公式里就无所谓了随便用。命令效果适用场景\frac{a}{b}自适应尺寸分数通用行内块级均可\dfrac{a}{b}强制大号分数块级公式中强调\tfrac{a}{b}强制小号分数行内公式中避免撑高\sqrt{x}平方根块级公式\sqrt[n]{x}n次根号块级公式4. 希腊字母、运算符与关系符别再去复制粘贴了4.1 希腊字母的命名规律希腊字母在LaTeX里就是拼写转写大部分直接对应英文名。小写用\alpha、\beta、\gamma大写把首字母大写写成\Gamma、\Delta、\Theta。但有几个例外需要单独记\varepsilon和\epsilon是两个不同的符号前者是花体 (\varepsilon)后者是标准 (\epsilon)\varphi和\phi同理前者是 (\varphi)后者是 (\phi)。我个人的选择习惯是在公式里表示角度或相位时用\varphi因为它的开口更明显不容易和别的符号混淆表示集合空集时用\varnothing而不是\emptyset因为后者在某些字体下看起来像个圆圈加斜杠容易和“非”运算符搞混。4.2 运算符与关系符的语义区分运算符分几类二元运算符如\times、\div、\pm、关系符如\leq、\geq、\neq、箭头如\rightarrow、\Rightarrow、\leftrightarrow。这些符号的写法有规律大部分是在基础符号前加\再加限定词。但有几个容易写错的小于等于号是\leq或\le不是\leqq大于等于号是\geq或\ge不等于号是\neq或\ne。我见过有人写\leqslant那个是斜杠版本和普通的小于等于号不是一个东西。还有一个高频错误把\times写成*。在数学公式里*显示出来就是星号而\times显示的是乘号 (\times)两者语义完全不同。写向量叉乘、笛卡尔积的时候必须用\times写卷积或普通乘法可以用\cdot或直接省略。提示如果你记不住某个符号的命令可以在搜索引擎里搜“LaTeX symbol 符号名”或者用在线公式编辑器手写识别。但长期来看把常用符号的命令整理成一张自己的速查表效率最高。5. 多行公式与对齐从“能看”到“好看”的关键一步5.1 align环境的对齐原理多行公式如果只是简单换行用\\分隔就行。但要让等号对齐就得用align环境。写法是在$$里面包一层\begin{align}...\end{align}每行用标记对齐位置通常放在等号前面。$$ \begin{align} (ab)^2 a^2 2ab b^2 \\ (a-b)^2 a^2 - 2ab b^2 \end{align} $$渲染出来两行的等号会垂直对齐看起来非常整齐。的作用就是告诉渲染器“这里是对齐点”每行有几个就分几列列与列之间自动调整间距。这里有个细节align环境默认会给每行编号如果不想编号用align*。编号在写论文需要引用公式时很有用但写博客通常不需要所以我一般直接用align*省得还要处理编号样式。5.2 cases环境与矩阵的排版技巧分段函数用cases环境写法是\begin{cases}...\end{cases}每行用分隔“值”和“条件”。矩阵用matrix、pmatrix、bmatrix等环境区别在于外面的括号样式pmatrix是圆括号bmatrix是方括号vmatrix是竖线。矩阵的列对齐用分隔行用\\分隔。如果矩阵元素宽度差异大可以用\begin{pmatrix} a b \\ c d \end{pmatrix}这种紧凑写法也可以每个元素单独一行方便阅读。我倾向于紧凑写法因为矩阵通常不大展开写反而占篇幅。$$ A \begin{pmatrix} a_{11} a_{12} \\ a_{21} a_{22} \end{pmatrix} $$分段函数和矩阵的共同点是它们都是“块状结构”必须用块级公式。行内公式里塞cases或matrix会渲染得一塌糊涂这个边界要守住。6. 字体、间距与颜色让公式融入正文的细节功夫6.1 数学字体的切换逻辑LaTeX默认的数学字体是斜体这是为了区分变量和普通文本。但有些场景需要正体比如函数名sin、cos、log单位kg、m/s或者多字母变量名。这时候用\text{}或\mathrm{}切换。\text{}会继承周围文本的字体适合在公式里插入中文或普通英文单词。\mathrm{}强制使用罗马正体适合函数名和单位。还有\mathbf{}加粗、\mathit{}斜体、\mathcal{}花体、\mathbb{}空心体这些在写集合论、线性代数时经常用到。我个人的习惯是函数名一律用\sin、\cos这种预定义命令而不是\text{sin}因为预定义命令会自动处理间距比如\sin x里sin和x之间会有合适的空隙而\text{sin} x会挤在一起。6.2 间距的微调与颜色的克制使用公式里的间距可以用\,、\;、\quad、\qquad来手动调整分别对应不同宽度的空白。\,最窄\qquad最宽。什么时候需要手动调间距比如积分号后面的微分算子dx前面通常加一个\,写成\int f(x)\,dx这样dx不会紧贴着f(x)视觉上更舒服。颜色用\color{red}{...}或\textcolor{red}{...}但我要给个忠告技术文档里的公式尽量别用颜色。颜色在不同主题下可能看不清而且打印出来全是灰度颜色信息直接丢失。如果非要强调某部分用加粗或下划线更稳妥。命令效果建议使用场景\text{}继承正文字体公式内插入中文或单词\mathrm{}罗马正体函数名、单位\mathbf{}加粗向量、矩阵\mathcal{}花体集合、空间\mathbb{}空心体数集实数集、整数集7. 渲染器差异与兼容性写完能显示才是硬道理7.1 常见渲染引擎的行为差异Markdown本身不解析LaTeX真正干活的是渲染引擎。不同引擎对LaTeX的支持程度差别很大。有的只支持基础命令align、cases这些环境直接报错有的要求$$必须独占一行有的对中文和公式混排的处理方式不同。我踩过最坑的一次是在本地编辑器里预览一切正常发到平台上公式全变成乱码。后来排查发现那个平台用的是另一套渲染引擎不支持\text{}里的中文。解决办法是把中文移到公式外面用普通文本写公式里只保留纯数学符号。所以我的建议是写完带公式的文章一定要在目标平台上预览一遍。如果平台支持实时预览就边写边看如果不支持就先在本地用同款引擎测试。别等到发布之后才发现公式挂了那时候改起来很麻烦。7.2 降级方案与纯文本备选如果目标平台对LaTeX支持实在太差可以考虑降级方案。最简单的降级是用Unicode字符代替LaTeX命令比如用≤代替\leq用×代替\times用α代替\alpha。Unicode字符在任何地方都能显示缺点是复杂公式没法表达比如分数和矩阵就无能为力。另一种方案是用图片但前面说过图片在移动端体验很差而且不利于搜索引擎抓取。我的折中做法是简单公式用Unicode复杂公式用LaTeX如果平台不支持LaTeX就在公式旁边附一张截图作为备选。虽然麻烦但至少保证了可读性。注意不要依赖某个特定平台的“公式插件”或“扩展语法”。这些插件往往绑定平台换一个地方就失效。掌握标准的LaTeX数学模式写法走到哪里都不怕。8. 我这些年攒下来的实战心得8.1 公式的可读性优先于美观很多人一开始追求公式“好看”花大量时间调间距、换字体、加颜色。但实际写技术文档可读性才是第一位的。一个公式如果读者看不懂再好看也没用。我的原则是能用简单符号表达就不用复杂结构能一行写完就不拆成多行能加文字说明就不全靠符号。比如写算法复杂度$O(n \log n)$就比$\mathcal{O}(n \log n)$更易读虽然后者更“数学规范”。写概率分布$P(Xx)$比$\mathbb{P}(Xx)$更亲切除非是面向数学专业的论文。这些选择没有绝对对错关键看读者是谁。8.2 建立自己的公式片段库写多了之后会发现很多公式结构是重复的。比如矩阵、分段函数、带上下标的求和、带极限的积分。与其每次从头敲不如建一个自己的片段库用的时候直接复制粘贴改改变量就行。我的片段库分几类基础结构分数、根号、上下标、常用符号希腊字母、运算符、复杂环境align、cases、matrix、排版模板带编号的公式、多行推导。每类下面存几个最常用的写法用文本文件管理搜索关键词就能找到。这个习惯帮我省了大量时间也减少了手误。8.3 遇到渲染问题时的排查顺序公式不显示或者显示异常排查顺序很重要。我的经验是按这个顺序来先检查美元符号是否配对$和$$的数量必须是偶数再检查花括号是否闭合{和}必须成对然后检查反斜杠命令是否拼写正确\frac写成\farc这种错误很常见最后检查渲染器是否支持该命令换个简单公式测试一下。如果以上都没问题但公式还是不对那可能是渲染器本身的bug。这时候可以试试把公式单独拎出来放在一个干净的Markdown文件里测试排除上下文干扰。实在不行就换一种写法用等效的简单命令代替复杂命令。8.4 中文与公式混排的间距处理中文和公式混排时间距问题特别烦人。公式紧贴中文会显得拥挤加空格又可能被渲染器忽略。我的做法是在公式前后各加一个半角空格如果渲染器还是挤就用\反斜杠加空格在公式内部加不可忽略的空白。还有一个技巧如果公式后面紧跟中文标点比如逗号、句号可以把标点放在公式外面写成$x0$而不是$x0$。这样标点会使用正文字体和公式的数学字体区分开视觉上更清晰。9. 从“会写”到“写得好”的最后一公里公式写多了慢慢会形成自己的风格。有人喜欢把所有符号都写得规规矩矩有人喜欢用简写提高效率。我的风格是核心公式用块级、加编号、写清楚推导步骤辅助说明用行内、能简则简符号命名保持全文一致不今天用\alpha明天用a。还有一点很重要公式是给读者看的不是给自己看的。写完一个复杂公式隔一天再回来看如果自己都要想半天才能理解那读者肯定更懵。这时候就该加文字说明或者把公式拆成几步。技术文档的价值在于传递信息公式只是工具别让工具喧宾夺主。最后分享一个我最近才养成的习惯在公式源码旁边用注释写一句“这个公式在算什么”。Markdown本身不支持注释但可以用HTML注释!-- --包起来渲染时不会显示但自己看源码时能快速回忆起来。这个习惯在维护长文档时特别有用尤其是隔了几个月再回来改的时候。