字体与资源限制¶
自建实例时，这几个数字决定了它能扛多少人和多大的活。
CPU 限制¶
docker-compose.yml 默认给两个容器都设了 CPU 配额：
| 容器 | 配置 | 相当于 |
|---|---|---|
frontend |
cpu_quota: 50000、cpu_period: 100000 |
半个核 |
backend |
cpu_quota: 80000、cpu_period: 100000 |
0.8 个核 |
不想要这个限制，把那三行（cpu_count / cpu_quota / cpu_period）删掉或者注释掉；
想改强度就调 cpu_quota 的数值 —— 它是「每个 cpu_period 微秒里能用多少微秒」。
内存限制在 mem_limit / memswap_limit 里，默认 frontend 800 MB、backend 1500 MB。
渲染大尺寸纸张很吃内存，报内存不足的时候先动这两个值。
并发：同时只渲染 2 个¶
后端有个并发闸门：
同一时间最多 2 个渲染任务在跑，多出来的排队等。这是按中小机器的算力定的 ——
渲染是纯 CPU 密集的，开太多只会互相拖慢。机器很猛的话可以调大，
但要相应放宽 cpu_quota，不然它们还是在抢那 0.8 个核。
队列：满了就返回 503¶
「排队中 + 处理中」的任务总数到 8，新的提交会被直接拒绝并返回 503， 前端据此弹出等待倒计时。任务不会无限堆积。
任务过期¶
任务和它渲染出来的图片在 30 分钟后自动清理，磁盘不会被占满。
用户在这之前下载完就行，过期后同一个 task_id 返回 404。
过载保护¶
后端会看自己的 CPU 占用，超过阈值就给新请求返回 429，避免机器被压垮：
E2E 测试和桌面版会把它设成 100，就是为了不受这个守卫干扰。
限流¶
接口有基于来源 IP 的限流，默认是：
各个路由还有各自更细的限制（轮询和取结果的额度比提交任务宽松得多）。
被限流时返回 429。
字体¶
- 打进镜像的字体 来自仓库的
font_assets/，镜像构建时就带上了。 - 自己加的字体 放
ttf_files/，见 Docker 部署。 - 两者都会出现在界面的字体下拉框里。
字体授权自己确认
代码是 MIT，字体不是。 仓库里自带的字体和用户上传的字体各有各的授权， 对外提供服务前请确认你有权分发它们。