Fuchsia 系统界面不断变化，并且不断有新的 Fuchsia 版本发布。与推理每个 Fuchsia 版本与其他每个版本的 Fuchsia 系统接口的兼容性（这将非常繁琐）相比，一个版本只与少数 API 级别兼容。
API 级别本质上是构成 Fuchsia 平台 Surface 的 API 的版本。例如，API 级别 10 是 Fuchsia API Surface 的第 10 版。API 级别会与里程碑版本同步，因此 API 级别 10 也可以视为 F10 发布时 Fuchsia 平台 Surface 的最新稳定版数字版本。
API 级别不可变。虽然 API 可能会随时间的推移而添加、移除或更改，但在特定 API 级别发布后，该 API 级别的一组 API 及其语义将永远不会更改。这意味着，任何两个都知道给定 API 级别的 Fuchsia 版本都同意构成该 API 级别的 API 元素的集合和行为。
Fuchsia 系统接口不仅限于 FIDL，还包括系统调用、C++ 库及其方法、永久性文件格式等。从概念上讲，这些都按 API 级别进行版本控制，但在实践中，FIDL 库的版本控制支持比 Fuchsia 系统接口的其他方面要成熟得多。
作为 Fuchsia SDK 的用户，您在构建组件时可以选择单个目标 API 级别。如果您以 API 级别 11 为目标平台，则无论您使用的是哪个版本的 Fuchsia SDK，您的组件都只能访问 API 级别 11 中提供的 API 元素。如果在 API 级别 12 中添加了方法，则组件无法在生成的绑定中使用该方法。如果 API 级别 11 中提供的方法在 API 级别 12 中被移除，该组件仍可继续使用该方法。
构建组件时，SDK 中的工具会将目标 API 级别的关联 ABI 修订版本嵌入到组件的软件包中。这称为组件的 ABI 修订戳。
借助 ABI 修订戳，Fuchsia 可以确保组件观察到的运行时行为与其目标 API 级别指定的行为一致。ABI 修订版戳的使用非常粗糙：如果 Fuchsia 平台 build 支持该 ABI 修订版的相应 API 级别，则允许运行该组件。否则（例如，如果外部组件以 API 级别 11 为目标平台，但操作系统二进制文件不再实现 API 级别 11 的一部分方法），组件管理器会阻止其启动。
示例
您可以使用 API 级别进行声明，例如，fuchsia.lightsensor.LightSensorData FIDL 表在 API 级别 10 中有三个字段（rgbc、calculated_lux 和 correlated_color_temperature），但在 API 级别 11 中又添加了两个字段（si_rgbc 和 is_calibrated）。从 API 级别 11 开始，它有五个字段，但将来（例如在 API 级别 16 中）可能会添加或移除字段。
Fuchsia SDK 的平台开发者和用户之间的差异
作为 Fuchsia SDK 的用户，您可以选择 API 级别，该级别定义了您可以使用的 API 集，以及（间接地）您的 Fuchsia 组件可以运行的平台版本集。您的组件只能使用该特定 API 级别中存在的 API，而不能使用在所选 API 级别之后添加或之前删除的任何 API。如果您想使用其他 API，则应更新组件的目标 API 级别，以便使用新功能。
另一方面，平台 build 会根据 version_history.json 的内容定位到一组 API 级别。因此，作为平台开发者，您需要确保所做的所有更改都与所有受支持的 API 级别兼容。添加新功能或以其他方式更改 Fuchsia 系统接口时，您必须在 HEAD 或 NEXT API 级别执行此操作。
阶段
阶段表示 Fuchsia 版本对给定 API 级别提供的支持级别。API 级别可以处于“受支持”“弃用”或“已废弃”阶段。
每个 Fuchsia 版本都支持多个 API 级别，并将每个 API 级别分配给一个阶段。
API 级别可以处于以下任一阶段，按各 API 级别经历的顺序列出：
支持
在此阶段（使用任何版本）针对 API 级别构建的组件会在平台版本上运行。此外，您还可以在此阶段使用该 SDK 构建以 API 级别为目标平台的组件。
例如，如果给定版本支持 API 级别 17，则表示该版本中的操作系统二进制文件可以运行以 API 级别 17 为目标平台的组件，并且该版本中的 SDK 可以构建以 API 级别 17 为目标平台的组件。
日落
在此阶段，以 API 级别为目标构建的组件会在平台版本上运行。不过，您无法在此阶段使用该 SDK 构建以 API 级别为目标平台的组件。
例如，如果 API 级别 17 在给定版本中已弃用，则表示该版本中的操作系统二进制文件可以运行以 API 级别 17 为目标平台的组件，但该版本中的 SDK 无法构建以 API 级别 17 为目标平台的组件。
已弃用
在此阶段，以 API 级别为目标平台构建的组件无法在平台版本上运行，并且 SDK 也不支持这些组件。
例如，如果 API 级别 17 在给定版本中被弃用，则该版本中的操作系统二进制文件无法运行以 API 级别 17 为目标平台的组件，并且该版本中的 SDK 无法构建以 API 级别 17 为目标平台的组件。
示例
例如，Fuchsia 版本 20.20240203.2.1 可能包含：
- 支持阶段中的 API 级别
17、18和19。这意味着，SDK 版本20.20240203.2.1可以构建以任何这些 API 级别为目标平台的组件，而搭载 Fuchsia 版本20.20240203.2.1的设备可以运行以任何这些 API 级别为目标平台的组件。 - API 级别
15和16处于弃用阶段。Fuchsia 仍会运行以弃用 API 级别为目标的组件，但 SDK 在构建组件时将不再支持以这些级别为目标。 - API 级别
1-14处于已弃用阶段。Fuchsia 不会构建或运行以已弃用的 API 级别为目标平台的组件，但会保留这些组件以供后人使用。
API 级别会在“受支持”阶段发布，即在相应里程碑分支切割前不久。上述假设的 20.20240203.2.1 Canary 版本来自 API 级别 20 发布之前，因此没有 API 级别 20。在 F20 分支切割前不久，API 级别 20 将发布，后续版本（例如 20.20240301.4.1）将将 API 级别 20 列为“受支持”。具体而言，所有里程碑版本在“受支持”阶段都包含其对应的 API 级别。
特殊 API 级别
除了稳定的数字 API 级别之外，还有三种特殊的 API 级别：
与其他 API 级别不同，NEXT 和 HEAD 的内容可能会因版本而异，可以以任意方式进行更改。API 元素可以添加、修改、替换、废弃和/或移除。原则上，20.20240203.1.1 中的 NEXT 可能与 20.20240203.2.1 中的 NEXT 完全不同，但在实践中，更改将是增量更改。
HEAD 比 NEXT 更高级，这意味着 NEXT 中的所有 API 变更也包含在 HEAD 中。
作为 Fuchsia SDK 的用户，如果以 HEAD 或 NEXT 为目标平台，则会使API 和 ABI 兼容性保证失效。作为 Fuchsia SDK 的用户，您不应直接以 PLATFORM 级别为目标平台。
NEXT
NEXT 表示下一个数字 API 级别的“草稿”版本。当发布团队发布新的 API 级别时，NEXT 会在整个代码库中替换为新的 API 级别。为此，您可以创建一个更改列表，将 FIDL 注解、C 预处理器宏和 Rust 宏中的 NEXT 实例替换为下一个里程碑分支的具体编号。NEXT 中的 API 元素必须可正常运行，并且在下一个 API 级别发布之前不太可能发生变化，但仍有可能发生变化。
HEAD
HEAD 代表开发的最前沿，适用于树内客户端（例如其他平台组件或集成测试）使用，不应对稳定性有任何期望。HEAD 中引入的 API 元素可能甚至无法正常运行；例如，某个方法可能已在 HEAD 中添加到协议中，但协议服务器可能尚未实际实现该方法。
PLATFORM
PLATFORM 是一种特殊的元 API 级别，用于构建 Fuchsia 平台，不适合 SDK 用户定位。
PLATFORM 表示当前版本的 Fuchsia 平台必须支持的完整 API 集，例如：
PLATFORM 的主要用途是确保平台可以运行针对其支持的任何稳定 API 级别构建的组件，以及针对 HEAD 级别构建的组件。PLATFORM 包含所有受支持的稳定数字级别的 API，因此可能包含已从 NEXT 或 HEAD 中移除的 API。