JamStack 架构强调静态优先、按需动态，而图片生成恰恰是一个典型的按需计算场景。无论是社交分享卡片、文章封面图，还是数据报表的截图输出，如果靠设计师手动出图，效率低且难以规模化。Node.js 生态里其实早有一套成熟的做法：用无头浏览器渲染 HTML 页面，再截图输出为图片。这个思路常被称作页面转图片服务，社区里一些类似项目把它命名为 JamStack2Image，本文就来拆解这套方案的完整实现。
为什么选择无头浏览器而不是 Canvas
在动手写代码之前，先回答一个高频问题：生成图片为什么不用 Node.js 的 Canvas 库？答案很直接：Canvas 画图本质上是代码绘图，你需要用 JS 手动描述每一行文字、每一个矩形、每一条渐变。字体加载、自动换行、文字溢出裁剪这些浏览器里理所当然的能力，在 Canvas 里全要自己造轮子，一旦设计稿稍作调整，代码就得跟着大改。
而无头浏览器方案完全复用了浏览器的渲染引擎。你只需要维护一套 HTML 模板，样式交给 CSS 处理，Flexbox、Grid、自定义字体、SVG 图标全部原生支持，设计稿还原度接近百分之百。Puppeteer 是这个方案里最主流的选择，它由 Chrome 团队维护，通过 DevTools 协议控制一个 Chrome 实例，API 稳定且文档完善。
两者的性能差异也值得注意。Canvas 在纯几何绘制上确实更快，但涉及富文本排版时会明显变慢；无头浏览器的主要开销在进程启动和页面加载上，只要做好浏览器实例复用，单次截图通常能控制在几百毫秒内。综合来看，对样式复杂度要求高的场景，无头浏览器是更划算的选择。
搭建基础的截图 HTTP 服务
整体架构很朴素：Express 起一个 HTTP 服务，接收 URL 或者 HTML 模板参数，调用 Puppeteer 完成渲染，把截图以二进制流返回给客户端。先安装依赖：
npm install express puppeteer
核心服务代码如下，注意这里用了 page.setContent 而不是 page.goto，因为模板内容由服务端动态拼接，不需要真实发起网络请求去加载远程页面。当然如果你的场景是对已有页面截图，把 setContent 换成 page.goto(url, {waitUntil: 'networkidle0'}) 即可。
const express = require('express');
const puppeteer = require('puppeteer');
const app = express();
app.use(express.json());
let browser = null;
// 复用浏览器实例，避免每次请求都冷启动
async function getBrowser() {
if (!browser) {
browser = await puppeteer.launch({
headless: 'new',
args: ['--no-sandbox', '--disable-setuid-sandbox', '--disable-dev-shm-usage']
});
}
return browser;
}
app.post('/api/image', async (req, res) => {
const { title, desc, width = 1200, height = 630 } = req.body;
const html = buildTemplate(title, desc);
try {
const b = await getBrowser();
const page = await b.newPage();
await page.setViewport({ width, height, deviceScaleFactor: 2 });
await page.setContent(html, { waitUntil: 'networkidle0' });
const buffer = await page.screenshot({ type: 'png' });
await page.close();
res.set('Content-Type', 'image/png');
res.set('Cache-Control', 'public, max-age=86400');
res.send(buffer);
} catch (err) {
console.error(err);
res.status(500).json({ error: 'render failed' });
}
});
function buildTemplate(title, desc) {
return `<!DOCTYPE html>
<html>
<head><meta charset="utf-8">
<style>
body { margin: 0; display: flex; align-items: center; justify-content: center;
background: linear-gradient(135deg, #667eea, #764ba2);
font-family: "PingFang SC", "Microsoft YaHei", sans-serif; }
.card { width: 80%; color: #fff; }
h1 { font-size: 64px; margin-bottom: 24px; }
p { font-size: 28px; opacity: 0.85; line-height: 1.6; }
</style></head>
<body><div class="card"><h1>${title}</h1><p>${desc}</p></div></body>
</html>`;
}
app.listen(3000, () => console.log('image service running on 3000'));有几个细节要展开说。第一，deviceScaleFactor: 2 会输出两倍分辨率的图片，这是社交分享卡片的常见做法，能避免高分屏下发虚。第二，waitUntil: 'networkidle0' 会等到网络空闲再截图，确保异步加载的字体和图片都渲染完成，这是新手最常踩的坑——截图出来文字是默认字体，多半就是没等字体加载完。第三，模板拼接处存在 XSS 风险，生产环境务必对用户输入做转义，或者改用 DOMPurify 之类的库过滤。
并发控制与队列设计
无头浏览器是资源大户，一个 Chrome 实例开太多标签页会导致内存暴涨甚至崩溃。最简单的做法是限制同时打开的页面数量，超出的请求排队等待。这里可以用 p-limit 或者自己写一个简易信号量。同时建议定期重启浏览器实例，防止内存泄漏累积：
const pLimit = require('p-limit');
const limit = pLimit(5); // 最多同时渲染5张
app.post('/api/image', (req, res) => {
limit(async () => {
// 上面的渲染逻辑
}).catch(err => res.status(500).json({ error: err.message }));
});
// 每渲染500张图重启一次浏览器，回收内存
let renderCount = 0;
async function maybeRestart() {
if (++renderCount > 500 && browser) {
await browser.close();
browser = null;
renderCount = 0;
}
}如果流量再大一些，单进程会顶不住，这时可以把渲染逻辑抽成独立的 worker 进程池，或者干脆用 Bull 队列加多个渲染容器横向扩容。请求进来只做参数校验和入队，图片生成异步完成后写入对象存储，CDN 直接回源取图，这就是很多 OG 图服务在用的架构。
缓存与部署实战要点
缓存是这个服务的性价比之王。同样的标题描述生成的图片几乎不会变化，重复渲染纯属浪费。方案有两层：HTTP 层面设置较长的 Cache-Control，让浏览器和 CDN 帮你挡掉大部分请求；服务层面可以用内容参数做哈希，把结果落盘或存进 Redis，命中直接返回。
const crypto = require('crypto');
function cacheKey(params) {
return crypto.createHash('md5')
.update(JSON.stringify(params))
.digest('hex');
}
// 命中缓存直接返回，未命中才渲染
const cached = await redis.getBuffer(key);
if (cached) return res.send(cached);部署方面，Docker 是标配，但有两个坑要提前知道。一是官方 Node 镜像里没有 Chrome 依赖，直接 npm install puppeteer 后启动会报缺少共享库，建议在 Dockerfile 里补充 apt-get install 安装依赖，或者直接使用 node 镜像加 puppeteer 的完整依赖清单。二是容器里必须加上 --no-sandbox 参数，因为默认的沙箱机制在容器环境缺少足够权限。如果对镜像体积敏感，可以改用 puppeteer-core 配合自己维护的 Chrome for Testing 二进制，能省下不少空间。
最后提一句 Serverless 场景。虽然无头浏览器冷启动在 FaaS 里偏慢，但各大云厂商的容器函数产品已经能跑到一到两秒的冷启动水平，配合预置并发实例，完全可以承接中低流量的图片生成需求。对于个人博客或文档站的 OG 图需求，这套方案跑在最小规格的容器里绰绰有余，成本几乎可以忽略。