企业官网建设流程全解析

在Overleaf上写长文档，最让人血压升高的时刻往往不是公式拼写不对，而是按下Recompile之后，那个转圈动画一直不结束，最后弹出一个红色的Timeout。我自己带论文项目的时候，七十多页的章节配上几十张高清位图，一次编译要等四十秒甚至更久，改一个错别字也得付出同样的代价。后来踩了不少坑，试过各种方案，从工程结构、宏包管理、图片处理到Overleaf自带的功能开关，慢慢整理出了一套比较完整的提速思路。这篇文章就把这些经验拆开讲清楚，适合正在写学位论文、期刊论文、书籍或者任何大型LaTeX项目的人参考。

1. Overleaf编译慢，到底慢在哪

1.1 一次编译请求的完整路径

很多人把“编译变慢”简单归因于Overleaf服务器不行，但实际情况远没那么简单。你点击Recompile之后，会发生一串事情：项目被打包上传到编译节点，LaTeX引擎开始解析主文件，加载所有宏包，读取图片和样式文件，跑完一遍之后还要根据交叉引用、目录、参考文献等生成辅助文件，然后再跑第二遍、第三遍，最后把PDF和日志传回你的浏览器。

这个过程里，每一步都可能成为瓶颈。宏包解析是纯 CPU 密集型的，图片嵌入是 IO 密集型的，参考文献和索引会成倍增加编译轮数，网络传输则影响上传和下载环节。换句话说，编译慢往往不是某一个动作慢，而是多个环节叠加出来的结果。

1.2 平台瓶颈和文档瓶颈要分开看

我见过不少人一遇到编译慢就怀疑是免费版账号被限速，甚至想着换个平台。其实平台层面的因素确实存在，比如高峰期服务器排队、网络延迟、套餐资源配额，但这些不是你能控制的，换了网络环境也只能改善一部分。真正能由你掌握的是文档本身的复杂度，这才是决定编译时间的核心变量。

你可以做一个简单测试：新建一个空文档编译一次，记录时间，再把你的大项目编译一次，对比一下。如果空文档也要很久，说明问题在网络或平台侧；如果空文档很快而大项目很慢，那基本可以断定是你的文档变重了。搞清楚这一点，才能对症下药，不要一上来就怪服务器。

2. 先从工程结构下手，效果最明显

2.1 用 \include 和 \includeonly 实现章节级编译

我在写作过程中最常用的提速手段，是只编译当前正在修改的章节。LaTeX提供了两个配套命令：\include和\includeonly。\include负责把子文件的内容引入主文档，\includeonly则可以在导言区指定只编译哪些子文件。

比如你的主文件长这样：

\documentclass{book} \includeonly{chapters/ch02} \begin{document} \frontmatter \include{chapters/ch00_abstract} \mainmatter \include{chapters/ch01} \include{chapters/ch02} \include{chapters/ch03} \end{document}

当你在调第二章时，\includeonly{chapters/ch02}会让其他章节完全跳过，编译时间直接砍掉一大半。注意这里的文件路径不要加.tex后缀，Overleaf和本地TeX Live都是这样。

你可能会问，\input不是更灵活吗？\input确实不会强制分页，也不用非得配合\includeonly，但它有一个致命缺点：无法被\includeonly过滤。所以对于正文章节这种需要经常单独调试的内容，我强烈建议统一用\include，只在导言区维护一个\includeonly列表，写作时改一两行就能切换编译范围。

2.2 主文件保持精简，子文件拆清楚

工程结构的另一个原则是主文件只做“装配”，不要堆积内容。有些人的主文件里直接写了上百行导言区，宏包一个接一个地加载，图表代码也塞在正文里，这种项目编译速度不可能快。

我习惯的做法是：主文件只放文档类、宏包、以及一组\include语句，每个章节单独放一个文件夹，图表统一放figures/目录，宏包配置如果多还可以单独拆出一个preamble.tex用\input引入。这样不仅能提升编译速度，更重要的是让\includeonly的粒度更清晰，想跳过哪一章就跳过哪一章。

