配方：做一个可验证的 Worker JSON API

用最小文件结构、明确的成功与错误响应，完成第一条边缘 API。

RECIPE · 可交付成果约 25 分钟Worker · 无外部依赖

成品预览

GET /api/health 返回带请求 ID 的 JSON；其他路径返回结构化 404。你将验证两条分支，而不是只看一条成功请求。

需要什么

已完成部署第一个 Worker。
本地项目可以运行 wrangler dev。

文件结构

package.json

wrangler.jsonc

index.ts

写入并验证

src/index.ts

export default {
  async fetch(request: Request): Promise<Response> {
    const url = new URL(request.url);
    const requestId = crypto.randomUUID();

    if (request.method === 'GET' && url.pathname === '/api/health') {
      return Response.json(
        { ok: true, requestId },
        { headers: { 'cache-control': 'no-store' } },
      );
    }

    return Response.json(
      { ok: false, error: 'not_found', requestId },
      { status: 404 },
    );
  },
};

为什么健康检查不缓存

这个配方用 cache-control: no-store 明确表达健康状态需要实时生成。后续静态内容配方会采用不同策略。

AI 审查提示词

AI 工作台已人工审阅

审查 API，而不是重写 API

请审查下面的 Cloudflare Worker fetch handler。只报告可复现的问题，并分别检查：
- GET /api/health 的状态码、JSON 与 cache-control；
- 未知路径是否稳定返回结构化 404；
- 是否泄露密钥、内部错误或用户输入；
- 是否使用当前 ES Modules fetch handler。
先给验证命令，再给最小修改。不要虚构 wrangler 字段。

检查点与常见坑

每个响应都应有新的 requestId。
404 是预期分支，不应被误判为 Worker 崩溃。
不要把 API Token、账号 ID 或 Secret 写进响应与仓库。
部署前先查阅当前 wrangler deploy 文档并在自己的预览环境验证。

下一步：理解这条 API 的架构边界。