最痛的 Firebase 部署是那种”安静地成功”——CLI 打出一个绿色 URL，但某条 rewrite 规则配错了、function region 漂移了、或者某个静态资源现在是 404。AI 在这种检查上很擅长，因为 firebase.json 体积小、结构化、失效模式也都很经典。这是一份你在任何重要 deploy 之前可以让 Claude/ChatGPT 跑一遍的 10 分钟清单。
这篇讲什么
部署前飞行检查——针对你的 firebase.json、function 配置和 public 目录。重点抓那些”绿了但线上炸”的问题：rewrite 顺序、function region 不一致、public 路径错、本地和线上 env 漂移、CDN 缓存头过时。
本文涉及的工具 / 概念：
- Firebase: Google 的后端 / 托管平台，常用于网站发布、Cloud Functions、Firestore、身份验证。
- firebase.json: 一份声明式配置，控制 hosting、rewrites、headers、redirects 和 function 绑定。大部分上线退化都能追到这里某一块。
- Function regions: Cloud Functions 在某个具体 region 跑（
us-central1、asia-northeast1等）。一条 rewrite 链里混 region 会让延迟暴涨，看起来像”function 慢”。
这篇适合谁看
每周至少部署一次的 Firebase Hosting 用户，特别是用 Astro/Next.js 配合 firebase.json rewrite 到 Cloud Functions 或 Cloud Run 的团队。没有独立 staging 环境的独立开发者收益最大——AI 审计就是你的 staging。
什么时候适合用
任何动到 firebase.json、加新 function、换域名、改缓存头的 deploy 之前都跑一遍。纯内容更新、路由层没动可以跳过。“deploy 成功了但感觉怪怪的”也立刻跑一遍——比如某条路由 404、某 region 突然变慢、Firestore 规则突然挡了读。
开始前准备
- 把完整
firebase.json、package.json和functions/源码备好。给一半上下文得到的就是一半审计。 - 明确说出目标 region。AI 没法猜”我们一直部
asia-east1”。 - 列出”上次成功 deploy 以来改了什么”——新 function、新 rewrite、新域名。这是杠杆最高的上下文。
- 决定要”严格审”（所有小问题）还是”能不能上”（只挡车的）。开头告诉 AI。
具体步骤
- 把
firebase.json粘给 AI，附一句项目描述（“Astro 静态站 + 两个 Cloud Function：OG 图生成和联系表单”）。 - 跑结构化审计 prompt：
审计这份 firebase.json，检查部署期风险：
- Rewrite 顺序（具体路径在 catch-all 之前）
- Function region 一致性（除非有意，所有 function 同 region）
- public 目录路径对不对
- Headers：静态资源有缓存，HTML 无缓存
- Redirects：有没有死循环，有没有跟 rewrite 冲突
- Function 与 rewrite 绑定：function 名是不是真实存在的 export
输出格式：blocker / warning / nit，给出具体行和修复。- 每个发现都让它”给我能直接粘的 diff”。不要散文，要代码块。
- 应用修复。在修过的文件上再跑一次审计。应当返回 zero blocker。
- 先跑
firebase deploy --only hosting:preview到预览频道。冒烟测审计点出来的路由。 - 推生产。盯日志 5 分钟，看有没有标记过的 function 出现冷启动延迟。
AI 经常抓到的失效模式
- catch-all rewrite 排在具体路径前面:
**先匹中，/api/*永远到不了它的 function。重排顺序就行。 - rewrite 里 function 名拼错:
functions/index.js导出ogImage，rewrite 写成og-image。静默 404。 - region 混搭: 一半 function 在
us-central1，一半在asia-east1，rewrite 链跨 region，每调用多 200ms。 - public 目录不一致: build 输出在
dist/，但public设成out/。CLI 传了错的文件夹，线上是上一份。 - HTML 也被缓存:
index.html被一条本来想给静态资源的max-age=31536000通配规则缓存了一年。
第一次实操怎么跑
就算没坏，也对当前 firebase.json 跑一次审计。AI 大概率能挖出 2-4 个你一直带着的问题——通常是缓存头或 region 漂移。修最高杠杆的那个，重新 deploy 看看。第一次跑的意义是校准：在你这个 stack 上，审计有没有信号？如果只返回通用建议，说明你贴的上下文不够。
完成后检查
- AI 是不是引用了具体行号或 block 名，还是泛泛而谈？泛泛 = 你没贴够。
- 修复是可粘代码还是散文？散文 = AI 在猜。
- 修过之后再审，是不是干净的？冒出新问题 = AI 在幻觉 problems，推回去：“这为什么是个问题？引用 Firebase 文档哪一节。”
- 预览部署的行为跟预测一致吗？function 仍 404 = AI 漏了一处，收集新证据再问。
怎么复用这套流程
- 把审计 prompt 存成模板，把项目名和 region 写死。每个 repo 一份。
- 维护一份”以前抓到过”的清单——模式会重复，AI 不会跨会话记住。
- 没改代码也季度跑一次。Firebase 会废弃旧选项，配置可能过期。
- 团队场景：把审计发现贴进 PR 描述，让 reviewer 直接看到改了什么、为什么。
建议的操作流程
配置 + 最近改动总结 + region 声明 → 结构化 prompt 审计 → diff 形式的修复 → 应用 → preview deploy → 冒烟 → 推生产。总耗时 10-15 分钟，相比一次坏部署回滚的一小时。
容易踩的坑
- “小 deploy”不跑审计——小 deploy 才是 rewrite 拼写错溜过去的时机。
- 只贴
firebase.json，不带 function 源码——AI 没法验证 binding。 - 问”这样行不行”而不是走结构化清单——开放问题得到的是模糊回答。
- 接受散文修复而不要 diff。
- 不走 preview 频道直接推生产——preview 是免费的，能挡掉 90% 残余问题。
- 一直放着 nit 不修——它们会累积成下个月的事故。
FAQ
- AI 知道我的 Firebase 项目设置吗？: 不知道，只知道你贴的。region、project ID、最近改动都要明说。
- 能审 Firestore rules 吗？: 能。把
firestore.rules单独贴，套同样的结构化输出格式。 - App Check / 账单配置呢？:
firebase.json单独看不到。要审就把控制台页面截图也带上。 - 跟
firebase deploy --dry-run有什么区别？: dry-run 检查语法；AI 抓的是语义错（顺序错、region 错、目标错）。 - 能自动化吗？: 可以——pre-deploy 脚本里把
firebase.json和git diffpipe 给模型，遇到 blocker 就 exit 非 0。