企业官网建设流程全解析

第一次把 VSCode、LaTeX、SumatraPDF 这三样东西凑到一块儿的人，十有八九会在配置里耗掉一整个晚上：编译明明过了，点一下 PDF 却跳不回源码；或者反过来，光标停在某一行按了快捷键，PDF 那边纹丝不动。这套组合本身没问题，问题在于它把三件互相不认识的工具硬接在一起，中间那根线叫 SyncTeX，而绝大多数教程只给你一段 settings.json，不讲每行参数对应哪个具体故障。这篇就按我第一次配这套环境的完整过程写，把每一步"为什么这么填"讲清楚，最后能拿到一个按一个键就编译、点一下 PDF 就跳回源码的闭环。

适合看这篇的人：准备写学位论文、会议论文、技术报告，需要反复改公式和图的人；已经装了 TeX 发行版但只会用命令行敲 xelatex 的人；以及从 Overleaf 搬到本地、被"下载 zip→改一行→重新上传"折腾烦了的人。如果你一年只写两页文档，Overleaf 完全够用，下面这些不用看。

1. 为什么我最后停在了 VSCode + LaTeX Workshop + SumatraPDF 这个组合上

1.1 三种写 LaTeX 的路子，实际差别在哪

先把我试过的三套方案摆出来对比，这里说"差别"不是比谁高级，而是比谁在"改一句话看一次效果"这个动作上更省时间。写论文的真实工作流不是从头写到尾，而是反复微调某一段措辞、某个公式的括号大小、某张图的浮动位置，一天编译几十次很正常，所以每次迭代的耗时才是关键指标。

我最后离开 TeXstudio 不是因为功能不够，而是我的项目里同时存在 .tex、.bib、Python 画图脚本、JSON 配置和一堆 shell 命令，TeXstudio 只能管好其中一部分，来回切窗口太碎。VSCode 把我的整个工作目录收进一个窗口，LaTeX Workshop 只是其中一个扩展，这个"顺手"的价值在长期项目里会被放大。

1.2 这套组合真正的价值：一个快捷键闭环加双向跳转

很多人以为 LaTeX 编辑器的核心竞争力是补全和语法高亮，其实不是。真正决定你一天能改多少稿的，是正向搜索和反向搜索这两条路径顺不顺。

正向搜索（forward search）：光标在源码第 137 行，按一下快捷键，SumatraPDF 立刻翻到这篇源码编译出来的那个位置，并且高亮出来。反向搜索（inverse search）：你在 PDF 里发现某个公式的上下标不对，双击那个位置，VSCode 自动打开对应源文件并把光标定位到那一行。

这两条路径打通之后，你的注意力就不用再在"这段文字在哪个文件的哪一段"上消耗了。一篇一万多行的论文章节拆成七八个文件是常态，靠肉眼找位置一晚上要浪费十几分钟，而跳转是零成本的。这套配置里 80% 的折腾时间，都是在为这两条路径服务。

1.3 什么时候不值得折腾这套

说句实在话，不是所有人都需要这套。如果你的稿子是两人协作、导师只看 PDF、学校模板锁定 pdflatex 加 bibtex 不许换引擎，那 Overleaf 加一个本地 TeX 发行版做备用就够了。如果你是偶尔写两页实验报告，装个 TeX Live 再配 VSCode 的时间成本可能比写报告本身还高。

我建议动手的条件是：文档要维护三个月以上，或者编译一次要 20 秒以上（说明体量大，值得本地跑），或者你需要在同一项目里混用多种语言文件。三条里满足两条，配这套就不亏。

2. 动手之前，先把三件套的安装路径和版本确认清楚

2.1 TeX 发行版选 TeX Live 还是 MiKTeX

Windows 上主流就两个选择。TeX Live 是一次装全，完整版五六个 G，装完基本不用再操心缺包；MiKTeX 是精简安装，缺什么宏包在编译时自动下载。

我给的结论很直接：写论文、而且电脑硬盘不紧张的话，上 TeX Live 完整版。原因是 MiKTeX 的按需下载在无人值守的自动编译下很容易卡住——它弹个窗口问你要不要安装某个宏包，而自动编译不会帮你点"是"，于是编译就停在那里，你却以为是配置出错，白白排查半小时。这个坑我踩过，症状是日志最后一行停在某个 .sty 文件上不再往下走。

TeX Live 装完之后，用命令行确认一下：

xelatex --version latexmk --version tlmgr --version

