我对 Edge 渲染降温之后：先问数据在哪，再问页面跑在哪

前端基础组件与状态性能与缓存

刚开始关注 Edge 渲染的时候，我其实挺容易兴奋。

边缘函数、边缘缓存、边缘中间件、离用户更近的节点，这些词放在一起，很容易让人觉得它就是性能问题的下一站答案。尤其是前端项目做多了以后，页面慢、接口慢、跨地区访问慢，大家总想找一个更“架构级”的办法。

后来我在几个项目里看过落地讨论，想法慢慢冷静下来。

Edge 当然有价值，但它不是“页面慢”的默认解法。很多时候真正要先问的不是页面能不能跑到边缘，而是：用户在哪里，数据在哪里，慢在哪里。

我第一次降温，是因为数据库还在中心区

有个内容管理类项目，当时大家讨论要不要把部分页面放到 Edge。理由很直观：用户分布不完全在一个地区，页面又是服务端渲染，理论上离用户近一点会快。

但把链路画出来以后，问题就没那么漂亮了。

1用户 -> Edge 节点 -> 中心接口 -> 中心数据库 -> Edge 节点 -> 用户

页面渲染函数离用户近了，但核心数据仍然在中心区域。每次请求还是要跨区域回去拿数据。更麻烦的是，页面还依赖几个内部服务，这些服务只在中心网络里稳定访问。

如果不改数据和接口链路，只把渲染位置搬到边缘，可能只是把复杂度挪了个地方。

当时我们还真做了一组对照测试，把同一个页面分别部署在中心区域的 Node 服务和某个边缘平台上，用合成监控从几个地区打 TTFB。结果挺打脸：边缘版本对静态壳子确实快了几十毫秒，但只要页面里有那个跨区拿数据的接口，整体 TTFB 反而比中心版本还高了 50 到 80 毫秒。原因是边缘节点和中心数据库之间多了一跳，而中心 Node 服务和数据库本来就在同一个内网，回源几乎没有网络成本。

后来我画了个更细的链路对比，才真正想明白：

1中心渲染：用户 --(跨区, 一次远)--> 中心服务 --(内网, 近)--> 数据库
2边缘渲染：用户 --(就近, 近)--> 边缘节点 --(跨区, 一次远)--> 中心数据库

两种方案都有一次“远”，区别只是这一跳发生在用户到服务之间，还是服务到数据之间。如果页面的耗时大头是数据查询而不是首字节，把渲染挪到边缘并不会让那一跳消失，只是换了个位置出现。

这次之后我记住了一个判断：Edge 优化的是“离用户远”的那部分成本，但如果页面真正依赖的是“离数据远”，它未必会变快。真正能让边缘发挥作用的前提，是数据本身也能跟着靠近用户——要么走边缘可读的缓存，要么用支持多区域只读副本的数据库，否则边缘渲染就是在给一个回源很慢的接口套了层更近的壳。

Edge 适合轻、读多、可缓存的东西

我现在会把 Edge 的适用场景收窄。

它适合这类任务：

  • 内容页、文档页、营销页这类读多写少页面。
  • 根据地区、语言、设备做轻量分流。
  • 登录前的入口判断、重定向、灰度分桶。
  • 可以被 CDN 或边缘缓存稳定命中的响应。
  • 不依赖复杂中心状态的短逻辑。

比如一个帮助中心页面，内容更新频率低，访问地区分散，用户私有状态少，这类页面非常适合把缓存和渲染往边缘推。

但订单、权限、库存、审批状态、个人资料这类东西，我会很谨慎。它们不是不能走边缘，而是要先证明一致性、数据会不会串到别的租户、回源链路都设计清楚。

我现在更愿意先给页面做一个简单分级：

1公共内容：博客、文档、帮助中心、活动页
2半动态内容：商品详情、公开榜单、推荐模块
3高一致性内容：订单、权限、库存、支付、个人资料

第一类可以大胆缓存，第二类要设计失效策略，第三类不要为了“离用户近”轻易牺牲准确性。

这个分级我后来在代码里也落成了约定。比如在框架的渲染配置上明确标出每个路由段的策略，而不是靠口头记忆：

1// 公共内容：长缓存 + 后台再验证
2export const revalidate = 3600
3
4// 半动态内容：短缓存，配合按需失效
5export const revalidate = 60
6
7// 高一致性内容：强制每次动态渲染，不进缓存
8export const dynamic = 'force-dynamic'

把这几行写在文件顶部的好处是，任何人改这个页面时一眼就能看到它的缓存语义，而不是上线后才发现订单页被 CDN 缓了五分钟。我吃过一次类似的亏：一个本该实时的状态页，因为复用了内容页的布局和默认缓存头，结果用户刷新半天看到的都是旧状态，排查了挺久才发现是继承下来的 s-maxage 在作怪。从那以后我对“默认值”特别警惕，高一致性页面我宁可显式写死动态渲染，也不接受隐式继承。

缓存策略比运行位置更关键

