App Hosting 会处理一系列复杂的后台任务，以简化应用的部署。本页介绍了该任务流程的关键部分，并提供了有关您可能需要根据应用需求自定义流程的各个位置的信息。
框架集成
App Hosting 为以下框架中开发的 Web 应用提供预配置的构建和部署支持：
- Next.js 13+
- Angular 17.2 及更高版本
App Hosting 会通过检查代码库中的 package-lock.json 文件或其他锁定文件来确定您使用的框架。如果您尝试部署缺少锁定文件的 Node.js 应用，App Hosting 将无法构建和运行您的应用。您可以在根目录中运行 npm
install 来创建 package-lock.json。
框架适配器
App Hosting 框架适配器具有两个关键角色：
- 它们会解析您的源代码和任何特定于框架的配置文件（例如
next.config.js），并生成可由 App Hosting 基础架构的其余部分处理的输出软件包。 - 它们会运行应用的 build 命令，以生成静态资源并创建经过优化的正式版应用。
框架适配器使用 npm run build 构建 Node.js 应用，最适合与每个框架的默认构建脚本搭配使用：next build（适用于 Next.js）和 ng build（适用于 Angular）。App Hosting 会尝试使用自定义 build 命令进行构建，但无法保证一定会成功。
Next.js 和 Angular 适配器的源代码可在 firebase-framework-tools 中找到。
其他框架
除了 Next.js 和 Angular 之外，App Hosting 还支持能够提供与我们的输出软件包规范相符的 build 输出的任何 Web 框架。框架作者可以利用输出软件包规范来确保其框架受 App Hosting 支持。
如果您希望支持其他框架，可以创建适配器，或与框架的维护者联系，以将 build 输出转换为 App Hosting 格式。Nextjs 和 Angular 适配器对于创建适配器的任何人来说都是很好的参考示例。
如需了解受支持的框架，请参阅 Firebase Open Source。
App Hosting 代码库集成的工作原理
GitHub 代码库与 App Hosting 后端之间的重要连接由 Developer Connect 处理，这是 Google Cloud 面向外部 DevOps 工具的连接平台。在创建 App Hosting 后端期间，Developer Connect 的界面工作流会引导您完成 Firebase GitHub 应用的安装。此过程中的关键步骤如下：
- 您向 Developer Connect 授予 Secret Manager Admin 角色。这样，系统便可将凭据安全地存储为 Cloud Secret Manager 中的“Secret”。
- 您授权 Firebase GitHub 应用访问您的 GitHub 代码库。
- Developer Connect 会在项目的 Secret Manager 代码库中存储专用的 GitHub 授权令牌；请勿修改或删除此令牌。
此外，App Hosting 还与 GitHub Checks API 集成，以提供对发布版本的检查。通过此检查，您可以在 GitHub 中查看发布状态，并在出现任何错误时调试部署流程。
与 Firebase 和其他 Google 服务集成
App Hosting 会同时设置构建环境和运行时环境，以便您使用 Google 应用默认凭据初始化 Firebase Admin SDK。这样，您的后端便可以在构建和部署期间与其他 Firebase 产品通信。
App Hosting 个位置
App Hosting 部署会在特定位置创建您的后端资源。这种 Web 应用位置灵活性具有以下关键优势：
- 将数据放置在地理位置上更接近用户的位置，从而提升性能并缩短延迟时间。
- 某个区域的 App Hosting 发生灾难性故障不会影响在其他区域部署的 Web 应用。
在控制台或 Firebase CLI 中创建 App Hosting 后端时，您可以选择以下任一区域：
us-central1（爱荷华）asia-east1（台湾）europe-west4（荷兰）
App Hosting 后端服务账号
在构建期间和运行时，您的 App Hosting 后端会使用服务账号与其他 Google 服务进行身份验证。当您首次在 Firebase 项目中启用 App Hosting 时，系统会创建一个用于以下用途的默认服务账号：
firebase-app-hosting-compute@PROJECT ID.iam.gserviceaccount.com
此服务账号默认适用于所有后端，并且具有一组最少的权限，可让您构建、运行和监控应用。它还可以使用应用默认凭据对 Admin SDK 进行身份验证，以执行从 Cloud Firestore 加载数据等操作。请参阅 Firebase App Hosting 角色。
如果您的应用需要在构建时或通过正在运行的后端与其他 Google 服务交互，您可以通过添加角色来自定义默认服务账号。例如，如果您的应用需要 Vertex AI 权限，您可能需要添加 roles/aiplatform.user 或某个相关角色。
关键术语和定义
- 后端：App Hosting 创建的用于构建和运行 Web 应用的一系列托管资源。
- 发布版本：正式版应用的特定版本，与 git 提交关联。
- 正式版分支：GitHub 代码库中要部署到正式版网址的分支。通常，它是功能分支或开发分支要合并到的分支。
已知问题和限制
App Hosting 预览版存在一些已知限制：
- 在某些情况下，App Hosting 后端可能会在应用的网址中返回
Intermittent connection error消息。我们会在后续版本中提供修复程序。 - 修改了 Cache-Control 标头，将 CDN 缓存限制为 60 秒；将来，当 App Hosting 能够在部署时快速清除缓存时，此限制将被解除。
- 默认情况下，图片优化是在 Cloud Run 中完成的，优化后的图片不会保留。在有更好的解决方案之前，我们建议您停用图片优化功能或手动指定加载器。
- 未缓存的静态文件由 Cloud Run 提供；在较新版本中，它们将从 App Hosting 来源存储和提供，以便获得更好的性能。
- App Hosting SKU 可能不会显示在 Firebase 控制台的后端使用情况页面中。我们将在后续版本中提供这些功能。
- 在后端创建时，Firebase 控制台可能会不时显示“找不到 build 且 build 无效”错误。
- 目前，同一项目中的所有后端都共用一个 GitHub 组织/账号。它们可以与该组织/账号下的不同代码库相关联。如需创建与不同的 GitHub 账号关联的后端，请将它们放在单独的项目中。
- Next.js 中间件、重写和重定向是在 CDN 后面的 Cloud Run 中执行的。由于这些措施无法保护缓存的响应，因此请务必为您要呈现的内容设置适当的控制指令。