三个命令都能输出版本号才算装好。如果提示命令不存在，说明安装目录下的 bin 路径没进环境变量。TeX Live 在 Windows 上会问你要不要顺带把 bin 目录加到 PATH，勾上最省事；忘了勾就手动加，路径形如D:\texlive\2024\bin\windows，注意版本年份要换成你实际装的那个。

宏包补装用包管理器：

tlmgr update --self tlmgr install ctex

第二条在后面讲中文时会用到。养成一个习惯：报错说找不到某个 .sty，先tlmgr install对应的包名，再去怀疑配置，能省掉大量无效排查。

2.2 VSCode 与 LaTeX Workshop 的安装与版本确认

VSCode 本体从官网拿安装包，安装时把"添加到右键菜单"和"添加到 PATH"两个选项都勾上。加到 PATH 这点很关键，后面配置反向搜索要用到 Code.exe 的路径，虽然有全路径也不影响，但写到 PATH 里能用更短的命令，出错概率低。

装完先确认版本，顺手在终端里验证 Code 命令可用：

code --version

能输出版本号说明 PATH 生效。如果这里报错，反向搜索基本一定失败，先解决这一步再往下走。

扩展只装一个必修的：LaTeX Workshop，作者是 James Yu，扩展标识是james-yu.latex-workshop。搜索的时候认准作者和下载量，别装到同名的野包上。可选的有几个，我列在最后一节里，首次配置阶段先别装，减少变量。

安装完之后，扩展会在状态栏和活动栏留下入口，编译的默认快捷键是 Ctrl+Alt+B，预览 PDF 是 Ctrl+Alt+V，从光标位置做正向搜索是 Ctrl+Alt+J。这套键位可能与某些输入法冲突，冲突了就去 Keyboard Shortcuts 里搜latex-workshop自己重设，我不建议在这上面花太多时间，默认能用就用。

2.3 SumatraPDF 为什么比其他阅读器更适合当 LaTeX 预览器

系统的默认 PDF 阅读器，无论装的是哪家，基本都不太适合做编译预览器，原因有三。

第一是文件锁定。有些阅读器在打开 PDF 时会独占文件句柄，导致下一次编译写不出 PDF，报错大意是"无法写入该文件"。SumatraPDF 是以共享方式打开的，检测到文件被覆盖后会自动重载视图，编译完不用手动关掉再打开。这一条是选它的最主要原因。

第二是命令行参数。SumatraPDF 支持-forward-search这类启动参数，可以让外部工具直接告诉它"打开这个文件并跳到第 N 行"。别的阅读器大多没有这种接口，正向搜索就无从谈起。

第三是启动速度。写文档时 PDF 窗口常年开着不关，这条影响不大，但首次打开时差别明显。

安装方面，SumatraPDF 有安装版和便携版两种，都行。我建议用安装版装到默认路径C:\Program Files\SumatraPDF\SumatraPDF.exe，因为路径里没有空格问题少，后面写配置直接复制。如果你安装在自定义目录，记住路径里不要有中文和空格，这不是迷信，是命令行参数拼接时真的会出问题。

顺便说一句，不要把它设成系统默认 PDF 阅读器。它是我的 LaTeX 预览器，读普通 PDF 文件我还是用别的，职责分开，避免误操作把正在编译的文件当成普通文档处理。

3. settings.json 的每一段都对应一个具体问题

3.1 先让最朴素的一次编译跑起来：tools 与 recipes

LaTeX Workshop 的配置分两块：tools定义"怎么调一个命令"，recipes定义"按什么顺序调哪几个命令"。这个概念一定要分清，很多人的配置乱就是从这儿开始的——把编译顺序写到 tools 里去了。

写配置的位置有两个选择：VSCode 全局的 settings.json，或者项目目录下的.vscode/settings.json。我建议全部写到项目级的.vscode/settings.json里，理由在 3.4 节展开。先在项目根目录建.vscode文件夹，再在里面建settings.json。

第一步先不管自动编译、不管跳转，只求能连续编译两遍。可以从这个最小配置开始：

{ "latex-workshop.latex.tools": [ { "name": "xelatex", "command": "xelatex", "args": [ "-synctex=1", "-interaction=nonstopmode", "-file-line-error", "-output-directory=%OUTDIR%", "%DOC%" ] }, { "name": "bibtex", "command": "bibtex", "args": ["%OUTDIR%/%DOCFILE%"] } ], "latex-workshop.latex.recipes": [ { "name": "xelatex", "tools": ["xelatex"] }, { "name": "xelatex -> bibtex -> xelatex x2", "tools": ["xelatex", "bibtex", "xelatex", "xelatex"] } ], "latex-workshop.latex.outDir": "%DIR%/out" }

