为什么Firebase Hosting的Rewrite规则是无服务器架构核心firebase-gcp-examples路由优先级深度解析【免费下载链接】firebase-gcp-examples Firebase app architectures, languages, tools some GCP things! React w Next.js, Svelte w Sapper, Cloud Functions, Cloud Run.项目地址: https://gitcode.com/gh_mirrors/fi/firebase-gcp-examplesFirebase Hosting 的 Rewrite 规则是无服务器架构里最容易被低估的路由中枢。开源示例集firebase-gcp-examples通过 Next.js、Nuxt.js 等 3 个可部署项目完整演示了路由优先级如何让静态请求走 CDN、动态请求走 Cloud Functions 或 Cloud Run——一条 rewrites 配置就是混合渲染架构的核心所在。 一、30 秒理解Rewrite 是无服务器架构的隐形总机Firebase Hosting 处理每个请求时遵循一条固定的路由优先级先查找静态文件public/目录下的页面、图片、CSS/JS未命中静态文件 → 按redirects改道仍未命中 → 按rewrites透明转发到后端计算层全都失败 → 返回 404关键区别在于规则浏览器地址栏适用场景redirects会变化301/302旧链接迁移、域名规范rewrites保持不变动态路由、SSR 回源rewrites是一个隐形总机用户看到的永远是干净 URL而请求实际被悄悄转给了 Cloud Function 或 Cloud Run 服务。这正是无服务器架构中前端静态 后端按需计算能够共存的前提。 二、看真实配置firebase-gcp-examples 的 3 条 Rewrite 规则1️⃣ Next.js Cloud Functions一条**接管全部动态路由functions-nextjs/firebase.json是整个仓库最经典的示范hosting: [ { site: TODO_YOUR_WEB_APP_DEPLOY_TARGET_HERE, public: public/, cleanUrls: true, rewrites: [ { source: **, function: nextjs-server } ] } ]三个要点public/承载 Next.js 构建出的纯静态页面请求直接由 CDN 命中零计算成本source: **是通配兜底所有 CDN 未命中的请求SSR 页、iSSG 页都落到nextjs-server这个 Cloud Function该 Function 内部用 Express 包裹 Next.js 应用服务端入口见functions-nextjs/server.js静态走 CDN、动态走 Function 的混合 SSG/SSR 架构原理在functions-nextjs/readme.md中有完整说明。2️⃣ Nuxt.js Cloud Functions同样的优先级套路functions-nuxtjs/firebase.json的结构几乎一致只是换了一颗引擎rewrites: [ { source: **/**, function: nuxtjs-server } ]functions-nuxtjs/src/server/index.js中将 Nuxt 实例挂载到 Express 上再交给 HTTP Function——说明 Rewrite 规则不关心后端是什么框架只关心转发给谁。3️⃣ Next.js Cloud RunRewrite 直接指向容器服务cloudrun-nextjs/firebase.json展示了 Compute 层的另一种形态rewrites: [ { source: **, run: { serviceId: nextjs-app, region: us-central1 } } ]转发目标不再是 Function而是 Cloud Run 上的容器服务镜像定义见cloudrun-nextjs/Dockerfile。注意source: **这条路由规则完全没变——这正是 Rewrite 层价值的最佳证明计算层从 Functions 换成 Run前端路由策略零改动。 三、为什么说 Rewrite 规则是无服务器架构的核心① 动静分离 成本与速度的双优化静态页和 SSG 页由 CDN 缓存直接返回带s-maxagestale-while-revalidate缓存策略只有真正需要数据的请求才唤醒计算层。按量付费的无服务器计费模式下这直接省钱。② 一条规则覆盖所有动态路由**通配意味着新增页面、新增博客文章都不需要改任何路由配置——路由是声明式的而非逐条枚举。③ 路由层与计算层彻底解耦Hosting 负责分诊Cloud Functions / Cloud Run 负责治疗。后端可以随业务规模从 Functions 平滑升级到 Run参考cloudrun-nextjs/readme.md中对比两者的改进点而用户侧的 URL 结构永远稳定SEO 不受影响。⚠️ 四、新手排错清单路由优先级的 4 个常见坑坑 1误用 redirects 做动态路由redirect 会改变地址栏并丢失部分 SEO 权重动态页面必须用 rewrite坑 2兜底规则位置不对更具体的source路径必须排在**之前否则会被通配规则截胡永远轮不到坑 3忽略cleanUrls与尾斜杠开启cleanUrls后/page.html变成/page。functions-express/src/server.js里就演示了 simple / CORS / cleanPath 三种服务器对尾斜杠的不同处理坑 4多站点未替换部署目标多站点项目中hosting.site字段决定部署到哪个 Web 应用部署前记得替换配置里的TODO_YOUR_WEB_APP_DEPLOY_TARGET_HERE占位符✅ 五、5 分钟上手从零配好第一条 Rewrite在firebase.json的hosting块中设置public指向静态资源目录确认cleanUrls是否符合你的 URL 风格为动态路由写一条兜底{ source: **, function: 你的函数名 }本地用firebase serve验证优先级先改静态文件看 CDN 命中再请求动态路径看是否回源functions-nextjs/firebase.json的emulators块给出了本地端口参考hosting 5000、functions 5001 总结Rewrite 规则之所以是无服务器架构的核心是因为它同时解决了三件事静态资源零成本分发、动态路由零配置扩展、计算层可自由替换。读懂functions-nextjs、functions-nuxtjs、cloudrun-nextjs这三个firebase.json里各只有几行的 rewrites 配置你就掌握了 Firebase 混合渲染架构的路由底层逻辑——剩下的只是往里填业务。【免费下载链接】firebase-gcp-examples Firebase app architectures, languages, tools some GCP things! React w Next.js, Svelte w Sapper, Cloud Functions, Cloud Run.项目地址: https://gitcode.com/gh_mirrors/fi/firebase-gcp-examples创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考