嘿，针对你这个2GB、120K页面的静态站增量部署需求，我来给你梳理几个靠谱的方案，刚好之前也帮不少类似场景的开发者解决过问题：

一、Firebase Hosting原生增量部署技巧 #

Firebase Hosting其实默认就支持增量部署，但很多人没注意到正确的用法：

• 每次执行firebase deploy --only hosting时，CLI会自动对比本地文件和远程已部署文件的哈希值，只上传有变化的文件，不会整站重传2GB。不过要注意几个前提：
  • 确保本地生成的文件哈希值稳定，比如静态资源的文件名不要每次构建都变（除非内容真的改了），像有些构建工具会给文件名加哈希后缀，这其实是好事，能帮Firebase快速识别变化；
  • 如果你用了CI/CD管道，要保证每次构建的环境一致，避免相同内容生成不同哈希值，导致误判为需要上传；
• 如果只想部署特定路径的内容，可以用firebase deploy --only hosting:path的方式，比如你要更新/blog路径下的内容，就执行firebase deploy --only hosting:blog，不过这个需要你在firebase.json里提前配置好对应的目标（target），具体可以在项目里用firebase target:apply hosting blog your-project-id来绑定目标，然后在firebase.json的hosting数组里配置每个target的public目录和rewrites规则，确保不同模块对应不同路径。

二、拆分项目为多个Hosting站点（同域名映射） #

如果你的模块拆分很清晰，还可以把不同模块拆成独立的Firebase Hosting项目，然后通过自定义域名映射把它们都指向同一个主域名的不同路径：

• 比如主站是yourdomain.com，把博客模块部署到一个单独的Hosting项目，然后在主站的firebase.json里配置rewrites规则，将/blog/**的请求转发到博客项目的托管地址；
• 这种方式的好处是每个模块可以独立部署，完全互不影响，而且依然能共享同一个域名下的用户认证状态（因为Cookie是绑定域名的）；
• 注意要在Firebase控制台的每个Hosting项目里都添加同一个自定义域名，并且配置好对应的路径映射，避免冲突。

三、结合Cloud Storage+Cloud Functions做动态分发 #

如果你的静态页面中有大量低频访问的内容，可以把这些内容放到Cloud Storage里，然后用Cloud Functions做动态路由：

• 高频访问的核心页面还是部署在Firebase Hosting，低频的归档页、历史页存到Cloud Storage的存储桶里；
• 当用户请求某个低频页面时，Cloud Functions先判断是否在Hosting里存在，不存在就从Storage里读取返回，这样平时只需要部署Hosting里的核心内容，低频内容更新直接上传到Storage即可，不需要走Hosting部署流程；
• 这种方式还能节省Hosting的带宽成本，因为Cloud Storage的存储和带宽定价更适合海量静态文件的存储。

四、构建层面优化：拆分输出目录 #

在你的静态站点构建工具（比如Gatsby、Next.js静态导出、Hexo等）里，把不同模块的输出目录分开：

• 比如把核心模块输出到dist/core，博客模块输出到dist/blog，文档模块输出到dist/docs；
• 然后在firebase.json里配置hosting的public目录为dist，但部署的时候可以指定只上传某个子目录，比如firebase deploy --only hosting --public dist/blog，这样就能只部署博客模块的更新。

最后提醒一下，不管用哪种方案，都建议先在测试环境验证一下增量部署的效果，比如修改几个文件后执行部署，看看控制台的输出是不是只上传了变化的文件，避免出现意外的全量上传。

备注：内容来源于stack exchange，提问作者angelcervera