[翻譯] 爲什麼我在 Overleaf 上一直遇到編譯超時錯誤信息？Compile Timeout Error Message in Overleaf

原  文：Why do I keep getting the compile timeout error message?
譯  者：Xovee
翻譯時間：2020年5月21日

爲什麼我在 Overleaf 上一直遇到編譯超時錯誤信息？

Compile timeout，也就是編譯超時，意味着編譯你的文檔花費了過長的時間來生成 PDF 文件。本篇博文將會解釋這個問題爲什麼會發生，以及如何解決這個問題。

過大的高清晰度圖片

如果你的文檔中包含許多高清晰度的 PNG 或 JPEG 圖片，那麼 $\LaTeX$ 在每次編譯文檔的時候將會調整它們的大小，這個過程可能會花費很長的時間。下面是一些解決的建議：

• 對於各種示意圖和數據圖，請使用 PDF 文件，而不是 PNG 文件。如果你的製圖軟件可以導出文件爲 PDF 格式，那麼編譯的速度將會大大提升（顯示效果也會更好）。你也可以將 PNG 文件轉換爲 PDF 文件來加快編譯速度。
• 使用草稿模式，點擊 Recompile 按鈕旁邊的倒三角箭頭，然後選擇 Fast (draft) 選項。這個選項將會把你的所有圖片都替換爲空白的矩形，從而使編譯速度大大加快。
• 在這個在線版本的文檔中使用低質量的圖片。

更多有關於解決過大圖片的詳細的建議，請參考這篇文章。

過於複雜的 TikZ 或 pgfplots 圖片

TikZ 和 pgfplots 會生成非常漂亮的圖片，但是它們會花費非常多的時間來編譯。你可以使用很多方法來處理 TikZ 圖片，使得 $\LaTeX$ 不需要在每次生成新的 PDF 文件時都要再編譯它們一次。

mhchem

最近版本的mhchem包會花費很長的時間來編譯。取決於你的用法，chemformula包可能會編譯的更快。如果你已經在使用mhchem了，你可以試試用一下chemformula包：

% \usepackage{mhchem}
\usepackage{chemformula}
\let\ce\ch

因爲這兩種包之間有着些許不同的語法和功能差異，這個辦法不一定都行得通。例如，\ce{2H2O}在mhchem中表現正常，而在chemformula中你需要在第一個2後面添加一個空格：\ch{2 H2O}。

biblatex

如果你的項目很舊，並且使用着 TeX Live 2017 來編譯圖片，你的 項目很可能在使用 biblatex v3.7。這個版本的 biblatex 非常的慢，特別在當你使用了那些需要跟蹤引用的出現次數的功能的時候，例如，authoryear-comp、authoryear-icomp、APA 等。你可以複製你的這個項目，讓其使用新的 TeX Live 版本，例如 2018 版本的 TeX Live 使用了 v3.12 版本的 biblatex，其編譯速度非常的快。

如果你實在要繼續使用 TeX Live 2017 版本來編譯你的項目，而又想避免慢的 biblatex v3.7，你也許可以試一試使用一種非跟蹤的樣式來在線編譯，例如，authoryear，或者使用 BibTeX。instead.

跟蹤、調試調用

如果你在你的文檔中使用了\tracingall（也許是從某個模版文件或者本地項目中引入的），它會在日誌文件中記錄非常多非常多的信息（很可能超過了幾百MB）以及可能絲毫沒有停止的跡象。移除\tracingall調用，或者使用trace包。

無限循環

LaTeX 在輸出 PDF 文件的時候有可能陷入一個無限循環，不管你等待多長時間，它永遠不會停止。無限循環一般是由第三方包中的 bug，或者是由用戶自定義的指令所導致的，例如，當一個指令調用它自己的時候（一種被稱爲遞歸的過程）。所以你需要檢查那些可能導致無限循環的 bug，例如 \newcommand{\foo}{\foo}。

致命的編譯錯誤

不幸的是，有些 LaTeX 編譯錯誤會完全阻礙 latexmk 的構建過程，從而導致編譯超時。爲了調試這些錯誤，有時候你需要在項目中添加一個名爲 latexmkrc 的文件，在文件的首部，添加如下行：

$pdflatex = 'pdflatex --halt-on-error %O %S';

這個操作將會讓編譯器在遇到最初幾個編譯錯誤的時候就停止運行（儘管還沒有生成任何輸出預覽）。然後你就可以調試你所遇到的錯誤，直到項目不再包含任何錯誤；之後你就可以刪除 latexmkrc 文件。（如果你仍舊遇到了超時問題，那麼可能的原因應該是之前幾個章節所討論過的錯誤。）

下面是一些經常出現的阻塞編譯器運行的錯誤：

• \caption{}應當一直出現在 tabular 環境之外；不然它可能會造成致命的錯誤（當 caption 包被加載的時候）。（但是longtable確實要求\caption{}在其內部。）
• \caption{}不應該包含任何 \\、\newline、centering、raggedright等。
• 在某些模版或者包中，有着\caption的\ref{...}或者\cite{...}應當在其之前添加\protect指令來避免致命的錯誤。
• 相似地，如果你使用soul或者changes包來高亮文字或者刪除文字，\cite或\ref也許需要\protect命令出現在它們前面。
• 檢查tabular環境中的不完整的\cmidrue{...}命令；它要求一定範圍內的表格的列，所以你需要把\cmidrule{3}改寫爲\cmidrule{3-3}來添加一個一列寬的水平線。
• 避免嵌套的tabular環境。如果你想要在一個表格項中換行，你可以使用makecell；你還可以使用p{...}列類型，或者tabularx包，來創建一個自動換行的列。（一般來說，在創建表格的時候要非常小心。）
• \author{...}中不應當包含任何空白行。
• 在tikzpictures中，在 path/node 指令的末尾缺失;，或者在參數列表的末尾缺失]
• breqn包的 dmath 環境有可能陷入無限循環；使用align環境，並且在必要的情況下手動調整換行。
• flushend包可能造成無限循環。這一般發生在，當最後一頁只包含一點點文字的時候來讓flushend算法執行。因爲這個原因，flushend包在 ACM 的模版中被移除了。
  當你仍在書寫手稿的時候，你可以暫時去除flushend包。當你完成之後，你可以再添加flushend包，來看看情況有沒有變好。如果還是不行的話，你可以考慮使用balance包。

\usepackage{balance} 
%% don't load flushend
\begin{document}
.... (somewhere in the left column of the last page) 
\balance

• 當你有着過多的圖片或者表格使用了[H]佈局標識符，它可能會導致 LaTeX 陷入無限循環（爲了找到合適的位置來放置所有的圖片/表格）。考慮將[H]替換爲[hbt!]，並且在有必要的情況下，使用\clearpage命令，在插入一個分頁之前清理隊列中所有的表格和圖片，
• 有些babel語言選項可能會改變某些字符的含義，當這些字符在它們“正常的環境”中使用的時候，例如在數學模式下，這可能造成更多的問題。試着在加載 babel的時候添加shorthands=off選項來停止這個行爲。

合理使用限制

如果你確實有着一個非常非常大的文檔，它確實可能需要花費很長的時間來編譯。我們在付費訂閱的計劃中提供了更長時間的編譯時間：

	Free	Student, Collaborator, Pro
超時	1 分鐘	4 分鐘

Overleaf 需要設置編譯超時錯誤來避免無限循環，並且確保這一點對於我們的所有用戶都是公平的。

問題還沒有解決？

如果你仍舊有着無法解決的編譯超時錯誤，請聯繫我們，我們將會幫助你。