将 App Check 库添加到应用后，在启用 App Check 强制执行之前，您应确保这样做不会干扰现有的合法用户。
您可以使用 App Check 请求指标这一重要工具，来决定是否为这些服务启用 App Check 强制执行。您可以在 Google API Console 或 Firebase 控制台中监控 App Check 指标。
在 Google API Console中监控指标
如需查看 iOS OAuth 客户端的指标，请在“凭据”页面中找到该客户端的修改视图。在该页面右侧的 Google Identity for iOS 部分下，您会看到相关指标。这些指标会显示您的 App Check 请求指标。这些指标包含以下信息：
- 已验证的请求数 - 具有有效 App Check 令牌的请求。启用 App Check 强制执行后，只有此类别的请求会成功。
- 未验证请求的数量：可能过时的客户端请求 - 缺少 App Check 令牌的请求；这些请求可能来自未包含 App Check 实现的旧版应用。
- 未验证请求数：未知来源的请求 - 缺少 App Check 令牌且看起来不像来自您的应用的请求。
- 未经验证请求数：无效请求 - 具有无效 App Check 令牌的请求，可能来自企图冒充您的应用的不可信客户端，也可能来自模拟环境。
在 Firebase 控制台中监控指标
您可以查看整个项目的指标，也可以查看各个 OAuth 客户端的指标：
如需查看项目的 App Check 请求指标，请打开 Firebase 控制台的 App Check 部分，然后展开 Google Identity for iOS 部分。例如：
如需查看特定 OAuth 客户端的 App Check 请求指标，请打开 Firebase 控制台的 OAuth 客户端页面，然后展开与该客户端对应的部分。
请求指标分为四类：
已验证请求是具有有效 App Check 令牌的请求。启用 App Check 强制执行后，只有此类别的请求会成功。
过时的客户端请求是缺少 App Check 令牌的请求。这些请求可能来自应用中未包含 App Check 的旧版 Firebase SDK。
未知来源请求是缺少 App Check 令牌并且看起来不像来自 Firebase SDK 的请求。这些请求可能是使用被盗 API 密钥发出的请求，或者是在未使用 Firebase SDK 的情况下发出的伪造请求。
无效请求是具有无效 App Check 令牌的请求，这些请求可能来自企图冒充您的应用的虚假客户端，也可能来自模拟环境。
这些类别的分布情况可以帮助您决定何时为您的应用启用强制执行。下面列出了一些指南：
如果几乎所有近期请求都来自经过验证的客户端，请考虑启用强制执行，开始保护您的身份验证端点。
如果最近的请求中有很大一部分来自可能已过时的客户端，为了避免干扰用户，请考虑等待更多用户更新您的应用，然后再启用强制执行。如果对已发布的应用强制执行 App Check，未与 App Check SDK 集成的先前的应用版本将无法使用。
如果您的应用尚未发布，您应立即启用 App Check 强制执行，因为用户还没有使用任何过时的客户端。
后续步骤
在了解 App Check 对用户有何影响并为后续操作做好准备之后，您便可以启用 App Check 强制执行。