实战SOP:CodeArts操作EdgeOne Functions,轻量边缘函数

背景:把逻辑挪到离用户最近的地方

有个很常见的尴尬:你的服务部署在一台源站上,北方的用户点一下按钮,请求要跑一千多公里才有人接;等响应回来,几百毫秒已经过去了。而真正要做的事情——判断 UA、校验签名、决定回源还是重定向、把结果拼一下——往往只有几十行代码,根本不需要跑在源站。

边缘函数就是为这个场景准备的:它把逻辑部署到 CDN 的边缘节点上,请求在离用户最近的节点执行,响应不用绕回中心机房。腾讯云 EdgeOne 的边缘函数(edge-functions)属于轻量档:Web 标准的 Request/Response 模型、按请求计费、上手门槛低,特别适合分流、鉴权、防盗链、短链这类"短、快、无状态"的逻辑。

这次我把部署流程交给码道 CodeArts:从定事件契约、写 handler,到建函数、配匹配规则、发布验证,一趟跑完。

方案:五步上线一个边缘函数

1. 先定契约。 边缘函数的契约比云函数更简单:哪个域名的哪些路径进来、函数看到什么(请求方法、头、查询参数)、返回什么(响应体、状态码、额外头)。CodeArts 让我把这些写成一句话:“对 /api/* 的请求,按 A/B 分流打标后回源,并回传分流标记头”。

2. 写 handler(Web 标准 API,不依赖 Node 内置模块):

// index.js —— 边缘函数示意:按 A/B 分流打标后回源
export default async function onRequest(context) {
  const { request } = context;
  const url = new URL(request.url);

  // 分流:优先读外部标记,否则随机
  const bucket = request.headers.get("x-ab") || (Math.random() < 0.5 ? "a" : "b");

  // 回源,并把分流标记带给源站
  const upstream = await fetch(url.toString(), {
    method: request.method,
    headers: { ...Object.fromEntries(request.headers), "x-bucket": bucket },
  });

  // 复制响应,追加边缘标记
  const res = new Response(upstream.body, upstream);
  res.headers.set("x-edge-bucket", bucket);
  res.headers.set("cache-control", "public, max-age=30");
  return res;
}

这段代码里没有任何 Node API——fetch、URL、Response 都是 Web 标准,边缘运行时只认这些。

3. 校验。 CodeArts 会检查两件事:代码里有没有 require("fs") 这类边缘环境不存在的模块;依赖能不能被静态打包(边缘函数是单文件部署,不能带 node_modules 目录)。这一关拦住的问题,比上线后再排查省事得多。

4. 部署。 在 EdgeOne 控制台创建边缘函数,把打包后的代码上传,然后配匹配规则:站点域名 + 路径模式(如 /api/*)、执行时机(请求前/回源后)、优先级。规则是"发布"制——改完要显式发布,不发布会一直用旧版本。

5. 验证。 用一次真实请求看响应头里有没有 x-edge-bucket,再对比源站日志里有没有收到 x-bucket。边缘函数最典型的坑是"配好了但没生效",原因几乎都是匹配规则没命中(路径模式写错、域名不在站点里、规则优先级被覆盖)。

实践要点

1. 边缘运行时是受限 JS 环境。 没有 fs、net、child_process,很多 npm 包直接不能用。判断标准很简单:依赖里只要出现 Node 内置模块,就得换实现或换到云函数。写代码时把"只依赖 Web 标准"当成硬约束。
2. 函数是无状态的,全局变量不可靠。 边缘实例随时创建、随时回收,同一个用户两次请求可能落在不同节点。计数、会话、限流状态必须放平台存储或外部服务,不能塞进模块级变量。
3. 响应体大小和执行时长都有上限。 边缘函数适合"轻加工",适合把大文件聚合、图片转码这类重活放边缘的话,很快就会撞上限。超过就老老实实回源。
4. 缓存是双刃剑。 给响应加 public, max-age 之前先想清楚:这个响应是否因人而异?带用户维度的内容一旦被公共缓存,别人就能刷到别人的数据。调试期用 no-store 或加唯一查询参数,别让缓存掩盖问题。
5. 一定要有回源兜底。 边缘函数超时或异常时,请求应该能降级回源站,而不是直接返回错误。函数里对 fetch 做 try/catch,极端情况下返回一个"让请求通过"的响应。
6. 先小流量,再全量。 新规则先在测试域名或少量路径上验证,确认响应头、缓存命中、源站行为都对,再放开匹配范围。边缘规则的出错半径很大——一条错规则可能让整个站点的 API 都挂掉。
7. 计费看请求数,也看内部请求。 边缘函数按调用和执行时长计费,函数里自己发起的回源请求也会产生流量与请求。做分流实验时,别让"一次用户请求触发三次内部请求"的写法悄悄把账单翻上去。

小结

边缘函数的价值不是"又一个云函数",而是补上延迟这一层:把几十行判断逻辑挪到用户旁边,源站只处理真正需要中心化的事情。它的边界也很清楚——轻、短、无状态、可降级。想清楚哪些逻辑属于边缘、哪些必须回源,这套东西就是免费的性能提升。

对个人项目,它甚至比云函数更划算:没有冷启动焦虑,没有服务器要维护,写一个 handler 配一条规则,分流、鉴权、防盗链就都有了。轻量的东西,用在轻量的位置上,才是它最好的用法。