如何用Node.js实现Mock图片生成服务并部署到Deno Deploy和K8s？

在前后端分离的开发流程里，图片资源经常是接口联调时最容易被忽视的一环。设计师的切图还没到位，后端的图片接口还没稳定，前端页面上就会出现一片空白或者裂图。占位图服务（Placeholder Image Service）就是为了解决这个问题而生的，知名的placeholder.com、picsum.photos都属于这一类。本文将带你用Node.js从零实现一个可自定义尺寸、背景色和文字的Mock图片生成服务，并重点讲解如何把它部署到Deno Deploy边缘平台和Kubernetes集群上，形成一个可以在团队内部长期使用的工具。

用Node.js实现Mock图片生成的核心逻辑

实现一个占位图服务，本质上就是根据URL参数动态生成一张PNG图片并返回给浏览器。核心依赖有两个：一个是HTTP服务器，Node.js内置的http模块就能胜任；另一个是图片绘制能力，这里选择node-canvas，它提供了与浏览器Canvas几乎一致的API，可以在服务端绘制矩形、填充颜色、绘制文字。

请求路径的设计参考主流做法，例如/300x200/2b7a4b/ffffff?text=Banner，表示生成一张宽300、高200、背景色为2b7a4b、文字颜色为ffffff、显示文字为Banner的图片。解析路径时要注意容错：尺寸缺省时给默认值，颜色值需要做十六进制合法性校验，避免非法输入导致绘制异常。

const http = require('http');
const { createCanvas } = require('canvas');

function parseColor(str, fallback) {
  if (!str || !/^[0-9a-fA-F]{6}$/.test(str)) return fallback;
  return '#' + str;
}

const server = http.createServer(async (req, res) => {
  const url = new URL(req.url, 'http://localhost');
  // 解析尺寸参数，例如 /300x200/2b7a4b/ffffff
  const match = url.pathname.match(/^\/(\d+)x(\d+)(?:\/([0-9a-fA-F]{6}))?(?:\/([0-9a-fA-F]{6}))?/);
  if (!match) {
    res.writeHead(404, { 'Content-Type': 'text/plain' });
    return res.end('Usage: /300x200/[bgColor]/[textColor]?text=hello');
  }

  const width = Math.min(parseInt(match[1], 10), 4096);
  const height = Math.min(parseInt(match[2], 10), 4096);
  const bg = parseColor(match[3], '#cccccc');
  const fg = parseColor(match[4], '#333333');
  const text = url.searchParams.get('text') || `${width}x${height}`;

  const canvas = createCanvas(width, height);
  const ctx = canvas.getContext('2d');
  ctx.fillStyle = bg;
  ctx.fillRect(0, 0, width, height);
  ctx.fillStyle = fg;
  // 字号随图片尺寸自适应，保证文字在图内居中
  const fontSize = Math.max(12, Math.floor(Math.min(width, height) / 6));
  ctx.font = `${fontSize}px sans-serif`;
  ctx.textAlign = 'center';
  ctx.textBaseline = 'middle';
  ctx.fillText(text, width / 2, height / 2);

  const buffer = canvas.toBuffer('image/png');
  res.writeHead(200, {
    'Content-Type': 'image/png',
    'Content-Length': buffer.length,
    'Cache-Control': 'public, max-age=86400'
  });
  res.end(buffer);
});

server.listen(3000, () => console.log('mock image service on :3000'));

这段代码里有几个细节值得展开。第一，宽高做了上限限制，防止恶意请求生成超大图片把服务器内存打爆；第二，字号根据图片短边自适应计算，这样无论生成多大的图，文字比例都是协调的；第三，响应头里加了Cache-Control，占位图内容确定后不变，让浏览器缓存一天可以大幅减少重复请求。生产环境还可以加一层LRU缓存，以「尺寸+颜色+文字」为key缓存生成好的Buffer，命中后直接返回，省去重复绘制的CPU开销。

部署到Deno Deploy：Node.js代码的兼容运行方案

Deno Deploy是部署在边缘节点上的Serverless平台，请求会被自动调度到离用户最近的数据中心，冷启动极快，非常适合图片这类读多写少的服务。虽然它是Deno的官方平台，但从Deno 1.25开始提供了Node.js兼容层，可以直接运行许多依赖npm包的Node项目，不需要重写成Deno原生API。

不过要特别说明一个限制：Deno Deploy的运行环境不允许使用原生二进制依赖，而node-canvas底层依赖Cairo原生库，在Deno Deploy上是跑不起来的。解决办法是换用纯JavaScript实现的PNG编码方案，例如pngjs，它完全用JS实现编码流程，兼容性没有问题。绘图逻辑相应简化为逐像素填充背景色，文字部分可以用极简的点阵字库或者干脆省略，只输出尺寸信息。

