Overleaf 编译链路拆解从 LaTeX 源码到 PDF 的四层路径【免费下载链接】overleafA web-based collaborative LaTeX editor项目地址: https://gitcode.com/GitHub_Trending/ov/overleaf在 Overleaf 里点击编译按钮后请求并不会停留在承载你项目的 Web 进程上它要经过转发落到一个名为 CLSI 的独立服务里而真正执行 pdflatex 的 TeX 引擎则在一个临时拉起的隔离环境中运行。这篇文章沿请求走过的路径把每一层做什么、编译超时的参数在哪里、生成的 PDF 又存在哪儿讲清楚内容足以支撑你在自建 Overleaf 后快速定位和调参。编译请求的第一跳web 把接力棒交给 CLSI浏览器里前端发起的编译请求最终会命中 CLSI 的 REST 接口。在入口文件 services/clsi/app.js 里能看到核心路由POST /project/:project_id/compileCLSI 默认监听 3013 端口REST 接口另有 3048 和 3049 两个端口分别用于上报负载和运维控制这些默认值定义在 services/clsi/config/settings.defaults.cjs。这一层有两个容易被忽略的硬限制请求体大小上限compileSizeLimit默认7mb由环境变量COMPILE_SIZE_LIMIT覆盖——所以编译包上传失败多半是撞了这条线HTTP 超时统一设为 630 秒10.5 分钟代码注释写明是为文件下载时间预留了 30 秒。整条链路可以概括成一张图CLSI 内部它不跑 LaTeX它负责调度编译CLSI 收到请求后由 CompileController 接管把源码写入按项目隔离的编译目录然后交给 LatexRunner 构造真正的编译命令。这里有个反直觉的点CLSI 自己并不包含 TeX Live 发行版。启用沙箱编译SANDBOXED_COMPILEStrue时它会通过挂载的 docker.sock 拉起兄弟容器来跑 TeX Live 镜像镜像由TEXLIVE_IMAGE指定配置文件尾部还有 seccomp、AppArmor 等安全配置社区版的本地模式下则由 LocalCommandRunner 在 CLSI 所在环境直接执行命令。真正下发给编译器的命令是latexmk参数在 LatexRunner 里固定拼好latexmk -cd -jobnameoutput -auxdir$COMPILE_DIR -synctex1 -interactionbatchmode -time编译器选择通过一张映射表完成pdflatex对应-pdf默认值、xelatex对应-xelatex、lualatex对应-lualatex、latex对应-pdfdvi。传一个表里没有的名字会直接抛错而不是尽力而为。整个服务的编译并发上限为 64抢占式实例为 32由compileConcurrencyLimit控制。Overleaf 编译超时三个数字分别在哪儿编译超时其实涉及三个互不相干的数值混淆它们是调参时最常见的坑⏱单次编译进程超时请求选项里的timeoutLatexRunner 中默认60000 毫秒超时就杀掉该次编译——这是你日常该调的那个⏱HTTP 层超时630 秒在 services/clsi/app.js 里写死是前者的兜底上限⏱进程生命周期PROCESS_LIFE_SPAN_LIMIT_MS默认 2 天它限制的是 CLSI 进程自己活多久后自杀重启与单次编译时长无关。编译体量的限制则是COMPILE_SIZE_LIMIT默认 7mb管的是请求体而非磁盘占用。PDF 结果存在哪个服务又如何被取回编译产物不落在 CLSI 的临时目录里等人搬运。output.pdf和output.log被写入输出目录后由 OutputController 通过/project/id/output/output.pdf这样的 URL 直接交付浏览器里的 PDF 视图加载的就是这个地址——所以PDF 存哪个服务的答案是临时编译产物由 CLSI 就近托管项目里持久化的资源文件则由 filestore 服务默认 3009 端口管理。这两者的衔接点在编译开始前如果请求里的资源只有 URL 而没有内联内容CLSI 会并行从 filestore 下载并发数由FILESTORE_PARALLEL_FILE_DOWNLOADS控制。仓库里那个仅含几十字节的 tiny.pdf 就是配合冒烟测试用的最小样本——CLSI 会定期跑一次这种迷你编译/health_check接口据此报告整条工具链是否可用。这对自建部署很有用不用等用户真的编译失败健康检查就能告诉你 TeX 环境坏了。PDF 与源码的双向跳转是怎么实现的回到前面那条 latexmk 命令里的-synctex1它会同步产出一份.synctex.gz映射文件。CLSI 为此专门提供了/sync/code和/sync/pdf两个端点同样在 services/clsi/app.js 中注册配合 SynctexOutputParser 完成在 PDF 里点引用 → 跳回 LaTeX 对应行以及反方向的定位。也就是说双向同步不是前端的魔法而是编译期就写进产物的坐标表。自建环境出问题先查哪三处如果把这份链路当成排障清单优先级很清楚services/clsi/config/settings.defaults.cjs——端口、大小限制、并发以及文件尾部的 TeX 镜像与安全配置大部分行为差异都在这里services/clsi/README.md 的环境变量列表——TEXLIVE_IMAGE决定你用的是哪一代 TeX Live宏包缺失类错误通常先查它/health_check返回的冒烟测试结果——能区分工具链坏了和这份文档本身编译不过。值得注意的是Overleaf 把跑 LaTeX从 Web 主进程中彻底剥离出来换来的是编译负载可以独立扩缩、崩溃不会拖垮编辑会话、以及用容器隔离换来的安全边界。代价则是多了一层需要理解的服务边界。对阅读源码的人来说从 LatexRunner 里那条固定的 latexmk 命令出发顺着 CommandRunner 往下追是进入这套编译链路最快的入口。【免费下载链接】overleafA web-based collaborative LaTeX editor项目地址: https://gitcode.com/GitHub_Trending/ov/overleaf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Overleaf 编译链路拆解：从 LaTeX 源码到 PDF 的四层路径
Overleaf 编译链路拆解从 LaTeX 源码到 PDF 的四层路径【免费下载链接】overleafA web-based collaborative LaTeX editor项目地址: https://gitcode.com/GitHub_Trending/ov/overleaf在 Overleaf 里点击编译按钮后请求并不会停留在承载你项目的 Web 进程上它要经过转发落到一个名为 CLSI 的独立服务里而真正执行 pdflatex 的 TeX 引擎则在一个临时拉起的隔离环境中运行。这篇文章沿请求走过的路径把每一层做什么、编译超时的参数在哪里、生成的 PDF 又存在哪儿讲清楚内容足以支撑你在自建 Overleaf 后快速定位和调参。编译请求的第一跳web 把接力棒交给 CLSI浏览器里前端发起的编译请求最终会命中 CLSI 的 REST 接口。在入口文件 services/clsi/app.js 里能看到核心路由POST /project/:project_id/compileCLSI 默认监听 3013 端口REST 接口另有 3048 和 3049 两个端口分别用于上报负载和运维控制这些默认值定义在 services/clsi/config/settings.defaults.cjs。这一层有两个容易被忽略的硬限制请求体大小上限compileSizeLimit默认7mb由环境变量COMPILE_SIZE_LIMIT覆盖——所以编译包上传失败多半是撞了这条线HTTP 超时统一设为 630 秒10.5 分钟代码注释写明是为文件下载时间预留了 30 秒。整条链路可以概括成一张图CLSI 内部它不跑 LaTeX它负责调度编译CLSI 收到请求后由 CompileController 接管把源码写入按项目隔离的编译目录然后交给 LatexRunner 构造真正的编译命令。这里有个反直觉的点CLSI 自己并不包含 TeX Live 发行版。启用沙箱编译SANDBOXED_COMPILEStrue时它会通过挂载的 docker.sock 拉起兄弟容器来跑 TeX Live 镜像镜像由TEXLIVE_IMAGE指定配置文件尾部还有 seccomp、AppArmor 等安全配置社区版的本地模式下则由 LocalCommandRunner 在 CLSI 所在环境直接执行命令。真正下发给编译器的命令是latexmk参数在 LatexRunner 里固定拼好latexmk -cd -jobnameoutput -auxdir$COMPILE_DIR -synctex1 -interactionbatchmode -time编译器选择通过一张映射表完成pdflatex对应-pdf默认值、xelatex对应-xelatex、lualatex对应-lualatex、latex对应-pdfdvi。传一个表里没有的名字会直接抛错而不是尽力而为。整个服务的编译并发上限为 64抢占式实例为 32由compileConcurrencyLimit控制。Overleaf 编译超时三个数字分别在哪儿编译超时其实涉及三个互不相干的数值混淆它们是调参时最常见的坑⏱单次编译进程超时请求选项里的timeoutLatexRunner 中默认60000 毫秒超时就杀掉该次编译——这是你日常该调的那个⏱HTTP 层超时630 秒在 services/clsi/app.js 里写死是前者的兜底上限⏱进程生命周期PROCESS_LIFE_SPAN_LIMIT_MS默认 2 天它限制的是 CLSI 进程自己活多久后自杀重启与单次编译时长无关。编译体量的限制则是COMPILE_SIZE_LIMIT默认 7mb管的是请求体而非磁盘占用。PDF 结果存在哪个服务又如何被取回编译产物不落在 CLSI 的临时目录里等人搬运。output.pdf和output.log被写入输出目录后由 OutputController 通过/project/id/output/output.pdf这样的 URL 直接交付浏览器里的 PDF 视图加载的就是这个地址——所以PDF 存哪个服务的答案是临时编译产物由 CLSI 就近托管项目里持久化的资源文件则由 filestore 服务默认 3009 端口管理。这两者的衔接点在编译开始前如果请求里的资源只有 URL 而没有内联内容CLSI 会并行从 filestore 下载并发数由FILESTORE_PARALLEL_FILE_DOWNLOADS控制。仓库里那个仅含几十字节的 tiny.pdf 就是配合冒烟测试用的最小样本——CLSI 会定期跑一次这种迷你编译/health_check接口据此报告整条工具链是否可用。这对自建部署很有用不用等用户真的编译失败健康检查就能告诉你 TeX 环境坏了。PDF 与源码的双向跳转是怎么实现的回到前面那条 latexmk 命令里的-synctex1它会同步产出一份.synctex.gz映射文件。CLSI 为此专门提供了/sync/code和/sync/pdf两个端点同样在 services/clsi/app.js 中注册配合 SynctexOutputParser 完成在 PDF 里点引用 → 跳回 LaTeX 对应行以及反方向的定位。也就是说双向同步不是前端的魔法而是编译期就写进产物的坐标表。自建环境出问题先查哪三处如果把这份链路当成排障清单优先级很清楚services/clsi/config/settings.defaults.cjs——端口、大小限制、并发以及文件尾部的 TeX 镜像与安全配置大部分行为差异都在这里services/clsi/README.md 的环境变量列表——TEXLIVE_IMAGE决定你用的是哪一代 TeX Live宏包缺失类错误通常先查它/health_check返回的冒烟测试结果——能区分工具链坏了和这份文档本身编译不过。值得注意的是Overleaf 把跑 LaTeX从 Web 主进程中彻底剥离出来换来的是编译负载可以独立扩缩、崩溃不会拖垮编辑会话、以及用容器隔离换来的安全边界。代价则是多了一层需要理解的服务边界。对阅读源码的人来说从 LatexRunner 里那条固定的 latexmk 命令出发顺着 CommandRunner 往下追是进入这套编译链路最快的入口。【免费下载链接】overleafA web-based collaborative LaTeX editor项目地址: https://gitcode.com/GitHub_Trending/ov/overleaf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考