Firebase 是谷歌云旗下的后端即服务（BaaS）平台，它把实时数据库、身份认证、云函数、对象存储和静态托管打包在一起，开发者不需要维护服务器也能快速上线应用。对于静态资源与动态接口的加速，Firebase 托管服务自带的 CDN 和谷歌云 Cloud CDN 是两条关键路径。很多项目只用到了 Firebase 的数据库和登录能力，却忽略了它自带的 Hosting 已经是一个可用的全球 CDN，配合合适的缓存策略就能大幅提升前端加载速度。
Firebase 的 BaaS 能力需要 CDN 支撑哪些部分
Firebase 的核心服务可以分成两类：一类是负责数据与逻辑的 BaaS，比如 Cloud Firestore、Realtime Database、Authentication 与 Cloud Functions；另一类是负责文件与分发的托管能力，比如 Hosting 和 Cloud Storage。BaaS 的价值在于省掉后端服务器，让客户端直接通过 SDK 访问云端资源，但这也意味着客户端请求量会明显增加，如果所有请求都打到单一源站，延迟和并发压力会迅速上升。
CDN 主要解决的是静态资源和可缓存 HTTP 响应的问题。Firebase Hosting 部署后的 HTML、JavaScript、CSS、图片和字体文件天然接入 CDN，用户会从距离自己最近的边缘节点获取内容。Cloud Storage 中的公开文件则可以配合 Cloud CDN 做更细粒度的缓存。需要特别注意的是，Cloud Firestore 和 Realtime Database 的数据同步默认走 WebSocket 或 gRPC 长连接，不适合用普通 HTTP CDN 缓存，它们的优化重点在网络链路、索引和权限规则，而不是对象缓存。
理解这个边界很关键。很多应用把登录状态、评论列表、用户配置等数据放在 Firestore，而把前端壳子、静态图片、视频封面等放到 Hosting 或 Storage。前者提供实时性，后者提供下载速度。把这两类资源分开处理，才能让 CDN 真正发挥作用，同时避免把动态数据错误地缓存到边缘节点，造成用户看到旧数据或越权命中缓存的问题。
Firebase Hosting 内置 CDN 的缓存机制
Firebase Hosting 不只是一个文件服务器，它背后是谷歌的全球边缘网络。每次执行 firebase deploy 后，资源会被推送到分布在世界各地的缓存节点。用户访问自定义域名或默认的 web.app 域名时，DNS 会解析到任播地址，请求自动落到最近的节点。如果边缘节点已有缓存且未过期，就会直接返回，不再回到源站取文件。这种链路对首屏性能尤其重要，尤其是图片和打包后的脚本文件。
缓存行为由响应头 Cache-Control 控制。Firebase Hosting 允许在 firebase.json 中按路径规则配置 headers。常见的策略是：对带哈希指纹的构建产物设置一年左右的 max-age，并加上 immutable，因为文件名变了会重新请求；对 index.html 这种入口文件则设置 no-cache 或很短的有效期，避免新版本发布后用户仍然加载到旧壳子。下面是一个典型配置。
{
"hosting": {
"public": "dist",
"ignore": ["firebase.json", "**/.*", "**/node_modules/**"],
"rewrites": [
{
"source": "**",
"destination": "/index.html"
}
],
"headers": [
{
"source": "**/*.@(js|css|png|jpg|webp|svg)",
"headers": [
{
"key": "Cache-Control",
"value": "public, max-age=31536000, immutable"
}
]
},
{
"source": "**",
"headers": [
{
"key": "Cache-Control",
"value": "no-cache, must-revalidate"
}
]
}
]
}
}
上面的配置还会把单页应用的深层路由重写到 /index.html，这样刷新 /settings 这类路径时仍然能正确加载应用。CDN 节点会缓存重写后的响应，但 no-cache 会要求每一次使用前先向源站验证，性能会略低一些，却不会牺牲版本新鲜度。实际项目中还可以把 index.html 单独设置为 max-age=0，再用 ETag 或 Last-Modified 命中 304，兼顾速度与更新及时性。
另一个容易忽略的点是：Firebase Hosting 部署不是删除旧文件那么简单，它会把发布内容作为一个新版本，并在边缘节点逐步生效。如果文件名没有哈希，用户浏览器可能长期使用旧的 CSS 或 JS。因此，前端构建工具中设置内容指纹非常必要。即使是图片也建议在文件名或查询参数中加入版本号，确保重要更新不会被缓存拖住。
用 Cloud CDN 为对象存储和动态接口加速
Firebase Hosting 的 CDN 适合静态站点，但它的缓存规则只能覆盖 Hosting 自己的文件。当应用需要加速 Cloud Storage 中的大文件下载，或者对部署在 Cloud Run 上的 API 做 GET 响应缓存时，就需要使用谷歌云的 Cloud CDN。Cloud CDN 通过外部 HTTP(S) 负载均衡接入，后端可以是 Cloud Storage 存储桶、Cloud Run 服务、GKE 集群或虚拟机实例。
Cloud Storage 配合 Cloud CDN 的常见做法是：创建一个公开存储桶，保存用户头像、商品图、安装包、视频分段等文件；然后把它挂到负载均衡后端，并启用 Cloud CDN。文件第一次被访问时，边缘节点会回源到 Storage 拉取并缓存，后续用户直接从边缘获得。上传文件时最好显式设置 cacheControl 元数据，这样 CDN 和浏览器都能识别有效期。下面的 Node.js 示例展示了如何上传并设置一天的缓存时间。
const { Storage } = require('@google-cloud/storage');
const storage = new Storage();
const bucket = storage.bucket('my-app-assets');
async function uploadFile(filePath, destFileName) {
await bucket.upload(filePath, {
destination: destFileName,
metadata: {
cacheControl: 'public, max-age=86400'
}
});
console.log(`${filePath} uploaded to ${destFileName}`);
}
uploadFile('./logo.png', 'assets/logo-20250301.png');
对于部署在 Cloud Run 上的 Firebase 云函数或自定义 API，Cloud CDN 也可以缓存 GET 请求的响应。这需要函数的响应头中包含 Cache-Control: public, max-age=60 之类的信息，并保证同一 URL 在不同用户之间返回的内容是相同的。例如，一个公共配置接口、公开文章列表、未登录的首页聚合数据都可以设置短时间缓存。这样既能降低云函数冷启动和数据库读取次数，又能减轻峰值流量压力。
但动态接口的缓存必须非常谨慎。如果响应内容依赖登录用户、地区、权限或实时库存，就不能简单按 URL 缓存。否则 CDN 可能把用户 A 的数据返回给用户 B，造成严重的隐私泄漏。对于这类接口，要么完全绕过 CDN，要么在缓存键中加入用户无关的公共上下文，并在客户端单独请求用户私有数据。安全规则的粒度比缓存速度更重要。
实战部署：单页应用结合 Firebase Hosting 与 CDN
一个典型的 Firebase 前端项目部署流程是：先用构建工具生成 dist 或 build 目录，再通过 Firebase CLI 初始化 Hosting，上传构建产物并发布。初始化时，命令行会询问公共目录、是否配置单页应用重写、是否自动部署等选项。完成初始配置后，每次只需要重新构建并执行 firebase deploy --only hosting 即可。
npm run build firebase deploy --only hosting
部署完成后，可以通过 curl -I https://你的项目.web.app/ 查看响应头。重点观察 cache-control、age、via 和 server 字段。age 表示边缘节点缓存已经存在的秒数，via 中出现 1.1 google 说明请求经过了谷歌 CDN。也可以在 Chrome DevTools 的 Network 面板里看到 x-goog-generation 或 x-goog-meta 等头信息，帮助确认资源确实来自 CDN。
常见的问题几乎都集中在缓存配置上。比如，index.html 被长缓存后，用户刷新页面看不到新版本；或者哈希文件名没有正确生成，导致部署后 CSS 仍引用旧的 JS；还有团队把带用户信息的 API 响应也放进 CDN，最终出现数据串号。解决方法是：入口文件保持短缓存，带指纹文件保持长缓存，所有私有数据请求都不要命中公共 CDN。只要遵循这个原则，Firebase 配合 CDN 就能在开发效率和性能之间取得不错的平衡。