写论文这件事最容易让人崩溃的往往不是内容本身而是编译环境。版本冲突、宏包缺失、几 GB 的 TeX Live 装了又卸、卸了又装好不容易在新电脑上编译出一个 PDF换台机器又得重来一遍。我前后折腾过七八次 TeX Live直到把编译环境整个塞进 Docker才算彻底告别“环境先行、论文后写”的噩梦。这篇文章就围绕 Docker 部署 TeX Live 搭一套 LaTeX 论文排版编译平台来展开不讲虚的直接给你一条能跑通的完整链路Docker 环境准备、TeX Live 镜像选型、日常编译命令封装、VSCode 集成、论文模板踩坑以及几个高频问题的排查记录。适合准备写学位论文和课程报告的学生、需要多人协作的实验室以及不想在自己电脑上装一堆宏包但又要稳定出稿的开发者。文章涉及的方案我已经在 Windows、macOS 和 Linux 上分别跑过命令和配置都是实测可用的。1. 为什么要用 Docker 部署 LaTeX 编译环境我踩过的本地方案痛点1.1 本地安装 TeX Live 的“三宗罪”版本冲突、卸载困难和环境不一致先说本地装 TeX Live 的坑。第一是版本冲突。TeX Live 每年一个大版本论文模板往往对应某一年的宏包行为比如某个期刊模板里\documentclass依赖的宏包被tlmgr update更新后行为可能就变了轻则间距不同重则直接 compile error。这种问题的排查成本非常高因为你不知道是你的代码问题还是环境问题最后只能靠反复装旧版来试错。第二是卸载困难。Windows 上卸 TeX Live 需要到安装目录去找uninstall.bat有时候卸完还会残留 PATH 环境变量、字体文件和注册表项。macOS 稍微好一点但/usr/local/texlive下的文件也不干净。我的感受是每次想“重装一次干净环境”都要鼓捣半个多小时真正写论文的时间反而被压缩了。第三是环境不一致。我在实验室的台式机上跑得好好的模板拷回宿舍笔记本就编不过去队友的 Ubuntu 上正常我的 macOS 上字体渲染出来就是和编辑部要求的不一样。这种锅非常憋屈因为你没法保证每个协作成员的机器、宏包版本、系统字体完全一致。我之前几次投稿前准备几乎都花了一大块时间在处理“为什么他那台可以、我这台不行”这种事情上。1.2 Docker 方案好在哪可复现、可迁移、无残留Docker 的方案本质上是把“厨房”整个打包成“集装箱”。容器里有一套固定版本的 TeX Live、固定宏包集合、固定字体配置编译输出结果和宿主环境完全无关。你想在一个全新的机器上编同一份论文只要挂载目录后运行同一条docker run命令出来的 PDF 就是一样的这是我在本地方案里难以做到的。另一个好处是无残留。容器退出后加--rm参数直接销毁宿主机器上不会多出几个 GB 的文件也不会污染 PATH。想彻底卸载编译环境清掉本地镜像就行一条docker rmi收工。对于我这种不喜欢在主力机上装一堆一年只用几次的软件的人来说这个体验是决定性的。还有一个容易被忽略的点是团队协作。论文写作经常是几个人共用模板、互相改稿以前发模板还要附带一句“你这个宏包版本不对升级一下”。用 Docker 之后直接把build.sh和 Docker 镜像发过去对方拉完镜像就能编减少了非常多的“环境对不上”的沟通成本。1.3 谁适合这套方案目标用户与不适合场景如果你符合下面任意一条我建议优先考虑 Docker 路线在校学生要交毕业论文、课程设计报告模板从网上下的经常依赖各种宏包期刊投稿者需要反复修改、多次回稿格式不能因为换机器而变化开发者或者有环境洁癖的人不想在系统里放一堆平时用不到的 TeX 文件。也有不适合的情况。如果你只是临时编一个简历或者单页文档本地方案反而更快毕竟拉镜像也要花时间如果你已经有一套非常稳定的 TeX Live 环境并且短期没有换机的打算也没必要折腾。这套方案的定位是“一次配置长期受益”不是写给所有 LaTeX 用户的。2. 环境准备Docker 本身怎么装不踩坑2.1 安装 Docker Desktop 前的三个检查项虚拟化、WSL2 和 Windows 功能这里先默认大家主要用 Windows 或者 macOS 的 Docker Desktop。Docker Desktop 在 Windows 上默认依赖 WSL2 后端所以不只是装一个 exe 那么简单需要先确认三个基础条件。第一虚拟化是否开启。在 Windows 的任务管理器里切到“性能”标签找到 CPU看右下角“虚拟化”一栏是不是“已启用”。如果显示“已禁用”需要重启电脑进 BIOS找到Intel Virtualization TechnologyIntel 平台或SVM ModeAMD 平台打开后保存退出。这一步没做后面 Docker Desktop 启动基本必报错。第二WSL2 是否可用。在 PowerShell管理员模式里执行wsl --status如果提示没有安装发行版先执行wsl --update更新 WSL 内核。WSL2 是 Docker Desktop 和宿主机之间的桥梁没有它 Docker Desktop 的 Linux 容器后端跑不起来。第三Windows 功能里需要勾选“适用于 Linux 的 Windows 子系统”和“虚拟机平台”。你可以在控制面板里打开“启用或关闭 Windows 功能”手动勾也可以在 PowerShell 管理员模式里执行dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart执行完记得重启电脑然后再安装 Docker Desktop。 macOS 用户相对省心直接装 Docker Desktop 就行但如果是 Apple Silicon 芯片注意镜像是否支持 arm64 架构官方 TeX Live 镜像对多架构的支持已经比较完善目前的latest标签可以直接拉。2.2 报错“Virtualization support not detected”的排查流程很多人在启动 Docker Desktop 时都会遇到一句“Docker Desktop failed to start because virtualization support wasnt detected.”这句话极其劝退但排查起来有固定的流程。先回顾自己有没有完成上面三个检查少一个都不行。特别是 BIOS 虚拟化很多人装系统时默认没开这个必须在硬件层面解决软件里怎么折腾都没用。另一个常见原因是 Windows 家庭版的问题。家庭版默认不提供完整 Hyper-V但你依然可以用 WSL2 后端来跑 Docker Desktop前提是 WSL2 本身安装正确。如果你之前手动装过 Hyper-V反而可能和 WSL2 冲突建议把 Hyper-V 相关的 Windows 功能关掉只保留 WSL2 和虚拟机平台。还有一个容易被忽视的坑是Docker Desktop 装好后第一次启动会提示需要注销或重启让用户权限生效。很多人忽略这一步直接点启动结果报错后就以为是虚拟化问题反复重装。经验是装完先重启一次再把 Docker Desktop 打开哪怕提示说可以不用重启也建议重启。这个操作我实测下来能解决很大一部分“启动即失败”的莫名其妙的问题。2.3 验证 Docker 环境用 hello-world 和镜像加速器确认基础可用Docker Desktop 正常启动后在终端里执行docker --version能打出版本号说明客户端正常。接着跑一个最小化的验证docker run hello-world如果看到一段 “Hello from Docker!” 的英文说明说明拉镜像、创建容器、运行容器的链路已经通了。这一步我建议每个人都做一遍因为后面所有 TeX Live 操作都建立在这个链路之上链路不通后面全是白折腾。同时建议提前配置镜像加速器尤其是国内网络环境下不配置的话拉 TeX Live 这种几个 GB 的镜像会非常痛苦。在 Docker Desktop 的设置里找到 Docker Engine 的 JSON 配置或者直接编辑/etc/docker/daemon.jsonLinux添加镜像加速地址{ registry-mirrors: [https://docker.example.com] }把docker.example.com换成你实际可用的加速地址。保存后重启 Docker再执行docker info看 Registry Mirrors 一栏是否生效。这一步不要跳过因为 TeX Live 的latest镜像压缩体积就有好几个 GB没有加速器真的会等到怀疑人生。3. 镜像选型和体积权衡别选错 Tag 白等半小时3.1 TeX Live 官方镜像与常用 Tag 速查Docker Hub 上最常用的是texlive/texlive这个官方仓库目前主流的做法是直接用带年份的 Tag比如texlive/texlive:2025或直接latest。我对 2026 的镜像也试过目前看 2025 和 2026 在普通论文编译场景下没有本质区别除非你的模板明确依赖某个版本的宏包一般建议选一个公布年份固定的 Tag而不是长期追 latest。这里有一个重要的经验镜像 Tag 不要随意更新。论文写到一半假如突然把镜像从 2025 换到 2026宏包版本变化可能导致编译出来的 PDF 字体、间距和浮动对象位置都变了这种“无源头”的差异在投稿前是最恶心的。所以我的建议是选定一个 Tag 后在项目文档里写死等这轮论文彻底结束再考虑升级。3.2 full 与 slim 的体积对比和场景选择官方镜像默认是 full scheme也就是把 TeX Live 几乎能装的宏包、字体、文档类都塞进去了。这样做的优点是开箱即用缺少某个宏包的概率极低缺点就是体积大拉取时间长磁盘占用高。镜像变体压缩体积参考解压后占用适用场景texlive/texlive:latest约 4 GB 以上解压后可能超过 6 GB论文排版、投稿、多模板开发省心首选texlive/texlive:年份数 GB 不等同样较大需要固定版本宏包行为的场景社区维护的 slim 变体1-2 GB 左右相对小快速验证、临时使用但缺宏包概率高如果你只是偶尔写一个简单文档slim 也够用但论文排版真心不建议省这一点体积因为模板千奇百怪指不定哪个模板就需要一个偏门宏包到时候再进容器里tlmgr install反而更耗时间。我的习惯是无脑拉 full宁可多等十分钟下载也不要在写作过程中被“缺少 .sty 文件”打断思路。3.3 拉取镜像与首次启动实测耐心等一次后面都是甜的拉镜像的命令很简单docker pull texlive/texlive:latest实测下来在配置好镜像加速器的前提下拉取时间取决于网络状况快的话十几分钟慢的话半小时以上。中途中断了也没关系重新执行docker pull会基于已有层继续下载并不是从头再来。拉取完成后可以先快速验证镜像是否可用docker run --rm texlive/texlive:latest latex --version看到pdfTeX或者相关版本信息输出就说明镜像已经能跑了。第一次启动之后你不需要再进入容器去“安装”任何东西所有宏包和工具链都在镜像里预装好了你的宿主机只需要一个 Docker 和一块干净的磁盘。4. 核心实操用一条 Docker 命令编译论文4.1 目录挂载与工作目录理解 -v 和 -w 参数容器是一个隔离环境你的.tex源文件默认不存在于容器内部所以需要用-v参数把宿主机的项目目录挂载进去。-w参数则指定容器内的工作目录相当于执行cd。我把这两件事写进同一条命令docker run --rm \ -v $(pwd):/workdir \ -w /workdir \ texlive/texlive:latest \ latexmk -xelatex -synctex1 main.tex--rm表示容器运行完直接销毁避免在宿主机上留下一个个无用的退出容器。latexmk是一个自动化编译工具它会判断当前文档需要编译多少次自动调度 xelatex、bibtex、makeindex省去手动多次执行编译命令的麻烦。这也是为什么我强烈推荐用latexmk而不是直接xelatex main.tex然后手动跑 bibtex 再跑两遍 xelatex。4.2 三种终端下挂载路径的写法Windows 最容易在这里翻车Docker 的-v参数在不同终端里获取“当前目录”的变量名不同这里是最多人在 Windows 上翻车的地方。# bash / zsh / WSL docker run --rm -v $(pwd):/workdir -w /workdir texlive/texlive:latest latexmk -xelatex main.tex # PowerShell docker run --rm -v ${PWD}:/workdir -w /workdir texlive/texlive:latest latexmk -xelatex main.tex # cmd docker run --rm -v %cd%:/workdir -w /workdir texlive/texlive:latest latexmk -xelatex main.tex经验之谈不要手写C:\Users\xxx\project这种绝对路径除非你确定它的转义方式不会出问题。Windows 路径的盘符冒号很容易让 Docker 解析出错导致挂载后容器里看不到你的.tex文件。最稳妥的方案就是上面这种用$(pwd)或${PWD}或%cd%让终端帮你拼路径。4.3 把编译命令封装成脚本以后一键出 PDF每次输入那么长一串 Docker 命令确实麻烦而且容易记错参数。我的做法是把编译命令封装成项目内的脚本。在 Linux/macOS/WSL 下可以写一个build.sh#!/usr/bin/env bash set -e docker run --rm \ -v $(pwd):/workdir \ -w /workdir \ texlive/texlive:latest \ latexmk -xelatex -synctex1 -interactionnonstopmode $然后给脚本执行权限chmod x build.sh之后编译论文只需要执行./build.sh main.texWindows 用户可以在 PowerShell 里定义一个函数放进$PROFILEfunction Build-Tex { docker run --rm -v ${PWD}:/workdir -w /workdir texlive/texlive:latest latexmk -xelatex -synctex1 -interactionnonstopmode $args }这样每次打开 PowerShell 进入论文目录执行Build-Tex main.tex就好。脚本化之后Docker 方案比本地方案还要省事因为你不再需要关注工具链本身只需要保证 Docker 在运行。4.4 中文排版支持字体问题怎么处理中文排版是论文场景的刚需。使用 Docker 环境时第一个问题往往是字体缺失。texlive/texlive官方镜像内置了 Fandol 字体这是一套开源中文字体配合ctexart、ctexbook等宏包可以正常编译出中文 PDF。实测下来绝大多数通用中文文档用 Fandol 就能出结果不需要额外挂载字体。但如果你套用的模板指定了系统字体比如宋体、黑体或者模板里用了\setCJKmainfont{SimSun}这类命令容器里没有这些字体就会编译失败报错信息通常是字体找不到。解决办法是把宿主机里的字体目录挂载到容器中docker run --rm \ -v $(pwd):/workdir \ -w /workdir \ -v /path/to/fonts:/usr/share/fonts/custom:ro \ texlive/texlive:latest \ latexmk -xelatex main.tex注意:ro表示只读挂载避免容器意外修改字体文件。挂载完成后容器内执行fc-list | grep -i simsun能看到对应字体就说明 fontconfig 已经识别到了。缺少中文字体是 Docker 方案里出现频率最高的坑之一提前把模板里用到的字体列出来一次性挂进去能省很多反复试错的时间。5. 集成 VSCode像用本地环境一样写 LaTeX5.1 LaTeX Workshop 插件与整体思路命令行编译已经很高效了但写作体验还可以更进一步。VSCode 里最主流的 LaTeX 插件是 LaTeX Workshop它支持语法高亮、代码补全、错误定位、PDF 预览、正向同步源码到 PDF和反向同步PDF 到源码。把这些能力与 Docker 编译环境结合起来就能实现“本地编辑、容器编译、本地预览”的舒服流程。整体思路是LaTeX Workshop 负责监听你的.tex文件保存动作保存后触发的不是本机的latexmk而是我们之前封装的docker run命令。因为宿主机和容器共享同一份挂载目录编译生成的.pdf、.synctex.gz文件会直接出现在宿主机的项目目录中VSCode 的 PDF 查看器就能正常加载。5.2 settings.json 配置 Docker 编译工具链在 VSCode 里打开设置搜索latex-workshop.latex.tools在settings.json中加入如下配置{ latex-workshop.latex.recipes: [ { name: Docker latexmk, tools: [docker-latexmk] } ], latex-workshop.latex.tools: [ { name: docker-latexmk, command: docker, args: [ run, --rm, -v, %DIR%:/workdir, -w, /workdir, texlive/texlive:latest, latexmk, -xelatex, -synctex1, -interactionnonstopmode, %DOC% ], env: {} } ], latex-workshop.latex.clean.fileTypes: [ *.aux, *.bbl, *.blg, *.log, *.out, *.fls, *.fdb_latexmk ] }%DIR%是当前.tex文件所在目录%DOC%是当前文件名。LaTeX Workshop 会自动把这两个变量替换成实际值。此时在 VSCode 里打开main.tex点右侧的 TeX 菜单里的 Build LaTeX project就会触发 Docker 编译。有一个小坑需要提醒VSCode 的终端环境变量不一定包含docker命令的路径。如果你配置后发现点击编译没有任何反应先检查一下终端里能不能直接运行docker --version如果不能需要把 Docker Desktop 的安装路径加到 PATH或者把command字段改为 Docker 可执行文件的完整路径比如 Windows 下常见的是C:\Program Files\Docker\Docker\resources\bin\docker.exe。5.3 SyncTeX 同步正向跳转和反向跳转怎么配LaTeX Workshop 加上-synctex1参数后编译目录中会生成.synctex.gz文件VSCode 就能实现源码和 PDF 的双向同步。正向同步也就是从源码跳到 PDF 对应的位置在main.tex中按CtrlAltJ或者调出命令面板执行 “SyncTeX from cursor”PDF 查看器会直接滚动到编译出的那一行对应的页面。反向同步则是从 PDF 点击跳到源码。在 LaTeX Workshop 内置的 PDF 查看器中按住Ctrl然后点击 PDF 文字会自动跳到对应的源码行。这里值得注意一点因为容器内的工作目录是/workdir而宿主机里可能是C:\Users\xxx\project两者路径不一致会在个别场景下导致反向同步定位不准。我的实测结论是只要.tex文件与辅助文件在同一个目录下、文件名不包含中文和空格VSCode 内置查看器的反向同步基本都能正常工作。如果出现跳转错位优先检查文件名是否规范而不是折腾其他配置。5.4 联调阶段的常见问题保存后不编译、权限拒绝、路径乱码保存后不编译先检查右下角有没有报错信息再看 LaTeX Workshop 的 Output 面板。最常见的原因是docker命令在 VSCode 的集成终端里不可用重启 VSCode 之后仍然不行就用where docker或which docker找到完整路径填到配置里。权限拒绝则主要出现在 Windows 上Docker Desktop 的共享目录设置里没有把项目所在盘符加进去。需要在 Docker Desktop 的 Settings 里找到 Resources / File Sharing把对应的磁盘勾上再重启 Docker。路径乱码的问题大多出在项目目录包含中文。LaTeX 本身对中文文件名的支持就比较弱SyncTeX 在中文路径下更容易出问题。所以无论本地方案还是 Docker 方案我都强烈建议论文项目和所有.tex文件名一律用英文纯英文路径能规避掉一整个类别的诡异问题。6. 实战案例从空目录到完整论文模板6.1 最小中文模板3 分钟跑通第一份 PDF起步阶段不需要复杂的模板结构先验证整条编译链路。新建一个目录比如latex-demo里面创建main.tex\documentclass[UTF8]{ctexart} \title{基于 Docker 的 LaTeX 编译环境测试} \author{Alice} \date{\today} \begin{document} \maketitle \section{引言} 这是一份用于验证 Docker 编译链路的中文文档。 行内公式示例$a^2 b^2 c^2$。 独立公式示例 \[ \int_0^1 f(x) \, dx \] \end{document}在项目目录下执行./build.sh main.tex等待编译完成后目录下会出现main.pdf。打开 PDF看到中文标题、作者、公式都正常渲染就说明 Docker TeX Live 中文支持的整条链路已经通了。这里说明一下为什么用ctexart而不是article搭配xeCJK宏包ctex宏集一站式处理了中文字体、段落缩进、标题格式等细节对新手最友好对论文写作也够用。如果你用的是学位论文模板模板里通常会自己加载ctexbook或ctexrep底层逻辑是一样的。6.2 BibTeX 报错排查“This is BibTeX, version 0.99d”到底是怎么回事这是搜索引擎里出现频率极高的一段报错信息很多人看到This is BibTeX, Version 0.99d (TeX Live 2022)就慌了以为版本有问题。其实这一行只是 BibTeX 程序的启动提示BibTeX 的版本号从几十年前就是 0.99d 一直没变过不是错误。真正的问题通常出现在这句话的下面The top-level auxiliary file: main.aux之后如果 BibTeX 没有正常生成.bbl文件最常见的两个原因是一是main.tex里根本没有写\bibliography{refs}或者写的文件名和实际.bib文件名不一致二是你在没有任何.aux文件的情况下直接执行了bibtex mainBibTeX 没有辅助文件可读自然什么都做不了。解决方案就是使用latexmk自动调度它会先跑 xelatex 生成.aux再在需要时自动调用 bibtex然后继续跑后续的 xelatex。如果非要手动执行标准顺序是xelatex main.tex bibtex main xelatex main.tex xelatex main.tex另外强烈建议.bib文件名只用英文不要用空格、中文或特殊符号。我见过太多人把参考文献.bib写进\bibliography{}然后 BibTeX 各种报错找不着文件换成refs.bib一次通过。6.3 编译错误定位技巧日志怎么读、latexmk 帮你干了什么很多新手遇到编译失败就不知道从哪里下手。其实 LaTeX 的编译日志是有固定阅读顺序的。先看终端输出里的最后一段latexmk通常会直接指出第一个错误发生的行号和错误类型。如果输出信息不够直观就去项目目录下找.log文件打开后搜索!开头的行比如! LaTeX Error: File xxx.sty not found.或者! Undefined control sequence.这些就是错误的真正原因。排查思路上先区分是“环境问题”还是“文档问题”。File not found多半是宏包缺失Docker 镜像如果已经是 full scheme这种情况很少见。Undefined control sequence则是文档里用了未定义的命令大概率是忘记加载某个宏包或者某个命令拼写有误。Missing $ inserted则是数学模式的经典问题说明在数学环境外使用了数学命令。还有一个非常实用的技巧在编译命令中加-interactionnonstopmode让 LaTeX 遇到错误时不要停下来等待输入而是把所有错误记录到日志里一次性展示完。这样你就可以根据main.log逐条修复而不是被交互式停顿卡住后不知所措。这一点对容器化编译尤其重要因为在非交互式终端里一旦 LaTeX 停下来等你按键整个编译流程就卡死了。6.4 顺手解决几个高频排版小问题换行、希腊字母、数学公式写论文时经常有人卡在这些基础细节上。LaTeX 里的“换行”分两种段落内强制换行用\\或\newline另起一段则用空行两种效果不一样混用容易造成莫名其妙的间距问题。如果你发现空行没有生效检查是不是\\后面直接跟了空行这种写法在部分文档类下会有问题。希腊字母在 LaTeX 里属于数学模式的命令最常用的写法是\alpha、\beta、\gamma、\omega。注意区分大小写小写\delta对应 δ大写\Delta对应 Δ两者不是同一个符号。\epsilon和\varepsilon也有区别排版习惯上后者更常见。行内公式用单个$...$包裹独立成行的公式用\[...\]多行公式则建议加载amsmath宏包后使用align环境。写论文时如果需要公式自动编号用equation环境即可。基础的数学公式能力在绝大多数论文模板里都是默认配备的这些只是帮你快速上手不至于在最基础的地方卡壳。7. 常见问题排查与避坑速查表7.1 问题现象与处理方案对照表下面这个表格是我在实际使用中整理出来的高频问题基本覆盖了从安装 Docker 到编译论文全过程会遇到的典型坑。现象最可能的原因处理方式Docker Desktop 启动提示虚拟化未检测到BIOS 虚拟化没开或 WSL2 组件缺失进 BIOS 开 VT-x/AMD-V勾选 Windows 功能执行wsl --update拉取 TeX Live 镜像非常慢没有配置镜像加速器在 Docker Engine 的 JSON 配置里加 registry-mirrors容器内编译中文乱码引擎没用 xelatex编译命令改成latexmk -xelatex提示找不到字体如 simsun容器内没有模板指定的系统字体挂载字体目录到/usr/share/fonts/custom挂载目录后容器内看不到文件Windows 挂载路径写错用$(pwd)、${PWD}或%cd%获取当前目录BibTeX 提示顶层辅助文件无法处理缺少.aux或.bib文件名不匹配改用 latexmk 自动调度或按 xelatex → bibtex → xelatex ×2 顺序手动跑编译停住不动好像在等待输入缺少-interactionnonstopmode编译参数加上-interactionnonstopmode缺少宏包.sty not found镜像里没有对应包首先确认用的是 full 镜像其次再考虑临时tlmgr install容器里执行fc-list提示命令不存在镜像没装 fontconfig 工具不影响编译可以不处理或挂载字体后换一个带工具链的容器调试SyncTeX 反向同步跳转错位项目目录或文件名含中文、空格改成纯英文路径辅助文件与.tex同目录7.2 几条独家避坑心得镜像更新、临时调试与离线迁移最后分享几条我自己踩过坑之后形成的习惯。第一不要手贱更新镜像 Tag。论文期间保持环境固定是最重要的一条纪律。很多人看到 Docker Hub 提示有新版本就顺手换了镜像结果同一份文档编译出来的 PDF 和上次不一样这种问题排查起来极其痛苦。第二临时调试的时候可以进入容器交互式操作。有时候光看编译日志解决不了问题我会直接跑docker run --rm -it \ -v $(pwd):/workdir \ -w /workdir \ texlive/texlive:latest \ bash进入容器后就能手动执行xelatex、tlmgr install、fc-list等命令逐步定位问题。注意容器是临时的退出后里面安装的包就没了所以这只适合排查不适合作为长期改环境的手段。第三如果项目长期需要某个额外的宏包不要每次都进容器手动装而是写一个简单的 DockerfileFROM texlive/texlive:latest RUN tlmgr update --self tlmgr install somepackage CMD [bash]然后重新构建镜像这样团队里所有人都能用上同一个带额外包的环境完整复现。另外还有一个我非常推荐的离线迁移技巧用docker save把镜像导出成 tar 包拷到没有网络的电脑上再docker load导入。比如评审机器或者没有外网的实验室电脑docker save texlive/texlive:latest | gzip texlive.tar.gz到了目标机器上解压再 load 就能跑这也是我在出差写论文时最救命的功能。这套 Docker TeX Live 方案我用了快两年。现在实验室里来了新同学要写论文我基本不用再花时间帮别人配环境发一份build.sh再告诉对方docker pull texlive/texlive:latest十分钟之内就能开始编译。你要是也被 LaTeX 的环境问题折磨过真心建议今天就拉一个镜像试试亲自感受一次“编辑器里写完终端一条命令出 PDF”顺畅体验大概率就回不去了。