我刚装好 TeX Live 2020，第一次在命令行里敲下pdflatex test.tex，满心期待 PDF 输出，结果屏幕上冷冰冰地蹦出一行：
I can't find the format file `pdflatex.fmt'!更憋屈的是，这行提示根本不告诉你去哪找、为什么找不到。对刚接触 LaTeX 的新手来说，这就是一盆冷水；对老手来说，也经常是折腾半天才想起是格式文件没生成。实际上，pdflatex.fmt这行报错背后牵扯到 TeX 的预编译机制、PATH 环境变量、权限问题、甚至多版本共存冲突，排查路径还挺长。
这篇文章我打算从.fmt文件本身讲起，带你完整走一遍排查和修复流程，把 TeX Live 2020 里最常见的几种诱因一次说清楚。无论你是刚入门还是被困扰了很久的老用户，按照下面的步骤操作，大概率能在十分钟内解决。
1. 先搞明白 pdflatex.fmt 到底是什么
很多用户遇到这个报错第一反应是重装 TeX Live，这其实是最费时间的做法。要解决问题，得先理解 TeX 的启动机制。
1.1 format 文件对 TeX 启动意味着什么
TeX 引擎（包括 pdfTeX、XeTeX 等）启动时并不会像普通程序那样从头加载宏包文件，而是直接读取一个“预编译”好的格式文件（format file），扩展名就是.fmt。
你可以把.fmt理解成预制菜：latex.ltx这类核心宏包相当于生鲜食材，在安装时 TeX 会先把这些食材统一洗净、切好、打包，生成一个半成品包。每次编译文档时，引擎直接拆开这个半成品包用，省去了重复解析宏包的时间。如果没有这个预编译包，每次启动 TeX 都要经历几秒钟的完整加载，效率和稳定性都会受影响。
pdflatex.fmt就是 pdfTeX 引擎配合 LaTeX 格式生成的格式文件，专门服务于pdflatex命令。当系统提示找不到这个文件，含义就是引擎在它所有的搜索路径里都没能找到这个预编译包，于是进程直接终止。
1.2 为什么 TeX Live 2020 特别容易遇到这个报错
除了干净的首次安装场景之外，TeX Live 2020 这个版本因为年代特殊，踩坑概率相当高。
2020 版是很多 Linux 发行版默认软件源里自带的版本，也是很多人在线安装脚本默认拉取的版本。问题恰恰出在“版本多、来源杂”上：发行版自带一套 TeX Live，你手动又装了一套 TeX Live 2020，命令行默认访问的却是另一套；或者你之前用过旧版 TeX，用户目录下残留了旧格式文件，新版本搜索路径又正好优先扫到了残留的坏文件。
另外，TeX Live 2020 的安装脚本本身也更依赖系统环境和权限设置。比如安装时用了sudo，生成的目录归 root 所有，普通用户运行pdflatex时无法在系统目录下写入新的格式文件缓存，就会出现“格式找不到”的假象。2020 版年代较久，官方在后续版本修复了不少安装器问题，但 2020 本身这些问题还在，所以格外值得排查。
2. 第一步排查：你的 TeX 到底从哪来
遇到报错别急着重装，先搞清楚一件最基本的事：你现在命令行里调用的pdflatex，到底是哪个版本、装在哪个目录、用的是哪套 TeX 发行版配置。
2.1 先运行三条命令确定当前环境
打开终端，依次执行：
which pdflatex pdflatex --version kpsewhich pdflatex.fmtwhich pdflatex告诉你命令行调用的二进制文件实际路径，比如/usr/local/texlive/2020/bin/x86_64-linux/pdflatex或/usr/bin/pdflatex。路径直接暴露了它来自哪个发行版。pdflatex --version会显示引擎版本号，确认它是否来自 TeX Live 2020。kpsewhich pdflatex.fmt是 Kpathsea 库的搜索工具，它会按当前配置的搜索路径去找.fmt文件。这一步很关键：如果它输出了某个路径，说明文件其实存在，只是调用方式有问题；如果输出为空，说明文件确实不在任何搜索路径里。
如果kpsewhich能找到pdflatex.fmt，但pdflatex还是报找不到格式文件，那问题基本锁定在引擎和配置不匹配上，继续往后看排查 PATH 和多版本冲突。
2.2 PATH 顺序坑与多版本共存问题
Linux 和 macOS 下，命令行的执行顺序完全取决于 PATH 环境变量里的目录先后顺序。系统默认的/usr/bin/pdflatex通常来自发行版的 texlive-base 包，而你手动安装的 TeX Live 2020 通常位于/usr/local/texlive/2020/bin/<架构>目录。如果/usr/bin排在前面，即使 2020 已经装了，也不会被优先调用。
更麻烦的是，当你用系统包管理器安装的 texlive-bin 版本和手动安装的 TeX Live 2020 混在一起时，很容易出现“调用的引擎是一套、找格式文件的配置是另一套”的分裂状态。kpsewhich读到的配置，和pdflatex实际运行时使用的配置可能完全不同。此时最常见的现象就是：which pdflatex指向系统目录，而kpsewhich去找的却是 2020 的 texmf 树，两边对不上，于是格式文件找不到。
解决办法很直接：在~/.bashrc或~/.zshrc里把 TeX Live 2020 的 bin 目录放到 PATH 最前面：
export PATH=/usr/local/texlive/2020/bin/x86_64-linux:$PATH具体架构目录名可能不同，可以先用ls /usr/local/texlive/2020/bin看看实际目录。设置完记得执行source ~/.bashrc或重新打开终端，再跑一次which pdflatex确认指向 2020。
注意：如果你不确定当前系统里有没有系统自带的 TeX Live 组件，可以先执行
dpkg -l | grep texlive（Debian/Ubuntu 系）或rpm -qa | grep texlive（RedHat 系）查一下。有的话不一定非卸载，但一定要确保 PATH 顺序明确可控。
3. 核心修复：用 fmtutil 重建 pdflatex.fmt
如果排查完 PATH，确定调用的是正确的 TeX Live 2020，问题依然存在，那大概率是格式文件真的缺失、损坏或配置异常。这时候就要请出 TeX Live 自己的格式管理工具fmtutil。
3.1 fmtutil 的作用与家族成员
fmtutil是 TeX Live 中专门负责生成和管理.fmt文件的工具。它读取fmtutil.cnf配置文件中注册的格式列表，按需逐条编译生成对应的格式文件。直接说，它是修复“格式文件缺失”这类问题的主力工具。
TeX Live 2020 里它有三个变体：
fmtutil-sys：系统级操作，需要管理员权限，作用于系统安装的 texmf 树，生成的格式文件对所有用户生效。fmtutil-user：用户级操作，不需要管理员权限，作用于当前用户目录下的 texmf 树，只对当前用户生效。fmtutil：自动判断，根据安装位置和权限决定调用哪个变体，或者需要手动加参数指定。
在 Linux/macOS 上，如果 TeX Live 是以sudo方式安装到/usr/local/texlive/2020，建议直接使用fmtutil-sys，否则生成的文件可能没有权限写入系统目录。在 Windows 上则要在管理员命令行里操作。
3.2 重建格式文件的标准操作流程
最简单的修复方式是全量重建：
sudo fmtutil-sys --all这个命令会按照配置重建所有格式文件，可能耗时几分钟，耐心等它跑完。如果只想重建pdflatex对应的格式，可以按需缩小范围：
sudo fmtutil-sys --byfmt pdflatex注意，--byfmt的参数是格式名，不是文件名，所以这里的pdflatex是格式名，执行时会自动生成pdflatex.fmt文件。
执行完以后，验证是否修复：
pdflatex --version echo "hello" > /tmp/test.tex cd /tmp && pdflatex test.tex如果不再出现格式文件找不到的报错，并且能正常生成 PDF，说明问题已经解决。
3.3 重建时看到什么算成功
fmtutil执行过程中会输出大量日志，出现类似这样的行就说明pdflatex重建成功：
fmtutil-sys: running `pdftex -ini -jobname=pdflatex -progname=pdflatex -etex -8bit ...' fmtutil-sys: running `pdftex -ini -jobname=pdflatex -progname=pdflatex -etex -8bit ...'结尾处一般会有个汇总，提示生成了多少个格式、跳过多少个、失败多少个。只要pdflatex对应的行没有报错，基本可以放心。
如果看到失败行，比如缺少某个宏包文件，先不要急。通常是因为宏包树（texmf tree）里确实缺文件，后续可以用tlmgr补装对应集合，或者检查安装完整性。
3.4 fmtutil 本身报错怎么办
偶尔会遇到更尴尬的情况：连fmtutil自己也跑不起来。常见提示是找不到配置文件：
fmtutil: no config file "fmtutil.cnf"这说明 Kpathsea 配置有问题。此时用kpsewhich查一下配置文件搜索路径：
kpsewhich fmtutil.cnf kpsewhich texmf.cnf如果kpsewhich本身输出为空，说明 TeX 的目录树配置彻底混乱了。这时候最干净的办法是直接检查环境变量：
env | grep TEX看到TEXMFROOT、TEXMFLOCAL、TEXMFCONFIG这些变量时，先想一下它们是不是被手动设置过。这些变量一旦指向无效目录，全套工具都会跟着失灵。解决办法是临时清空它们再试：
env -u TEXMFROOT -u TEXMFLOCAL -u TEXMFCONFIG sudo fmtutil-sys --all如果清空后正常，说明就是环境变量背的锅，去 shell 配置文件里揪出export TEX开头的行删掉即可。
4. 深挖另外三种隐蔽原因
排查完 PATH 和 fmtutil，还有几种隐蔽原因需要留意。它们出现频率不算最高，但一旦遇到，排查起来跟大海捞针差不多。
4.1 TEXMF 目录变量被错误覆盖
TeX 的目录树系统通过一组 TEXMF 相关变量来定位文件。正常安装情况下，这些变量都由texmf.cnf配置文件自动计算，用户不需要手动设置。但有些用户为了“自定义安装目录”，会在 shell 里手动加环境变量，结果反而破坏了原本的搜索链。
最典型的坑是两个：
- 设置了
TEXMFROOT指向一个不完整或空的目录，所有搜索都会在这个空目录里打转。 - 设置了
TEXMFHOME指向一个没有正确结构的手动目录，导致格式化文件搜索时优先命中无效位置。
排查方法很简单，一条命令看全部变量：
kpsewhich -var-value TEXMFROOT kpsewhich -var-value TEXMFHOME kpsewhich -var-value TEXMFCNF如果输出路径和你安装的 TeX Live 2020 不一致，或者指向一个明显不存在的目录，那基本可以确定变量被污染了。到~/.bashrc、~/.profile、/etc/profile里搜索TEXMF关键词，删掉可疑的内容再开新终端测试。
我自己就踩过一次：为了“方便”，在某配置里加了export TEXMFHOME=~/mytmf，结果那个目录里只放了几个简单的.sty文件，没有 format 文件，导致pdflatex每次启动都找不到格式。删掉变量后一切恢复正常。
4.2 文件权限与用户目录污染
这个原因在 Linux 下很普遍，而且特别狡猾。常见路数是这样：你之前用旧版 TeX Live 编译过文档，用户目录~/.texlive2020（或类似目录）里已经生成过一份格式文件缓存。后来系统切换了 TeX Live 版本，或者你手动改过目录权限，旧缓存的权限变成 root 所有，当前用户读不了、删不掉、也无法覆盖写入。此时 TeX 搜索时看到目录里有同名文件，但打开时权限不足，最终报出“找不到格式文件”。
排查时先看看用户目录下的 TeX 相关目录是否可写：
ls -la ~ | grep texlive ls -la ~/.texlive2020如果发现有些目录或者文件 owner 是 root 而你自己没有写权限，可以接管所有权：
sudo chown -R $USER:$USER ~/.texlive2020然后重新运行格式重建命令。这一步操作之后，很多莫名其妙的问题都会消失。
另一种用户目录污染的情况是：残留了过时的texmf-config配置。比如旧版本在~/.texlive2020/texmf-config下写了自定义映射或格式配置，新版本启动时会优先读取这些陈旧配置，导致格式名和引擎对不上。处理办法是备份后清空该目录下可疑的updmap.cfg、fmtutil.cnf等文件，再执行fmtutil-user --all重建。
4.3 安装不完整与事后修复思路
有些人是通过在线安装脚本装的 TeX Live 2020，安装途中网络波动、终端意外关闭，安装器实际并没有完整写入所有格式文件。表面上 bin 目录和 texmf 树都在，但检查细节时会发现缺了一些关键集合，比如latex-bin缺失导致格式文件根本没生成。
这种“半成品”安装很难一眼看出来。比较高效的验证方式是查看安装日志里是否包含如下关键集合：
tlmgr info latex-bin tlmgr info latexconfig如果tlmgr报这些包未安装或异常，按需补装：
sudo tlmgr install latex-bin latexconfig sudo tlmgr install collection-latexrecommended补装完再执行fmtutil-sys --all。一般情况下，补上缺失集合后格式文件就能正常生成。
4.4 临时目录与安全软件干扰
还有两类原因不太容易被人联想到，但确实会导致格式文件生成失败。一类是TMPDIR或系统临时目录不可写。TeX Live 在生成格式文件时会在临时目录里创建中间文件，如果临时目录空间不足或无权限，pdftex -ini阶段会静默失败，然后fmtutil把结果标记为失败。
检查临时目录状态：
df -h /tmp touch /tmp/test.txt如果/tmp空间满了，清理一些大文件后再试；如果touch失败，说明权限或挂载方式有问题，需要手动修复。
另一类是 Windows 用户经常遇到的杀毒软件干扰。部分安全软件会把 TeX Live 安装目录下的pdftex.exe等二进制文件加入“可疑程序”名单，或者阻止其在缓存目录里写入.fmt文件。表现就是：明明安装正常，一运行就报格式文件找不到，fmtutil执行也每次失败。解决方法是把 TeX Live 安装目录加入杀毒软件白名单，并用管理员权限重新运行fmtutil-sys --all。
5. 常见错误变体与快速对照速查表
这类问题在实际操作中经常以不同面貌出现，把常见变体和对应处理方法整理成表，方便读者直接对照。
| 报错现象 | 可能原因 | 快速处理 |
|---|---|---|
I can't find the format file \pdflatex.fmt'!` | PATH 不对、格式未生成、多版本冲突 | 先查kpsewhich pdflatex.fmt，再按需fmtutil-sys --byfmt pdflatex |
I can't find the format file \latex.fmt'!` | 旧的latex命令对应格式缺失 | 通常是系统 TeX 与新版共存，统一 PATH 后重建 |
I can't find the format file \pdftex.fmt'!` | pdfTeX 原始格式缺失 | fmtutil-sys --byfmt pdftex |
fmtutil: no config file "fmtutil.cnf" | Kpathsea 配置损坏 | kpsewhich fmtutil.cnf，检查 TEXMFCNF 变量 |
kpsewhich pdflatex.fmt有输出但pdflatex报错 | 引擎和配置分属两套 TeX | 重查which pdflatex，调整 PATH 顺序 |
fmtutil运行失败且常见包缺失报错 | 安装不完整 | tlmgr install latex-bin latexconfig后重建 |
Windows 下fmtutil每次失败 | 杀毒软件拦截 | 加白名单，管理员权限重跑 |
这张表主要给到操作顺序：先定位问题在环境还是格式文件本身，再决定执行哪条修复命令。很多人一看到“格式文件找不到”就直接去重装系统级 TeX，结果浪费了大量时间。其实 80% 的场景都集中在 PATH 或权限两类问题上。
再来一个拆解案例。我曾经在某台机器上遇到一个诡异情况：终端里pdflatex明明指向/usr/local/texlive/2020/bin/x86_64-linux/pdflatex，kpsewhich pdflatex.fmt也有输出，但每次编译都报格式文件找不到。仔细看了才发现，这台机器上存在两个 texmf 树：2020 的 texmf-dist 和一套很老的 texmf 目录。kpsewhich搜索时老 texmf 排在前面，里面的pdflatex.fmt是旧版引擎生成的二进制格式，新版 pdftex 根本无法读取，所以引擎侧把它当成无效格式，最终提示找不到。处理方式是修改texmf.cnf里的搜索顺序，或者干脆把老目录移走，然后用fmtutil-sys --all重建。这种问题靠经验很难一次看穿，但按上面的排查顺序走一遍就能定位。
6. 避免下次再踩坑的做法
问题解决了，顺手做点预防，免得下次装新版本或换机器时重蹈覆辙。
6.1 用 tlmgr 管理，少用 sudo 乱装
TeX Live 自己的包管理器tlmgr是标准维护工具。很多人习惯用系统包管理器去装 LaTeX 支持组件，结果装出两套 TeX 环境互相打架。如果是手动安装的 TeX Live 2020，后续补包、更新一律用tlmgr：
sudo tlmgr update --self sudo tlmgr install <包名>不要用系统包管理器去补 TeX Live 手动版的依赖，两边管理机制完全不同。
6.2 固话 PATH 时给后人留条退路
配置 PATH 时，在~/.bashrc里写清楚来源是个好习惯：
# TeX Live 2020 PATH export PATH=/usr/local/texlive/2020/bin/x86_64-linux:$PATH注释能帮你和未来接手机器的同事快速理解这里改过什么。也建议把tlmgr path add这种自动配置方式了解清楚，它会在配置里写入当前 TeX Live 的路径，减少手工拼路径的错误率。
6.3 多版本共存时的铁律
如果你必须同时保留系统 TeX Live 和手动版 TeX Live 2020，务必遵守两点：第一，手动版 bin 目录永远放在 PATH 最前面；第二，不要在两个版本间混用tlmgr和系统包管理器去安装同一宏包，否则很容易出现宏包文件新旧混杂。
我个人的建议是，如果不是有特殊依赖需求，直接用纯手动版 TeX Live 2020 一套环境就够了。系统自带的版本大可以卸载或留着不用，没必要同时维护两套。因为 TeX 生态本身就敏感于文件搜索路径，两套环境共存带来的排查成本，远高于省下的那点磁盘空间。
6.4 养成“三件套”排查习惯
遇到任何 TeX 环境问题，先跑这三个命令：
which pdflatex kpsewhich pdflatex.fmt tlmgr --version这三个命令依次回答“用的是谁家的引擎”“格式文件在哪”“包管理器是不是同一套”。只要这三项对得上，绝大多数环境类问题都能快速定位。我自己每次装完新版本，也会顺手跑一遍这个三连，确认环境健康后再开始干活。
说句实在话，I can't find the format file \pdflatex.fmt'!这个报错本身并不复杂，真正麻烦的是它背后牵扯的变量和路径太多。但只要你理解了 TeX 的格式预编译机制，再配合which、kpsewhich、fmtutil` 这几个工具按顺序排查，它反而是最容易根治的 TeX 环境问题之一。希望这篇记录能帮你少走几步弯路，下次再看到这行报错，心里能立刻浮现出一条清晰的排查路线。
