静态资源就近分发：边缘脚本的加速实践

公司应用的用户分布天南海北，主服务器在华东，西北和华南的用户打开应用，图片样式加载慢半拍，移动端尤为明显。这一年我们用内容分发网络加边缘脚本做了静态资源加速，全国访问速度拉平。这篇记录整个实践的思路、配置和效果。结论先说：静态资源加速的收益公式很简单——资源离用户越近，加载越快；而边缘脚本是加速器的变速箱，缓存命中率、回源流量、更新时效，全靠它在边缘调度。

一、加速前的体检

1.1 慢在哪：一次全链路测量

动手前先测量。用拨测工具从多地域模拟访问，数据说话：华东用户首屏一秒二，西北两秒八，华南两秒五——差着一倍多。拆解耗时：应用本身的接口响应各地差距不大，慢的大头在静态资源——图片、样式、脚本文件全部回源华东机房加载，物理距离摆在那里，一个两百毫秒起步的往返，几十个资源文件排队走，慢就慢出了积少成多。网络延迟这东西，单次不起眼，乘以请求次数再乘以用户数，就是一片可观的账。诊断结论：接口不用大动，静态资源分发必须改。测量先行这个习惯帮我们省下了冤枉钱——差点连接口层一起折腾，实际瓶颈根本不在那。

1.2 为什么静态资源适合分发

静态资源天生适合就近分发：内容不变——一张图标对华东用户和西北用户是同一张，天然可在各处缓存；读多写少——被访问成千上万次，源头只发布一次；容错高——静态资源加载失败刷新重试即可，不像交易请求那样娇贵。这三个特性意味着：把静态资源复制到离用户近的节点，体验提升立竿见影，风险几乎为零。改造的头一课：知道什么该分发，比知道怎么分发更重要。

二、分发的架构与配置

2.1 接入分发网络

改造动作：静态资源域名从应用主域拆出，独立资源域名接入内容分发网络，源站指向华东机房的静态资源服务。应用页面里所有静态资源引用改走新域名——这一步改动量不小，好在低代码平台的静态资源统一管理，改一处配置全局生效。拆独立域名的附带好处： Cookie 隔离——资源请求不再携带应用会话信息，请求体积小了，浏览器并发限制也松了绑。一个看似只是改名的小动作，收益是三层叠加的——基础设施的账，从来不能只算一行。

2.2 缓存策略分层

缓存策略是分发效率的灵魂，我们按资源类型分层配置：带哈希指纹的文件——构建产物文件名带内容哈希，内容变文件名就变——设置长缓存一年，放心大胆让浏览器和边缘节点都存住；不带指纹的文件——用户头像、动态生成的图片——短缓存一小时加协商缓存，改了能较快生效；完全动态的内容——不走分发，回源处理。分层的关键逻辑：缓存时长和更新机制配对设计——能长缓存的必然有办法换名字刷新，不能换名字的必须短缓存，两头堵死才不会出现改了不生效的尴尬。

2.3 边缘脚本：分发网络的变速箱

边缘脚本是运行在分发节点上的轻量逻辑，是这次实践的技术核心。我们用它做三件事。

// 边缘脚本: 请求改写与缓存控制
async function handle(req) {
  let url = new URL(req.url);
  // 1. 资源规范化: 去掉查询串里的追踪参数,提升缓存命中率
  for (const k of [...url.searchParams.keys()]) {
    if (k.startsWith('utm_') || k === 't') url.searchParams.delete(k);
  }
  // 2. 目录索引改写: /assets/js/ -> /assets/js/index.js
  if (url.pathname.endsWith('/')) url.pathname += 'index.js';

  let resp = await fetch(url, req);
  // 3. 响应头治理: 统一补充缓存头与安全头
  resp.headers.set('Cache-Control', 'public, max-age=31536000, immutable');
  resp.headers.set('X-Content-Type-Options', 'nosniff');
  return resp;
}

头一件事，请求规范化：不同页面引用资源时带的追踪参数、时间戳参数五花八门——同一个文件被当成十个不同地址，缓存命中率被无辜稀释。边缘脚本统一抹掉这些参数，缓存命中率立涨一成多。这个案例后来成了我们团队的内训教材：伤害缓存命中率的，往往不是配置，是那些自作聪明的参数。第二件，路径改写：资源目录的默认文件解析在边缘做掉，回源请求规整化。第三件，响应头治理：统一补充缓存头和安全头，不依赖源站配置的自觉——治理动作下沉到边缘，一处配置全网生效。