不过要注意，\include会在每个子文件前后插入分页命令，这会使章节之间始终从新页开始。如果你的内容需要连续排版而不是分章，那可能不太适合拆成多个\include，这种情况下\input更合适。权衡方式很简单：需求决定结构，速度优化要建立在文档逻辑正确的基础上。

2.3 临时排除章节的几种写法

除了\includeonly，有时候你只是想临时注释掉某段实验还没写完的内容，又不想大动干戈。这时可以借用\iffalse和\fi。

\iffalse 这一段暂时不参与编译 \fi

\iffalse比逐行%注释更省心，因为它不需要修改每一行。还有一个场景是某些交叉引用还没写完，编译时老是警告，你想快速检查某一段的效果，也可以临时把后续章节包上\iffalse。

但这里有个细节：如果用\include排版的章节被\iffalse包住，那\includeonly的过滤作用和它会有冲突，编译行为可能不符合预期。所以我通常只在正文段落内部用\iffalse，整体章节的快速跳过交给\includeonly，两者各管一段，互不干扰。

3. 宏包是最大的隐性开销

3.1 重型宏包黑名单

宏包是LaTeX生态的灵魂，但也是编译速度的头号杀手。每加载一个宏包，引擎都要解析其内部代码，有些宏包还会在文档开始时执行大量计算，这些开销累加起来非常可观。

以我的经验，最拖速度的几类宏包包括：minted（代码高亮，需要外部Python和Pygments参与）、glossaries（术语表，多轮编译才能生成完整索引）、biblatex（配合biber时比传统bibtex多跑很多轮）、tikz和pgfplots（排版复杂图形时CPU占用极高）、hyperref（功能强大但加载和交叉引用解析成本不低）。

我见过一个实际案例，一位同事的项目里为了两个表格引入了pgfplotstable，结果整个文档编译时间从二十秒涨到接近一分钟，仅仅因为一个宏包。快速排查方法很简单：把导言区的宏包逐个注释掉，每注释一个编译一次，对比时间差，就能锁定大头。听起来笨，但效率很高。

3.2 轻量替代方案

对于minted，如果你的LaTeX基础还可以、代码展示又不是最终交付的核心，可以先换成listings或者纯verbatim。listings本身也不快，但比minted稳定快不少；如果只是临时调试代码，verbatim就够了，最终定稿前再换回minted做高亮也不迟。

对于glossaries，如果只是几个术语，不妨手动维护或直接用普通表格列出。对于biblatex，如果参考文献不多，可以考虑回到natbib加bibtex的组合。这套老方案虽然功能朴素，但编译轮数少，稳定性高，很多期刊模板至今还在用。

表格数据量大、需要画复杂图表时，优先把数据整理成图片或简化绘制，而不是全部塞给pgfplots。能静态化就静态化，能提前导图就提前导图。

3.3 宏包加载的工程规范

如果你已经确定某些宏包必须保留，那么在加载它们的时候也有一些讲究。尽量把宏包放在一起集中管理，不要在每个章节文件里零零散散地加载，否则每个子文件编译时都会重复解析。加载宏包时把用不到的选项去掉，很多宏包的选项会额外引入子模块，例如\usepackage[table]{xcolor}会同时加载绘制彩色表格所需的组件，如果没用到可以不加。

另外，\documentclass的选项也没必要堆一大堆。\documentclass[11pt,a4paper,twoside]{book}这种基础配置是合理的，但如果你为了奇怪的版式加了很多选项，而文档本来只需要默认版面，那这些选项都会反映在编译时间上。规范的做法是：只保留最低必要选项，其余需求写到导言区，这样排查和关闭都容易。

4. 图片与TikZ图的加速处理

4.1 图片格式、分辨率和体积的取舍

图片是LaTeX编译时间的大户，这个坑我几乎每次帮人看项目都会遇到。很多人直接把相机拍的高分辨率照片、数MB的截图往Overleaf上一拖，然后用法\includegraphics[width=\textwidth]一插，编译立刻变慢。

