在实际的 LaTeX 写作场景里最让人头疼的往往不是语法而是环境本地 TeX Live 没装好、编译引擎对不上、中文显示乱码、表格列宽怎么调都失效、换一台电脑整个工具链又得重来。TexLite 这个项目瞄准的正是这个问题它用一个轻量级、可自托管的 LaTeX 工作区把编辑器、编译器和 PDF 预览收进同一个 Web 服务里让写论文、写技术报告、做 Beamer 幻灯片时不再被本地环境绑架。本文会围绕 TexLite 这类自托管 LaTeX 工作区讲清楚它背后的架构、部署步骤、编译链路、中文和表格支持以及上线后最常遇到的一批问题要怎么查。这类工具的价值可以这样理解LaTeX 的编译是一个重依赖、高资源消耗、对版本极其敏感的过程而 Web 化的工作区则把这个过程收敛到服务端。每个用户只需要打开浏览器新建一个.tex文件剩下的编译、日志、 PDF 生成都由服务器统一完成。团队使用时的收益更明显同一套 TeX Live 版本、同一批宏包、同一类字体配置可以避免“我本地能编译到别人电脑上就报错”的经典问题。同时自托管也意味着项目文件保存在自己的服务器上不受第三方平台的订阅、容量限制和隐私策略影响。1. 先理解 TexLite 要解决的痛点1.1 在线 LaTeX 编辑器与本地环境的矛盾在线 LaTeX 平台确实解决了一部分环境问题它不需要用户安装 TeX 发行版浏览器打开就能写。但它也有明显不适配的场景论文和项目文件不在自己手里平台对免费用户通常限制编译时长、项目数量和容量对部分高校或企业内部用户来说把开题报告、技术方案、产品文档传到第三方服务器本身就走不通隐私审核。本地环境是另一条路。VSCode 配合 LaTeX Workshop 插件是很多人的选择但真正配置起来后才会发现问题不止“安装一个插件”这么简单。你需要确保系统里装了 TeX Live 或 MacTeX需要选择默认编译工具还要处理正向同步、反向同步、PDF 预览插件、bib 文件路径、中文字体等一系列细节。每一环都可能出问题而每一环的问题都只发生在你这一台电脑上。TexLite 的做法是把这个“环境”从个人电脑中抽离出去变成一个可独立部署的 Web 服务。它仍然是自托管的所以数据、编译资源、访问权限都由部署方控制它又是一个工作区所以用户在浏览器里就能完成从编辑到预览的完整流程。1.2 自托管 LaTeX 工作区的核心能力一个能实际使用的自托管 LaTeX 工作区至少要具备以下能力项目文件管理能够新建项目、管理.tex文件、图片和参考文献文件目录可以按用户或项目隔离。浏览器内编辑给用户一个可用的代码编辑器至少要能识别 LaTeX 语法、对括号做匹配、提供自动补全。编译执行器后端能够调用latexmk、xelatex或pdflatex等程序控制超时和并发并把日志和输出文件保存到指定目录。PDF 预览编译完成后生成 PDF前端能嵌入预览最好还能支持点击跳转回源码位置。用户与权限控制自托管服务一旦开放给团队使用就要考虑登录、项目成员和应用权限。这些能力组合起来就是一个简化版的“私有 Overleaf”。加不加多人实时协同取决于项目所处的阶段第一步通常是把单用户流程跑通。1.3 适合使用这类工具的用户自托管 LaTeX 工作区并不是要替代所有人的本地 VSCode。它更适合这几类场景高校实验室多学生、多课题需要统一的论文模板和宏包环境。企业内部文档团队技术方案、产品白皮书、投标文档涉及敏感内容不适合放第三方平台。需要离线环境或内网环境的研究人员服务器在内网浏览器访问即可不需要把代码和数据带到外部网络。对 LaTeX 不熟悉、但需要完成排版的新手Web 工作区里模板和示例可以直接复制不用先理解“安装 TeX Live”和“配置 PATH”等概念。如果只是写一个几页的简单文档本地工具可能更快但如果要长期维护一批 LaTeX 项目并且有团队协作自托管工作区的成本投入就变得值得。2. TexLite 的核心架构和工作流2.1 三条链路编辑、编译、预览把一个浏览器里的 LaTeX 工作区拆开看它同时存在三条非常清晰的链路。编辑链路负责把用户在浏览器里输入的文本保存到服务器。前端编辑器通常会把自动保存做得比较轻比如在用户停止输入 1 到 2 秒后才触发送到服务端避免每个字符都产生一次 HTTP 请求。保存后文件树要刷新后端要把文件写入项目目录。编译链路是核心。它需要接收用户或系统的编译请求检查项目是否正在被编译然后选择合适的编译引擎。因为 LaTeX 编译可能很快几秒完成也可能很慢比如一个大文档加上多轮 bib 解析可能需要几十秒甚至几分钟。因此编译必须以任务的方式执行不能卡住整个 Web 服务。预览链路负责把编译产物返回给浏览器。最简单的方式是编译完成后给前端一个 PDF 的 URL前端用iframe或 PDF 渲染组件加载。更复杂的实现会在编译过程中持续推送日志让用户看到“第 3 章编译到第 20 页”这类进度。理解这三条链路才能在故障时快速定位问题文件没保存是编辑链路的问题编译没执行是后端或编译器问题日志能看到但 PDF 不刷新则是预览链路的问题。2.2 典型组件与技术栈TexLite 这类项目通常不会使用非常复杂的中间件常见组件如下。模块常见选型作用前端编辑器CodeMirror、Monaco Editor提供 LaTeX 语法高亮、括号匹配、自动补全后端 APINode.js、Python FastAPI、Go处理项目文件、编译请求、用户认证编译执行器child_process、subprocess调用系统安装的 TeX Live 工具文件存储本地目录、NFS、MinIO保存.tex、图片、生成物通知机制WebSocket、SSE向前端推送编译状态和日志数据库SQLite、PostgreSQL保存用户、项目元信息、权限配置具体技术选型最终要参考项目源码或 README。工程上的关键点不在于选什么语言而在于模块之间的关系是否清晰。比如编译执行器能不能独立扩展文件存储能不能从本地目录平滑切到对象存储这些会直接影响后续运维成本。2.3 一次编译请求如何走到 PDF把一次编译请求的数据流列出来可以非常直观地理解整个系统。用户在浏览器点击编译或按下保存前端向后端发送一个编译请求。后端根据项目 ID 找到对应目录检查项目是否正在编译如果正在编译直接返回“已有编译任务执行中”。后端创建一个编译任务加入并发队列。任务开始后后端调用latexmk或xelatex传入-interactionnonstopmode、-halt-on-error等参数。编译进程结束后后端读取输出目录中的日志和 PDF 文件记录最终状态。后端通过 WebSocket 向前端发送“编译成功”或“编译失败”。前端收到成功后将预览地址指向最新的 PDF 文件。这个过程中需要格外注意“编译是外部进程”这个事实。Web 应用本身可能不会因为某个请求崩溃但编译进程如果失控比如生成过大的临时文件、长时间占用 CPU、残留进程导致文件锁都会影响整个服务的稳定性。2.4 与 VSCode 本地 LaTeX 插件之间的差异自托管工作区和 VSCode 本地 LaTeX 插件表面上都是“编辑 LaTeX 并预览 PDF”但架构差异很大。对使用 TexLite 这类工具的人来说理解差异能避免用错误的预期排查问题。维度VSCode LaTeX Workshop自托管 LaTeX 工作区编辑器本地 IDE依赖个人配置浏览器内编辑器服务端统一提供编译环境使用本机 TeX Live使用服务器上的 TeX Live宏包安装每台电脑分别处理服务端集中安装PDF 预览本地查看器或内置预览浏览器内嵌预览多人协作基本不适用天然适合团队共享故障范围只影响本机影响所有用户需要更谨慎这个对比也解释了为什么自托管服务上线前必须把环境的标准化做好。VSCode 里装错宏包只影响一个人服务器上缺少宏包会影响所有项目。3. 部署前环境准备与 Docker 安装3.1 服务器与软件清单在开始部署前先确认服务器和软件版本是否满足基本要求。下面是一份适合中小团队的常见配置参考实际资源大小要根据项目规模和并发量调整。资源项最低要求建议配置CPU2 核4 核及以上编译是 CPU 密集型任务内存2 GB4 GB 以上TeX Live 编译时内存占用明显磁盘10 GB 可用SSD预留 50 GB 以上用于项目和宏包操作系统Linux 发行版Ubuntu 22.04、Debian 12 等软件Docker、docker-compose最新稳定版TeX 发行版TeX Live 2021 及以上尽量用与镜像一致的版本需要注意LaTeX 编译时不仅生成 PDF还会生成大量中间文件包括.aux、.log、.toc、.bbl等。如果项目长期迭代磁盘增长会比想象中快建议把数据目录单独挂载到一块容量足够、可备份的磁盘上。3.2 使用 docker-compose 跑起最小服务假设你已经有 TexLite 的镜像或源码最小启动方式可以用 docker-compose 完成。先创建数据目录mkdir -p /srv/texlite/projects mkdir -p /srv/texlite/config cd /srv/texlite再写一个docker-compose.yml。下面是一个典型的自托管 LaTeX 工作区配置文件具体环境变量名要以项目文档为准。version: 3 services: texlite: image: texlite:latest container_name: texlite ports: - 8080:8080 volumes: - /srv/texlite/projects:/data/projects - /srv/texlite/config:/etc/texlite environment: - TEXLITE_DATA_DIR/data/projects - TEXLITE_MAX_BUILD_TIME60 - TEXLITE_CONCURRENCY2 - TEXLITE_DEFAULT_ENGINExelatex - TEXLITE_ENABLE_REGISTRATIONfalse restart: unless-stopped这个配置文件做了几件重要的事把项目数据挂载到宿主机避免容器升级时数据丢失。把项目目录和配置目录分开便于备份和恢复。限制最大编译时间为 60 秒避免某个失败文档耗尽服务资源。默认编译引擎使用xelatex中文支持更友好。关闭开放注册适合先由管理员创建用户。启动服务docker compose up -d docker compose logs -f texlite看到日志中输出服务监听端口后访问http://服务器IP:8080即可进入工作区。3.3 没有现成镜像时从源码构建如果项目没有打包好的镜像需要从源码构建。命令通常围绕“安装依赖、构建前端、启动后端”三个阶段。git clone 项目仓库地址 cd texlite npm install npm run build npm start如果后端是 Python则可能是git clone 项目仓库地址 cd texlite pip install -r requirements.txt python manage.py migrate python manage.py runserver 0.0.0.0:8080不要直接把这里的命令当作文档实际项目可能使用 pnpm、yarn、Poetry 或 Shell 脚本。更重要的一点是从源码构建时服务器上必须预先安装 TeX Live否则服务启动成功但编译任何.tex项目都会失败。3.4 本地直装 TeX Live 和字体的选择如果使用 Docker 镜像很少需要手动安装 TeX Live。但如果是源码方式部署或者需要自定义镜像可以用下面命令安装最小中文环境。以 Ubuntu 为例sudo apt update sudo apt install -y texlive texlive-xetex texlive-lang-chinese texlive-latex-extra fonts-noto-cjk这里的关键是texlive-lang-chinese和fonts-noto-cjk。前者提供中文 LaTeX 支持后者提供中文字体。只有安装了中文字体ctex宏包在编译时才能找到可用的字体资源。对自托管工作区来说字体文件很关键。服务端缺少FandolSong、Noto Sans CJK等字体时同一份.tex文件在本地能编译在服务器上会报字体找不到。这也是“本地可以部署后不行”的常见原因之一。4. 核心实现编辑器、编译器与预览的关键细节4.1 编译进程的控制超时、并发与日志Web 服务调用命令行编译工具时最大的风险不是命令本身而是进程控制。假如一个.tex文件里写了死循环的交叉引用或异常宏包编译可能会持续很长时间。如果后端不做超时控制这个编译子进程会一直占用 CPU最终拖垮整个服务。下面是一段 Node.js 环境下的编译调用示例用于说明处理思路。实际项目会结合自己的异常处理和日志规范调整。const { execFile } require(child_process); const fs require(fs); const path require(path); function compileProject(projectPath, options {}) { const { timeout 60000, engine xelatex, mainFile main.tex } options; const outDir path.join(projectPath, build); fs.mkdirSync(outDir, { recursive: true }); return new Promise((resolve, reject) { const child execFile( latexmk, [ -${engine}, -interactionnonstopmode, -halt-on-error, -outdir${outDir}, mainFile ], { cwd: projectPath, timeout, maxBuffer: 10 * 1024 * 1024 }, (error, stdout, stderr) { fs.writeFileSync(path.join(outDir, build.log), stdout, utf8); if (error) { reject(new Error(compile failed: ${error.message})); return; } resolve({ stdout, pdfPath: path.join(outDir, main.pdf) }); } ); child.on(error, (err) { child.kill(); reject(err); }); }); }这段代码要解决的核心问题有三个超时通过timeout参数限制外部进程最多运行 60 秒。日志把 stdout 写入build.log方便用户在前端查看错误。产物目录把生成物放到build子目录避免.aux文件和源码混在一起。-interactionnonstopmode的作用是让 LaTeX 在遇到错误时不要停下来等待用户输入-halt-on-error则让它在第一个错误处停止避免无效地继续往下跑。Web 场景下不能使用交互模式因为没有任何人可以坐在服务器前按回车。4.2 前端保存、自动编译与状态通知编辑器的体验直接影响工具是否可用。如果用户写一个公式还要手动切到命令行去执行编译那么自托管工作区的意义就削弱了大半。因此服务端通常要提供一个编译触发接口配合前端做自动保存和状态通知。一个常见的做法是“防抖自动保存 手动编译 WebSocket 推送”。用户在编辑器中停止输入 1 秒后前端把文件内容发送到后端保存用户点击编译或配置了“保存后自动编译”前端再发送编译请求。// 前端防抖保存的简化示意 let timer null; function onEditorChange(content) { clearTimeout(timer); timer setTimeout(() { fetch(/api/projects/project1/files/main.tex, { method: PUT, headers: { Content-Type: text/plain }, body: content }); }, 800); }每次保存都触发编译会浪费服务器资源尤其在一个大项目里。更稳妥的默认策略是“手动编译”或“用户主动开启自动编译”避免多人同时编辑时后端被编译请求打满。编译状态的推送可以使用 WebSocket。前端接收到compiling状态时展示进度接收到success时刷新 PDF 预览接收到failed时把build.log里的错误行解析出来展示给用户。错误日志最好按行解析直接定位到.tex文件的行号而不是让用户看一整屏原始日志。4.3 中文支持为什么默认引擎推荐 XeLaTeX中文 LaTeX 是自托管工作区里最容易被忽略、又最影响体验的一部分。很多本地用户一开始使用pdflatex编译中文文档结果要么报Invalid UTF-8 byte sequence要么生成 PDF 后变成一堆空白或乱码。原因在于pdflatex对 UTF-8 和系统字体的处理能力较弱。推荐在自托管工作区里默认使用xelatex并配合ctex宏包。下面是一个可运行的最小中文示例% !TEX program xelatex \documentclass[UTF8]{ctexart} \usepackage{booktabs} \begin{document} \section{自托管 LaTeX 工作区} 中文排版示例。\LaTeX{} 支持数学公式 $Emc^2$也支持表格。 \begin{table}[h] \centering \begin{tabular}{|p{3cm}|p{8cm}|} \hline \multicolumn{1}{|c|}{列名} \multicolumn{1}{c|}{说明} \\ \hline 项目ID 全局唯一标识创建后不可修改 \\ \hline 编译引擎 xelatex / pdflatex / lualatex \\ \hline \end{tabular} \caption{固定列宽表格示例} \end{table} \end{document}保存为main.tex进入项目后选择xelatex或latexmk -xelatex编译即可生成中文 PDF。示例中使用了ctexart文档类它内部会自动处理中文字符编码和中文版式。p{3cm}是固定列宽的关键。在tabular环境中l、c、r表示内容自动宽度而p{宽度}表示固定宽度内容超过指定宽度时会自动换行。如果想让固定列左对齐可以写成\begin{tabular}{|{\raggedright\arraybackslash}p{3cm}|p{8cm}|}{\raggedright\arraybackslash}的作用是在该列内容前插入左对齐命令\arraybackslash是为了避免\\在列内被重新定义后无法正常换行。这个写法在自托管服务里非常适合控制表格列宽因为浏览器预览时不会因为你本地显示器的宽度改变而改变 PDF 排版。4.4 数学公式、Beamer 与 Doxygen 中文处理的常见问题LaTeX 用户经常搜索“数学公式怎么打”“latex求导怎么打”“latex下标怎么打”这些问题在 Web 工作区里同样存在但解决方式没有区别。行内公式用$...$独立公式用\[...\]多行对齐用align环境下标用_上标用^分数用\frac{分子}{分母}。\begin{align} f(x) \frac{d}{dx} x^2 2x \\ \int_0^1 x^2 \,dx \frac{1}{3} \end{align}这些语法不管在哪个编辑器里都一样TexLite 需要做的只是让编译日志能正确显示错误位置。另一个高频问题是 Doxygen 生成的 LaTeX 无法处理中文。这个问题的根源通常不是 TexLite而是 Doxygen 默认的编译流程使用pdflatex。在 Doxyfile 中要找到LATEX_CMD_NAME改成LATEX_CMD_NAME xelatex同时要注意Doxygen 生成的.tex文件默认不包含ctex宏包。只把编译器改成xelatex可能仍会遇到中文无法显示或字体缺失的问题。常见做法是在 Doxygen 的LATEX_EXTRA_STYLESHEET或附加宏包配置中手动加入ctex或者生成后再对refman.tex做一次文本替换。自托管工作区如果提供了自定义编译命令能力可以用一段包装脚本处理这个过程。5. 参数、存储和资源控制5.1 环境变量与参数说明自托管部署时环境变量决定了服务的边界。合理的参数配置可以避免绝大多数资源耗尽问题。下面是一份常用参数参考表实际参数名以项目为准。参数作用常见值调大影响调小影响TEXLITE_DATA_DIR项目文件存储根目录/data/projects存储容量增大项目文件可能不够用TEXLITE_MAX_BUILD_TIME单次编译最大秒数60支持大文档编译复杂文档超时被中断TEXLITE_CONCURRENCY同时编译的项目数2支持更多并发用户排队时间变长TEXLITE_DEFAULT_ENGINE默认编译引擎xelatex中文兼容好如果选错中文文档会失败TEXLITE_ENABLE_REGISTRATION是否开放用户注册false便于多用户使用更安全需要管理员创建账号请特别注意TEXLITE_CONCURRENCY。LaTeX 编译会消耗大量 CPU 和内存把并发数设成 8 不等于“更快”反而可能让服务器在多个大文档同时编译时直接 OOM。初学者容易犯这个错误。5.2 项目目录隔离与权限控制多用户场景下项目目录必须按用户隔离。一个可行的目录结构如下/data/projects/ /user_a/ /paper_1/ main.tex build/ /paper_2/ /user_b/ /report_1/后端在创建项目时应该生成唯一项目 ID并将项目归属记录到数据库。文件操作接口必须校验当前用户是否有该项目权限不能只看文件路径是否存在。权限问题在容器环境中尤其容易踩坑。如果容器以 root 用户运行而数据卷在宿主机上那么生成的中间文件可能全部归属 root。升级镜像后以普通用户运行的新容器可能无法覆盖旧文件。一个简单的处理方式是在 compose 文件中指定固定用户services: texlite: image: texlite:latest user: 1001:1001宿主机上再执行mkdir -p /srv/texlite/projects chown -R 1001:1001 /srv/texlite/projects这样容器内和宿主机对文件权限的理解就能保持一致。5.3 编译队列、资源限制与清理当多个用户同时执行编译时后端必须有一个编译队列。队列的粒度可以是“项目级锁”即同时只允许一个项目发生一次编译避免同一项目里的旧编译和新编译互相覆盖生成物。除了应用层的队列容器层面也要做资源限制。Docker 可以直接限制 CPU 和内存docker run -d \ --name texlite \ --cpus2 \ --memory2g \ -p 8080:8080 \ texlite:latest这样即使某个 LaTeX 文档编爆炸了也不会拖垮宿主机上的其他进程。还要定期清理编译中间文件。LaTeX 项目里的.aux、.log、.toc、.bbl文件会随着编译次数越来越多。如果每个项目都把build目录完整保留磁盘很快会告警。常见策略是只保留main.pdf和最新一次build.log其余中间文件在每次编译前后清理或覆盖。6. 运行验证与问题排查6.1 验证服务是否正常部署完成后不要急于让用户上传项目。先按下面的顺序做一轮冒烟验证能省下后面大量排查时间。docker ps docker logs texlite --tail 50 curl http://localhost:8080/api/health确认健康检查接口返回正常后创建一个测试项目粘贴一段最小 LaTeX 文档执行编译。\documentclass{article} \begin{document} Hello, TexLite. \end{document}编译成功后检查 PDF 接口是否返回 200curl -I http://localhost:8080/api/projects/test/build/main.pdf如果服务能跑通这一步说明编辑、编译、预览链路基本正常。接下来再测试中文文档验证xelatex和字体环境。6.2 编译失败时的日志查看路径编译失败的排查核心是看日志但日志要看对地方。前端页面里的提示往往只有“编译失败”真正有价值的信息在服务端日志和build.log中。docker logs texlite --tail 200 cat /srv/texlite/projects/user_a/test/build/build.log查看build.log时重点搜索以下关键字! LaTeX Error:表示宏包或环境出错。File ... not found表示缺少文件或宏包。Emergency stop表示编译器因为错误太多直接退出。Missing character表示字符或字体缺失。Fatal error occured表示编译进程异常退出。日志一般会包含行号例如l.12对应.tex文件的第 12 行。先看第一个错误因为 LaTeX 经常会在第一个错误之后产生大量连带报错。6.3 常见问题排查表把自托管 LaTeX 工作区上线后最常遇到的问题整理成下表便于快速定位。问题现象日志或现象常见原因处理建议服务启动失败EADDRINUSE端口被占用修改端口或停掉占用进程项目目录无权限EACCES数据卷权限不正确chown到容器用户中文乱码或空白Missing character使用pdflatex或缺少中文字体改用xelatex安装fonts-noto-cjk中文编译失败找不到ctex.sty缺少texlive-lang-chinese安装中文宏包宏包找不到File .sty not foundTeX Live 未安装该宏包安装texlive-latex-extra或tlmgr install编译超时日志卡在某个.tex行文档过大或存在死循环调大TEXLITE_MAX_BUILD_TIME优化文档无法生成 PDF日志有Emergency stop.tex语法错误严重根据第一个错误定位行号上次编译未结束Unable to lock file残留的latexmk进程清理进程和.aux文件表格列宽不生效预览正常但宽度不对tabular未使用p{宽度}按 4.3 节写法调整列格式其中“残留进程”这个问题在自托管服务里比较隐蔽。如果某个编译进程因为网络或服务重启被中断latexmk会认为输出目录被锁定后续所有编译任务都进不去。排查时用ps aux | grep latex找出残留进程并手动清理。6.4 学习环境与生产环境的差异在个人电脑上用 Docker 跑通 TexLite 只是第一步真正的复杂度在上线。下面是学习环境与生产环境的主要差异。维度学习环境生产环境用户数1 到 2 人十几人到上百人数据备份不备份需要定时备份数据目录和数据库访问方式IP 直连域名 HTTPS 反向代理权限控制管理员自己用必须启用用户认证和项目权限编译并发1需要团队内约定并限制并发资源监控不关注CPU、内存、磁盘、编译队列指标日志控制台输出保存到文件并按天轮转升级策略随手更新先备份再灰度测试更新生产环境的很多事故都可以提前避免。例如在 Nginx 前面加一层 HTTPS配置client_max_body_size限制上传文件大小在数据目录做好备份在日志采集里加入编译失败率。这些都是上线前而不是上线后才做的事。7. 把 TexLite 用起来的实践建议7.1 至少避开这三个坑自托管 LaTeX 工作区本身并不复杂但三个坑很容易让初入门的维护者措手不及。第一个坑是“把本地 VSCode 的配置思路直接搬上服务器”。本地编辑器可以很方便地为每个项目指定编译参数但服务端是集中式的默认编译参数会影响所有项目。如果团队里有人用bibtex有人用biber有人在文档里写死了pdflatex就不能只靠一个全局默认引擎解决。建议把编译参数做成项目级配置允许每个项目指定自己的主文件和引擎。第二个坑是“不设超时”。很多本地用户没有关掉编译进程的概念因为编译卡住时手动终止即可。但在 Web 服务里编译进程不受用户浏览器控制。用户关闭页面服务器上的latexmk可能还在跑。必须把超时、并发队列和残留进程清理一起设计进去。第三个坑是“数据不挂卷”。容器是随用随建的升级镜像时旧容器会被删除。如果项目文件写在容器内部升级一次就丢一次。所有项目数据、配置、数据库文件都必须挂载到宿主机或对象存储并且定期备份。7.2 上线前检查清单在把 TexLite 开放给团队之前可以对照下面这份清单做一轮检查。服务是否可以只通过 HTTPS 访问未开启弱口令或默认密码。数据目录和配置目录是否都挂载到宿主机。TEXLITE_DATA_DIR是否指向正确的挂载卷。TeX Live 是否已经包含中文支持和常用宏包。默认编译引擎是否为xelatex或者是否按项目指定了正确引擎。编译超时和并发数是否已配置。是否清理了容器内测试时产生的临时数据和目录。用户注册是否已关闭团队成员账号是否由管理员创建。是否配置了日志轮转避免docker logs无限增长。是否对数据目录做了备份并且备份可以恢复。这份清单也适合每次升级版本后重新跑一遍。7.3 扩展方向与下一步TexLite 作为轻量级自托管工作区第一版只要做到“浏览器内编辑、服务端编译、 PDF 预览”就已经能覆盖很多真实需求。继续扩展时方向可以按团队需要选择Git 集成每次保存后自动提交提供版本回滚和 diff。模板市场预置毕业论文、技术报告、 Beamer 幻灯片模板。多人协同编辑级实时协同需要引入 CRDT 或 OT 算法复杂度会明显上升。单点登录集成 LDAP 或 OAuth方便企业内部账号体系。编译沙箱用普通用户、独立容器或 gVisor 限制编译进程权限避免用户上传恶意宏包执行系统命令。导出能力在 PDF 之外支持导出 HTML、Word 或 Markdown。对个人项目来说不一定要立刻实现这些先保证“环境可重复、数据可备份、编译可控”就已经比一堆人各自折腾本地 TeX Live 稳定得多。下一步最值得做的是拿一份真实论文或技术文档在内网跑一轮压力测试观察 5 个用户同时编译时服务器的 CPU、内存和队列情况再根据结果调整并发和资源限制。