有个问题看起来简单，做起来极难：如何在一个你不信任的代码片段跑起来之后，还能保证自己的服务器不被搞坏？
用户提交的代码可以无限循环、可以 fork 炸弹、可以吃光内存、可以尝试读你的文件系统、可以发起对外连接。在线判题系统、编程教学平台、招聘笔试、乃至现在让 AI 生成代码后「真的跑一下看看」，全都要解决这个问题。
Judge0 就是干这个的。它 2016 年 8 月由 Herman Zvonimir Došilović 创建，如今 4516 星、941 fork，GPL-3.0 协议，支持 90 多种语言。它的自我定位写得很克制：robust, fast, scalable, and sandboxed open-source online code execution system——健壮、快、可扩展、沙箱化的在线代码执行系统。
一、它到底是什么：一个「执行后端」
很多人第一次听说 Judge0 会以为它是个在线判题网站。不是。它更像一个只做「执行」这一件事的后端服务：你给它源码、语言 ID、标准输入，它返回 stdout、状态、耗时和内存。至于题目、评分、排行榜、用户系统，那是你的事。
官方列的使用场景也印证了这个定位：AI agent（让模型写的代码真的能跑）、竞赛编程平台、在线教学、招聘评估、在线 IDE、在线代码编辑器。这些场景的共同点是——它们都需要执行陌生代码，但都不想自己做沙箱。
它提供两种形态：Judge0 CE（Community Edition，在 master 分支）和 Judge0 Extra CE（在 extra 分支），两者主要差别是支持的语言集。此外还有官方托管的 SaaS（走 RapidAPI 或直接合作），以及完全自托管。
二、一次提交经过哪几层
它的架构并不神秘，但每一层都在解决一个具体问题：
第一层是 HTTP JSON API。只收单，不做执行。你 POST 一个提交，它会给你一个 token；如果带上 wait=true，它会同步等到结果再返回（适合简单集成），否则你先拿 token 再轮询。
第二层是入队。提交被写成一条数据库记录，交给后台 worker 处理。这一步是整个设计能「扛住高并发」的关键——收单和执行解耦，突发流量堆在队列里，不会把执行层打崩。
第三层是调度。worker 取到任务后，按语言准备运行环境、套上你指定（或默认）的时间和内存限制、拼出编译命令与执行命令。这一步决定了「多文件程序」「额外文件」「自定义编译选项」这些能力怎么落地。
第四层才是真正的沙箱执行，用的是 isolate——国际信息学奥林匹克（IOI）出品的沙箱工具。README 的「特别感谢」里点名了三个项目：Isolate、Docker、Ruby on Rails，这三个基本就是它的全部技术底座。
第五层回填结果：捕获输出、记录 CPU 时间与峰值内存、给出状态码，还可以通过 webhook 把结果回推给你的服务。
三、结果里那几个数字的含义
这是官方的 Judge0 IDE（ide.judge0.com），免费开源。看右下角那一行小字：Accepted, 0.004s, 1516 kB, TAT: 387ms。四个信息点各管一件事：
| 字段 | 含义 | 为什么重要 |
|---|---|---|
| Accepted | 状态（还有 Wrong Answer、Time Limit Exceeded、Runtime Error 等） | 判题系统的核心输出，你的程序是「跑通了」还是「跑错了」还是「跑超时了」 |
| 0.004s | CPU 时间 | 竞赛计分与超时判定的依据，注意是 CPU 时间不是墙钟时间 |
| 1516 kB | 峰值内存 | 内存限制的判定依据；也是排查「为什么别人能过我过不了」的关键数据 |
| TAT 387ms | Total Assessed Time，总周转时间 | 从提交到出结果的真实等待，包含排队与容器启动开销 |
这四个字段分开看才有意义。举个例子：TAT 387ms 而 CPU 只有 4ms，说明绝大部分时间花在排队和准备环境上，不是跑你的代码。如果你在做一个需要毫秒级反馈的产品，这个差距就是你要优化的地方。
顺便说个细节：IDE 右上角原来有个「AI Assistant」面板（需要登录第三方服务才能用）。我在配图里把它裁掉了——不是因为不能用，而是它属于第三方服务的入口，跟 Judge0 本身的能力无关。这个细节倒也说明一件事：连官方 IDE 都在往「AI 写代码 + 立刻执行」这个方向靠。
四、API 设计：一个端点解决大部分问题
官方 API 文档（ce.judge0.com）的分组很清楚：Authentication、Authorization、Submissions、Statuses and Languages、System and Configuration、Statistics、Health Check。核心就一个 /submissions，其余是查语言列表、查状态字典、查系统信息这类支撑性接口。
请求体只有三个必填项：language_id（数字，比如 109 对应某个 Python 版本）、source_code、stdin。想加限制就再加 CPU 时间、内存上限、编译选项、命令行参数。
这个设计的聪明之处在于它把复杂度压在了「语言 ID」这一个字段上。90 多种语言、每种语言的不同版本、各自的编译命令与运行方式，全部收进一张映射表。调用方不需要知道 Python 用 python3 main.py 还是 py main.py，只要说「我要跑 Python」。
官方还提供了 Python SDK 和 JavaScript SDK。Python 那个用起来就一行：给源码、给 stdin、给语言，拿回结果对象。对做脚本和小工具的人来说，比自己拼 HTTP 请求省事。
五、为什么它有一半篇幅在列论文
打开它的 README 会看到一个奇怪的现象：参考文献列表长得离谱，几十条，全是学术论文——教育评估系统、在线判题、编程教学、AI 辅助编程、无障碍编程工具，甚至还有克罗地亚语、印尼语、葡萄牙语的学位论文。
这不是凑数。它说明一件事：Judge0 已经成了「在线代码执行」这个细分领域的基础设施。别人做研究、做教学平台、做评估系统时，默认拿它当执行层，然后在论文里引一句。作者自己那篇发表于 MIPRO 2020 的《Robust and Scalable Online Code Execution System》也是正式出版物，有 DOI，README 里明确求引用。
一个开源项目能同时做到「被工业界用」和「被学术界引」，通常意味着两件事：接口足够稳定，行为足够可预期。
六、自托管前必须知道的几件事
它的功能清单看着很美好（沙箱、多语言、多文件、webhook、可扩展），但真到自己部署的时候，有几个现实门槛：
- 它依赖 isolate，而 isolate 依赖内核级的隔离能力。这意味着容器需要相应权限（cgroups、命名空间这些）。共享型虚拟主机、部分「无特权容器」的托管平台，通常跑不起来。官方把部署步骤放在 CHANGELOG 的 deployment procedure 里，核心还是 Docker 那一套。
- 镜像不小。90 多种语言意味着几十个运行时环境，全量拉下来是几十 GB 级别的磁盘占用。想省空间就得自己裁剪语言集——但那样又失去了「支持 90 种语言」的卖点。
- 公共实例不能当生产用。
ce.judge0.com是给你试接口和做小规模验证的，有速率限制。真要用，要么自托管，要么买官方云。 - 沙箱不是「绝对安全」的同义词。它能防的是「普通恶意代码」，防不了内核漏洞级别的逃逸。README 敢把它定位成执行不可信代码的系统，是因为它把隔离交给了 isolate 这个久经考验的工具，而不是自己写一套。但这仍然意味着：跑在里面的代码越不可信，你越要及时更新宿主机与容器运行时。
还有一个容易忽略的点：它默认的执行环境是无网络的。这对判题是必须的（否则选手可以直接搜答案），但如果你想用它跑「需要联网的 AI agent 工具调用」，就得自己放开网络策略——而这一步会显著提高风险。它近年把 topics 加上了 ai-agents、ai-tools、code-executor，说明这个用法已经是主流场景之一，但网络策略的取舍还是使用者自己扛。
七、它和别的方案比，位置在哪
同类的东西不算少：各家云厂商有沙箱服务，Piston 之类的开源项目也能跑代码，容器平台也能自己搭。Judge0 的位置大致是：
| Judge0 | 自建容器池 | 云厂商沙箱服务 | |
|---|---|---|---|
| 上手成本 | 中（要跑 Docker，配 isolate） | 高（隔离策略全自己写） | 低（调 API 即可） |
| 语言覆盖 | 90+，开箱即用 | 自己装 | 看厂商，通常较少 |
| 数据是否出自己机器 | 自托管则不出 | 不出 | 会出 |
| 长期成本 | 自己的机器 | 自己的机器 | 按调用量计费 |
| 成熟度 | 10 年迭代、论文背书、大量生产使用 | 看你水平 | 高，但绑定厂商 |
所以选择逻辑挺清楚：如果你在意数据不出内网、且需要多语言支持，Judge0 自托管是首选；如果你只是偶尔跑一小段代码、量也不大，直接用官方云更省事；如果你有很强的安全团队并且只需要两三种语言，自己写容器池反而更可控。
八、适合谁
值得用：
- 要做在线判题、编程作业、笔试评估的平台方——这是它最经典的场景。
- 要做 AI agent 的团队：让模型生成的代码有一个可控的执行环境，比在本地直接
exec安全得多。 - 教学场景：90 多种语言意味着学生用什么都能跑，老师不用为每门课搭环境。
- 需要「代码跑一下看看」的在线编辑器、笔记本类产品。
不太必要：
- 只需要跑 Python 一种语言的内部小工具：一个容器加几行代码就够了。
- 没有能力维护 Docker 与内核权限的环境：这类托管平台跑不起来。
- 要求毫秒级响应：TAT 里含着排队与启动开销，它不是为极低延迟设计的。
一句话总结：Judge0 的价值不在「能跑代码」——那太容易了；它的价值在于把「安全地跑不可信代码」这件事做成了一个十年没塌过的基础设施，并且用一套极简的 API 把它藏起来。你付出的代价是要自己维护 Docker 环境、接受几十 GB 的镜像、以及理解「沙箱不是万能」这个前提。
本文根据项目公开仓库 judge0/judge0 的 README、官方 API 文档（ce.judge0.com）与官方 IDE（ide.judge0.com）的实际访问整理撰写。图一为官方 IDE 截图（已裁去右侧第三方 AI 助手面板），图二为 API 文档截图（已裁去下半部分的商业套餐介绍），图三为依据 README 与论文中的架构描述自绘。图片均统一转为 JPEG 并去除元数据，未修改画面内容。文中星标数、许可协议、语言数量与功能说明为撰写时项目文档所载，项目迭代较快，请以仓库当前状态为准。本文不含推广链接与商业入口。
本文整理自公开资料并做重写，原始出处：https://github.com/judge0/judge0。文中配图已去除站点叠加水印与推广信息；版权归原作者所有。