「用无头浏览器出图」很常见。真正少见的是把交付契约写清楚：同架构离线包（目标机禁止再装依赖）+ 进程级 worker 池 + 分批落盘防 OOM。
能力拆分
| 能力 | 要点 |
|---|---|
| 探活 | 渲染忙时健康检查仍要能响应 |
| 批渲染 | 入参为图表任务列表 → PNG 落指定路径 |
| 进程级池 | 多路 HTTP 共用一池，避免过订阅；单任务超时防挂死占池 |
| 主路径 | 前端只触发并轮询 → 后端异步收集 option + 分批渲染 → 临时目录 → 流式打 ZIP → 对象存储 |
| 离线 | 与目标机同 OS/CPU 打包；解压即跑；禁止目标机再装包（原生画布 ABI） |
为什么要拆进程
出图是 CPU 绑定，不宜与事务 API 抢同一进程。契约应是「批任务 + 落盘路径」，而不是一次 HTTP 返回全部图片内容。
离线环境里，「拷过去又被要求安装/下载」几乎总会发生——所以离线包约定不是锦上添花，而是交付底线。原生依赖 ABI 不对齐时，任何「到现场再 npm install」都会翻车。
可复用的落点
- 出图与业务 API 进程隔离。
- 契约是批任务 + 路径，不是巨型响应体。
- 离线难点在原生依赖 ABI，不在业务逻辑本身。