LuaTeX 重新编译只要 1 毫秒？它真正省掉的是“不必做的整本书”
林岚｜OC 开发者生态编辑
林岚｜OC 开发者生态编辑
根据 Clemens Lode 在 TUG 2026 提交的论文 Real-Time LuaTeX: Recompiling Large Documents in 1ms，他开发的 texlode 编辑器让一个持续运行的 LuaTeX 进程只重新排版正在编辑的段落，并直接读取内部显示列表，在测试机器上把短段落的完整往返时间压到约 0.79 毫秒。整份文档的页码、浮动对象和交叉引用则在后台重新收敛。
一句话结论： 这里的“1 毫秒重新编译大型文档”不是 300 页 PDF 每次都在 1 毫秒内完整生成，而是把用户眼前必须立刻正确的局部结果，与可以稍后更新的全局布局拆开。
LaTeX 用户很熟悉这种循环：改一个字，保存，等待几秒甚至几十秒，再从 PDF 里找到刚才那一页。文档越长、字体和宏包越复杂，等待越明显。Typst 的流行也有一部分来自这种体验差异，它从架构上支持增量计算，编辑反馈通常比传统 LaTeX 快得多。
Lode 的思路并不是重写 TeX，也不是宣称 Knuth 的算法突然快了几千倍。他问了一个更像性能工程师的问题：用户修改一个段落时，为什么要重新计算整本书？
段落局部，分页全局
TeX 的断行算法有一个适合交互编辑的性质。在行宽、字体和段落内容不变时，一个段落怎样拆成多行，不取决于前后段落写了什么。因此用户在当前段落敲字时，真正需要立即更新的是这段文字的断行和字形位置。
分页却是全局问题。当前段落多出一行，后面所有内容都可能移动；脚注、浮动图片、页码和交叉引用也可能变化。但这些变化通常不需要在每次键盘输入后的同一毫秒完成。Word、InDesign 和 Google Docs 多年来都在使用类似策略：眼前内容先更新，完整布局在后台追上来。
texlode 保持 LuaTeX 进程常驻，省掉约一秒的复杂前导区启动成本；把单个段落交给引擎排版后，不生成 PDF，而是直接从 LuaTeX 节点结构里提取包含字形坐标的 display list，再交给浏览器 Canvas 绘制。完整 LuaLaTeX 编译在后台运行，用来修正全局页位。
1 毫秒到底测了什么
论文使用 Intel Core i7-1355U 与 TeX Live 2025。单纯断行测试中，短段落中位数约 0.17 毫秒，四到五行的中等段落约 0.70 毫秒，十行以上长段落约 1.99 毫秒。加入进程通信、序列化和浏览器数据展开后，短段落往返约 0.79 毫秒，中等段落约 6.11 毫秒。
所以标题里的 1 毫秒是合理的代表值，却不是任何内容都固定 1 毫秒。更不能把它理解成最终 PDF 导出时间。作者自己列出了快速路径的边界：脚注会影响分页，\ref 和 \thepage 依赖全局状态，浮动对象也必须等待后台完整编译。
论文还拿 Typst 0.14.2 做了比较。修改同一个中等段落时，Typst 在 10、100、300 页文档上的测试分别约为 12.6、76 和 206 毫秒；LuaTeX 局部路径保持约 0.70 毫秒。这个对比不能简单推出“LuaTeX 比 Typst 快 294 倍”，因为两边提供的保证不同：Typst 每次让全局布局收敛，texlode 刻意接受暂时不一致。
这是一个很通用的工程取舍
很多慢系统并不缺更快的底层算法，而是每次更新都做了用户暂时不需要的完整工作。IDE 不会每输入一个字符就重新构建所有目标，数据库不会为读一行扫描整张表，网页也不会为了改变一个按钮重排所有无关节点。
texlode 的启发就在这里：先定义交互时必须成立的最小一致性，再把全局正确性放到后台。但这个技巧也会制造新的状态管理问题。用户当前看到的段落已经更新，页码却可能还是旧的；后台编译失败时，界面必须明确告诉用户，而不是长期展示一份局部正确、整体错误的文档。
texlode 计划在 2026 年 10 月公开发布，目前仍应把论文看成架构和基准展示，而不是已经成熟替代 Overleaf 的产品。
关键事实
- 快速路径只重新排版当前段落，并不在 1 毫秒内完整生成大型 PDF。
- 短段落端到端测试约 0.79 毫秒，中等段落约 6.11 毫秒。
- 页码、脚注、浮动对象和交叉引用依靠后台完整编译收敛。
- texlode 未修改 LuaTeX 引擎，但需要常驻进程、节点遍历、浏览器绘制和缓存系统。
OC 判断
这项工作最有价值的不是“击败 Typst”的跑分，而是把 LaTeX 的交互延迟重新定义成局部一致性问题。它用暂时的全局滞后换取即时反馈，适合编辑器，却不能替代最终构建。任何引用 1 毫秒数字的人，都应该把这项交换条件一起说出来。
为什么重要
- 对开发者： 先找出真正需要同步完成的最小计算单元，往往比继续优化完整流程更有效。
- 对工具厂商： 实时体验需要后台收敛、错误状态和缓存失效机制，不能只展示一次漂亮基准。
- 对 LaTeX 用户： 这条路线可能让书籍级排版获得接近普通文字处理器的反馈速度，同时保留最终输出质量。
评论
围绕这篇文章补充信息、提出问题或分享观察。