import { PNG } from 'npm:pngjs@7';

Deno.serve((req) => {
  const url = new URL(req.url);
  const match = url.pathname.match(/^\/(\d+)x(\d+)/);
  if (!match) {
    return new Response('Usage: /300x200', { status: 404 });
  }
  const width = Math.min(parseInt(match[1]), 2048);
  const height = Math.min(parseInt(match[2]), 2048);

  const png = new PNG({ width, height });
  // 简单示例：纯色填充，逐行写入像素
  const r = 43, g = 122, b = 75;
  for (let y = 0; y < height; y++) {
    for (let x = 0; x < width; x++) {
      const idx = (width * y + x) << 2;
      png.data[idx] = r;
      png.data[idx + 1] = g;
      png.data[idx + 2] = b;
      png.data[idx + 3] = 255;
    }
  }

  const buffer = PNG.sync.write(png);
  return new Response(buffer, {
    headers: {
      'Content-Type': 'image/png',
      'Cache-Control': 'public, max-age=86400'
    }
  });
});

部署方式很简单，在项目目录执行deployctl deploy --project=mock-image --entrypoint=main.js，或者把仓库关联到Deno Deploy的Git集成，推送代码即自动发布。部署完成后会得到一个xxx.deno.dev的域名，全球任何地方访问延迟都很低。如果你的Mock服务只是给团队原型页面用，这种方案几乎零运维成本，免费额度也完全够用。

容器化并部署到Kubernetes集群

如果团队有自己的Kubernetes集群，把服务容器化后跑在K8s上是更可控的选择，方便统一管理资源配额、日志和监控。第一步是构建镜像，这里的关键点是node-canvas这类原生依赖需要在镜像里预装系统库，基础镜像建议选Alpine并配合--build-from-source相关参数，或者直接使用带build工具的镜像阶段做多阶段构建，减小最终镜像体积。

FROM node:20-alpine AS builder
# node-canvas 需要的系统依赖
RUN apk add --no-cache build-base g++ cairo-dev pango-dev jpeg-dev giflib-dev
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev

FROM node:20-alpine
# 运行期只需要运行库
RUN apk add --no-cache cairo pango jpeg giflib
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

镜像构建完成后推送至私有仓库，接着编写K8s清单。一个最小可用的部署包含Deployment和Service两部分：Deployment管理Pod副本，通过resources字段声明CPU和内存的请求与上限，防止图片生成这类CPU密集操作抢占其他服务的资源；Service用ClusterIP把服务暴露给集群内部，如果需要外部访问，再配合Ingress或LoadBalancer。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mock-image
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mock-image
  template:
    metadata:
      labels:
        app: mock-image
    spec:
      containers:
        - name: mock-image
          image: registry.ippipp.com/mock-image:v1.0.0
          ports:
            - containerPort: 3000
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 256Mi
          readinessProbe:
            httpGet:
              path: /10x10
              port: 3000
            initialDelaySeconds: 3
---
apiVersion: v1
kind: Service
metadata:
  name: mock-image
spec:
  selector:
    app: mock-image
  ports:
    - port: 80
      targetPort: 3000

这里把就绪探针的路径设成了/10x10，即请求一张10x10的小图，既能真实验证服务可用性，开销又极小。副本数设为3配合imagePullPolicy默认策略，滚动更新时新Pod就绪才会接流量，发布过程不会中断服务。

两种部署方案的选型对比与优化建议

Deno Deploy和K8s各有明确的适用边界。Deno Deploy胜在零运维、边缘加速、按请求计费，缺点是运行时受限、不能依赖原生模块、无法做有状态缓存；K8s胜在完全可控、可以横向扩容、能集成Prometheus监控和日志系统，缺点是需要专人维护集群，成本更高。如果是面向公网的原型演示页，优先Deno Deploy；如果是企业内部多团队共用的基础设施，放K8s里更合适。

无论选择哪种部署方式，性能优化上有三点通用建议。一是充分利用HTTP缓存，除了Cache-Control，再加上ETag，让条件请求返回304，进一步节省带宽；二是进程内做生成结果的LRU缓存，相同参数的图片直接复用Buffer；三是如果并发量真的上来了，考虑把图片生成的结果推到对象存储加CDN，源服务只负责首次生成，架构上从「每次实时生成」演进为「生成一次、永久分发」，这才是图片类服务最终形态的性价比方案。

最后补充一点工程化建议：把「尺寸校验、颜色校验、参数解析」这些逻辑抽成纯函数并写好单元测试，HTTP层只做薄薄一层包装，这样无论将来迁移到Deno Deploy、K8s还是其他Serverless平台，核心代码都可以原样复用，部署层的变化不会侵蚀业务逻辑。

Node.jsMock图片服务Deno Deploy修改时间：2026-09-13 19:59:15