配置Cloud Function重写的Firebase部署期博客路径空白页及平滑部署咨询

所有白屏现象本质都是部署过程中的路由-后端就绪时序错配，具体拆为两点：

• 部署流程执行顺序带来的窗口期错配
  Firebase CLI 执行全量部署时，严格按照「先推送静态托管资源→再同步云函数代码与配置→最后更新hosting层重写路由规则」的顺序执行。当路由规则完成更新、开始把所有/blog/**的请求转发给addDynamicOG云函数时，云函数的运行环境、路由绑定、冷启动实例可能还未同步完成，此时到达的请求要么匹配不到有效路由，要么触发云函数的502/超时错误，最终返回空响应造成页面白屏。等所有组件同步完成、云函数可稳定接参返回后，页面即可恢复正常。
• 云函数路由绑定的固有延迟
  就算云函数代码已经上传完成，从代码部署结束到Firebase边缘节点能正确将请求路由到对应云函数实例，中间通常存在几秒到几十秒的延迟。这个延迟期完全落在部署操作的时间范围内，刚好对应测试时观察到的白屏阶段。

• 分步拆分部署任务，避免一次性全量切换
  不要直接执行全量的firebase deploy，把部署拆成两步执行：
  1. 先单独部署目标云函数：执行firebase deploy --only functions:addDynamicOG，等待部署完成、手动测试确认该云函数可以正常返回博客页面内容后，再执行下一步
  2. 再单独部署静态托管资源与重写规则：执行firebase deploy --only hosting
     这种顺序下，当hosting层的重写规则更新完成时，对应的云函数早已完成部署、路由绑定与冷启动，不存在规则已切流、后端未就绪的窗口期。
• 给云函数加异常兜底逻辑
  在addDynamicOG的代码逻辑里增加全链路异常捕获，不要在读取博客元数据、替换OG占位符、渲染HTML的流程出错时直接抛出500错误。一旦捕获到异常，直接读取静态目录下缓存的原始index.html返回给客户端即可。即使云函数临时出现波动，也能保证返回SPA的基础入口文件，不会出现整页白屏，最多是动态OG标签暂时不生效，不影响核心页面功能。
  参考伪代码结构：

  exports.addDynamicOG = async (req, res) => {
    try {
      // 原有逻辑：拉取对应博客的元数据、替换index.html中的OG占位符、返回渲染结果
    } catch (err) {
      // 兜底逻辑：直接返回静态目录下的原始index.html
      const originalHtml = await readStaticIndexFile()
      res.send(originalHtml)
    }
  }
  

• 保留静态路由的兜底匹配规则
  不要在配置中把/blog/**的路由做成硬切割流。在原有的重写规则基础上，始终保留一条全路径匹配的SPA兜底规则，即使云函数路由临时失效，也能把请求引导回静态index.html，从根源上避免白屏。参考配置：

  "rewrites": [
    {
      "source": "/blog/**",
      "function": "addDynamicOG"
    },
    // 全局SPA兜底规则，永久保留
    {
      "source": "**",
      "destination": "/index.html"
    }
  ]
  

内容的提问来源于stack exchange，提问作者damingzi