Overleaf 给免费计划的编译时间是 10 秒，付费计划是 240 秒（Overleaf 官方文档，2026 年 8 月核对）。这 24 倍的差距，是「继续在云端写 LaTeX，还是自己留一套环境」这个判断最容易入手的切口。但真正的争点并不在速度，而在于：稿件放在谁的服务器上、能不能自己选 TeX Live 的版本、服务停摆时能不能把稿件带走。本页不是给初次接触者的入门，而是已经在写的人所面临的「云端还是本地」。就从 2017 年那件事说起吧——它解释了为什么偏偏 Overleaf 可以架在自己的服务器上。
Overleaf 之所以开源，要归功于 2017 年 7 月的合并
2017 年 7 月 20 日，Overleaf 收购了竞争对手 ShareLaTeX（Scribtex Limited）。当时的公告写下了两件事：ShareLaTeX 的编辑器将「成为新平台的核心」，以及公开的 ShareLaTeX 代码库将全部保持开源并继续积极开发。这两条承诺恰好解释了今天的局面。Overleaf 本身在 2012 年底以 WriteLaTeX 之名起步，由 John Hammersley 与 John Lees-Miller 创办，2015 年更名为 Overleaf。合并后的「Overleaf v2」建立在 ShareLaTeX 的编辑引擎之上，而那条开源血脉至今仍以 overleaf/overleaf 之名、按 AGPL v3 公开。
这段往事之所以在实务上有意义，是因为「选择云端」并不必然等于「托付给别人」。Cloud LaTeX 与 Papeeria 都只做托管，没有自建的路。主要服务中实际上只有 Overleaf 可以自行运营，而原因不在技术，正在 2017 年那次合并。反过来说，看似二选一的问题，实际上是三选一：别人的服务器、自己的服务器、自己的电脑。下文先用数字把前两项之间的取舍讲清楚，最后再回到第三条路。
Overleaf 免费版做不到什么
真正会咬人的限制有三个：编译时间、项目容量、Git。免费写多少页没有上限，项目数也不限，但官方文档列出的数值里，实务上真正会撞上的就这三条。其中 Git 集成属于付费功能这一点最容易被忽略——「先免费起步，日后再连历史一起拉回本地」的打算是行不通的。下表照录 Overleaf 文档中的数值（2026 年 8 月）。
| 项目 | Overleaf 的数值（2026 年 8 月官方文档） | 实务上如何生效 |
|---|---|---|
compile timeout | 免费 10 秒 / 付费 240 秒 | 长篇学位论文或繁重 TikZ 最先撞上的墙 |
editable material | 每项目 7 MB；单个文本文件 2 MB | 塞进巨大的 .bib 或生成的表格就会碰到 |
uploads | 单次上传最大 50 MB；每项目最多 2000 个文件 | 图版多且分辨率高的稿件会有问题 |
project size | 建议低于 500 MB；使用 Git 或 GitHub 时建议低于 100 MB | 若图版要进版本管理，尽早精简 |
collaborators | Standard 与 Student 可邀请 10 人，Pro 不限 | 在合作者不断增加的实验室里会真切生效 |
git clone | 付费功能；Server Pro 4.0 及以后也可用 | 免费层无法带走历史——这直接关系到出口策略 |
在云端能固定 TeX Live 的版本吗
用 Overleaf 可以。TeX Live 的年份是按项目设置的，官方博客公告过的版本一直可以回溯到 2016 年。新建项目默认使用服务器上最新的版本，因此当投稿方要求特定年份时，需要显式切换。这一项控制的重要性超过它的外表：「在 Overleaf 上能编译、在我这儿不行」的多数情形，症结是发行版年份而非编辑器。这个设置在界面上的位置，由 Overleaf 那一页负责。
其他服务的做法不同。Cloud LaTeX 提供的是完整版 TeX Live（稳定版与开发版），由服务方更新，而非由用户挑年份。日文投稿规程常要求「须以 TeX Live 20xx 排版」，因此这个差别并非纸上谈兵。若把可重现性放在第一位，容器镜像的 digest 比云端的年份选择更硬——这是事实，对学位论文或数年后可能被要求复现的工作，现实的折中是在云端写作、只把最终构建交给容器。
Cloud LaTeX 与科研费模板：用日文写作者的选项
Cloud LaTeX 的卖点有两个：日文无需配置即可排版，以及超过一百套模板中包含科研费申请书格式。运营方是 Acaric 公司。在 Overleaf 上排日文需要一步操作——比如把编译器从默认的 pdfLaTeX 切到 LuaLaTeX——而在 Cloud LaTeX 上这就是初始状态。它还提供 Dropbox 同步与 VS Code 集成，不会把你锁死在浏览器标签页里。由于日本的科研经费申请书每年都会改版式，模板是否持续更新才是它的实际价值所在。
第三个选项 Papeeria 有一个恒久免费层：公开项目不限量，私有项目免费只能一个。它也有 Git 集成，但免费层覆盖的只有公开仓库——私有仓库属于付费功能。粗暴地归纳一下：以日文为主选 Cloud LaTeX，合作者多且依赖模板选 Overleaf，一开始就打算公开选 Papeeria。不过这只是起点；接下来两节——机构账号与出口策略——在一个项目的整个生命周期里影响更大。
先查一查学校有没有 Overleaf Commons
在自掏腰包买付费计划之前，先确认所在机构有没有站点授权。Overleaf Commons 是机构为全体成员提供 Overleaf 的订阅方式；一旦签了，成员就都能用上付费功能——更长的编译时间、更多合作者名额、修订记录、Git 集成。加入通常只需通过机构的单点登录，或确认一个属于机构域名的邮箱地址即可完成。不少大学都已采用：例如 UCLA 就公告，自 2025 年 4 月 7 日起，全体在册学生、教职员工均可获得免费的 Overleaf Professional 账号。先去搜一搜自家信息化部门的页面，是回报率最高的一步。
不过站点授权有一个性质：它绑定在一个会到期的身份上。加入之所以成立，是因为你的隶属关系得到确认；一旦毕业、结业或调动使这个确认失效，付费功能也随之失效。用机构账号写完硕士论文，毕业后应合作者之请打开却看不到历史——这是完全可能发生的事故。因此共同研究项目的定式是：让实验室或项目管理的账号做所有者，而不是某个人的个人账号，并在离开之前把整套稿件导出，这是最低限度的准备。
未发表的研究可以放在云端吗
这是规章问题，不是技术问题。每家服务都会说明自己的加密与访问控制，但真正决定此事的是所在机构的信息管理规定、经费附带的条件，以及合作研究的保密协议。只要其中任何一条写着数据不得离开本组织，那么无论服务品质多高，托管型都不合格。若没有这类约束，云端的好处则相当可观。下面的比较以规章允许为前提，读法不是「哪个更好」，而是你放弃什么、又把什么留在自己手里。
| 关注点 | 托管型服务 | 本地安装 |
|---|---|---|
where the source lives | 在服务商的服务器上——依规定不同，仅这一条就可能把它排除 | 在自己的磁盘上；数据外流的问题从一开始就不存在 |
maintenance | 无需操心；更新在服务端进行 | 自己更新，自己管理宏包 |
devices and network | 任何有浏览器的设备，但基本上需要联网 | 只有装过的那台机器，但断网也能用 |
collaboration | 开箱即用的实时协作编辑，人数受套餐上限约束 | 自己搭，通常用 Git；人数没有上限 |
compile ceiling | 以套餐上限为准——Overleaf 免费 10 秒，付费 240 秒 | 没有上限；机器的速度就是上限 |
version pinning | 限于服务提供的范围；Overleaf 允许选择年份 | 宏包与字体皆可自由选定，甚至可固定镜像 digest |
出口策略：能不能连历史一起把稿件带走
导出 ZIP 每家服务都能做。问题在历史。在 Overleaf 上，把整个项目连同历史拉下来的 git clone 是付费功能，免费账号用不了。Cloud LaTeX 除 ZIP 导出外还有 Dropbox 同步，最新版的副本可以始终留在自己的磁盘上。Papeeria 本就围绕 Git 设计，但免费层只覆盖公开仓库。由此得出的经验法则只有一句：选一个能用 git clone 走出来的服务。无论服务器出什么事，稿件和它的历史都留在你手里。
这个出口同时也是进入 CI 的入口。把 Overleaf 项目与 GitHub 仓库保持同步，每次 push 都能触发 GitHub Actions 在干净的 TeX Live 中排版，在浏览器之外验证 PDF 是否真的构建得出来。既保留云端的舒适，又让机器来检查这份工作是否真能复现——在合著论文上尤其管用。不过如前所述，Git 与 GitHub 集成属于付费功能，免费账号搭不出这套结构。日常运作上，把下面三件事定下来，基本就能挡掉大事故。
- 先定所有者。共同研究的项目，让实验室或项目管理的账号做所有者，而不是某个人的个人账号。
- 把环境写进 README。用一行记下所用服务、编译器和 TeX Live 年份——日后在本地或容器中复现时正需要它。
- 提交前统一导出。把 PDF、源码 ZIP、
.bib和图版的原始数据，收进一个带日期的文件夹。
把 Overleaf 架在自己的服务器上（自托管）
这是第三条路。Overleaf 的核心以 overleaf/overleaf 之名按 AGPL v3 公开，这就是 Overleaf Community Edition（CE）。实验室或企业因此可以在自己的服务器上运行自己的 Overleaf，与商业的 overleaf.com 完全无关。推荐的部署路径是官方的 Overleaf Toolkit：一套 Docker Compose 栈，把 Overleaf 应用连同作数据库的 MongoDB 和作缓存的 Redis 一起拉起来。从 GitHub 取得 overleaf/toolkit，初始化并启动，就有了一个可从自己浏览器访问的 Overleaf。一旦搭起来，即便在完全断网的内网里也能运行。
# Bring up your own Overleaf with the official toolkit.
git clone https://github.com/overleaf/toolkit.git
cd toolkit
bin/init # generates the config/ directory
bin/up # starts Overleaf + MongoDB + Redis via Docker Compose你得到的是对数据的支配权以及不依赖外部。稿件不会离开本组织的服务器，也不会被服务中断或涨价波及。代价就是运维本身——备机、备份、升级 TeX Live、安全，统统成了自己的活。此外还有一条无法回避的限制：免费的 Community Edition 没有用于隔离编译的「Sandboxed Compiles」。用户的 LaTeX 编译以与容器相同的权限运行，能够触及容器的文件系统与网络。项目自己的 README 写得很明白：CE 面向所有用户都可信任的环境。
若需要面向更广的人群开放，或需要编译隔离、通过 LDAP / SAML 的单点登录、修订记录等面向企业的功能，则有付费的 Server Pro。实务上的判断是：可信任的小规模实验室，CE 就够了；要向全校开放，则考虑 Server Pro。另外别忘了，一旦选择自托管，云端最大的好处——不必维护——也就随之消失。三条路中的最后一条最自由，也最费工。