在构建前端页面时，经常需要不同尺寸的图片来验证响应式布局和视觉样式。如果后端无法及时提供真实图片，开发进度就会被拖慢。CaddyMock2Image 正是针对这一痛点设计的 Node.js 服务，它可以根据 URL 参数快速生成占位图片，再借助 Caddy 反向代理对外提供 HTTPS 访问。本文会从零开始实现这个工具，并说明如何与 Caddy 集成，让本地开发和测试环境更接近生产环境的行为。
Caddy 与 Mock 图片服务的结合点
Caddy 是一个以自动 HTTPS 和简洁配置著称的 Web 服务器。它内置了 Let's Encrypt 支持，只需在配置文件中声明域名，就能自动获取并续期证书。对于本地开发或内网测试，Caddy 也可以使用自签名证书或纯 HTTP 模式，大大降低了 TLS 配置的复杂度。与此同时，Mock 图片服务通常是开发环境中的一个辅助组件，用来代替尚未就绪的真实图片接口。将两者结合，可以让前端开发者在开发阶段就通过 HTTPS 访问占位图服务，避免浏览器安全策略带来的跨域或混合内容问题。
从架构角度看，CaddyMock2Image 是一个独立的 Node.js 进程，监听本地端口，根据请求路径和查询参数生成图片内容。Caddy 作为反向代理，将外部请求转发给这个 Node.js 服务。这种分离设计的好处是：Node.js 服务不需要关心 TLS、域名解析或负载均衡，Caddy 也可以随时替换后端实现，例如在未来接入真实的图片存储服务。对于团队协作来说，只需共享一份 Caddyfile 配置，所有成员就能获得一致的开发体验。
使用 Node.js 实现 CaddyMock2Image 核心逻辑
Node.js 的 http 模块足以构建一个轻量的图片生成服务。核心思路是解析请求 URL 中的参数，如宽度 w、高度 h、背景色 bg、文字颜色 color 和显示文本 text，然后动态生成 SVG 字符串返回给客户端。SVG 是一种文本格式的矢量图，生成速度快，无需额外依赖，非常适合占位图场景。下面是一个最小实现示例：
const http = require('http');
const url = require('url');
const server = http.createServer((req, res) => {
const parsedUrl = url.parse(req.url, true);
const query = parsedUrl.query;
// 解析宽高，默认 300x200
const width = parseInt(query.w) || 300;
const height = parseInt(query.h) || 200;
const bgColor = query.bg || '#cccccc';
const textColor = query.color || '#333333';
const text = query.text || `${width} x ${height}`;
// 限制最大尺寸，防止内存滥用
const maxSize = 4000;
if (width > maxSize || height > maxSize) {
res.writeHead(400, { 'Content-Type': 'text/plain; charset=utf-8' });
res.end('Invalid size');
return;
}
// 生成 SVG 字符串，注意 HTML 实体转义
const svg = `<svg xmlns="http://www.w3.org/2000/svg" width="${width}" height="${height}" viewBox="0 0 ${width} ${height}">
<rect width="100%" height="100%" fill="${bgColor}"/>
<text x="50%" y="50%" fill="${textColor}" font-family="Arial" font-size="${Math.min(width, height) / 10}" text-anchor="middle" dominant-baseline="middle">${text}</text>
</svg>`;
res.writeHead(200, {
'Content-Type': 'image/svg+xml',
'Cache-Control': 'public, max-age=3600',
});
res.end(svg);
});
server.listen(3000, () => {
console.log('CaddyMock2Image running on port 3000');
});上述代码中，通过 url.parse 获取查询参数，并用 parseInt 做基础的类型转换。为了防止恶意请求传入超大尺寸导致服务器内存暴涨，代码里设置了最大尺寸限制。SVG 内容使用模板字符串拼接，rect 元素填充背景色，text 元素居中显示文本。返回的 Content-Type 是 image/svg+xml，浏览器可以直接渲染。缓存头 Cache-Control 设置为 public 并且最大缓存一小时，减少重复请求对服务的压力。
如果希望生成 PNG 或 JPEG 格式，可以引入 sharp 库。sharp 是一个高性能的图像处理库，底层使用 libvips，能够将 SVG 缓冲转换为光栅图像。不过对于纯占位图需求，SVG 已经足够，而且体积更小、响应更快。只有当前端必须使用 <img> 标签且要求真实像素格式时，才需要考虑 PNG 转换。下面给出使用 sharp 将 SVG 转为 PNG 的代码片段：
const sharp = require('sharp');
async function svgToPng(svgString, width, height) {
return await sharp(Buffer.from(svgString))
.resize(width, height)
.png()
.toBuffer();
}
// 在请求处理中：
if (query.format === 'png') {
const pngBuffer = await svgToPng(svg, width, height);
res.writeHead(200, {
'Content-Type': 'image/png',
'Cache-Control': 'public, max-age=3600',
});
res.end(pngBuffer);
} else {
res.writeHead(200, {
'Content-Type': 'image/svg+xml',
'Cache-Control': 'public, max-age=3600',
});
res.end(svg);
}这段代码展示了如何根据 format 参数决定返回 SVG 还是 PNG。使用 sharp 时需要注意异步处理，避免阻塞事件循环。另外，sharp 的安装在不同平台可能需要编译原生模块，如果团队环境复杂，保持纯 SVG 方案会更省心。
通过 Caddy 配置反向代理与 HTTPS
要让外部用户通过 Caddy 访问 CaddyMock2Image，需要编写一份 Caddyfile。Caddyfile 是 Caddy 的配置文件，语法非常简洁。下面是一个典型配置，将 mock.ippipp.com 域名下的 /mock 路径转发到本地的 Node.js 服务：
mock.ippipp.com {
encode gzip
handle_path /mock/* {
reverse_proxy localhost:3000
}
}这里的 handle_path 指令会匹配路径并移除前缀 /mock 后再转发给后端。也就是说，外部请求 /mock?w=800&h=600 会被转发为 localhost:3000/?w=800&h=600。这样可以避免后端服务感知到路径前缀，保持代码简洁。如果不需要移除前缀，可以直接使用 reverse_proxy /mock/* localhost:3000，但这样后端收到的路径仍然包含 /mock，需要额外处理。
Caddy 会自动为 mock.ippipp.com 申请 Let's Encrypt 证书并启用 HTTPS。在本地开发环境中，如果无法使用公网域名，可以将域名改为 localhost 并使用 tls internal 指令生成自签名证书。浏览器会提示证书不受信任，但可以通过手动信任来解决。另一种做法是在 Caddyfile 中使用 http:// 前缀强制使用 HTTP，适合纯内网环境。无论哪种方式，Caddy 都大幅简化了 HTTPS 的配置流程，让开发者专注于业务逻辑。
此外，Caddy 的 encode gzip 指令可以对 SVG 文本进行压缩，进一步减小传输体积。SVG 本身是纯文本，gzip 压缩率通常能达到 70% 以上，对于大量占位图请求的场景非常有效。如果担心缓存命中率，可以在 Node.js 服务中增加 ETag 或 Last-Modified 响应头，配合 Caddy 的缓存策略，减少重复生成图片的开销。
进阶优化与部署实践
在真实项目中使用 CaddyMock2Image 时，有几个优化点值得关注。首先是参数校验和错误处理。除了尺寸限制，还应该对颜色值进行正则校验，防止注入非法 SVG 元素或脚本。例如可以使用 ^#[0-9a-fA-F]{6}$ 来限制十六进制颜色格式。对于文本参数，需要转义 HTML 特殊字符，避免生成的 SVG 被解析为可执行脚本。一个简单的做法是使用 escapeHtml 函数，将 &、<、> 等字符替换为对应实体。
其次是缓存策略。虽然浏览器缓存可以减轻服务器压力，但跨用户的缓存命中率并不高。可以考虑在 Caddy 层增加响应缓存插件，或者使用 CDN 进行边缘缓存。对于开发环境，一个更简单的做法是在 Node.js 服务内部使用内存缓存，将相同参数生成的 SVG 字符串保存起来，设置最大条目数和过期时间。这样即使多个开发者同时请求相同尺寸的图片，也只需计算一次。
部署方面，推荐使用 Docker Compose 同时运行 Caddy 和 CaddyMock2Image。下面是一个示例配置：
version: '3'
services:
caddy:
image: caddy:latest
ports:
- "80:80"
- "443:443"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile
- caddy_data:/data
depends_on:
- mockimg
mockimg:
build: .
ports:
- "3000:3000"
volumes:
caddy_data:在这个 Compose 文件中，Caddy 容器负责对外暴露 80 和 443 端口，并将 Caddyfile 挂载到容器内。mockimg 容器运行 Node.js 服务，通过 depends_on 确保启动顺序。在生产环境中，建议不要将 mockimg 的端口直接暴露给宿主机，而是通过 Docker 内部网络通信，Caddy 使用 reverse_proxy mockimg:3000 即可。这样可以减少攻击面。
最后需要强调，CaddyMock2Image 的价值在于快速解决联调阶段的图片缺失问题，而不是替代真实的图片处理服务。当后端接口就绪后，应该及时切换到真实数据源，避免 Mock 服务长期运行带来的维护成本和误导风险。通过本文的实现思路，你可以根据团队需求扩展更多功能，例如支持渐变背景、自定义字体、水印文字，甚至生成二维码占位图。Node.js 的生态足够灵活，而 Caddy 的简洁配置让整个方案落地成本极低。