逐个参数说清楚它干什么用，因为这几个参数直接决定后面跳转能不能用。

-synctex=1是生成跳转索引文件的开关，没有它，正反向搜索全都是空谈。这是整套配置里最不能省的一个参数。

-interaction=nonstopmode让编译遇到错误不暂停等输入。不加这个参数，一旦某一行出错，编译进程会停下来等你敲回车，而 IDE 里没有地方给你敲，表现就是"编译一直转圈不结束"。

-file-line-error把报错信息格式化成"文件名:行号:错误内容"，VSCode 的问题面板才能解析成可点击的条目，否则你只能看一段看不懂的日志。

-output-directory=%OUTDIR%把所有中间产物和 PDF 都扔进 out 目录。%OUTDIR%的值由latex-workshop.latex.outDir决定，%DIR%是主文件所在目录，所以最终产物落在项目根目录下的 out 里。这个目录我强烈建议留着，不然编译一次你的项目根目录会多出十几个 .aux、.log、.out、.toc 文件，git status 一片红。

配方里"跑两遍 xelatex"不是冗余。LaTeX 的交叉引用、目录、页码需要第二遍才能收敛，顺序是"第一遍生成 .aux → bibtex 读 .aux 生成 .bbl → 再跑两遍消化引文和编号"。少跑一遍的表现是正文里全部显示为"??"，很多人以为是自己写错了引用标签，其实是遍数不够。

用 bibtex 的情况下，注意%OUTDIR%/%DOCFILE%这个写法。bibtex 的参数必须是不带扩展名的主文件名，而且要和 .aux 文件在同一个目录，%DOCFILE%正好展开成不带扩展名的文件名，拼上输出目录就是 .aux 所在位置。我第一次配的时候只写了%DOCFILE%，bibtex 在源码目录找不到 .aux，报错信息很难懂。

3.2 正向搜索失灵，八成是 -synctex=1 或 %PDF% 路径的问题

编译跑通了，接下来接正向搜索。需要把 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": [ "-forward-search", "%TEX%", "%LINE%", "-reuse-instance", "%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%", "-reuse-instance", "%PDF%" ], "latex-workshop.synctex.afterBuild.enabled": true }

关键点说三个。

第一个是路径分隔符。JSON 里写 Windows 路径，反斜杠要转义成两个，容易写错；直接全部用正斜杠，Windows 的 API 一样认，省心。所以上面写的是C:/Program Files/...。

第二个是%TEX%和%PDF%这两个占位符。%TEX%是当前主文件的完整路径，SumatraPDF 拿它去和 PDF 里记录的源文件信息比对，从而定位到对应页；%PDF%是编译产物路径。如果你改了 outDir 但跳转参数里的%PDF%还是指向旧位置，正向搜索就会打开一个不存在的文件，表现是 SumatraPDF 弹一下就没了，或者打开的永远是上一次编译的旧 PDF。这是启用 outDir 之后最常见的坑。

第三个是-reuse-instance。不加它，每按一次快捷键就开一个新的 SumatraPDF 窗口，十几分钟后任务栏全是图标。加上它，所有跳转都复用同一个窗口。

latex-workshop.synctex.afterBuild.enabled设为 true 表示编译完成后自动做一次正向搜索，光标在哪就跳到哪。我的使用习惯是关掉它——自动跳转会在你翻 PDF 看别的内容时把你拽回去，很打断思路。想要就打开，这个纯看个人习惯。

3.3 反向搜索：SumatraPDF 里那行命令怎么写才认

正向搜索是从 VSCode 那边发指令，反向搜索反过来了，是 SumatraPDF 双击时去调用 VSCode。所以这条链路的"主人"变成了 SumatraPDF，得在它的设置里告诉它该调谁。

较新版本的 LaTeX Workshop 在启动外部阅读器时会自动带上反向搜索参数，配好 3.2 那一段之后双击 PDF 有时直接就跳了，不用额外设置。但如果双击没反应，就手动补上。方法是打开 SumatraPDF，进入"设置 → 选项"，找到"反向搜索命令行"这一项，填入：

"C:\Program Files\Microsoft VS Code\Code.exe" -g "%f":%l

