边缘计算实战：前端如何利用 CDN 节点“干掉”API 延迟？

做前端的都有过这种体验：页面首屏加载，JS/CSS 资源走 CDN 很快，但那个关键的 user/profile 或者 product/list 接口却还在转圈。

原因很简单：

"

你的静态资源在用户家门口的 CDN 节点，但 API 逻辑还在大洋彼岸的源站（Origin Server）。

把计算逻辑从“源站”搬到离用户最近的“CDN 边缘节点”，这就是边缘计算（Edge Computing）在前端性能优化中最核心的价值。

今天聊聊怎么用 Cloudflare Workers 实战解决这个问题。

---

为什么是边缘计算？

传统的请求路径是：

用户 (上海) -> 互联网 -> 源站服务器 (美国弗吉尼亚) -> 数据库 -> 返回

这一来一回的 RTT (Round-Trip Time) 物理延迟是没法消除的。

引入边缘计算（Cloudflare Workers）后：

用户 (上海) -> CF 边缘节点 (上海) -> 返回

我们实际上是在边缘节点部署了一个轻量级的 JavaScript 环境（Service Worker API），拦截用户请求，在边缘直接处理响应，或者通过边缘节点去请求源站（走优化的骨干网）。

---

三个最实用的应用场景

1. 边缘缓存动态 API (Cache at Edge)

对于一些更新频率不高、但查询量大的接口（比如配置信息、新闻列表、热门商品），完全没必要每次都回源站查库。

在边缘节点直接缓存 API 的 JSON 响应，可以将延迟从 500ms+ 降到 50ms 以内。

2. 轻量级 BFF (Backend for Frontend)

如果你的页面需要调 3 个接口才能渲染（比如：用户信息 + 消息数 + 推荐列表）。

• **传统模式：**浏览器发 3 个请求，排队、等待。
• **边缘模式：**浏览器发 1 个请求给边缘节点，边缘节点并发请求源站（走内网或优化的线路），组装好数据一次性返回。

3. 身份验证前置

把 JWT 校验放在边缘节点。如果 Token 无效，直接在边缘拦截返回 401，流量根本不需要打到你的源站服务器，既省钱又安全。

---

实践：用 Cloudflare Workers 缓存 API 响应

场景：我们要代理api.yourdomain.com/products，并对其结果缓存 60 秒。

export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);

    // 只处理特定的 API 路径
    if (url.pathname.startsWith('/api/products')) {
      return handleProductsRequest(request, ctx);
    }

    // 其他请求直接透传（回源）
    return fetch(request);
  }
};

async function handleProductsRequest(request, ctx) {
  // 1. 定义缓存键（通常是 URL）
  const cacheUrl = new URL(request.url);
  const cacheKey = new Request(cacheUrl.toString(), request);

  // 2. 检查 Cloudflare 边缘缓存
  const cache = caches.default;
  let response = await cache.match(cacheKey);

  if (!response) {
    console.log(`[Miss] Fetching from Origin: ${request.url}`);

    // 3. 缓存未命中，去源站拉取数据
    // 注意：这里可以修改请求头，比如加上鉴权 Secret
    response = await fetch(request);

    // 4. 为了安全，最好重新构造 Response，确保只缓存 200 OK
    if (response.status === 200) {
      response = new Response(response.body, response);

      // 5. 设置浏览器缓存 (Browser Cache) 和 边缘缓存 (CDN Cache)
      // s-maxage 控制 CDN 缓存时间，max-age 控制浏览器
      response.headers.set('Cache-Control', 'public, max-age=30, s-maxage=60');

      // 6. 异步写入缓存（不阻塞当前请求返回）
      ctx.waitUntil(cache.put(cacheKey, response.clone()));
    }
  } else {
    console.log(`[Hit] Serving from Edge: ${request.url}`);
  }

  return response;
}

代码解析：

• caches.default: Cloudflare 提供的标准 Cache API，就在节点本地。
• ctx.waitUntil: 这句很关键。它允许你在向用户返回响应之后，继续在后台执行写入缓存的操作，让用户感知的延迟降到最低。
• s-maxage: 专门告诉 CDN 节点缓存多久，让我们能灵活控制边缘与浏览器的缓存策略分离。

---

避坑指南

虽然边缘计算很香，但实际落地有几个坑要注意：

1. 冷启动问题（Cold Start）： 虽然 Workers 启动极快（毫秒级），但如果你的代码体积巨大或者依赖性很高，首个请求还是会有微小延迟。保持代码精简。

2. 缓存一致性： 既然缓存了 API，就要考虑怎么更新。如果源站数据变了，边缘节点可能还在推旧数据。

   • 解法： 如果对实时性要求极高，不要用强缓存，或者配合 Cloudflare KV/Durable Objects 做智能失效。

3. 调试难度： 以前看 Chrome Network 面板就知道发生了什么，现在中间多了一层。建议善用 wrangler tail (Cloudflare 的实时日志工具) 来监控边缘节点的行为。

---

总结

边缘计算不是在取代后端，而是在前端和后端之间加了一个高性能缓冲层。

对于前端工程师来说，Cloudflare Workers 这类工具让我们有了控制网络层的能力。下次再遇到 API 慢的问题，别只想着加 Loading 动画，试着把逻辑往“边缘”推一推，用户体验会有质的飞跃。