去年年底，我有一篇论文在 Overleaf 上改到最后一版，免费版编译队列突然排到十分钟开外，我盯着那个转圈的小图标，一口气喝完了一杯水。也是在那个瞬间我下定决心：不如把写作环境彻底迁回本地，用 VS Code 搭一套顺手的 LaTeX 工作流。折腾了一个周末之后，我最大的感慨是——这件事一点也不难，真正难的是没人把配置里的"为什么"讲清楚。
这篇文章就把我当时的完整动作拆给你看，从 TeX 发行版怎么选、VS Code 插件怎么配，到 latexmk 的编译优化、PDF 正反向同步，再到中文、字体、辅助文件这些我踩过的坑。无论你是刚入门的 LaTeX 新手，还是被 Overleaf 免费版折磨了许久的老用户，照着这个流程走一遍，应该都能在半小时内得到一个能长期使用的本地写作环境。我不会劝所有人立刻放弃 Overleaf，但如果你经常遇到编译超时、网络波动、宏包版本滞后，或者单纯想拥有一个完全可控的自动化写作工具链，这篇文章大概率能帮上忙。
1. 本地写作的账要算清楚：为什么我最后还是放弃了 Overleaf
1.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，它们的适用场景有区别：
| 发行版 | 常见系统 | 核心特点 | 适合人群 |
|---|---|---|---|
| MiKTeX | Windows | 默认按需自动安装宏包，体积小 | 新手、Windows 用户 |
| TeX Live | Linux / Windows | 全量宏包，离线稳定，社区最广 | 老用户、离线环境、服务器 |
| MacTeX | macOS | 基于 TeX Live，集成 Mac 常用工具 | macOS 用户 |
如果你是 Windows 用户，我建议第一套环境直接上 MiKTeX。原因很简单：它的"按需自动安装缺失宏包"功能，能帮你省掉大量手动装宏包的时间。很多新手的第一个 LaTeX 工程都会报错"Package not found"，MiKTeX 默认会在编译时询问是否自动下载缺少的包，装完即用，非常友好。代价是首次编译某个包时可能会多等几秒，但对我来说这个代价完全值得。
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 --install=ctex mpm --install=fontspec这两个包是中文编译的基础。如果不确定某个宏包叫什么名，可以在命令行里用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 的设置界面（快捷键Ctrl+Shift+P输入 "open user settings json"），在settings.json里加一段默认配置。我第一次折腾的时候照着官方文档抄了一长串，后来发现真正必需的核心其实就这几项。下面是我打磨过的基线配置：
{ "latex-workshop.latex.tools": [ { "name": "latexmk-xelatex", "command": "latexmk", "args": [ "-xelatex", "-synctex=1", "-interaction=nonstopmode", "-file-line-error", "-outdir=build", "%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，-synctex=1开启源码与 PDF 的位置同步信息，-interaction=nonstopmode让编译遇到错误时不弹交互询问而是直接报错输出，-file-line-error让错误信息带上具体文件路径和行号，方便我们在 VS Code 的问题面板里点击跳转。-outdir=build把编译产生的中间文件全部丢到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更不容易出错。
保存文件后，按Ctrl+Alt+B（Windows）或Control+Option+B（macOS）触发编译。左下角状态栏会显示编译进度，第一次编译因为要生成中文字体缓存，可能慢一些，之后会明显提速。编译成功后会弹出内置 PDF 预览面板，看到"你好，世界"四个字，就说明整条链路已经通了。如果编译失败，按Ctrl+Alt+X打开编译日志，先搜error关键字定位出错行——最常见的两个错误是xelatex is not recognized（PATH 问题）和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里把-outdir=build设成固定构建目录，这样所有.aux/.log/.bbl/.toc之类的中间产物都集中在build/里，不会把工程根目录搞得乱七八糟。当你不需要看中间产物时，可以一键清理：按Ctrl+Alt+C会调用 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 中，内置查看器的正向同步默认就绑定在Ctrl+Alt+J，在"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 里按住Ctrl+Alt+J正向定位 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[style=gb7714-2015]{biblatex} \addbibresource{refs.bib}然后在正文里正常\cite{key}，最后在合适的位置打印文献表。因为我在魔法注释里写了% !BIB program = biber，latexmk 会自动调用 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 有些插件会占用Ctrl+Alt+B（比如某些代码运行工具），而这是 LaTeX Workshop 的默认编译快捷键。遇到这种情况，可以在 VS Code 的键盘快捷设置里搜索 "build" 相关条目，改成你习惯的组合键。我在某次装了一个自定义快捷键插件后，编译快捷键失效，一度以为配置坏了，最后发现只是被占用。
第二个是中文路径。Windows 上如果工程文件夹路径或文件名包含中文，SyncTeX 正反向同步偶尔会失效，有些 externa viewer 的传参也会出异常。我后来把所有 LaTeX 工程目录名都改成英文或拼音，连build/里的辅助文件都是纯英文路径，之后就没再出过类似的怪问题。这个改动很小，但能立竿见影地减少奇奇怪怪的故障。
第三个是过度依赖自动清理。Ctrl+Alt+C清理辅助文件虽然方便，但如果你在多个预览窗口开着一个旧 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这四件套。这样无论写论文还是做技术文档，从零开始到跑通编译基本只需要一分钟。如果你也决定迁移到本地，建议现在就找一篇旧文档试跑一遍，遇到问题欢迎回来对照这篇文章的内容排查。