如果你的 VSCode 装在用户目录下（非管理员安装的默认情况），路径一般是：

"C:\Users\你的用户名\AppData\Local\Programs\Microsoft VS Code\Code.exe" -g "%f":%l

这里有几个细节值得强调。

%f会被 SumatraPDF 替换成源码文件的完整路径，%l替换成行号，这是它规定的占位符，不要改写。-g是 VSCode 的"跳转到文件某一行"参数，格式是文件路径:行号，所以中间那个冒号必须紧贴着，不能加空格。

因为路径里带空格，整个可执行文件路径必须用双引号包起来；而"%f":%l这一段也要带引号，防止源码文件的路径里含空格时参数被切断。我第一次配的时候漏了内层引号，项目放在D:\My Papers\下面，跳转就一直失败，把项目挪到无空格路径后才好用——问题其实是引号，不是路径。找到这个原因花了我不少时间，所以写在这里。

配完验证的方法很简单：在 PDF 里随便找个文字，双击。VSCode 应该切到前台并打开对应文件、光标停在那一行。如果没反应，先检查 Code.exe 的路径存不存在（直接在资源管理器地址栏粘贴试试），再检查引号，最后检查源码文件路径里有没有中文。

3.4 配置该放全局还是放项目：我的取舍

settings.json有两个层级：用户级（全局，对所有项目生效）和工作区级（项目里的.vscode/settings.json，只对当前项目生效）。

我的做法是全部放工作区级。理由是编译配方和项目类型强绑定：写中文报告的项目用 xelatex 加 ctex，投英文期刊的项目可能要求 pdflatex 加 bibtex，手边还有个用 latexmk 加 biber 的模板。如果全塞进全局配置，换项目就得进设置里改，改完忘了改回来，第二天编译别的稿子就会出一堆莫名其妙的错。

工作区配置的另一个好处是可以跟着项目一起进版本库，换电脑时 clone 下来就能编译，不用重新配一遍。这件事在毕业季换机器的时候价值极高。

代价是每建一个新项目都要复制一份.vscode目录，我的解决办法是把配好的.vscode文件夹留在模板目录里，新建项目时直接连模板带配置一起复制。比维护全局配置再逐项目覆盖要省心得多。

4. 中文写作、多文件与参考文献：三个绕不开的配置分叉

4.1 中文文档默认走 xelatex 的理由和字体检查方法

LaTeX 编译中文有三条路：pdflatex 加 CJK 宏包、pdflatex 加 ctex、xelatex 加 ctex。第一条现在基本没人用了，字体配置很折腾；第二条可行但对字体编码挑剔，遇到生僻字容易出问题；第三条是当下最省心的选择，xelatex 原生处理 Unicode 和系统字体，中文标点、换行、字距都由 ctex 处理好了。

所以配方里我把 xelatex 放在第一位，主文件里再加一行引擎声明，双保险：

% !TEX program = xelatex \documentclass[UTF8]{ctexart} \usepackage{graphicx} \usepackage{amsmath} \title{环境验证文档} \author{我} \begin{document} \maketitle \section{第一节} 这是一段中文正文，用来验证字体和换行是否正常。 \begin{equation} E = mc^{2} \end{equation} \end{document}

% !TEX program = xelatex这行注释叫魔术注释，LaTeX Workshop 会读它并优先使用指定引擎，比在配置里反复调整配方顺序可靠。

如果编译报"找不到 ctexart.cls"，就是没装 ctex 宏包，回到 2.1 节的tlmgr install ctex。如果编译过了但中文全是方块或者直接空白，八成是字体配置问题，检查方式是看日志里有没有字体相关的警告，同时在编译参数里临时指定字体集：

"args": [ "-synctex=1", "-interaction=nonstopmode", "-file-line-error", "-output-directory=%OUTDIR%", "%DOC%" ]

ctex 在 Windows 上通常能自动识别系统里的中文字体，不用手动指定。真遇到识别不了的情况，可以在文档导言区加\usepackage[fontset=windows]{ctex}明确告诉它用 Windows 字体集。这个参数在期刊模板里慎用，因为模板可能已经锁定了字体方案，强行加可能和模板冲突。

4.2 主文件与子文件：魔术注释和根文件识别的关系

论文写到后面必然拆文件，主文件只留导言区和\input，正文章节各一个文件。这时候 LaTeX Workshop 会遇到一个判断问题：你在chapters/intro.tex里按编译，它该编译谁？

