去年年底我有一篇论文在 Overleaf 上改到最后一版免费版编译队列突然排到十分钟开外我盯着那个转圈的小图标一口气喝完了一杯水。也是在那个瞬间我下定决心不如把写作环境彻底迁回本地用 VS Code 搭一套顺手的 LaTeX 工作流。折腾了一个周末之后我最大的感慨是——这件事一点也不难真正难的是没人把配置里的为什么讲清楚。这篇文章就把我当时的完整动作拆给你看从 TeX 发行版怎么选、VS Code 插件怎么配到 latexmk 的编译优化、PDF 正反向同步再到中文、字体、辅助文件这些我踩过的坑。无论你是刚入门的 LaTeX 新手还是被 Overleaf 免费版折磨了许久的老用户照着这个流程走一遍应该都能在半小时内得到一个能长期使用的本地写作环境。我不会劝所有人立刻放弃 Overleaf但如果你经常遇到编译超时、网络波动、宏包版本滞后或者单纯想拥有一个完全可控的自动化写作工具链这篇文章大概率能帮上忙。1. 本地写作的账要算清楚为什么我最后还是放弃了 Overleaf1.1 Overleaf 不是不好只是不适合我的写作节奏先说实话Overleaf 在打开即用这件事上做得非常出色我第一次用它的时候也被惊艳过——不需要装任何 TeX 环境浏览器打开就是完整编辑器写公式、插图片、多人实时修改这些体验放到五年前简直是奢侈。尤其是和同学合作改稿阶段每个人在自己的浏览器里动同一个 tex 文件互相能看到光标在哪那种实时感是本地环境很难替代的。但随着写作篇幅越来越长、章节越来越多Overleaf 免费版的问题开始变得具体。我遇到的第一道坎是编译超时。一篇带大量 TikZ 图和交叉引用的论文编译一次在免费队列里排队五分钟起步重编译三次之后整个人就麻了。第二道坎是字体和宏包Overleaf 服务端的字体库、宏包仓库和本地不完全一致我用某个字体微调过的版式下载 zip 到本地再编译字号和行距竟然能对不上。这让我意识到如果最终投稿、提交 camera-ready 版本时还是要回到本地环境那不如一开始就把本地环境打磨好。另外还有一个很多人忽略的点Overleaf 免费版对单个项目的编译时长是有限制的虽然日常写作通常够用但一到改稿高峰期频繁点击Recompile就会触发排队。而本地编译是即时的按一次快捷键几秒钟内 PDF 就刷新了。这个速度差异在改一句话就想看一眼效果的写作节奏里体验差距非常大。1.2 哪些人适合迁移哪些人建议留在原地我不是那种All in 本地的极端派。如果你和我一样是一个人独立写作、或者只需要和导师做间歇性沟通那本地 VS Code latexmk 的工作流几乎完胜编译快、可离线、能接脚本、能拥抱 Git 版本控制。但如果你是多人同时频繁编辑同一份文档的团队项目还是老老实实留在 Overleaf 更省心本地环境的协同方案Git 分支、冲突解决学习成本高而且注释、改动讨论的体验远不如网页端顺手。还有一个中间态你可以像我一样两者并行。本地负责日常写作和编译每次改完导出 zip 或同步到线上项目用于给合作者审阅。这样既享受本地编译的速度又不牺牲多人协作的可能。事实上我现在的固定节奏就是正文、图表、公式全在 VS Code 里搞定重要版本的 PDF 再传到线上分享链接给合作方看。用了一段时间后我打开 Overleaf 的频率降到每月一两次基本只是当交付看板用。如果你决定往下走下一节就是最关键的打地基环节本地 TeX 环境的选择和安装。这块很容易踩坑我按自己的实测经验拆细了写。2. 从零搭环境的完整动作TeX 发行版、VS Code 插件与 PATH 这一关2.1 先选一个能跑的 TeX 发行版在 VS Code 里写 LaTeX本质上 VS Code 只负责编辑文本真正把 .tex 文件变成 PDF 的是底层的 TeX 发行版。所以第一步是选发行版这一步直接决定你后面会不会被各种莫名其妙的问题折磨。我实验下来最常见的三个选择是 MiKTeX、TeX Live、MacTeX它们的适用场景有区别发行版常见系统核心特点适合人群MiKTeXWindows默认按需自动安装宏包体积小新手、Windows 用户TeX LiveLinux / Windows全量宏包离线稳定社区最广老用户、离线环境、服务器MacTeXmacOS基于 TeX Live集成 Mac 常用工具macOS 用户如果你是 Windows 用户我建议第一套环境直接上 MiKTeX。原因很简单它的按需自动安装缺失宏包功能能帮你省掉大量手动装宏包的时间。很多新手的第一个 LaTeX 工程都会报错Package not foundMiKTeX 默认会在编译时询问是否自动下载缺少的包装完即用非常友好。代价是首次编译某个包时可能会多等几秒但对我来说这个代价完全值得。macOS 用户就无脑选 MacTeX 官方包即可安装完之后 PATH 一般不用手动配。Linux 用户按发行版仓库装 TeX Live full 或者用官方安装器注意安装器安装时有一个选项是加入系统 PATH一定要勾选否则后面 VS Code 插件根本找不到 xelatex 命令。安装完先别急着打开 VS Code打开终端Windows 是 PowerShell分别敲这三条命令验证latex --version xelatex --version latexmk --version如果三条命令都能正确回显版本号说明 TeX 发行版已经装好且成功加入了 PATH。如果提示不是内部或外部命令或command not found那基本就是 PATH 没生效。Windows 上装完 MiKTeX 后需要在安装器里确认Add to PATH如果当时没勾重新运行 MiKTeX 安装器找到 PATH 相关选项补上然后重启终端再试。很多教程没强调这一点导致用户折腾半天 VS Code 配置其实问题出在更前面的环节。2.2 VS Code 侧只需要装对插件别装太多环境打完底接下来是 VS Code 侧。你只需要一个核心插件LaTeX Workshop。这个插件的功能覆盖了从编译、预览、同步跳转到辅助文件清理的几乎全部流程是本地 LaTeX 工作流的中枢。我的建议是第一轮只装 LaTeX Workshop 一个插件等跑通第一个文档后再按需加装。不要一次性装一大堆LaTeX 工具包类插件插件之间对编译命令的定义可能互相冲突出了问题反而排查困难。后续我实际加上的只有两个一个是代码拼写检查类插件用来给英文单词做拼写校验避免出现低级 typo另一个是语言语法检查类插件需要 Java 运行时对中英文混排文本可以给语法提示。但如果你的场景只是日常谢学术论文或技术文档这两个都是可选的——先跑通主流程再谈体验优化。顺便说一个很多人不知道的细节LaTeX Workshop 自带一套非常完整的代码片段snippet你输入begin它会提示\begin{...}和对应的\end{...}结构。这个功能默认是开启的不用额外配置。再加上自动补全环境名、命令名、章节标签日常写作速度能比在 Overleaf 上快一截。2.3 绕开最经典的 PATH 与宏包安装坑我在帮几位同事搭环境时发现90% 的为什么我编译失败都出在同一个位置VS Code 进程没有继承终端里的 PATH 设置。具体表现是你在终端里敲xelatex --version正常但 VS Code 里一编译就报xelatex is not recognized。这是因为 VS Code 如果是在 PATH 修改之前启动的它的进程环境还是旧 PATH。解决办法也非常简单改完 PATH 后完全退出 VS Code 再重新打开不要只是在里面重装插件或重载窗口。这个小细节我吃了两次亏写在这里希望你别再走一遍弯路。另一个高频问题是宏包安装失败。TeX Live 全量安装一般不会缺包但 MiKTeX 的自动安装机制在宏包仓库不稳定时可能会超时尤其是国内网络环境下。应对方案有两个一是把 MiKTeX 的包仓库镜像切到国内镜像站在 MiKTeX Console 的设置里找到Package repository改掉即可二是直接用命令行手动装需要用到的包例如mpm --installctex mpm --installfontspec这两个包是中文编译的基础。如果不确定某个宏包叫什么名可以在命令行里用mpm --search关键词模糊搜索。把这一步做顺了后面几乎不会再被宏包问题卡住。3. 打开 VS Code 的第一个工程LaTeX Workshop 核心配置与魔法注释3.1 魔法注释是文档的头部总开关在本地用 LaTeX Workshop 编译有一个概念必须从一开始就建立魔法注释Magic Comments。它是写在 .tex 文件头部、以% !开头的特殊注释LaTeX Workshop 会读取它们来决定用什么编译器、什么编码、哪个根文件。相当于给这段文档装了一套总开关。我的每个工程文件头部固定是这几行% !TeX program xelatex % !TeX encoding utf8 % !BIB program biber % !TeX root ./main.tex四行分别说明用 XeLaTeX 编译处理中文必需、源文件编码是 UTF-8、参考文献用 Biber 处理、根文件是当前目录下的 main.tex。最后一行在拆分文件写作时尤其重要如果你在chapter1.tex里打开编辑器LaTeX Workshop 会通过这一行找到根文件然后编译整个主文档而不是试图单独编译这个子文件。很多从 Overleaf 迁过来的同学会忽略这组注释结果默认的 pdfLaTeX 编译器遇到中文直接报错。所以我把这四行放在第一个工程的最前面希望你能形成习惯——任何新工程的第一件事就是先把魔法注释写好。3.2 最小可用的 settings.json 长什么样打开 VS Code 的设置界面快捷键CtrlShiftP输入 open user settings json在settings.json里加一段默认配置。我第一次折腾的时候照着官方文档抄了一长串后来发现真正必需的核心其实就这几项。下面是我打磨过的基线配置{ latex-workshop.latex.tools: [ { name: latexmk-xelatex, command: latexmk, args: [ -xelatex, -synctex1, -interactionnonstopmode, -file-line-error, -outdirbuild, %DOC% ] } ], latex-workshop.latex.recipes: [ { name: XeLaTeX 编译, tools: [latexmk-xelatex] } ], latex-workshop.view.pdf.viewer: tab, latex-workshop.latex.autoBuild.run: onSave, latex-workshop.latex.option.maxPrintLine: 100 }逐个说一下每项的用意。latex-workshop.latex.tools定义的是用什么命令编译。我统一走 latexmk 这个驱动工具它的原理下一节专门讲参数里-xelatex指定底层编译器是 XeLaTeX-synctex1开启源码与 PDF 的位置同步信息-interactionnonstopmode让编译遇到错误时不弹交互询问而是直接报错输出-file-line-error让错误信息带上具体文件路径和行号方便我们在 VS Code 的问题面板里点击跳转。-outdirbuild把编译产生的中间文件全部丢到build子目录保持工程根目录清爽。latex-workshop.latex.recipes定义的是在整个编译流程里按顺序执行哪些工具。我的基线只放了一个 latexmk 工具因为 latexmk 会自动处理轮次问题。latex-workshop.view.pdf.viewer设为tab表示 PDF 在 VS Code 内置面板里打开适合前期快速预览。latex-workshop.latex.autoBuild.run设为onSave表示每次保存 .tex 文件时自动触发编译保存即刷新这是本地写作最爽的体验之一。3.3 第一个能编译出中文 PDF 的文档配置写好后新建一个工程文件夹里面放一个main.tex先别直接复制论文用一个最小文本来验证整条链路是否打通\documentclass[UTF8]{ctexart} \begin{document} 你好世界。 这是一个公式测试$a^2 b^2 c^2$。 \begin{equation} \int_0^1 x^2 \, \mathrm{d}x \frac{1}{3} \end{equation} \end{document}注意文档类用的是ctexart这是中文写作最省事的文档类它会自动处理中文字体和中英文混排的标点压缩。如果你用的是 LaTeX 默认的article配合ctex宏包原理也类似但对新手来说直接用ctexart更不容易出错。保存文件后按CtrlAltBWindows或ControlOptionBmacOS触发编译。左下角状态栏会显示编译进度第一次编译因为要生成中文字体缓存可能慢一些之后会明显提速。编译成功后会弹出内置 PDF 预览面板看到你好世界四个字就说明整条链路已经通了。如果编译失败按CtrlAltX打开编译日志先搜error关键字定位出错行——最常见的两个错误是xelatex is not recognizedPATH 问题和Package ctex not installed宏包未装前者按 2.3 节的方案处理后者手动装一下即可。从这个最小文档开始你可以一步步往里加章节、插图、参考文献。每一次加内容本质都是在测试新的宏包和命令是否可用这样就算出了问题也容易定位是哪一个新增项引起的。4. 让编译聪明起来latexmk 的工作原理与多轮编译优化4.1 latexmk 到底替我们干了什么如果你直接在命令行里敲xelatex main.tex大概率只能得到一份缺少目录、缺少交叉引用编号的 PDF。因为 LaTeX 的编译机制是需要多轮完成的第一轮生成辅助文件第二轮读取辅助文件生成目录和引用编号第三轮刷新交叉链接。如果是带参考文献的文档中间还要穿插 BibTeX 或 Biber 处理文献数据库。手动敲命令很容易漏轮次而latexmk就是那个帮你自动规划这些轮次的驱动脚本。latexmk 的工作原理是先看一遍你的源文件找出它依赖哪些辅助文件.aux、.bbl、.toc、.idx等然后用监控文件时间戳的方式判断哪个环节需要重新跑。比如你的文档引用了\cite{key}第一轮编译后生成.aux文件latexmk 发现这个文件比源文件旧就会自动再跑一轮直到所有中间文件都比源文件新、交叉引用稳定为止。还有一个不容易察觉但很重要的事latexmk 在检测到biblatex宏包时会通过.fdb_latexmk文件记录依赖自动选择调用 Biber 而不是 BibTeX。这也是我在魔法注释里固定写% !BIB program biber的原因——先用注释把偏好锁定latexmk 就知道参考文献流程该怎么跑不用我在 recipe 里额外写一条biber命令。4.2 在 recipe 里把工具串起来很多人看 LaTeX Workshop 的文档会晕因为里面既有tools又有recipes傻傻分不清。我的理解方式很简单tools 是怎么执行每条命令recipes 是按什么顺序执行这些命令。我的基线配置用一个 tool 搞定所有事情因为 latexmk 内部处理了多轮编译不需要我在 recipe 里再插入xelatex、bibtex、xelatex、xelatex这种固定流水线。这样做的最大好处是灵活当你改了文档类或编译方式只要改魔法注释latexmk 就会自己调整轮次策略recipe 不用动。如果你确实需要在编译过程中插入额外命令比如有的模板要求先跑makedist或生成索引可以仿照这样一个多工具 recipes{ name: 带索引的编译流程, tools: [latexmk-xelatex, makeindex, latexmk-xelatex] }其中makeindex需要在tools里单独定义指向可执行文件和参数。但常规论文写作基本用不上这么复杂的链路保持简洁是最优选。4.3 增量编译、缓存目录与辅助文件清理latexmk 的另一个隐藏价值是增量编译。它会在工作目录生成一份.fdb_latexmk依赖数据库下次编译时只重新处理有变动的文件和相关依赖而不是把整个文档从头到尾重新跑一遍。在动辄几百行的大型文档里这个速度优势非常明显。为了配合增量编译我在settings.json里把-outdirbuild设成固定构建目录这样所有.aux/.log/.bbl/.toc之类的中间产物都集中在build/里不会把工程根目录搞得乱七八糟。当你不需要看中间产物时可以一键清理按CtrlAltC会调用 LaTeX Workshop 的清理辅助文件功能其实只是把build/目录删空。我建议把build/目录加入.gitignore第六节会讲这样 Git 仓库里只保留源代码每次 clone 下来后从零编译即可完全可复现。还有一个小优化值得提如果你特别在意每次编译的速度可以把latex-workshop.latex.autoBuild.run从onSave改成never然后只在需要时按快捷键手动编译。我个人的体感是onSave模式在大文档里会频繁触发编译稍有打扰后来改成了onFileChange配合手动快捷键反而更顺手。哪种模式适合你写几天就能试出来不必一开始就追求某一种。5. PDF 预览、正反向同步与外部查看器的正确接法5.1 内置 PDF 查看器就够用了吗LaTeX Workshop 自带的内置 PDF 预览面板胜在方便编译完自动刷新不需要切换窗口还支持Ctrl点击从 PDF 框选跳回源码。前期写作阶段我强烈建议先用它界面清爽、路径零配置尤其适合笔记本单屏用户。但内置查看器有两个天花板一是对大 PDF 或带有大量矢量图/复杂字体的文档渲染性能不如专业 PDF 阅读器滚动会有卡顿二是它不能挂在桌面端的 PDF 阅读器生态里批注、高亮、书签管理都不方便。当你开始做最终校对、需要反复在 PDF 上打标记时就该考虑接一个外部查看器。Windows 下我推荐 SumatraPDF——轻量、启动快、对 LaTeX 的 SyncTeX 反向同步支持最好macOS 可以用 Skim。下面以 SumatraPDF 为例说明配置思路其他查看器同理。5.2 正向同步从源码跳到 PDF 对应位置正向同步的意思是正在编辑main.tex的第 120 行按下快捷键PDF 预览页立刻定位到这一行生成的内容。在 LaTeX Workshop 中内置查看器的正向同步默认就绑定在CtrlAltJ在latex-workshop.view.pdf.viewer: tab模式下直接可跳体验很好前文已提到。如果切换到外部查看器需要在settings.json里指定两个命令一个是打开 PDF 用的一个是正向同步用的。我的配置是这样latex-workshop.view.pdf.viewer: external, latex-workshop.view.pdf.external.viewer.command: C:/Program Files/SumatraPDF/SumatraPDF.exe, latex-workshop.view.pdf.external.viewer.args: [%PDF%], latex-workshop.view.pdf.external.synctex.command: C:/Program Files/SumatraPDF/SumatraPDF.exe, latex-workshop.view.pdf.external.synctex.args: [ -forward-search, %TEX%, %LINE%, %PDF% ]注意两点一是路径里的斜杠建议统一用正斜杠或双反斜杠转义C:/Program Files/...这种写法在 JSON 里最省心二是%PDF%、%TEX%、%LINE%这些占位符是 LaTeX Workshop 规定的它会自动替换成当前编译出的 PDF 路径、当前激活的源文件路径和光标所在行号。如果你的可执行文件路径里包含空格不要手贱去加多余的引号JSON 字符串本身已经包含了路径内容多加引号反而会导致启动失败。5.3 反向同步双击 PDF 回到源码行反向同步是在 PDF 的某个位置双击跳回源码对应行。这个功能在内置查看器里是通过Ctrl点击实现的而在 SumatraPDF 里需要单独配置。做法是先在设置里把 VS Code 的latex-workshop.view.pdf.viewer设为external并且配置好上面的外部命令让 LaTeX Workshop 能调起 SumatraPDF。然后在 SumatraPDF 自身的设置界面里找到命令行inverse-search command配置项填入一条类似这样的命令C:/path/to/VS Code/bin/code --reuse-window -g %f:%l其中%f和%l是 SumatraPDF 提供的占位符表示点击位置对应的文件名和行号code可执行文件的路径要指向 VS Code 安装目录下bin文件夹里的那个版本而不是桌面快捷方式。配好之后以后在 PDF 上双击任意位置VS Code 会自动打开对应的源码文件并跳到对应行。这个功能在重新排版、修改措辞的时候极其好用省去来回滚动找位置的功夫。如果你暂时搞不定code的路径还有一个偷懒方案在 VS Code 里按住CtrlAltJ正向定位 PDF然后用 SumatraPDF 打开同一个 PDF手动滚动到目标位置即可。虽然不如反向同步优雅但至少可以把工作流跑通等有空再背调和优化。6. 迁移后我踩过的坑中文、字体、辅助文件与工程规范6.1 中文编译不是玄学但字体是要管的本地编译中文最核心的三个要素是XeLaTeX 编译器、UTF-8 编码、中文字体。编译器用 XeLaTeX 是因为它对 Unicode 和系统字体的支持最自然编码在魔法注释里已经锁死字体这块则是最容易出换台电脑排版就变了问题的环节。Overleaf 服务器上预装了一套固定的中文字体你在网页端看到的效果不一定等同于本地系统字体渲染出来的效果。最常见的差异是 Windows 默认的中文字体宋体/黑体等在 Linux 或 macOS 上不存在导致文档字体会自动 fallback 成别的字体版面可能轻微变化。我踩过的一次具体事故是用 Overleaf 的ctexart默认字体在服务器上编译是一套样式下载到本地 Windows 用 MiKTeX 重新编译宋体和黑体的字重、行距都变了目录页的分页位置也跟着变了一点。要解决这个问题我的做法是在文档头部显式指定字体比如\setCJKmainfont{宋体} \setCJKsansfont{黑体}Windows 上这样写会直接使用系统字体如果在 macOS 或 Linux 上需要改成带有具体名称的字体路径或用fontspec结合系统中文字体进行配置。如果你想在多个操作系统之间保持一致的最省事方案是用思源宋体、思源黑体这类跨平台免费字体并把它写进文档配置里。这样不管在哪台机器编译只要安装了对应字体输出结果就基本一致。6.2 参考文献与索引Biber/BibTeX 的选择从 Overleaf 迁到本地很多人会在参考文献处理上卡一阵子。Overleaf 的菜单里可以一键设置参考文献编译器而本地环境需要你理解 Biber 和 BibTeX 的区别。简单来说BibTeX 是老牌参考文献处理工具适合传统的bibtex风格参考文献Biber 对应新一代biblatex宏包体系对 UTF-8 编码、各种国际化书目字段的支持更好。我的建议是新文档一律用biblatex Biber因为它在处理中文文献、非英文作者名、DOI 等字段时更干净语法也更统一。文档里的引用示例\usepackage[stylegb7714-2015]{biblatex} \addbibresource{refs.bib}然后在正文里正常\cite{key}最后在合适的位置打印文献表。因为我在魔法注释里写了% !BIB program biberlatexmk 会自动调用 Biber整个过程无需额外配置。如果你以后打开某个老模板它明确要求 BibTeX比如某些期刊模板写死了\bibliography{refs}再切回 BibTeX 也不迟魔法注释改成% !BIB program bibtex即可。除了方向选择还有一个迁移细节Overleaf 项目下载的 zip 里通常已经帮你生成了.bbl或缓存文件本地编译前最好把这些中间文件删掉让 latexmk 从零跑一遍生成流程否则可能残留旧版本文献数据导致引用编号对不上。6.3 用 Git 收编辅助文件让工程能重来放弃 Overleaf 之后版本控制就得自己接手。Git 是本地写作最可靠的搭档但 LaTeX 项目的 Git 管理有一个小坑如果你把编译生成的辅助文件全部提交仓库会很快变得臃肿而且 merge 时冲突的main.aux会非常烦人。所以我习惯在工程根目录放一个.gitignore大致长这样build/ *.aux *.log *.out *.bbl *.blg *.toc *.lof *.lot *.fls *.fdb_latexmk *.synctex.gz *.pdf前三项就够日常使用了build/整个目录不提交、常见辅助文件忽略、PDF 一般也不进 Git或者看需求如果是给合作者预览用的 PDF 值得单独管理就把它例外出来。这样每次 commit 都只包含.tex、图片源码.pdf/.png/.eps如果算源文件的话按需例外、.bib和.vscode/settings.json这类真正值得版本化的东西。clone 到新机器后用code .打开工程按一次编译快捷键几秒钟就能把整份文档重新生成出来。更进一步你还可以把.vscode/settings.json放进工程里让同一个仓库的每个合作者打开时都使用同一套编译配置。这是 Overleaf 做不到的配置跟着项目走的好处。6.4 剩下那些零零碎碎、但很磨人的坑最后列几个我迁移后实际遇到、排查了半天的零碎问题不值得单独开章节但遇到了会让人很烦躁。第一个是快捷键冲突。VS Code 有些插件会占用CtrlAltB比如某些代码运行工具而这是 LaTeX Workshop 的默认编译快捷键。遇到这种情况可以在 VS Code 的键盘快捷设置里搜索 build 相关条目改成你习惯的组合键。我在某次装了一个自定义快捷键插件后编译快捷键失效一度以为配置坏了最后发现只是被占用。第二个是中文路径。Windows 上如果工程文件夹路径或文件名包含中文SyncTeX 正反向同步偶尔会失效有些 externa viewer 的传参也会出异常。我后来把所有 LaTeX 工程目录名都改成英文或拼音连build/里的辅助文件都是纯英文路径之后就没再出过类似的怪问题。这个改动很小但能立竿见影地减少奇奇怪怪的故障。第三个是过度依赖自动清理。CtrlAltC清理辅助文件虽然方便但如果你在多个预览窗口开着一个旧 PDF清理后外部查看器可能会短暂失去文件关联。我现在的习惯是只在最终定稿或准备提交 Git 前清理一次辅助文件平时不随手清理让 latexmk 的增量编译缓存好好待着这样编译速度更快。第四个是插件语言服务的内存占用。如果你给 LTeX 这类语法检查插件加载了很大的中英文词典VS Code 的内存占用会明显上升。在低配机器上我建议先关掉这类语法检查把latex-workshop.latex.autoBuild.run调成手动编译模式写作流畅度会高很多。毕竟 LaTeX 写作的主线是编辑、编译、预览语法检查属于锦上添花。把上面这些坑都趟平之后我现在的流程基本固定成了三件事在 VS Code 里改.tex保存后看内置 PDF需要精细校对时切到外部查看器做标注定稿前一键清理辅助文件、commit 到 Git。整套环境用了一年多没有再想回到 Overleaf 的冲动。最后分享一个我个人的小习惯每开一个新工程第一件事是复制一份固定的模板文件夹里面已经放好了main.tex、refs.bib、settings.json、.gitignore这四件套。这样无论写论文还是做技术文档从零开始到跑通编译基本只需要一分钟。如果你也决定迁移到本地建议现在就找一篇旧文档试跑一遍遇到问题欢迎回来对照这篇文章的内容排查。