很多页面上 Edge 后没有明显变快，是因为缓存策略本身没设计好。

如果每次都动态渲染、每次都回源拿数据、每次都绕过缓存，那 Edge 只是换个地方跑慢逻辑。

我现在会先问缓存：

  • 静态资源有没有长期缓存？
  • HTML 或数据响应能不能短缓存？
  • 过期后能不能先返回旧内容，再后台更新？
  • 用户私有数据有没有明确禁止缓存？
  • 缓存命中率能不能监控？

比如文章页或帮助页，下面这种策略往往比“单纯换成边缘渲染”更有价值：

1Cache-Control: public, s-maxage=300, stale-while-revalidate=86400

它的意思不是“永远缓存”，而是给体验和更新之间留一个缓冲：用户先拿到内容，后台再更新缓存。stale-while-revalidate 这个值容易被忽略，但它几乎是边缘缓存里最划算的一个参数——它把“内容更新延迟”和“用户等待时间”解耦了。用户永远拿到的是缓存里现成的内容，零等待；更新这件事在后台异步完成，最多就是某一个用户看到的内容晚了几秒。对内容页来说这点延迟完全可以接受。

不过光配 Cache-Control 还不够，内容真的改了怎么办？我后来更依赖按需失效（on-demand revalidation），在 CMS 发布内容时调一个 webhook 主动把对应路径的缓存打掉：

1// CMS 内容发布后触发，精确失效某个路径
2await fetch(`${SITE_URL}/api/revalidate`, {
3  method: 'POST',
4  headers: { 'x-secret': REVALIDATE_TOKEN },
5  body: JSON.stringify({ path: `/posts/${slug}` }),
6})

这样时间维度上靠 stale-while-revalidate 打底，事件维度上靠 webhook 精确失效，两条线一起用，既不会让用户等，也不会让编辑等太久看到自己改的内容。纯靠 TTL 过期我现在基本不用了，那个体验对内容运营同学太不友好。

但同样的策略放到权限页、订单页就可能出事。缓存不是越多越好，缓存错地方比不缓存更危险。还有一个容易被忽略的坑是缓存的 key——如果页面会根据 Cookie、地区或语言返回不同内容，但缓存键里没带这些维度，就会发生“A 用户的私有内容被缓存后发给了 B 用户”这种安全事故。所以凡是带个性化的响应，我要么明确 Cache-Control: private，要么把区分维度老老实实加进 Vary 或缓存键里，绝不让它走共享缓存。

Edge Runtime 的限制要提前看

另一个容易被忽略的点是运行时。

很多 Edge Runtime 不是完整 Node.js。文件系统、原生模块、部分 Node API、长时间任务、包体积、连接能力，都可能有限制。

迁移前我会查这些问题：

  • 是否依赖 fs、net、tls、child_process。
  • 是否依赖原生 npm 模块。
  • 是否需要访问内网服务。
  • 是否需要长连接或流式任务。
  • 是否有复杂加密、图片处理、文件生成逻辑。
  • 运行时间和包体积是否超限制。

这些限制不是缺点，而是 Edge 为了低延迟和快速启动做的取舍。真正的问题是你的业务代码适不适合这种取舍。

我见过一些讨论一开始只看“Edge 更快”，但一跑才发现依赖库用到了 Node 专属 API。最后不是不能改，而是改出来的成本已经超过了性能收益。

边缘真正值得做的，往往是那层薄逻辑

把 Edge 收窄到“轻、读多、可缓存”之后，我发现它反而有一类活干得特别漂亮，就是中间件级别的薄逻辑。请求还没到真正的渲染函数之前，先在边缘做一次判断：这个用户来自哪个地区、带没带登录态、要不要重定向、命中哪个灰度分桶。这类逻辑本身不碰数据库，只看请求头和 Cookie，天然适合放在离用户最近的一跳。

1// 边缘中间件：只做轻量分流，不碰中心数据
2export function middleware(request: Request) {
3  const country = request.headers.get('x-vercel-ip-country') ?? 'CN'
4  const url = new URL(request.url)
5
6  // 未登录用户访问后台，直接在边缘拦掉，不必回源
7  const hasSession = request.headers.get('cookie')?.includes('sid=')
8  if (url.pathname.startsWith('/admin') && !hasSession) {
9    return Response.redirect(new URL('/login', request.url))
10  }
11
12  // 按地区分发到不同的内容变体
13  if (country !== 'CN') {
14    url.pathname = `/intl${url.pathname}`
15    return Response.rewrite(url)
16  }
17}

这段逻辑的价值不在于“快了几毫秒”，而在于它把一部分本来要回源才能做的判断提前挡在了边缘。未登录访问后台的请求，根本没必要跑一趟中心服务再被拒。地区分流也一样，读一个请求头就能决定走哪个变体，比在渲染函数里再判断要省一整跳。

