前端项目上线这件事看起来简单无非就是把打包好的文件扔到服务器上。但等你真正折腾过几回就会发现里面全是细节服务器带宽就那么点图片和脚本一多加载直接卡成幻灯片改了几行代码重新部署用户那边死活加载不到新版本一问全是缓存遇到访问量稍微上来点一台机器扛不住还得考虑扩容、负载均衡……这些问题单靠一台 Web 服务器是越来越难招架了。我这边现在接手的前端静态资源部署基本都走阿里云 OSS CDN 这套组合。把静态文件放进对象存储再挂上 CDN 加速带宽成本降下来了访问速度上去了缓存问题也可控了。这篇就把我实操中总结的完整部署流程、配置参数、以及各种踩坑经验一次讲清楚适合刚准备把前端项目从服务器迁到 OSS、或者已经在用但总遇到奇怪问题的小伙伴参考。1. 为什么选择 OSS CDN 这套组合1.1 传统服务器部署方式的瓶颈在哪早年间做前端部署最常见的就是把dist文件夹整个扔到 Nginx 或者 Apache 的 web 目录里。这种方式在小流量阶段没什么毛病但等你的站点有了点规模问题就一个个冒出来了。首先是带宽成本。一张图片几百 KB一个 JS 文件 1-2MB如果一百个人同时访问那瞬时带宽占用非常吓人。为了应对峰值流量你得买高配带宽但低峰期这些带宽又闲着纯纯浪费钱。其次是并发能力单台服务器的连接数是有上限的尤其是 Nginx 默认的 worker_connections 也就 1024 左右一旦访问量上来就有一部分用户会看到连接被重置。再有就是缓存问题你可以配置 Nginx 的expires指令来让浏览器缓存静态文件但用户分布在不同地区网络链路千差万别单点服务器的访问速度完全取决于用户到服务器的物理距离和运营商路由质量。OSS 解决了存储问题它不限制并发连接数也不占用你的服务器资源按量付费存储成本低得惊人。CDN 则解决传输问题它在全国乃至全球部署了大量边缘节点用户就近从边缘节点拉取文件速度自然就上来了。两者配合等于把“存储”和“传输”这两件事都从你的应用服务器上剥离了。1.2 OSS 和 CDN 各自扮演什么角色要理解这套架构得先捋清楚 OSS 和 CDN 的分工。OSS 是阿里云的对象存储服务你可以把它想象成一个无限容量的文件仓库。前端打包出来的 html、js、css、png、fonts 这些文件上传到 OSS 的 Bucket存储空间里每个文件都有一个对应的 URL。OSS 本身也支持直接通过域名访问文件所以如果你的项目对速度不敏感或者访问量极小只接 OSS 其实也能跑。但 OSS 的默认域名是带 Bucket 名的不美观而且跨域和缓存配置相对受限。CDN 则在 OSS 前面加了一层“加速罩”。当用户请求你的静态资源时请求会先被调度到离用户最近的 CDN 边缘节点。如果这个节点上已经有缓存直接返回没有缓存CDN 节点会回源到 OSS 拉取文件然后缓存在本地再返回给用户。这样一来后续相同地区的用户请求同一资源就直接命中边缘节点缓存不再需要回源 OSS 了。这套组合里还有个很实际的收益CDN 的边缘节点带宽是海量的它替你的源站扛住了所有流量压力。你只需要按 CDN 的实际流量付费单价远低于你自建服务器扛峰值流量。我经手的一个项目原来部署在 4 台 ECS 上迁移到 OSS CDN 之后ECS 直接降到 1 台跑后端接口每月带宽成本省了差不多六成。2. 部署前的准备权限、Bucket 与域名规划2.1 RAM 子账号权限该怎么给才安全很多人刚开始用阿里云图省事直接拿主账号的 AccessKey 去配置工具这是很大的隐患。主账号拥有账号下所有资源的完全权限一旦 Key 泄露别人可以把你整个云账号的资源都删了。我在一开始就养成了一个习惯为静态资源部署单独建一个 RAM 子账号只授予 OSS 相关权限。在 RAM 控制台里创建用户时记得选择“编程访问”这样会生成 AccessKey ID 和 AccessKey Secret这两个值要保存好后面配置 ossutil、PicGo 或者 CI 工具都要用。权限方面我建议用自定义策略而不是直接给系统策略。系统策略AliyunOSSFullAccess太大了子账号拿到它可以操作你账号下所有 Bucket。你可以创建一个策略限定只允许管理某个特定 Bucket{ Version: 1, Statement: [ { Effect: Allow, Action: oss:GetObject, Resource: acs:oss:*:*:your-bucket-name/* }, { Effect: Allow, Action: oss:PutObject, Resource: acs:oss:*:*:your-bucket-name/* }, { Effect: Allow, Action: oss:DeleteObject, Resource: acs:oss:*:*:your-bucket-name/* }, { Effect: Allow, Action: oss:ListObjects, Resource: acs:oss:*:*:your-bucket-name } ] }your-bucket-name替换成你实际创建的 Bucket 名即可。这样即使 Key 泄露影响范围也被控制在一个 Bucket 内。2.2 Bucket 创建时的几个关键选择创建 Bucket 的位置在 OSS 控制台点“创建 Bucket”。里面有几个选项会在后续影响部署得提前想清楚。一是地域选择。理论上 Bucket 地域和你的 CDN 加速区域没有强绑定关系CDN 回源是走阿里云内网的。但为了回源延迟尽可能低我建议还是选择离你的源站或者主要用户群体近的地域。比如主要面向国内用户华东 1杭州、华东 2上海都是不错的选择我这边为了配合后端 ECS 的地域一般选华东 2。二是读写权限。这里有个常见的理解误区很多人为了能在浏览器里直接访问 OSS 上的文件把 Bucket 设成“公共读”。这么做确实省事但你这相当于把你整个文件仓库的大门敞开了任何人知道 URL 就能读文件而且如果不挂 CDN 直接用 OSS 域名流量费用会随着访问量上升不可控。我的建议是 Bucket 权限保持“私有”然后通过 CDN 来对外提供服务。CDN 回源 OSS 时如果配置了私有 Bucket 回源阿里云会通过内部机制授予 CDN 权限外部用户依然只能通过 CDN 域名访问无法直接访问 OSS 源站。这个配置在 CDN 控制台添加加速域名时有一个开关后面我会细讲。三是版本控制。如果你的 Bucket 是用来放前端构建产物的我建议关闭版本控制。前端项目更新频繁旧版本文件没必要保留开启版本控制会持续产生存储费用。但如果你想时不时回滚到某个历史版本可以保留费用也不算高看你自己权衡。2.3 域名规划一个域名用于 CDN 加速接入 CDN 之前要先规划好域名。这里强烈建议单独准备一个 CDN 专用域名而不是直接拿你的主域名来加速。因为你后面会配置缓存规则、CNAME 解析等如果 CDN 域名就是主域名万一配置文件里有问题影响的就是整个站点。常见的做法是用一个二级域名比如static.yourdomain.com这个域名专门负责承载前端静态资源主域名继续指向你的应用服务器。这样当后端接口和静态资源需要不同的缓存策略时配置起来各不干扰。同时你需要对这个 CDN 专用域名在 DNS 服务商处做好准备因为在 CDN 控制台添加完加速域名后会得到一个 CNAME 地址你需要去 DNS 处解析一条 CNAME 记录指向这个地址CDN 才能真正生效。这个流程在后面会具体操作。3. 从零到一的完整部署流程3.1 创建 Bucket 并完成基础配置打开阿里云 OSS 控制台点击“创建 Bucket”。Bucket 名称全局唯一我一般用项目名加环境标识比如web-ops-prod。地域按上一步的分析选择。读写权限选择“私有”。其余选项可以保持默认但是“服务端加密”如果你对静态资源没有加密需求可以不开启免得增加额外的处理开销。创建完成后进入 Bucket 的“基础设置”和“权限管理”页面有几个配置建议顺手做掉。一个是“跨域设置”如果你的前端页面部署在一个域名而 API 请求指向另一个域名或者你的页面用字体文件、Canvas 绘图这些涉及到跨域读取 OSS 文件的场景CORS 规则必须配置。另一个是“静态网站托管”如果你的 Bucket 主要用来存放纯前端项目而且你希望通过 OSS 直接访问首页可以在“基础设置”里开启静态页面托管默认首页设为index.html。但注意当你挂了 CDN 之后CDN 域名访问的时候CDN 是否透传这个配置取决于 CDN 侧的“回源方式”设置后面会说到。3.2 上传文件控制台、ossutil 与 CI 集成怎么选上传文件的方式有几种适用场景不同。如果你只是临时手动更新一两个文件直接在 OSS 控制台里选择文件上传就行。这种方式的缺点是无法同步目录结构一次上传一堆文件时非常低效。如果你有大量文件要同步推荐使用阿里云官方命令行工具 ossutil。下载后配置好 AccessKey运行同步命令ossutil cp -r ./dist/ oss://your-bucket-name/ --update--update参数的意思是只上传比 Bucket 里更新的文件可以加快增量发布的速度。首次全量上传时也可以不加这个参数。如果你的构建机器是 Linux还可以配合 CI 工具比如在代码仓库的流水线里加上一步构建完项目后自动执行 ossutil 同步命令这样你每次 push 代码静态资源就自动发布到 OSS 了。我做项目的时候遇到过前后端一体的仓库前端打包完 push 到 OSS后端走 ECS 上的发布脚本流水线一打通整个发布过程基本不需要人工参与。还有一个高阶用法是给上传设置 Content-Type。前端文件的类型很重要如果 JS 文件被识别成了application/octet-stream浏览器可能直接下载而不是执行页面就会白屏。ossutil 默认会根据文件后缀自动判断 Content-Type如果你用了 CDNCDN 回源时也会读取 OSS 上这个元数据。出问题时可以用下面的命令检查单个文件的头信息ossutil head oss://your-bucket-name/assets/index.js3.3 添加 CDN 加速域名一步步配置CDN 的配置是整个部署的重头戏。登录阿里云 CDN 控制台选择“域名管理”点击“添加域名”。加速域名填static.yourdomain.com业务类型这里我选“图片小文件”因为前端项目里大部分是图片、样式、脚本这类资源。如果你的项目里有大视频切片才需要考虑“大文件下载”或“视音频点播”。源站类型选择“OSS 域名”然后在下方选择你之前创建好的 Bucket。这里注意源站域名要填 OSS 的默认域名也就是your-bucket-name.oss-cn-region.aliyuncs.com这种格式而不是你自己绑定的自定义域名否则回源配置会绕弯路。端口默认 80/443 都勾上后面让你配置 HTTPS 证书的时候会用到 443。点击下一步会让你设置回源配置。这里有一个关键开关“私网回源”。如果你的 Bucket 是私有读必须开启“私网回源”并选择相应的授权方式。阿里云会让 CDN 通过一个内部服务角色去访问 OSS不消耗公网流量而且不用把 Bucket 改成公开。这一步配置错了后面的访问就会 403。添加完成后CDN 控制台会给出一个 CNAME 地址你需要去域名 DNS 服务商处添加一条 CNAME 记录。比如你的 CDN 域名是static.yourdomain.comCNAME 指向yourdomain.w.cdngslb.com。DNS 解析生效后访问static.yourdomain.com才会真正走 CDN。一般几分钟到几十分钟生效可以稍后再验证。3.4 HTTPS 证书配置为什么建议强制跳转现在部署静态资源HTTPS 基本是标配。CDN 控制台里在“域名管理”中找到你的加速域名进入“HTTPS 配置”你可以在阿里云数字证书管理服务里申请免费证书也可以上传自有证书。配置好证书后强烈建议开启“强制 HTTPS 跳转”把 HTTP 的请求都 301 到 HTTPS 上。这么做的好处不只是安全性。有些混用 HTTP/HTTPS 的场景下浏览器会拦截混入的 HTTP 请求导致字体、图片加载不出来。全站 HTTPS 之后这类问题基本就没了。如果你的页面里引用的接口是 HTTP 的那另当别论但静态资源服务本身建议全 HTTPS。另外在“HTTPS 配置”里还可以开启“HTTP/2”HTTP/2 的多路复用特性对于加载几十个前端小文件有明显的速度提升建议直接打开边缘节点和浏览器都支持的话默认就能跑。4. 上线后的核心优化缓存、回源与安全配置4.1 缓存配置是决定“改了代码不生效”还是“资源加载飞快”的分水岭缓存配置是我在做部署方案时最关注的环节因为它直接决定用户拿到的到底是新版本还是旧版本也决定了 CDN 回源频次。在 CDN 控制台的“缓存配置”里可以设置不同路径的缓存 TTL单位是秒。我的经验是分成两类来处理HTML 文件缓存时间要短建议 0 到 60 秒。因为 HTML 是入口文件它内部引用的 JS/CSS 文件名如果带 hash发布后路径就变了只需让 HTML 尽快回源拿到最新入口就能保证用户加载到新版资源。静态资源JS、CSS、图片、字体这些文件文件名里通常带内容 hash比如app.a1b2c3.js这类文件一旦发布就不可变可以放心设置最长缓存比如 30 天甚至 1 年。CDN 和浏览器都会把这类资源缓存住用户二次访问几乎零延迟。具体在阿里云 CDN 控制台“缓存配置”里添加两条规则路径缓存生效优先级.html60 秒高.js.css.png.jpg.woff2.svg30 天中注意CDN 的缓存规则匹配优先级是“先精确后模糊”所以你还可以通过路径前缀比如/assets/这样的方式做更细的控制。我实测下来前端资源如果 hash 命名规范设置 30 天缓存后CDN 命中率可以做到 95% 以上回源请求非常少费用自然就降下来了。4.2 版本管理发布新版时如何保证用户能拿到最新文件可能有朋友问既然 JS/CSS 设置了 30 天缓存那发布新版本时用户还得等 30 天吗这就要靠前端构建工具的 hash 命名了。以 Vue 或 React 项目为例打包输出文件名通常是index.b8b3f0.js这种带 hash 的格式每次文件内容变了hash 就变文件名也跟着变。HTML 继续引用的新文件名由于 HTML 缓存时间很短回源后拿到的是新入口从而加载新的 JS/CSS。老文件会继续存在 CDN 节点上直到过期或被清理。这正好是我前面 4.1 节设置短 HTML、长静态资源缓存的基础。如果你发布后想立即让新版本生效也可以使用 CDN 控制台的“刷新预热”功能。把需要刷新的目录填进去比如https://static.yourdomain.com/assets/或者精确到某个 HTML 文件提交刷新任务后 CDN 节点会主动回源更新缓存。不过刷新操作有配额限制一天内的刷新条数有限建议只在紧急发版时使用日常发布靠短 HTML 缓存就够了。4.3 防盗链与访问控制不能省你的站点一旦有了流量白嫖的人也来了。最典型的是图片盗链别人网站的 HTML 里直接引用你的图片地址加载时走的是你的 CDN 流量你替他掏钱。在 CDN 控制台的“访问控制”里可以配置 Referer 防盗链。设置“白名单”只允许你自己的域名以及可能用到资源的可信域名来引用资源。这里我踩过一个坑只填了主域名yourdomain.com结果发现 HTTP 和 HTTPS 混用时会因为 Referer 带http://和https://前缀不同而失效所以白名单里尽量把两种协议都写上。更进一步可以使用阿里云提供的鉴权配置给 CDN 资源加上时间戳签名。URL 中带上过期时间和签名只有生成正确签名的请求才能访问有效防止他人绕过 Referer 直接下载资源。签名算法不难阿里云控制台会自动生成样例代码照着改写即可。4.4 跨域配置前端页面跨域读取文件时的心头大患本来 OSS 和 CDN 都是服务静态资源的很少涉及跨域问题。但你只要在前端代码里通过 XHR 或 Fetch 请求这些静态资源或者用Web Font加载字体或者用 Canvas 绘制图片就会遇到浏览器跨域校验。比如你的站点在www.yourdomain.com而资源在static.yourdomain.com这已经是不同源了。浏览器在发起资源请求前对于非简单请求会先发送一个OPTIONS预检请求如果服务器返回的 CORS 头不对请求就会失败。配置的位置有两处OSS 的“跨域设置”和 CDN 的“回源 HTTP 头”。我建议先配 OSS。进入 OSS 控制台找到你的 Bucket点“数据安全”-“跨域设置”创建一条规则来源填https://www.yourdomain.com允许 Methods 填 GET、HEAD、OPTIONSAllowed Headers 填*暴露 Headers 填ETag缓存时间随便填个 600。如果 CDN 开启了自定义回源 Header 透传CORS 头就可以由 CDN 直接生成但多数场景下源站 OSS 配好 CORS 就够了CDN 回源时会原样带回来。5. 踩坑实录常见问题与排查技巧速查5.1 为什么配置了 CDN 域名访问还是出现 403403 错误在实际部署里出现频率相当高。如果是刚配置完 CDN最可能的原因就是 Bucket 权限和 CDN 回源授权不匹配。前面我强调过私有 Bucket 必须开启 CDN 的“私网回源”。如果你没开这个开关CDN 回源时拿不到权限用户自然就 403。还有一种情况你给 CDN 配置了源站域名但这个源站域名填的是 Bucket 自定义域名而不是 OSS 默认域名。自定义域名若要作为回源地址要求该域名已经绑定 Bucket 并且 Bucket 权限允许访问。为了避免这类问题我建议统一用 OSS 默认域名做 CDN 源站。排查顺序可以参考下面几步首先打开 CDN 控制台看加速域名是否“正常运行”。看 CDN 日志或 OSS 访问日志确认回源状态码。如果状态码是 403去 OSS 控制台看 Bucket 权限和 CDN 回源授权的状态。如果是 404大概率是路径没对上检查你的 HTML 里引用的资源路径和 Bucket 里的实际目录结构。5.2 改了代码但浏览器和 CDN 都还是旧资源这种问题简直属于“发布三连”。通常原因在于 HTML 文件被缓存了。很多人设置全局缓存 30 天结果 HTML 也被缓存了发布后用户刷新页面拿到的还是旧 HTML自然加载的还是旧资源。要解决除了前面说的 HTML 单独短缓存之外还有一个非常硬的技巧在 HTML 里引用的 JS/CSS 路径不变的情况下可以使用 CDN 控制台的“刷新预热”指定刷新 HTML 文件。但更稳妥的做法是让你的 CI 脚本在发布的时候顺便调用一下 CDN 刷新接口只刷新首页或入口 HTML。这样发布后几分钟内新用户就能拿到最新版本。从源头避免这个问题我在项目里还会加一个配置CDN 缓存键Cache Key忽略参数意思是不管 URL 后面带不带查询参数都会命中同一份缓存。如果你在 HTML 里给 JS 路径加了?v123这种版本号参数而 CDN 缓存键做成“保留参数”模式那同样路径不同参数的请求会多次回源绕过了 hash 文件名的意义。这里我把缓存键设置为“忽略全部参数”配合原文 hash 命名效果很好。5.3 明明配置了 CORS跨域请求还是报错这个问题我在字体加载的场景里遇到过。前端页面上用了 Google Font 类似的字体方案但字体文件放在 static 域名下。按理说 OSS 配置了 CORS 就能放行但实测仍然报跨域错误。排查后发现CDN 节点会在某些情况下改写或丢弃 CORS 相关的响应头。如果你使用的是 CDN 控制台可以在“回源配置”里找到“回源 HTTP 头”把Access-Control-Allow-Origin设置成你的站点域名。同时确认 CDN 配置中没有开启“压缩”功能对跨域头产生副作用。按这个顺序排查一般 10 分钟内能定位问题。另外注意字体文件请求一般属于简单请求不会发预检所以只需要响应头里有Access-Control-Allow-Origin即可。而通过 XHR 提交复杂的 JSON 请求才需要处理OPTIONS预检逻辑。5.4 资源加载耗时还是长怎么确定 CDN 是否真的生效在浏览器 DevTools 里打开 Network 面板点击任意一个静态资源在 Headers 里查看「Response Headers」。如果看到Via: cache或者X-Cache: HIT这样的字段说明命中了 CDN 缓存。阿里云 CDN 返回节点的缓存状态可以在响应头上看比如X-Cache是HIT TCP_MEM_HIT就表示边缘节点内存命中。如果每个文件都是MISS说明 CDN 节点还没缓存需要预热或者你的缓存配置有问题。判断 CDN 是否生效还有一个简单办法使用在线工具测试不同地区的解析结果看域名解析到的 IP 是不是遍布各地。如果所有地区解析到同一个 IP那说明 CNAME 没有完全生效或者某个区域的 Local DNS 有缓存等等。我自己常用的流程是部署完先通过浏览器访问一遍页面确认所有资源都能加载然后用 curl 测试一个具体文件观察响应头里的缓存命中状态最后再通过新页面访问确认 HTML 缓存策略生效。整套验证下来基本可以把上面提到的坑都排查干净。实际操作中的一点体会这套 OSS CDN 方案我前后在不同项目上用过不少次最直观的感受是成本可控、性能稳定、维护成本低。唯一要上心的就是前面反复提到的缓存策略和权限配置。许多团队部署完以后觉得“为什么和别人用的效果不一样”十有八次都是私有 Bucket 的回源授权没开对或者 HTML 被长时间缓存导致发版不生效。我现在把发布流程做成了一条标准的流水线本地构建好dist目录后直接扫描一遍文件类型按规则设好 Content-Type再通过 ossutil 同步上去然后触发 CDN 刷新入口 HTML。整个过程不需要登录控制台也不用人工干预稳定性提升非常明显。如果你们团队正打算把前端静态资源迁到云上或者已经在云上但还在和缓存、跨域、费用这些问题搏斗希望这篇实操记录可以帮你省掉几天的排查时间。按这个思路先把最基础的部署跑通再逐步加缓存规则、鉴权配置和自动化发布后续维护就能轻松很多。 
长河君 · 2026/10/15 15:00:07 · 阅读 1.2k 前端项目上云：OSS+CDN部署完整流程与踩坑总结
前端项目上线这件事看起来简单无非就是把打包好的文件扔到服务器上。但等你真正折腾过几回就会发现里面全是细节服务器带宽就那么点图片和脚本一多加载直接卡成幻灯片改了几行代码重新部署用户那边死活加载不到新版本一问全是缓存遇到访问量稍微上来点一台机器扛不住还得考虑扩容、负载均衡……这些问题单靠一台 Web 服务器是越来越难招架了。我这边现在接手的前端静态资源部署基本都走阿里云 OSS CDN 这套组合。把静态文件放进对象存储再挂上 CDN 加速带宽成本降下来了访问速度上去了缓存问题也可控了。这篇就把我实操中总结的完整部署流程、配置参数、以及各种踩坑经验一次讲清楚适合刚准备把前端项目从服务器迁到 OSS、或者已经在用但总遇到奇怪问题的小伙伴参考。1. 为什么选择 OSS CDN 这套组合1.1 传统服务器部署方式的瓶颈在哪早年间做前端部署最常见的就是把dist文件夹整个扔到 Nginx 或者 Apache 的 web 目录里。这种方式在小流量阶段没什么毛病但等你的站点有了点规模问题就一个个冒出来了。首先是带宽成本。一张图片几百 KB一个 JS 文件 1-2MB如果一百个人同时访问那瞬时带宽占用非常吓人。为了应对峰值流量你得买高配带宽但低峰期这些带宽又闲着纯纯浪费钱。其次是并发能力单台服务器的连接数是有上限的尤其是 Nginx 默认的 worker_connections 也就 1024 左右一旦访问量上来就有一部分用户会看到连接被重置。再有就是缓存问题你可以配置 Nginx 的expires指令来让浏览器缓存静态文件但用户分布在不同地区网络链路千差万别单点服务器的访问速度完全取决于用户到服务器的物理距离和运营商路由质量。OSS 解决了存储问题它不限制并发连接数也不占用你的服务器资源按量付费存储成本低得惊人。CDN 则解决传输问题它在全国乃至全球部署了大量边缘节点用户就近从边缘节点拉取文件速度自然就上来了。两者配合等于把“存储”和“传输”这两件事都从你的应用服务器上剥离了。1.2 OSS 和 CDN 各自扮演什么角色要理解这套架构得先捋清楚 OSS 和 CDN 的分工。OSS 是阿里云的对象存储服务你可以把它想象成一个无限容量的文件仓库。前端打包出来的 html、js、css、png、fonts 这些文件上传到 OSS 的 Bucket存储空间里每个文件都有一个对应的 URL。OSS 本身也支持直接通过域名访问文件所以如果你的项目对速度不敏感或者访问量极小只接 OSS 其实也能跑。但 OSS 的默认域名是带 Bucket 名的不美观而且跨域和缓存配置相对受限。CDN 则在 OSS 前面加了一层“加速罩”。当用户请求你的静态资源时请求会先被调度到离用户最近的 CDN 边缘节点。如果这个节点上已经有缓存直接返回没有缓存CDN 节点会回源到 OSS 拉取文件然后缓存在本地再返回给用户。这样一来后续相同地区的用户请求同一资源就直接命中边缘节点缓存不再需要回源 OSS 了。这套组合里还有个很实际的收益CDN 的边缘节点带宽是海量的它替你的源站扛住了所有流量压力。你只需要按 CDN 的实际流量付费单价远低于你自建服务器扛峰值流量。我经手的一个项目原来部署在 4 台 ECS 上迁移到 OSS CDN 之后ECS 直接降到 1 台跑后端接口每月带宽成本省了差不多六成。2. 部署前的准备权限、Bucket 与域名规划2.1 RAM 子账号权限该怎么给才安全很多人刚开始用阿里云图省事直接拿主账号的 AccessKey 去配置工具这是很大的隐患。主账号拥有账号下所有资源的完全权限一旦 Key 泄露别人可以把你整个云账号的资源都删了。我在一开始就养成了一个习惯为静态资源部署单独建一个 RAM 子账号只授予 OSS 相关权限。在 RAM 控制台里创建用户时记得选择“编程访问”这样会生成 AccessKey ID 和 AccessKey Secret这两个值要保存好后面配置 ossutil、PicGo 或者 CI 工具都要用。权限方面我建议用自定义策略而不是直接给系统策略。系统策略AliyunOSSFullAccess太大了子账号拿到它可以操作你账号下所有 Bucket。你可以创建一个策略限定只允许管理某个特定 Bucket{ Version: 1, Statement: [ { Effect: Allow, Action: oss:GetObject, Resource: acs:oss:*:*:your-bucket-name/* }, { Effect: Allow, Action: oss:PutObject, Resource: acs:oss:*:*:your-bucket-name/* }, { Effect: Allow, Action: oss:DeleteObject, Resource: acs:oss:*:*:your-bucket-name/* }, { Effect: Allow, Action: oss:ListObjects, Resource: acs:oss:*:*:your-bucket-name } ] }your-bucket-name替换成你实际创建的 Bucket 名即可。这样即使 Key 泄露影响范围也被控制在一个 Bucket 内。2.2 Bucket 创建时的几个关键选择创建 Bucket 的位置在 OSS 控制台点“创建 Bucket”。里面有几个选项会在后续影响部署得提前想清楚。一是地域选择。理论上 Bucket 地域和你的 CDN 加速区域没有强绑定关系CDN 回源是走阿里云内网的。但为了回源延迟尽可能低我建议还是选择离你的源站或者主要用户群体近的地域。比如主要面向国内用户华东 1杭州、华东 2上海都是不错的选择我这边为了配合后端 ECS 的地域一般选华东 2。二是读写权限。这里有个常见的理解误区很多人为了能在浏览器里直接访问 OSS 上的文件把 Bucket 设成“公共读”。这么做确实省事但你这相当于把你整个文件仓库的大门敞开了任何人知道 URL 就能读文件而且如果不挂 CDN 直接用 OSS 域名流量费用会随着访问量上升不可控。我的建议是 Bucket 权限保持“私有”然后通过 CDN 来对外提供服务。CDN 回源 OSS 时如果配置了私有 Bucket 回源阿里云会通过内部机制授予 CDN 权限外部用户依然只能通过 CDN 域名访问无法直接访问 OSS 源站。这个配置在 CDN 控制台添加加速域名时有一个开关后面我会细讲。三是版本控制。如果你的 Bucket 是用来放前端构建产物的我建议关闭版本控制。前端项目更新频繁旧版本文件没必要保留开启版本控制会持续产生存储费用。但如果你想时不时回滚到某个历史版本可以保留费用也不算高看你自己权衡。2.3 域名规划一个域名用于 CDN 加速接入 CDN 之前要先规划好域名。这里强烈建议单独准备一个 CDN 专用域名而不是直接拿你的主域名来加速。因为你后面会配置缓存规则、CNAME 解析等如果 CDN 域名就是主域名万一配置文件里有问题影响的就是整个站点。常见的做法是用一个二级域名比如static.yourdomain.com这个域名专门负责承载前端静态资源主域名继续指向你的应用服务器。这样当后端接口和静态资源需要不同的缓存策略时配置起来各不干扰。同时你需要对这个 CDN 专用域名在 DNS 服务商处做好准备因为在 CDN 控制台添加完加速域名后会得到一个 CNAME 地址你需要去 DNS 处解析一条 CNAME 记录指向这个地址CDN 才能真正生效。这个流程在后面会具体操作。3. 从零到一的完整部署流程3.1 创建 Bucket 并完成基础配置打开阿里云 OSS 控制台点击“创建 Bucket”。Bucket 名称全局唯一我一般用项目名加环境标识比如web-ops-prod。地域按上一步的分析选择。读写权限选择“私有”。其余选项可以保持默认但是“服务端加密”如果你对静态资源没有加密需求可以不开启免得增加额外的处理开销。创建完成后进入 Bucket 的“基础设置”和“权限管理”页面有几个配置建议顺手做掉。一个是“跨域设置”如果你的前端页面部署在一个域名而 API 请求指向另一个域名或者你的页面用字体文件、Canvas 绘图这些涉及到跨域读取 OSS 文件的场景CORS 规则必须配置。另一个是“静态网站托管”如果你的 Bucket 主要用来存放纯前端项目而且你希望通过 OSS 直接访问首页可以在“基础设置”里开启静态页面托管默认首页设为index.html。但注意当你挂了 CDN 之后CDN 域名访问的时候CDN 是否透传这个配置取决于 CDN 侧的“回源方式”设置后面会说到。3.2 上传文件控制台、ossutil 与 CI 集成怎么选上传文件的方式有几种适用场景不同。如果你只是临时手动更新一两个文件直接在 OSS 控制台里选择文件上传就行。这种方式的缺点是无法同步目录结构一次上传一堆文件时非常低效。如果你有大量文件要同步推荐使用阿里云官方命令行工具 ossutil。下载后配置好 AccessKey运行同步命令ossutil cp -r ./dist/ oss://your-bucket-name/ --update--update参数的意思是只上传比 Bucket 里更新的文件可以加快增量发布的速度。首次全量上传时也可以不加这个参数。如果你的构建机器是 Linux还可以配合 CI 工具比如在代码仓库的流水线里加上一步构建完项目后自动执行 ossutil 同步命令这样你每次 push 代码静态资源就自动发布到 OSS 了。我做项目的时候遇到过前后端一体的仓库前端打包完 push 到 OSS后端走 ECS 上的发布脚本流水线一打通整个发布过程基本不需要人工参与。还有一个高阶用法是给上传设置 Content-Type。前端文件的类型很重要如果 JS 文件被识别成了application/octet-stream浏览器可能直接下载而不是执行页面就会白屏。ossutil 默认会根据文件后缀自动判断 Content-Type如果你用了 CDNCDN 回源时也会读取 OSS 上这个元数据。出问题时可以用下面的命令检查单个文件的头信息ossutil head oss://your-bucket-name/assets/index.js3.3 添加 CDN 加速域名一步步配置CDN 的配置是整个部署的重头戏。登录阿里云 CDN 控制台选择“域名管理”点击“添加域名”。加速域名填static.yourdomain.com业务类型这里我选“图片小文件”因为前端项目里大部分是图片、样式、脚本这类资源。如果你的项目里有大视频切片才需要考虑“大文件下载”或“视音频点播”。源站类型选择“OSS 域名”然后在下方选择你之前创建好的 Bucket。这里注意源站域名要填 OSS 的默认域名也就是your-bucket-name.oss-cn-region.aliyuncs.com这种格式而不是你自己绑定的自定义域名否则回源配置会绕弯路。端口默认 80/443 都勾上后面让你配置 HTTPS 证书的时候会用到 443。点击下一步会让你设置回源配置。这里有一个关键开关“私网回源”。如果你的 Bucket 是私有读必须开启“私网回源”并选择相应的授权方式。阿里云会让 CDN 通过一个内部服务角色去访问 OSS不消耗公网流量而且不用把 Bucket 改成公开。这一步配置错了后面的访问就会 403。添加完成后CDN 控制台会给出一个 CNAME 地址你需要去域名 DNS 服务商处添加一条 CNAME 记录。比如你的 CDN 域名是static.yourdomain.comCNAME 指向yourdomain.w.cdngslb.com。DNS 解析生效后访问static.yourdomain.com才会真正走 CDN。一般几分钟到几十分钟生效可以稍后再验证。3.4 HTTPS 证书配置为什么建议强制跳转现在部署静态资源HTTPS 基本是标配。CDN 控制台里在“域名管理”中找到你的加速域名进入“HTTPS 配置”你可以在阿里云数字证书管理服务里申请免费证书也可以上传自有证书。配置好证书后强烈建议开启“强制 HTTPS 跳转”把 HTTP 的请求都 301 到 HTTPS 上。这么做的好处不只是安全性。有些混用 HTTP/HTTPS 的场景下浏览器会拦截混入的 HTTP 请求导致字体、图片加载不出来。全站 HTTPS 之后这类问题基本就没了。如果你的页面里引用的接口是 HTTP 的那另当别论但静态资源服务本身建议全 HTTPS。另外在“HTTPS 配置”里还可以开启“HTTP/2”HTTP/2 的多路复用特性对于加载几十个前端小文件有明显的速度提升建议直接打开边缘节点和浏览器都支持的话默认就能跑。4. 上线后的核心优化缓存、回源与安全配置4.1 缓存配置是决定“改了代码不生效”还是“资源加载飞快”的分水岭缓存配置是我在做部署方案时最关注的环节因为它直接决定用户拿到的到底是新版本还是旧版本也决定了 CDN 回源频次。在 CDN 控制台的“缓存配置”里可以设置不同路径的缓存 TTL单位是秒。我的经验是分成两类来处理HTML 文件缓存时间要短建议 0 到 60 秒。因为 HTML 是入口文件它内部引用的 JS/CSS 文件名如果带 hash发布后路径就变了只需让 HTML 尽快回源拿到最新入口就能保证用户加载到新版资源。静态资源JS、CSS、图片、字体这些文件文件名里通常带内容 hash比如app.a1b2c3.js这类文件一旦发布就不可变可以放心设置最长缓存比如 30 天甚至 1 年。CDN 和浏览器都会把这类资源缓存住用户二次访问几乎零延迟。具体在阿里云 CDN 控制台“缓存配置”里添加两条规则路径缓存生效优先级.html60 秒高.js.css.png.jpg.woff2.svg30 天中注意CDN 的缓存规则匹配优先级是“先精确后模糊”所以你还可以通过路径前缀比如/assets/这样的方式做更细的控制。我实测下来前端资源如果 hash 命名规范设置 30 天缓存后CDN 命中率可以做到 95% 以上回源请求非常少费用自然就降下来了。4.2 版本管理发布新版时如何保证用户能拿到最新文件可能有朋友问既然 JS/CSS 设置了 30 天缓存那发布新版本时用户还得等 30 天吗这就要靠前端构建工具的 hash 命名了。以 Vue 或 React 项目为例打包输出文件名通常是index.b8b3f0.js这种带 hash 的格式每次文件内容变了hash 就变文件名也跟着变。HTML 继续引用的新文件名由于 HTML 缓存时间很短回源后拿到的是新入口从而加载新的 JS/CSS。老文件会继续存在 CDN 节点上直到过期或被清理。这正好是我前面 4.1 节设置短 HTML、长静态资源缓存的基础。如果你发布后想立即让新版本生效也可以使用 CDN 控制台的“刷新预热”功能。把需要刷新的目录填进去比如https://static.yourdomain.com/assets/或者精确到某个 HTML 文件提交刷新任务后 CDN 节点会主动回源更新缓存。不过刷新操作有配额限制一天内的刷新条数有限建议只在紧急发版时使用日常发布靠短 HTML 缓存就够了。4.3 防盗链与访问控制不能省你的站点一旦有了流量白嫖的人也来了。最典型的是图片盗链别人网站的 HTML 里直接引用你的图片地址加载时走的是你的 CDN 流量你替他掏钱。在 CDN 控制台的“访问控制”里可以配置 Referer 防盗链。设置“白名单”只允许你自己的域名以及可能用到资源的可信域名来引用资源。这里我踩过一个坑只填了主域名yourdomain.com结果发现 HTTP 和 HTTPS 混用时会因为 Referer 带http://和https://前缀不同而失效所以白名单里尽量把两种协议都写上。更进一步可以使用阿里云提供的鉴权配置给 CDN 资源加上时间戳签名。URL 中带上过期时间和签名只有生成正确签名的请求才能访问有效防止他人绕过 Referer 直接下载资源。签名算法不难阿里云控制台会自动生成样例代码照着改写即可。4.4 跨域配置前端页面跨域读取文件时的心头大患本来 OSS 和 CDN 都是服务静态资源的很少涉及跨域问题。但你只要在前端代码里通过 XHR 或 Fetch 请求这些静态资源或者用Web Font加载字体或者用 Canvas 绘制图片就会遇到浏览器跨域校验。比如你的站点在www.yourdomain.com而资源在static.yourdomain.com这已经是不同源了。浏览器在发起资源请求前对于非简单请求会先发送一个OPTIONS预检请求如果服务器返回的 CORS 头不对请求就会失败。配置的位置有两处OSS 的“跨域设置”和 CDN 的“回源 HTTP 头”。我建议先配 OSS。进入 OSS 控制台找到你的 Bucket点“数据安全”-“跨域设置”创建一条规则来源填https://www.yourdomain.com允许 Methods 填 GET、HEAD、OPTIONSAllowed Headers 填*暴露 Headers 填ETag缓存时间随便填个 600。如果 CDN 开启了自定义回源 Header 透传CORS 头就可以由 CDN 直接生成但多数场景下源站 OSS 配好 CORS 就够了CDN 回源时会原样带回来。5. 踩坑实录常见问题与排查技巧速查5.1 为什么配置了 CDN 域名访问还是出现 403403 错误在实际部署里出现频率相当高。如果是刚配置完 CDN最可能的原因就是 Bucket 权限和 CDN 回源授权不匹配。前面我强调过私有 Bucket 必须开启 CDN 的“私网回源”。如果你没开这个开关CDN 回源时拿不到权限用户自然就 403。还有一种情况你给 CDN 配置了源站域名但这个源站域名填的是 Bucket 自定义域名而不是 OSS 默认域名。自定义域名若要作为回源地址要求该域名已经绑定 Bucket 并且 Bucket 权限允许访问。为了避免这类问题我建议统一用 OSS 默认域名做 CDN 源站。排查顺序可以参考下面几步首先打开 CDN 控制台看加速域名是否“正常运行”。看 CDN 日志或 OSS 访问日志确认回源状态码。如果状态码是 403去 OSS 控制台看 Bucket 权限和 CDN 回源授权的状态。如果是 404大概率是路径没对上检查你的 HTML 里引用的资源路径和 Bucket 里的实际目录结构。5.2 改了代码但浏览器和 CDN 都还是旧资源这种问题简直属于“发布三连”。通常原因在于 HTML 文件被缓存了。很多人设置全局缓存 30 天结果 HTML 也被缓存了发布后用户刷新页面拿到的还是旧 HTML自然加载的还是旧资源。要解决除了前面说的 HTML 单独短缓存之外还有一个非常硬的技巧在 HTML 里引用的 JS/CSS 路径不变的情况下可以使用 CDN 控制台的“刷新预热”指定刷新 HTML 文件。但更稳妥的做法是让你的 CI 脚本在发布的时候顺便调用一下 CDN 刷新接口只刷新首页或入口 HTML。这样发布后几分钟内新用户就能拿到最新版本。从源头避免这个问题我在项目里还会加一个配置CDN 缓存键Cache Key忽略参数意思是不管 URL 后面带不带查询参数都会命中同一份缓存。如果你在 HTML 里给 JS 路径加了?v123这种版本号参数而 CDN 缓存键做成“保留参数”模式那同样路径不同参数的请求会多次回源绕过了 hash 文件名的意义。这里我把缓存键设置为“忽略全部参数”配合原文 hash 命名效果很好。5.3 明明配置了 CORS跨域请求还是报错这个问题我在字体加载的场景里遇到过。前端页面上用了 Google Font 类似的字体方案但字体文件放在 static 域名下。按理说 OSS 配置了 CORS 就能放行但实测仍然报跨域错误。排查后发现CDN 节点会在某些情况下改写或丢弃 CORS 相关的响应头。如果你使用的是 CDN 控制台可以在“回源配置”里找到“回源 HTTP 头”把Access-Control-Allow-Origin设置成你的站点域名。同时确认 CDN 配置中没有开启“压缩”功能对跨域头产生副作用。按这个顺序排查一般 10 分钟内能定位问题。另外注意字体文件请求一般属于简单请求不会发预检所以只需要响应头里有Access-Control-Allow-Origin即可。而通过 XHR 提交复杂的 JSON 请求才需要处理OPTIONS预检逻辑。5.4 资源加载耗时还是长怎么确定 CDN 是否真的生效在浏览器 DevTools 里打开 Network 面板点击任意一个静态资源在 Headers 里查看「Response Headers」。如果看到Via: cache或者X-Cache: HIT这样的字段说明命中了 CDN 缓存。阿里云 CDN 返回节点的缓存状态可以在响应头上看比如X-Cache是HIT TCP_MEM_HIT就表示边缘节点内存命中。如果每个文件都是MISS说明 CDN 节点还没缓存需要预热或者你的缓存配置有问题。判断 CDN 是否生效还有一个简单办法使用在线工具测试不同地区的解析结果看域名解析到的 IP 是不是遍布各地。如果所有地区解析到同一个 IP那说明 CNAME 没有完全生效或者某个区域的 Local DNS 有缓存等等。我自己常用的流程是部署完先通过浏览器访问一遍页面确认所有资源都能加载然后用 curl 测试一个具体文件观察响应头里的缓存命中状态最后再通过新页面访问确认 HTML 缓存策略生效。整套验证下来基本可以把上面提到的坑都排查干净。实际操作中的一点体会这套 OSS CDN 方案我前后在不同项目上用过不少次最直观的感受是成本可控、性能稳定、维护成本低。唯一要上心的就是前面反复提到的缓存策略和权限配置。许多团队部署完以后觉得“为什么和别人用的效果不一样”十有八次都是私有 Bucket 的回源授权没开对或者 HTML 被长时间缓存导致发版不生效。我现在把发布流程做成了一条标准的流水线本地构建好dist目录后直接扫描一遍文件类型按规则设好 Content-Type再通过 ossutil 同步上去然后触发 CDN 刷新入口 HTML。整个过程不需要登录控制台也不用人工干预稳定性提升非常明显。如果你们团队正打算把前端静态资源迁到云上或者已经在云上但还在和缓存、跨域、费用这些问题搏斗希望这篇实操记录可以帮你省掉几天的排查时间。按这个思路先把最基础的部署跑通再逐步加缓存规则、鉴权配置和自动化发布后续维护就能轻松很多。