活动页面打开慢，未必是商品接口出了问题：商品图片、页面脚本、样式表和字体文件若都从单一地区的源站加载，远距离用户会承受更高的网络延迟。电商大促期间静态资源的全球分发方案，重点是让资源靠近访客，同时确保发布、回滚和缓存更新可控。
先区分哪些资源适合缓存
先盘点页面实际加载的文件，而不是把整站一股脑设成长缓存。商品主图、活动横幅、图标、字体、CSS 和带版本号的 JavaScript 通常具有较好的缓存条件；购物车数量、库存和价格等动态信息则应由业务接口实时提供，不能因为放在同一页面就当作静态文件缓存。
建议为构建后的脚本和样式使用内容哈希文件名，例如 app.a81c2f.js。文件内容改变时生成新文件名，旧文件仍可由已有页面继续请求。商品图片可按实际更新节奏设置缓存周期；经常修改的活动图片应配合版本化路径或明确的刷新流程。
选择全球分发架构
使用 CDN 边缘节点
常见做法是把静态资源放在对象存储或源站，再通过 CDN 将副本缓存到不同地区的边缘节点。访客请求通常由网络调度到合适节点；节点未命中时回源取文件，后续请求可直接读取缓存。它适合地区分布广、流量有明显峰值的活动，但需要关注节点覆盖、回源带宽、HTTPS 配置、日志与服务商的故障切换能力。
多源站与单一源站
单一源站配合 CDN，维护较简单，适合资源可从一个稳定位置回源的团队；多地区源站或对象存储副本能缩短回源距离、增加冗余，但会增加同步、权限和一致性管理工作。若采用多源站，应先明确主副关系、健康检查方式和文件同步完成条件，避免某个地区拿到旧版本。
按资源类型设置缓存
| 资源 | 常见策略 | 注意事项 |
|---|---|---|
| 带内容哈希的 JS、CSS、字体 | 可设置较长的浏览器与 CDN 缓存周期，并使用 immutable | 发布时生成新文件名，保留旧文件一段时间 |
| 活动 HTML | 短缓存或要求重新验证 | 更新频繁时避免长时间展示旧页面 |
| 商品图片、活动横幅 | 依据更新频率设置缓存，必要时采用版本化路径 | 替换同名文件后要确认刷新范围 |
例如，版本化脚本可采用较长的 max-age 并设置 immutable；HTML 则可设较短的共享缓存时间，或使用 ETag 进行重新验证。具体周期要结合页面更新速度、浏览器行为和服务商配置确定，不能只靠一次全站清缓存解决版本问题。
大促前按步骤验证
- 整理资源清单：统计活动页会加载的图片、脚本、样式和字体，标出文件大小、更新频率与依赖关系。
- 配置分发与缓存：将静态文件接入 CDN，设置缓存规则、回源地址和 HTTPS；检查压缩、跨域需求及访问权限。
- 发布新版本：先上传带版本号的文件，再发布引用这些文件的 HTML，避免页面先上线却找不到资源。
- 模拟多地区访问：从目标地区检查 DNS 解析、首字节时间、下载耗时、缓存命中情况和错误率；用压测验证峰值下的回源能力。
- 准备回退：保留上一版 HTML 和资源，约定刷新缓存的对象与操作人，并记录回滚后的验证结果。
容量评估不要只看总带宽，可用“峰值请求速率 × 单次平均资源大小 × 缓存未命中比例”估算回源流量。结果只是规划参考，实际值受页面资源数量、用户设备缓存、访问分布及压缩效果影响。观察 CDN 缓存命中率、源站带宽、5xx 错误和各地区加载时间，才能判断瓶颈是在边缘、回源还是资源本身。
让更新和故障处理有边界
缓存刷新宜按具体文件或路径执行，并确认刷新状态；大促期间频繁全量刷新会把请求重新推向源站。若某区域访问异常，可先核对该区域的 DNS、边缘响应与回源错误，再按预案切换备用源站或调整调度。涉及用户数据的接口不要混入公共静态缓存规则。
归纳来说，电商大促期间静态资源的全球分发方案不是单纯增加节点，而是把版本管理、缓存策略、容量验证和回退流程一起设计。先让可缓存资源稳定命中边缘，再为动态业务保留清晰边界，才能兼顾多地区加载速度与活动期间的更新安全。
常见问题
图片替换后，用户为什么仍看到旧图？
浏览器或边缘节点可能仍保留旧缓存。使用新文件名或版本路径通常更可控；若必须沿用原路径，应按规则刷新对应资源并验证各地区结果。
所有静态资源都应该设置一年缓存吗？
不应该。长期缓存更适合内容哈希文件；活动 HTML 和可能原路径覆盖的图片，应依据更新频率使用短缓存、重新验证或版本化路径。
只有一个源站能做全球分发吗？
可以。CDN 能缓存边缘副本并减少重复回源，但源站故障时仍可能影响未命中请求。是否增加备用源站，取决于业务可用性要求和团队运维能力。
上线前最该检查什么？
重点检查新旧版本文件是否齐全、缓存规则是否匹配资源类型、主要地区能否访问，以及异常时能否回滚并确认缓存刷新。