但这层薄逻辑也有它自己的坑。边缘中间件跑在每一个请求上，任何一点重活都会被放大——我见过有人在中间件里同步去调一个鉴权接口，结果每个请求都多挂了一次远程往返，本来想省的那一跳反而变成了新增的一跳。所以我给中间件定的规矩是：只读请求头和 Cookie，只做重定向、改写和分桶，绝不在里面发起会阻塞的远程调用。真要验签，也只验能在本地用密钥算出来的那种（比如 JWT 的签名校验），不去回源查库。

流式输出是边缘另一个真实场景

这两年 LLM 相关的功能多起来之后，Edge 还多了一个我原本没预料到的用途：流式响应。SSE 或者分块传输这种“边算边发”的场景，让首字节尽快到达用户比总耗时更重要，而边缘节点离用户近，正好能把这个首字节的延迟压下来。

1export const runtime = 'edge'
2
3export async function GET() {
4  const stream = new ReadableStream({
5    async start(controller) {
6      const encoder = new TextEncoder()
7      for await (const chunk of callUpstreamStream()) {
8        controller.enqueue(encoder.encode(`data: ${chunk}\n\n`))
9      }
10      controller.close()
11    },
12  })
13  return new Response(stream, {
14    headers: { 'content-type': 'text/event-stream' },
15  })
16}

这类场景边缘运行时反而比传统 Node 服务更顺手，因为它本来就是围绕 Request/Response 和 Web 流构建的。要注意的是流式响应和缓存基本互斥——一个逐字吐出来的响应没法整体缓存，所以别指望在这上面套 s-maxage。它优化的是“第一个字什么时候出现”，不是“整段内容什么时候能被复用”，这跟前面那些内容页的思路完全是两回事。

中后台项目不一定最先该上 Edge

这点和我的项目定位也有关。

复杂中后台的慢，很多时候不在网络边缘，而在这些地方：

  • 表格一次渲染太多数据。
  • 接口设计没有分页或聚合太重。
  • 权限、字典、配置接口串行请求。
  • 前端状态提升过度，交互重渲染。
  • 图表、导入、校验占用主线程。

这些问题上 Edge 解决不了。

如果一个后台系统主要用户都在同一区域，数据和服务也在同一区域，页面慢是因为接口慢或前端渲染重，那优先级应该是接口聚合、缓存、虚拟列表、交互性能，而不是边缘渲染。

Edge 更适合做入口层和内容分发，不应该拿来掩盖基础工程问题。

可观测性不能等上线后再补

Edge 出问题时，排查比中心服务更麻烦。

用户请求落在哪个节点？缓存有没有命中？回源耗时多少？边缘函数执行多久？哪个地区慢？错误来自源站、CDN、运行时，还是第三方接口？

如果没有日志，这类问题很难靠用户反馈定位。

我会至少记录这些字段：

1{
2  "requestId": "req_20250126_001",
3  "region": "sin1",
4  "cacheStatus": "MISS",
5  "edgeDuration": 24,
6  "originLatency": 180,
7  "status": 200
8}

这些信息不一定都展示给用户，但要能进入监控。否则“某些地区访问慢”只会变成一句无法行动的描述。

光有服务端这几个字段还不够，Edge 优化的本来就是用户侧体感，所以我会把真实用户的性能指标一起收上来对照。TTFB 只是首字节，用户实际感知的还有交互延迟。现在 INP 已经取代 FID 进了核心指标，我会在页面上采一份真实用户数据回传：

1// 采集真实用户的核心指标，和边缘日志对照着看
2import { onINP, onLCP, onTTFB } from 'web-vitals'
3
4function report(metric: { name: string; value: number }) {
5  navigator.sendBeacon('/api/rum', JSON.stringify({
6    name: metric.name,
7    value: Math.round(metric.value),
8    region: navigator.language,
9  }))
10}
11
12onTTFB(report)
13onLCP(report)
14onINP(report)

把这份 RUM 数据和边缘日志按地区拼起来，才能回答那个真正的问题：某个地区慢，到底慢在首字节（网络和回源），还是慢在渲染和交互（前端本身的事，跟跑不跑边缘没关系）。分不清这两者，很容易把一个前端渲染重的问题错怪到“没上 Edge”头上。

我现在的判断清单

决定要不要上 Edge 前，我会问自己：

  1. 用户是否真的跨地域分布？
  2. 当前瓶颈是否主要来自网络往返？
  3. 页面是否读多写少，适合缓存？
  4. 渲染逻辑是否轻量，依赖是否少？
  5. 数据源是否也在合理位置？
  6. 运行时限制是否接受？
  7. 出问题时是否能观测和回退？

如果前几个答案都不明确，我会先压住“上新技术”的冲动。

我现在仍然觉得 Edge 很值得关注。

它让内容、缓存和轻量逻辑更靠近用户，确实能改善一部分体验。但它不是万能加速器，也不是前端架构成熟的标志。

更成熟的判断应该是：先找到慢在哪里，再决定把什么放到哪里。页面跑在 Edge、Node、浏览器还是 CDN 后面，本质上都是为业务链路服务。链路想不清楚，位置换得再新也只是换一种复杂度。