最痛的 Firebase 部署是那种”安静地成功”。CLI 打出一个绿色 URL，但某条 rewrite 排错了顺序、某个 Cloud Function 悄悄漂回了 us-central1、或者某个 HTML 文件现在被 CDN 缓存了一年、而那个 CDN 你还清不掉缓存。这类 bug 上线时是绿的，几个小时后才浮出水面。AI 能在你推送前抓住它们，因为 firebase.json 体积小、是声明式的，失效模式也都有清晰文档。下面这份清单，用 Claude Opus 4.7 或 GPT-5.5 跑一遍大约 10 分钟。
一句话总结
- 把完整的
firebase.json和functions/入口文件一起粘给 Claude 或 ChatGPT，跑下面那条结构化审计 prompt。上下文含糊，审计结果就含糊。 - 五个高杠杆检查点：rewrite 顺序（具体路径在
**之前）、function region 一致性、public目录是否正确、缓存头（带指纹的资源用长缓存 + immutable，HTML 用短缓存）、rewrite 与 function 名是否对得上。 - 先用
firebase hosting:channel:deploy部到预览频道，冒烟测被标记的路由，再推生产。预览频道免费，默认 7 天后过期。 - 修复要”能直接粘的 diff”，不要散文。AI 一旦说”你可以考虑……”，它就是在猜。
为什么该审的是 firebase.json
几乎每一次 Hosting 退化都能追到 firebase.json 里五个块之一：rewrites、redirects、headers、public，以及 function 绑定。这份配置是声明式的，通常就几百行，恰好是 LLM 能稳定推理的体量。firebase deploy --dry-run 只校验 JSON 语法和 function 名能否解析；而 AI 读这份文件能抓出语义错误：规则顺序错、缓存指令贴错路径、region 悄悄回落到了默认值。
适合每周部署 Firebase Hosting 不止一次的人，尤其是用 firebase.json rewrite 把流量路由到 Cloud Functions 或 Cloud Run 的 Astro / Next.js 团队。没有 staging 环境的独立开发者收益最大——AI 审计就是你的 staging 步骤。
真正要紧的五个检查
1. rewrite 顺序
Firebase Hosting 会应用第一条模式匹中请求的 rewrite，然后停下（Hosting 配置文档）。所以一条 catch-all ** 放在某条具体路由之上，就会把那条路由永久吞掉：
"rewrites": [
{ "source": "/api/**", "function": "api" },
{ "source": "**", "destination": "/index.html" }
]如果这两条顺序反了，每个 /api/* 请求都会落到 index.html，你的 function 永远到不了。另外，只有当路径没有匹中静态文件时 Hosting 才应用 rewrite，所以 public/ 里一个多余文件就可能把整条规则盖掉。让 AI 确认顺序是从最具体到最宽泛、自上而下排列的。
2. function region 一致性
一个没有显式指定 region 的 2 代 Cloud Function 会回落到 us-central1。Firebase 官方文档建议显式设定 region，而不要依赖可能变动的默认值（Cloud Functions 区域）。当你一半 function 钉在 asia-northeast1、一个新 function 又悄悄落到 us-central1，rewrite 链在两者之间来回跳，每次调用就多一趟跨区往返。表现像”function 变慢了”，其实是地理问题。在代码里钉住 region：
const { setGlobalOptions } = require("firebase-functions/v2");
setGlobalOptions({ region: "asia-northeast1" });注意：截至 2026 年 6 月，setGlobalOptions 不一定对 Firestore 触发的 function 生效，它们仍可能初始化在 us-central1。这类触发器要单独显式指定 region。
3. public 目录
如果你的 build 输出落在 dist/（Astro、Vite），而 firebase.json 里 public 设成了 out/（Next.js export）或 build/，CLI 会照样上传错的文件夹。部署成功，线上却是你上一份 build。这是”我的改动怎么没生效”最常见的根因。让 AI 把 public 和你 build 工具的真实输出路径对照检查。
4. 缓存头
Firebase Hosting 会一字不差地照搬你的 Cache-Control 头，而且没有全局清缓存按钮。一个错的头只能靠重新部署正确的头、再等所有 CDN 边缘的 TTL 过期来修（缓存管理文档）。截至 2026 年 6 月的经验法则：
| 资源类型 | 建议的 Cache-Control | 原因 |
|---|---|---|
带指纹的 JS/CSS/字体（app.9f3a1.js） | public, max-age=31536000, immutable | 内容变 URL 就变，缓存一年也安全 |
| 带内容哈希的图片 | public, max-age=31536000, immutable | 同样的指纹逻辑 |
HTML / index.html | public, max-age=300, s-maxage=600 或 no-cache | 外壳要在几分钟内更新，不是一年 |
service-worker.js、manifest.json | no-cache | 必须每次重新校验 |
经典事故：一条本想给资源用的通配 max-age=31536000 规则同时匹中了 index.html，把导航外壳冻结了一年。让 AI 列出每条 header 规则各自匹中哪些路径，并标出任何被长缓存规则误伤的 HTML。
5. rewrite 与 function 的绑定
functions/index.js 导出的是 ogImage，rewrite 却指向 og-image。部署通过语法校验，路由却静默 404。这就是为什么要把 function 入口文件和 firebase.json 一起粘：没有它，AI 无法核实绑定的名字是否真实存在。
具体步骤
- 把
firebase.json和functions/入口文件一起粘给 AI，附一句项目描述，比如”Astro 静态站 + 两个 Cloud Function：OG 图生成和联系表单，部署在asia-northeast1”。 - 跑结构化审计 prompt：
审计这份 firebase.json 的部署期风险，检查：
- rewrite 顺序（具体路径在 catch-all ** 之前）
- function region 一致性（除非有意，所有 function 同 region）
- public 目录是否匹配我的 build 输出（说明你的 build 工具）
- Headers：带指纹的资源用长缓存 + immutable，HTML 用短缓存 / no-cache
- Redirects：有没有死循环、有没有跟 rewrite 冲突
- rewrite 与 function 绑定：每个 function 名是否对应真实 export
每个发现按这个格式返回：blocker / warning / nit，具体行号，
以及能直接粘的修复 diff。不要散文式修复。- 每个发现只接受能直接粘的代码块，绝不要”你可以考虑……”。
- 应用 diff，在修过的文件上再跑一次审计，应当返回 zero blocker。如果冒出新问题，AI 可能在幻觉，推回去：“这为什么是个问题？引用 Firebase 文档哪一节。”
- 部到预览频道，不是生产：
firebase hosting:channel:deploy preflight --expires 2d这会返回一个临时公开 URL，频道会自动过期（默认 7 天；--expires 支持 1h、2d 这类值）。专门冒烟测审计标记出来的那几条路由。
6. 用 firebase deploy --only hosting 推生产。盯日志 5 分钟，看审计标记过 region 漂移的 function 有没有冷启动延迟。
怎么把它变成可复用流程
- 把审计 prompt 存成模板，把项目名、build 工具、region 写死。每个 repo 一份。
- 每个项目维护一份简短的”以前抓到过”清单。模式会重复，而模型不跨会话记忆。
- 没改代码也季度跑一次。Firebase 会废弃旧选项，配置会过期。
- 团队场景：把审计发现贴进 PR 描述，让 reviewer 直接看到改了什么、为什么，再把预览频道 URL 给他们。
整个闭环——配置 + 最近改动总结 + region 声明，审计，diff，应用，预览部署，冒烟，推生产——10 到 15 分钟。而一次坏部署加回滚要一小时，还是当着用户的面发生。
容易踩的坑
- “小 deploy”不跑审计。小 deploy 才是 rewrite 拼写错溜过去的时机。
- 只贴
firebase.json、不带 function 入口文件，AI 没法验证绑定。 - 问”这样行不行”而不是走结构化清单。开放问题得到的是模糊回答。
- 接受散文式修复而不要 diff。
- 不走预览频道直接推生产。
- 一直放着 nit 不修，直到它们累积成下个月的事故。
FAQ
- AI 知道我的 Firebase 项目设置吗？ 不知道，只知道你贴的。region、project ID、最近改动都要明说。
- 能审 Firestore rules 吗？ 能。把
firestore.rules单独贴，套同样的结构化输出格式。 - App Check 或账单配置呢？ 这些不在
firebase.json里。要审就把相关控制台页面的截图也带上。 - 跟
firebase deploy --dry-run有什么区别？ dry-run 校验 JSON 语法和 function 名能否解析；AI 抓的是语义错：顺序错、region 错、缓存目标错。 - 该用哪个模型？ 两个旗舰都行。截至 2026 年 6 月，Claude Opus 4.7 和 GPT-5.5 都能轻松处理几百行配置；两者在顶级套餐上都支持 1M token 上下文，所以一棵较大的
functions/目录树一次就能粘进去。 - 能自动化吗？ 可以。把 prompt 接进 pre-deploy 脚本，把
firebase.json和git diffpipe 给模型，遇到任何 blocker 就 exit 非 0。