边缘计算实战：用 Cloudflare Pages 把 TTFB 拉下来

很多团队第一次听到“边缘计算”，眼睛会瞬间发亮：

代码离用户更近了，那岂不是所有页面都会快？

理想很丰满，现实通常是：

静态资源确实更快了
某些页面的 TTFB 也降了
但复杂动态接口依旧慢
数据库一旦还在单一区域，远距离回源还是要花钱也花时间

所以边缘计算最需要的不是热情，而是边界感。

Cloudflare Pages 很强，但它不是“全球加速魔法”，它只是给了你一个机会：

把真正值得靠前执行的逻辑，挪到离用户更近的地方。

1. 边缘真正优化的是什么

很多人把边缘优化理解成“让一切都更快”。

更准确的说法是：

它优先优化的是网络往返距离，以及那些可以在边缘就被拦截、命中、生成的响应。

因此你最容易受益的内容有三类：

静态资源
弱动态 HTML
轻量计算和路由裁决逻辑

最不容易直接受益的，是强依赖中心化数据库的复杂动态接口。

2. Cloudflare Pages 适合下沉什么逻辑

2.1 静态资源与页面外壳

这部分最直接，收益也最稳。

比如博客、文档、营销页、产品介绍页，它们的 HTML、CSS、图片本来就适合全球分发。

2.2 轻度个性化路由

例如：

根据国家或语言跳转站点版本
根据实验分组返回不同变体
读取 cookie 做轻量主题切换

这种逻辑在边缘做，能避免请求先跑到中心区域再决定“你该看哪个版本”。

2.3 缓存友好的聚合接口

如果某个接口本质是：

变化不算特别频繁
对每个用户差异不大
但调用量很大

那它就适合边缘缓存甚至边缘计算预处理。

3. 不适合硬塞到边缘的东西

边缘不是用来炫技的。以下场景强行下沉，常常得不偿失：

每次都要访问中心数据库的高一致性写操作
需要大量 CPU 的数据处理任务
依赖复杂内网资源和专有连接的业务

一句话：

如果你的主要耗时还在后方系统，边缘最多只能把“路”缩短，不能把“工厂”搬走。

4. 一个实用架构：边缘负责拦截、缓存、裁决，中心负责重业务

比较稳妥的做法是把职责分开：

层级	负责什么	不负责什么
边缘	就近分发、缓存命中、轻量重写、实验分流	复杂事务、重型数据聚合
中心应用	核心业务逻辑、权限、聚合、写操作	全球低延迟分发
数据层	真正的数据一致性与持久化	页面分发与流量吸收

当你这样拆，系统会更稳定。因为每一层都在做自己擅长的事。

5. 一个边缘函数例子：让弱动态页面先就近命中

export async function onRequestGet(context: {
  request: Request
  next: () => Promise<Response>
  env: Record<string, string>
}) {
  const cacheKey = new Request(context.request.url, context.request)
  const cache = caches.default

  const cached = await cache.match(cacheKey)
  if (cached) {
    return cached
  }

  const response = await context.next()

  if (response.ok) {
    const headers = new Headers(response.headers)
    headers.set('Cache-Control', 'public, s-maxage=300, stale-while-revalidate=600')

    const cachedResponse = new Response(response.body, {
      status: response.status,
      headers,
    })

    context.waitUntil(cache.put(cacheKey, cachedResponse.clone()))
    return cachedResponse
  }

  return response
}