图片对编译的影响主要体现在两个层面：文件大小和像素尺寸。文件太大，上传和读取慢；像素太高，引擎在嵌入和缩放时要做更多计算。一个很实用的经验法则是：最终展示宽度有多大，图片分辨率就按那个尺寸准备。如果图片显示宽度只有10厘米，那300dpi对应的像素大约是1180像素宽，超过这个数在视觉上没有差异，只会拖慢编译。

格式选择上，矢量图首选PDF；位图如果不是需要透明通道，尽量用JPEG而不是PNG，PNG在高质量下体积往往更大。EPS这种老格式能不用就不用，转换PDF之后编译更稳定更快。处理完图片之后，我通常会在项目里建一个figures目录，批量压缩好再传，避免一次次全量上传大文件。

4.2 TikZ外部化：一劳永逸的缓存方案

TikZ是一个非常灵活的画图宏包，但代价是每次编译都要重新计算所有路径、锚点、贝塞尔曲线，图多的时候很要命。好在TikZ提供了一套外部化（externalization）机制，可以把每张TikZ图编译成独立PDF，以后编译主文档时直接复用，不再重复计算。

在导言区加入：

\usepackage{tikz} \usetikzlibrary{external} \tikzexternalize[prefix=tikzcache/]

之后项目里的所有tikzpicture环境都会被自动识别成独立图片，并缓存到tikzcache目录。第一遍编译会非常痛苦，因为每张图都要单独跑一遍；但从第二次开始，只要图的内容没变，编译时间几乎可以忽略。这种方式特别适合图多且基本定稿的大项目。

需要提醒的是，外部化和部分TikZ特性有兼容性问题，比如remember picture、overlay这类跨图片定位的功能，容易冲突。遇到报错时，要么放弃外部化，要么把那张特殊的图局部排除，具体我建议翻一下TikZ的文档，里面有针对这些场景的开关。

4.3 大数据图表别硬画

有些时候编译慢不是图片多，而是数据量大。pgfplots直接加载几万行的CSV数据，每编译一次都要重新解析全部数据并绘制，速度自然难看。这种情况下，与其让LaTeX硬画，不如把数据用Python或Excel预处理出最终曲线图，导出成PDF再插入。

我并不是说pgfplots不好，而是在Overleaf这种在线编译环境下，大数据图的成本被放大了。如果只是十几个数据点，那pgfplots毫无压力；如果是动态数据、需要频繁更新图形，那更应该考虑外部工具预处理。把复杂的计算提前完成，让LaTeX只做“张贴”而不是“计算”，这是提高编译速度一个非常核心的思路。

5. Overleaf平台设置与编译策略

5.1 编译引擎选型：pdfLaTeX、XeLaTeX与LuaLaTeX

Overleaf的Menu设置里可以切换编译引擎，默认一般是pdfLaTeX。很多人习惯选择XeLaTeX，因为中文支持好、字体选择灵活，但XeLaTeX在字体解析和字形布局上要比pdfLaTeX慢不少，尤其文档里用了大量自定义字体时更明显。

如果项目是纯英文或中英混排且不依赖特定系统字体，可以试试pdfLaTeX配合ctex宏包。pdfLaTeX在Overleaf上对中文的支持其实也可以接受，编译速度比XeLaTeX快很多。当然如果要用某些现代字体功能、特殊标点或复杂排版，那还是得XeLaTeX，速度就要妥协。

LuaLaTeX是另一个选择，它比XeLaTeX更现代，部分场景下速度反而还行，但它的兼容性也相对更复杂。我的建议是：不要无脑追新引擎，按需求选择。如果你已经用了XeLaTeX且编译时间超过一分钟，先优化宏包和图片，再考虑换引擎，切换引擎往往是最后手段。

5.2 关掉自动编译和修订模式

Overleaf默认是自动编译的，你每输入一个字符都可能触发一次编译。对于小项目无所谓，但对于大项目，这会让你的浏览器一直处于忙碌状态，还白白消耗编译配额。在编辑器底部找到一个类似“Auto Compile”的开关，把它关掉，改成手动按Ctrl+S或点Recompile。这样你写完一段落、确认没问题再编译一次，体验反而更顺。

