Firebase Studio进入关停倒计时

Google 已确认，云端 AI 开发环境 Firebase Studio 将于 2027 年 3 月 22 日正式关闭，届时留在平台上的工作区数据会被永久删除，无法恢复。按今天——2026 年 11 月 9 日计算，现有用户只剩 133 天完成代码、配置、部署链路与 AI 对话记录的迁移。(firebase.google.com)

这并不是一项今天才发布的决定：Google 早在 2026 年 3 月 19 日就公布了关停计划，并于 6 月 22 日停止新用户注册和新工作区创建。最近 Engadget 等媒体重新报道此事，真正值得关注的变化是，Firebase Studio 已经从“仍可观望的预览产品”进入明确的清退阶段。(firebase.google.com)

关掉的是开发环境，不是 Firebase 后端

**Firebase Studio 是 Google 面向全栈应用开发者推出的云端 AI IDE。**它把浏览器代码编辑器、可定制云端虚拟机、Gemini 编程助手、应用预览和 Firebase App Hosting 部署能力放在同一个工作区里，开发者既可以用自然语言生成原型，也可以切换到 CodeOSS 风格的编辑器直接修改代码。(firebase.blog)

**此次关停只影响 Firebase Studio 开发环境，不代表 Firebase 服务本身退场。**Cloud Firestore、Firebase Authentication、App Hosting 等后端服务仍会继续运行，已经上线的数据库、用户账号和托管资源不会因为 IDE 关闭而自动消失。真正失效的是用于打开、编辑和迭代项目的 Firebase Studio 工作区。(firebase.google.com)

这个区别很重要，因为不少开发者看到“Firebase Studio 关闭”，第一反应是线上应用也要迁走。实际上，Google 更像是拆掉了 Firebase 办公楼里的共享工位，而不是停掉供水、供电和服务器：业务后端可以原地不动，但开发者需要换一间办公室继续写代码。

一款只活了两年的产品

**Firebase Studio 的生命周期只有不到两年。**Google 在 2025 年 4 月以预览形式推出该产品，将 Project IDX、Genkit 与 Gemini 整合为一个统一开发环境；到 2027 年 3 月停止服务，其公开生命周期约为 23 个月。(firebase.blog)

Firebase Studio 刚发布时的定位并不保守。它继承了 Project IDX 的云端虚拟机、Nix 环境配置、模拟器和代码仓库导入能力，并提供超过 60 个官方模板；免费用户最初可以创建 3 个工作区，Google Developer Program 会员可以创建 10 个，高级会员则可以创建 30 个。(firebase.blog)

**Firebase Studio 最大的问题不是功能太少，而是产品边界越来越尴尬。**它同时想做浏览器版 IDE、自然语言原型工具、Firebase 控制入口和 AI 编程助手，结果每个方向都与 Google 自己的另一款产品重叠：代码优先的 Agent 工作流有 Antigravity，提示词生成应用有 Google AI Studio，后端管理则继续留在 Firebase Console。

从产品整合角度看，关闭 Firebase Studio 是合理的；从开发者信任角度看，这仍然是一笔成本。Project IDX 被并入 Firebase Studio 后，用户刚完成一次品牌和工作流迁移，如今又要在不到两年内迁往另一套工具。对于只做过几个 Demo 的用户，这只是一次导出；对于把环境配置、部署流程和团队协作都放进工作区的用户，这相当于重新搭建开发基础设施。

Antigravity和AI Studio不是同一种替代品

**Google Antigravity 是面向代码优先开发者的 Agent 原生开发平台。**它提供桌面 IDE、终端和多智能体编排能力，适合让多个 Agent 并行处理重构、测试、调试和跨文件修改，同时保留开发者对代码仓库与本地环境的控制。(antigravity.google)

**Google AI Studio 是面向提示词驱动开发的浏览器应用构建平台。**它的 Build 模式可以根据自然语言生成完整 Web 应用或原生 Android 应用，并提供 React 前端、Node.js 服务端运行时、npm 包支持，以及 Firestore 和 Firebase Authentication 的自动配置能力。(ai.google.dev)

两条路线的差别不是“一个高级、一个简单”，而是谁掌握工作流。Antigravity 把开发者放在 Agent 管理者的位置，代码仓库仍是中心；AI Studio 把提示词和实时预览放在中心，代码更像生成结果。Firebase Studio 曾经试图把这两种模式放在一个产品里，Google 现在决定将它们拆开。

| 对比维度 | Firebase Studio | Google Antigravity | Google AI Studio | |---|---|---|---| | 产品形态 | 浏览器云端 IDE | 桌面 IDE、终端与多 Agent 平台 | 浏览器应用生成与原型平台 | | 核心入口 | 工作区、代码编辑器与 Gemini 对话 | 代码仓库、任务与 Agent 编排 | 提示词、Build 模式与实时预览 | | 更适合谁 | 已停止接收新用户 | 专业开发者、复杂代码库与长期项目 | 产品经理、独立开发者与快速原型 | | 环境控制 | 云端可定制虚拟机 | 本地环境控制更深 | 平台托管程度更高 | | 多文件复杂修改 | 支持，但产品已进入维护期 | 重点能力 | Agent 自动管理，人工控制相对较弱 | | Firebase 集成 | 原生深度集成 | 可继续使用 Firebase 服务 | 内置 Firestore 与 Authentication 配置 | | 迁移方式 | 迁出方 | 下载代码后导入，或由其他工具导出 | 工作区内点击迁移并自动转换 | | 长期建议 | 不应再新增依赖 | 代码优先项目首选 | 提示词原型项目首选 |

应该迁到哪一个？看项目是否已经“长大”