三、更新发布与缓存刷新

3.1 指纹命名：让刷新成为伪问题

静态资源更新的经典难题：缓存住了旧文件，改了新的用户还在看旧的。我们的解法是从根上绕开——构建时给文件名加内容指纹，logo 变了，文件名从 logo@a1b2 变成 logo@c3d4，页面引用新名字，边缘和浏览器自然去取新文件，旧缓存在过期前自然淘汰。指纹命名让缓存刷新从主动操作变成了被动结果——不需要刷新，因为地址本身就是新的。这是静态资源体系里优雅的一步棋。

3.2 主动刷新兜底

总有绕不开指纹的场景：动态生成的图片、第三方回源的文件、紧急修复的错误内容。这些走主动刷新：发布流程里挂了刷新钩子，变更清单自动提交分发网络的刷新接口，指定地址或目录预热——把新内容主动推到边缘节点。刷新是兜底手段，频次很低——指纹机制消化了九成九的更新，兜底只处理漏网的边角。

四、效果与成本

改造后的数字：全国首屏时间拉平到一秒五以内，西北用户从两秒八降到一秒四；缓存命中率稳定在九成五以上——边缘直接命中，回源流量降了一个量级；源站带宽压力骤减，机房出口流量曲线肉眼可见地平了。成本侧：分发网络按流量计费，每月成本比省下的源站带宽和用户体验收益，怎么算都划算。提速这件事，用户说不出技术细节，但手感的顺滑是骗不了人的。最意外的收获是稳定性——华东机房一次网络抖动，静态资源因边缘缓存几乎不受影响，用户只感觉接口慢了一点——分发网络顺手成了静态资源的高可用层——当初为速度做的设计，回头送了一份稳定性，工程里这种一鱼两吃的好事不多，遇到了要记下。

五、总结

静态资源就近分发的实践要点：静态与动态分域，独立资源域名接入分发网络；缓存分层配置——指纹文件长缓存，动态文件短缓存加协商；边缘脚本做变速箱——请求规范化提命中率，路径改写规整回源，响应头统一治理；指纹命名让更新自洽，主动刷新只做兜底。这套东西跑顺之后的心得：加速不是把同样的内容传得更快，是让内容根本不用跑那么远的路——架构上省下的距离，比带宽上挤出的速度更值钱。

常见问题

问:边缘脚本会不会成为新的故障点,挂了怎么办?

答:会有这个风险，防线三层：脚本逻辑保持纯函数化——只做改写和头治理，不依赖外部状态，出错概率低；灰度发布——新脚本先在一成流量上跑，观察错误率再全量；故障熔断——分发网络控制台支持一键停用脚本，请求退化为纯转发，资源照常加载，只是少了优化。上线三个月我们熔断过一次自己写错正则导致的改写异常，三分钟恢复——预案在，事故就只是事件。

问:低代码平台的静态资源能走自己的分发域名吗?

答:看平台开放程度，主流路径两条：平台支持自定义资源域名——在配置里把资源访问域名换成自己的分发域名，平台发布时自动同步资源过去；平台只支持外链资源——把图片样式等静态资产放自己的对象存储加分发，应用里用外链引用。我们用的平台走头一条路，配置十分钟。改造前先确认这一点，选型时也建议把静态资源的域名可配置性列入考量。

问:缓存命中率怎么持续监控,掉了怎么排查?

答:分发网络控制台看命中率曲线，正常稳在九成以上；掉了按三步排查：查请求规范化——是不是新版本带了新参数，缓存键被稀释；查缓存头配置——是不是某些路径漏配了缓存策略，回源比例升高；查流量结构——是不是新增了大量不可缓存的动态请求混进了资源域名。我们把命中率纳入日常巡检指标，阈值告警——命中率是分发体系的体温计，天天看，病苗一冒头就治。

问:动态内容和小文件,也适合分发网络吗?

答:分情况。动态内容——接口返回、个性化数据——分发网络只能做传输加速，缓存帮不上忙，收益有限，除非跨地域延迟特别痛，否则优先优化接口本身。小文件——图标、样式碎片——适合分发但不适合零散引用：几十个零碎请求的握手开销比传输本身还贵，先用打包合并减少请求数，再上分发锦上添花。分发网络是放大器，请求结构合理它放大的是速度，结构臃肿它放大的是混乱。