另一个容易被忽略的是修订模式（Track Changes）。如果你在Overleaf上开启了修订模式，每次编译都要额外计算文档改动和Diff结果，这个过程开销不小。协作时开启修订确实方便审阅，但自己单独写作的时候完全没必要开着，写完再开也不迟。我自己的习惯是：写作阶段始终关闭修订模式，只有发给合作者前才打开。

5.3 精简多轮编译：bibtex与术语表的取舍

LaTeX文档默认靠latexmk来协调编译轮数，遇到交叉引用、目录、参考文献和术语表时，它会让引擎跑很多遍，每一遍都完整执行一遍解析。这意味着如果你的文档同时包含大量交叉引用和参考文献，编译轮数可能是三四遍甚至更多，时间自然成倍上涨。

这里能做的优化是减少不必要的“多轮”需求。比如参考文献，如果只是简单引用，natbib加bibtex通常比biblatex加biber少跑一轮。术语表如果不是必须，建议直接取消对应宏包，因为glossaries几乎每次都要完整跑额外的makeindex流程。代码高亮、符号列表这些，都是同样的思路，最终定稿前再临时开启，平时保持精简。

6. 编译超时的应对与排查技巧

6.1 先搞清超时是平台配额还是文档问题

Overleaf的免费版编译超时阈值不算高，项目一大很容易触发。遇到超时，先别急着优化，你可以做一个判断：看是不是只有高峰期才超时，或者同样的项目换个时间段就正常了。如果是这样，问题更多出在平台排队和资源配额上，等一等再试就行。

如果是经常性超时，那多半是文档本身太重，上面的所有优化方法都能派上用场。还有一个实用技巧：把.tex主文件换成最简单的“Hello World”内容，看看编译能不能通过。如果最简单的都能超时，那基本可以断定是账号或平台问题，不是文档问题；如果最简单的能过而完整项目超时，那继续看下面的排查步骤。

6.2 从日志里定位耗时环节

Overleaf的“Logs and output files”能下载完整编译日志，里面藏着很多关键信息。我自己排查的顺序一般是：先搜索Warning，看有没有严重的字体或宏包报错；然后看Output written这一行，确认最终PDF有没有生成；再往前翻，看每一步耗时，尤其是biblatex、makeindex、minted这类外部工具做了什么。

经常出现的情况是，日志里某个宏包报了一堆错误，虽然最终PDF还是出来了，但编译被错误处理拖慢了好几倍。这时就要回头修正导言区。还有一个经验：如果日志中出现了多次Rerun，表示文档需要多轮编译才能稳定交叉引用，这也是时间开销的大头。看到这种情况，应该检查是否有循环引用或过于频繁变更的标签。

6.3 超时后的快速恢复套路

一旦踩到Timeout，我的恢复流程是固定的：先把\includeonly改成只保留正在写的章节，把图片用最简的占位框代替，注释掉所有非必要宏包，让文档能快速编译通过。确认代码逻辑正确之后，再慢慢加回章节和宏包，每加一批就编译一次，定位到具体是哪一部分导致超时。

这个流程看起来繁琐，但比直接在完整项目上盲目删改快得多。而且它还有个额外的好处：如果你把每一部分都单独验证过，后面合稿时出现交叉引用问题也会更容易定位。我多次用这套方法帮人解围，几乎每次都能在十几分钟内锁定问题来源。

最后的实操体会

说了这么多，最终的体会是：Overleaf的编译速度问题没有银弹，而是一系列小决策叠加的结果。把\includeonly用起来、清理重型宏包、压缩图片、避免没必要的自动编译，这些单看每一条都不难，组合起来效果却非常明显。我自己现在写作大文档时，已经形成了一个肌肉记忆：频繁编译阶段永远只开当前章节，图片能压缩就压缩，minted只在最后定稿前启用，修改参考文献后才允许latexmk多跑几轮。这样即使在免费配额下，也很少再看到Timeout。

最后分享一个小技巧：如果你手头有一个几万字的项目并在鸿沟边缘挣扎，可以先在Overleaf上把最小可编译版本跑通，然后本地用一些桌面编辑器做图预处理，两边的职责分开。这样Overleaf用于排版和协作，本地用于重计算和高负载的初稿，工作量分配合理后，在线编译的压力自然就小多了。