默认行为是编译当前打开的文件，而子文件通常没有完整导言区，单独编译必然报错。解决办法是在每个子文件的第一行加上根文件声明：

% !TEX root = ../main.tex

有了这行，无论你在哪个子文件里按编译或跳转，它都会去找main.tex作为编译入口。这个注释几乎是多文件项目里最值得记住的一行。相对路径的写法是相对于当前文件，不是相对于项目根目录，../main.tex表示上级目录里的 main.tex，写错方向会报找不到主文件。

另外 LaTeX Workshop 有自动识别根文件的能力，会向上回溯查找包含\documentclass的文件。识别不出来时它会弹窗让你手动指定，此时可以顺手勾选"不再询问"，把这个项目的根文件固定下来。如果你的项目结构比较特殊（比如主文件在src子目录），自动识别可能失灵，那就老老实实加魔术注释。

4.3 bibtex 与 biber 不要混用，配方里必须写死顺序

参考文献工具现在有两套：老的 bibtex 配 .bst 样式，新的 biber 配 biblatex 宏包。两套的调用命令、中间文件扩展名都不一样，混用是配置里最容易出隐蔽错误的地方。

判断方法看导言区：写了\usepackage{biblatex}和\addbibresource{refs.bib}，那就要用 biber，配方里把工具换成 biber，参数是%DOCFILE%（biber 需要在输出目录里找 .bcf 文件）；写了\bibliographystyle{...}和\bibliography{refs}，那用 bibtex。

对应的 biber 工具配置：

{ "name": "biber", "command": "biber", "args": ["--input-directory", "%OUTDIR%", "%DOCFILE%"] }

混用的典型症状是编译全程不报错，但参考文献列表为空，正文里的引用显示成加粗的问号。这时候看日志里的 .blg 文件，会明确写着找不到 .bcf 或 .aux，据此就能判断是用错了工具。

还有一个细节：biber 和 bibtex 都必须在 xelatex 跑完第一遍之后执行，因为它读的是第一遍生成的中间文件。顺序写反了会报"找不到 .aux"，看着像路径问题，其实是顺序问题。

5. 出问题时的排查顺序：从现象反推配置项

5.1 跳转类故障的排查链路

跳转失灵是出现频率最高的故障，我把遇到过的现象和原因整理成一张表，按这个顺序查基本能全覆盖。

排查顺序我建议从后往前：先确认 .synctex.gz 文件存在，这是所有跳转的前提；再看路径对不对；最后才怀疑反向搜索命令的写法。很多人一遇到问题就去改 SumatraPDF 的设置，实际上问题在编译参数里，方向反了。

5.2 找不到宏包、字体和 class 的几类报错

这类报错信息其实很直白，关键是别被日志的长度吓到。找错误的方法是看日志里第一个以!开头的位置，后面的报错往往是连锁反应。

• 报File 'xxx.sty' not found：宏包没装，tlmgr install xxx。TeX Live 用户基本不会遇到，MiKTeX 用户遇到最多。
• 报File 'xxx.cls' not found：文档类没装，同上处理。期刊模板的 .cls 文件通常要手动放到项目目录或本地 texmf 树里。
• 报字体找不到，附一堆字体名：多半是在非 Windows 环境编译了用 Windows 字体集的文档，或者字体集参数写错。
• 报Emergency stop，前面有明显语法错误：先修语法错误，这类连锁报错的根因只有一个。
• 报Too many }'s或Missing } inserted：括号不配对，通常是公式里少了右括号，编辑器的高亮能帮你快速定位。

这里有个经验：日志里!出现的位置不一定是最初出错的源码行，但配合-file-line-error参数，报错行号的可信度会高很多，这也是我在工具参数里坚持加它的原因。

5.3 编译反复触发、PDF 写不进去这类怪现象

剩下几个不常见但很烦人的问题，说一下处理思路。

编译反复触发停不下来。打开了onFileChange自动编译之后，如果你同时开了自动清理，清理动作会改动文件时间戳，可能触发新一轮编译，形成循环。表现是 CPU 一直占着，日志不断增长。解决办法是自动编译用onSave而不是onFileChange，改成保存时才编译，节奏完全由你控制。我最后就是这么设的：

"latex-workshop.latex.autoBuild.run": "onSave"

