胖厨胡学斌从 ShareLaTeX 时代一路折腾过来，我自己的私有化部署方案 xuhe2/sharelatex-ce 这次终于完整跟上了官方节奏，全面支持 Overleaf 6.x。这次版本跳跃是我维护这套方案以来最大的一次，不仅仅换了镜像 tag 那么简单，底层依赖、数据库索引、编译环境全都变了。过去两周我一边在几个团队的生产服务器上做迁移，一边把踩过的坑逐个记下来，终于确认整套流程可以稳定复现。
如果你正在使用 Overleaf 官方版但受限于访问速度、数据合规或者编译排队问题，又或者你已经跑着一套社区版正在犹豫要不要升 6.x，这篇文章应该能帮你省下大量试错时间。我不会照搬官方 changelog，只会把这次升级里真正影响实际使用的细节、配置项和排查思路讲明白。
1. 为什么要把 Overleaf 私有化：数据、速度和版本控制的三重问题
1.1 官方版用着顺手，但这些坎你迟早会碰到
官方 Overleaf 的协作体验确实做得很好，但把它作为团队的长期基础设施来用，大多数人很快会撞上三堵墙。
第一堵墙是数据主权。论文原稿、实验数据、审稿意见全部放在第三方平台，一旦课题组有保密要求，或者单位的信息安全规范里有明文规定，资料存储位置就是一个绕不开的风险点。很多科研院所的合规要求里写得很清楚：重要科研数据不得存储在境外在线平台上。即便项目不涉密，让导师把未发表成果传到第三方服务器，很多老师心里也是不踏实的。
第二堵墙是访问速度和编译稳定性。官方编译资源在高峰时段非常紧张，尤其是工作日下午，编译一个短文档经常要排队几十秒，甚至直接超时。对国内用户来说，官方服务的访问延迟本来就不低，偶尔还会出现页面加载失败的情况。编辑体验一旦卡顿，整个团队的工作节奏都会被拖慢。
第三堵墙是版本不可控。官方平台升级 TeX Live 或宏包不会提前通知你，今天能正常编译的文档，明天可能就因为某个宏包变更彻底报错。对于正在赶 deadline 的团队，这种来自外部环境的黑天鹅是最难受的。
1.2 私有化部署不是整套照搬，它解决的是控制权问题
很多人误以为私有化部署就是"自己搭一个一模一样的 Overleaf"，其实不然。自建方案的真正价值，是拿回三个控制权：
- 数据控制权：所有项目数据、用户数据、编译中间产物都存储在自己的服务器上，备份策略自己定。
- 资源控制权：编译超时、内存限制、磁盘配额、并发编译数都可以按团队实际需求调整，而不是被平台限死。
- 工作流控制权：可以接入团队已有的统一登录、内部模板仓库、Git 服务，把 Overleaf 真正嵌进团队的研发或科研流程里。
如果你只是一个人偶尔写写小文档，官方免费版完全够用，没必要折腾部署。但 5 人以上、有长期固定模板、对数据位置有要求的团队，私有化部署带来的收益会大得多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. xuhe2/sharelatex-ce 方案的核心思路与 6.x 升级重点
2.1 这套方案到底封装了什么
xuhe2/sharelatex-ce 本质上是一套围绕 Overleaf 社区版镜像的可复现部署方案。社区版本身是开源的，Docker Hub 上的 sharelatex/sharelatex 就是它的官方镜像，但直接用这个镜像裸跑，坑非常多：默认编译超时短、中文字体缺失、MongoDB/Redis 需要自己编排、反向代理和 HTTPS 也要自己接。
我做这套方案的思路很简单：把零散的容器编排、环境变量、数据持久化、备份策略全部固化下来，让一个只懂 Docker 基础的人也能在半小时内拉起一套可用的环境。架构层面，它由这几个核心服务组成：
| 服务组件 | 实际作用 |
|---|---|
| web | Overleaf 主应用，负责页面渲染、用户认证、项目管理 |
| document-updater | 处理文档内容更新与多人编辑时的冲突合并 |
| filestore | 文件内容的持久化存储，图片、附件、二进制文件都在这里 |
| clsi | 编译隔离服务，真正执行 LaTeX 编译的沙箱 |
| realtime | WebSocket 实时协同，保证光标、修订、评论的同步 |
| tpds | 实时推送文档状态变更 |
| git-bridge | Git 仓库与 Overleaf 项目的双向同步 |
| mongo | 存储元数据、用户信息、项目关系等结构化数据 |
| redis | 缓存与会话管理 |