**主要在 Firebase Studio 的 Code View 中工作的项目，优先迁往 Antigravity。**如果项目来自 GitHub、GitLab 或 Bitbucket，包含自定义脚本、复杂依赖、本地工具链或大量人工维护代码，把代码仓库作为唯一事实来源会更稳妥。Google 的官方迁移指南也将“使用内置模板或导入仓库”“依赖本地环境”“需要多模型与多 Agent 能力”列为选择 Antigravity 的典型条件。(firebase.google.com)

**主要依赖 App Prototyping Agent 的项目，迁往 Google AI Studio 更顺手。**Firebase Studio 现有工作区顶部会提供迁移入口，用户选择“Prepare for AI Studio”后，可以把代码转换并打开到新的 AI Studio 工作区；转换过程可能需要数分钟。(firebase.google.com)

**不确定路线的用户可以先迁往 AI Studio，再导出到 Antigravity。**Google 已在 AI Studio 的 Code 页面提供导出至 Antigravity 的路径，因此先保住项目、再决定是否进入更完整的代码优先环境，通常比拖到截止日前集中处理风险更低。(firebase.google.com)

我们的判断是：AI Studio 适合“应用还是提示词作品”的阶段，Antigravity 适合“应用已经成为软件工程项目”的阶段。只要项目开始出现持续集成、测试覆盖、环境隔离、多人协作和生产事故责任，继续把核心资产锁在纯提示词工作区里就不够稳健。

真正容易丢的不是代码，而是上下文

**Firebase Studio 的标准导出不会自动包含 Agent 聊天历史。**Google 表示，当前导出的 ZIP 文件不包含 AI 对话记录，相关提示词和回复保存在工作区的 /home/user/.idx/ai 目录中，用户需要单独压缩下载。部分 Prototyper 会话还可以通过 Git 提交历史找回提示词。(firebase.google.com)

这类记录看起来不像源代码重要，但它往往保存了“为什么这样实现”的隐性知识：模型尝试过哪些方案、哪些依赖存在兼容问题、某段代码为什么绕开默认实现，以及团队如何通过提示词约束生成结果。代码可以在 Git 仓库中恢复，未归档的决策过程却很难重新推导。

**共享工作区还存在所有权限制。**只有工作区创建者可以直接使用迁移按钮，被邀请加入的协作者需要先复制工作区，或手动执行 Zip & Download；如果直接复制代码，原项目的 Firebase 配置和环境变量仍可能指向创建者的资源。(firebase.google.com)

**环境变量是迁移中最需要人工检查的部分。**从 Firebase Studio 转到 AI Studio 后，如果项目继续通过 GitHub 同步发布到 Firebase App Hosting，开发者需要在 Firebase Console 中重新配置环境变量，并确认 .env 文件没有被提交到代码仓库。对于需要更细粒度权限控制的生产项目，Google 建议使用 Secret Manager。(firebase.google.com)

部署链路不会自动原样复制

**继续保留原有 *.hosted.app 地址，需要维持 Firebase App Hosting 部署链路。**迁移到 AI Studio 后，开发者可以把项目同步至 GitHub，再让 Firebase App Hosting 监听主分支完成构建和部署。(firebase.google.com)

**改用 AI Studio 的一键发布，应用通常会部署到 Cloud Run。**这种方式更简单，但可能获得新的 *.run.app 或 AI Studio 域名；如果原项目使用自定义域名，则需要重新完成域名映射，官方提示映射过程最长可能需要 24 小时，并可能产生短暂停机。(firebase.google.com)

因此，迁移不是把源代码下载下来就结束。一个可用的迁移清单至少应该包括：

1. 将最新代码提交到独立 Git 仓库，并验证所有分支和标签完整。
2. 单独下载 /home/user/.idx/ai 中的 Agent 对话历史。
3. 记录 Firebase 项目 ID、App Hosting 后端名称和部署区域。
4. 盘点 .env、Secret Manager、OAuth 回调地址与授权域名。
5. 在新环境中重新安装依赖，并运行构建与测试。
6. 验证 Firestore 安全规则、Authentication 登录和云端函数权限。
7. 进行一次真实部署，检查原域名、缓存、日志和回滚流程。
8. 确认新环境稳定后，再停止使用旧工作区。

Google正在收缩AI开发工具的中间层

**Firebase Studio 的退出说明 Google 不再需要一款“什么都能做一点”的 AI IDE。**AI 编程工具正在向两个极端分化：一端是以 Cursor、Claude Code 和 Antigravity 为代表的代码与 Agent 工程平台，另一端是以 Google AI Studio 等产品为代表的自然语言应用生成器。

中间形态并非没有价值，但最容易被内部产品重叠吞掉。云端 IDE 需要持续承担计算资源、环境镜像、扩展兼容、安全隔离和协作系统的成本；如果大部分用户只是生成一个原型，完整 IDE 显得过重；如果用户维护的是复杂生产项目，浏览器沙箱又显得限制太多。

**Firebase Studio 的关停不是 AI 编程需求下降，而是 Google 在重新划分入口。**Firebase 继续负责后端基础设施，AI Studio 负责从提示词快速生成应用，Antigravity 负责代码优先和多 Agent 开发。三者的职责比 Firebase Studio 存在时更清楚，但用户也必须接受工具之间的切换成本。

对于现有用户，最差的策略是继续把 Firebase Studio 当作长期工作区。2027 年 3 月 22 日不是停止更新，而是数据永久删除的硬截止日期；即使项目短期内不会继续开发，也应该至少完成代码、配置、对话历史和部署信息的离线归档。

参考来源

• IT之家：谷歌 Firebase Studio 明年3月关闭，用户可选择 Antigravity 或 AI Studio——报道关停日期、新工作区停用时间及主要替代方案。