PDF 写不进去。如果同时用别的阅读器打开了同一个 PDF，编译时可能报写入失败。关掉那个阅读器即可。另外项目如果放在云盘同步目录里，同步进程正好在上传产物文件时可能造成短暂的文件占用，报错也是写入失败。写论文这种高频写文件的场景，我建议把项目放在本地磁盘，用 git 或者手动复制做备份，不要直接放在同步目录里跑编译。

日志被清理掉了没法排查。自动清理如果设成编译完成后立刻清理，会把 .log 文件也删掉，出问题时你连查的地方都没有。所以我把清理类型里排除了.log，或者在排查阶段干脆把自动清理关掉：

"latex-workshop.latex.autoClean.run": "never"

排查完再打开，这个开关不值得为省几十 KB 空间去冒丢失诊断信息的风险。

6. 配置稳定之后我固定下来的几个习惯

6.1 目录结构：out 目录究竟省了什么麻烦

我现在的项目结构固定成这个样子：

paper/ .vscode/ settings.json main.tex chapters/ intro.tex method.tex figures/ flow.pdf refs.bib out/ main.pdf main.aux

好处有三个层面。视觉上，源码目录里只有你写的文件，找文件不用在十几个中间产物里翻。版本管理上，.gitignore里加一行out/就干净了，不会把每次编译都变动的二进制文件提交进去。清理上，想彻底重来直接删掉 out 目录，源码一个字节都不受影响。

有一点要提醒：产物进了 out 目录，某些要提交 PDF 的场合（比如期刊投稿系统要求 PDF 与源码同目录）记得手动复制一份出去。我一般是写一个提交前的小脚本把 out 里的 PDF 拷到项目根目录，避免每次手动操作漏掉。

6.2 自动编译与清理策略怎么定

自动编译我最后定的是保存时触发，配置就是前面提到的onSave。原因很实际：写公式的时候我会连续修改几秒钟，用onFileChange的话每敲一个字符就排队一次编译，大文档下体验很差；而保存是个明确的动作，按 Ctrl+S 的意思就是"我现在想看看效果"，用它当触发点最符合直觉。

自动清理我建议设成编译成功后清理中间文件，但保留 .log 和 .synctex.gz：

"latex-workshop.latex.autoClean.run": "onBuilt", "latex-workshop.latex.clean.fileTypes": [ "*.aux", "*.bbl", "*.blg", "*.idx", "*.ind", "*.lof", "*.lot", "*.out", "*.toc", "*.acn", "*.acr", "*.alg", "*.glg", "*.glo", "*.gls", "*.fls", "*.fdb_latexmk", "*.snm", "*.nav", "*.vrb" ]

注意这份清单里没有*.log和*.synctex.gz。前者是排查依据，后者是跳转依据，两个都不能删。很多人照抄网上配置时把 .synctex.gz 也放进清理列表，结果就是编译完跳转立刻失效，还得怀疑半天是不是配置写错了。

6.3 版本管理与备份

LaTeX 项目的版本管理比代码项目更需要 git，因为公式和措辞的改动很难靠记忆回溯。我的.gitignore只有两行：

out/ *.pdf

只跟踪源码、图片、bib 文件和配置。图表如果用脚本生成，脚本也一并跟踪，这样半年后想改一张图还能找到源头，而不是对着一堆导出的 PDF 发愁。

6.4 收尾用的插件清单与快捷键

扩展我只留了四个，装多了会互相抢快捷键和格式化权限。除了 LaTeX Workshop，另外三个是拼写检查、代码格式化支持和 git 可视化，都跟 LaTeX 编译链路无关，纯粹是写作辅助。首次配置阶段建议只装 LaTeX Workshop 一个，把跳转跑通后再加别的，这样出问题能快速定位到是哪一步引入的。

常用快捷键我记的就三个：

反向搜索没有快捷键，它的触发方式是在 PDF 里双击，这个动作是你和 SumatraPDF 之间的约定，不走 VSCode 的键位系统，所以别去键位表里找它。

最后分享一个后来才想明白的小细节：这套配置的真正门槛不是参数多，而是三个工具各自持有半张地图。VSCode 知道源码在第几行，SumatraPDF 知道 PDF 上那个字在第几页，SyncTeX 生成的 .synctex.gz 是它们之间唯一的地图。所以任何跳转问题，先问一句"中间那张地图生成了没有、路径对不对"，比一头扎进 settings.json 里逐行检查要快得多。我现在的习惯是每换一个项目，先编译一次确认 .synctex.gz 存在，再配跳转，顺序反了就只能在两个方向上同时怀疑，排查成本翻倍。