字体与资源限制¶
自建实例时，这几个数字决定了它能扛多少人和多大的活。
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， 前端据此弹出等待倒计时。任务不会无限堆积。
任务过期¶
任务以最后更新时间计算有效期；提交、查询状态和获取结果时会清理已过期的任务与响应文件。
请在有效期内下载，过期后同一个 task_id 返回 404。临时文件另有定时清理，仍需监控磁盘空间。
过载保护¶
后端会采样系统 CPU 占用，超过阈值就给新请求返回 429：
E2E 测试和桌面版会把它设成 100，就是为了不受这个守卫干扰。
正文与页数¶
应用没有固定的 10 页截断，也不根据请求域名施加正文长度限制。
长文本仍受 CPU 守卫、队列容量、纸张像素校验、内存和代理超时约束。
实际判断见 backend/app.py。
限流¶
接口有基于来源 IP 的限流，默认是：
各个路由还有各自更细的限制（轮询和取结果的额度比提交任务宽松得多）。
被限流时返回 429。
字体¶
- 打进 Docker 镜像的字体 来自仓库的
ttf_files/，构建时复制到镜像内的/app/font_assets。 - 自己加的字体 放
ttf_files/，见 Docker 部署。 - 两者都会出现在界面的字体下拉框里。
字体授权自己确认
代码是 MIT，字体不是。 仓库里自带的字体和用户上传的字体各有各的授权， 对外提供服务前请确认你有权分发它们。