命令行界面 (CLI) 工具指南

概览

命令行是工程师与 Fuchsia 互动的主要界面 及其工具、驱动程序和设备。提供清晰、一致和连贯 工具对于确保提高所有员工的工作效率和满意度 负责开发 Fuchsia 的工程师和团队。本文档提供了 为 Fuchsia 开发和改进 CLI 工具。

该指南主要分为三个部分：

• 注意事项
• 用户体验指南
• 技术指南

注意事项

Fuchsia 和运行 Fuchsia 的设备构成了广泛的开发者界面， 堆栈中各级用户的不同需求和要求。时间 开发 Fuchsia 工具和子工具时，确保一致性、 架构可预测性、可靠性以及持续的支持和维护 最终用户的体验

根据分发范围，不同的工具会有不同的 预期。以下准则和评分准则将有助于 帮助开发者了解用户体验注意事项、技术要求和 Fuchsia CLI 工具的文档预期。

受众群体

Fuchsia CLI 工具由许多不同的人员构建、维护和使用， 团队。放之四海而皆准的方法不会给那些 单独的上下文，例如树内与树外或 SDK 用户。 此外，某些用户可能对某些特定领域具有独特的工作流程， 例如驱动程序、内核或产品配置。

在开发或更新 Fuchsia 工具时，了解目标受众群体、 他们的情境，以及他们的具体应用场景对于构建更好的 开发者体验

Fuchsia CLI 工具

确保 CLI 工具易于发现并详细记录，可简化流程 方便开发者查找现有工具、了解工作流并发现不足之处。 在某些情况下，扩展现有工具以添加新的 而无需创建新的子工具。例如，如果您希望 通过 TCP 运行设备，建议将 TCP 选项添加到 ffx target flash，而不是 创建单独的工具

应使用哪种工具？

决定使用哪个工具、脚本或库取决于您的使用场景。 ffx 是一种 CLI 工具，用于与目标设备交互或开发 运行 Fuchsia 的产品，例如智能显示屏。fx 等树内工具 这些脚本通常知道 Fuchsia 以外的信息，例如， 软件库和集成

示例

• 使用 ffx 可与 Fuchsia 设备互动（例如，ffx target flash 在设备上刷写 Fuchsia 映像，或ffx component run与 设备上的组件）
• 使用 fx 在树中开发 Fuchsia（例如，fx set（用于配置 build），或 fx test，用于在主机上运行测试）

用于与 Fuchsia 设备交互或管理 Fuchsia 设备的 CLI 工具

• 作为 SDK 的一部分分发；开发者也可以使用 Fuchsia，包括树内开发者。
• 遵循用户体验，强调可检测性、一致性和稳定性 准则
• 提高了对文档和--help内容的期望， 支持开发者
• 其中一些工具由开发者直接使用，并通过 集成脚本或构建系统

平台源代码树中用于 Fuchsia 开发的树内工具

• 适用于使用 fuchsia.git 的树内开发者
• 强调较低的进入门槛，让工具能够快速演变， 主要用户是工具作者
• 预计会更频繁地变化，可能缺少详细记录

构建系统工具和脚本（例如 cmc、fidlc）

• 完全通过命令行选项和/或响应文件控制。
• 强调 CLI 的稳定性，以帮助在构建系统中使用。
• 作为 SDK 的一部分分发；整体用户群体是未知的， 且集成未知/不可访问。
• 通常从不由开发者直接运行，仅作为 build 的一部分运行 系统。

工具的替代方案

除了 ffx 之外，还有用于与内容交互和编写脚本的库 与来自开发主机的 Fuchsia 目标的交互。

• Fuchsia 控制器 是一个 Python 接口，允许开发者通过 FIDL 与目标进行交互
• 草坪舞曲 是基于 Fuchsia 控制器构建的主机端系统交互测试， 不能完全在目标端运行的脚本测试，例如 需要重新启动目标。

ffx 概览

ffx 是一种顶级工具，可为用户提供 与运行 Fuchsia 的设备交互。ffx 具有可扩展的接口， 使对 Fuchsia 开发者有用的其他工具可以注册为 子工具，更便于发现。

ffx 的目标是打造一个紧密结合的工具平台，可提供稳定的 命令行参数 surface 和命令的标准化 JSON 输出。 理想情况下，ffx 子工具将能够使用配置、 日志记录、错误处理和测试框架。这将提供可靠的 工具集合，这些工具的集合松散耦合，可根据具体应用 项目需求。

ffx 子工具生命周期

在开发、更新或弃用 ffx 子工具之前， 需要考虑的因素此工具的适用对象是否可用 还是仅在树内？是否已存在类似的工具？

构建新工具时，请遵循以下提示。您还可以 请查阅 CLI 工具开发评分准则，确定您的 工具满足 Fuchsia 的要求。

用户体验注意事项

该工具的目标用户是谁？他们将如何使用该工具？

• 该工具适合现有命令结构的什么位置？

真人用户和脚本/其他工具能否同样出色地使用该工具？

• 是否明确说明工具的哪些部分适用于机器和 自动化工作流程？
• 机器接口是否详细记录？

命令行界面是否符合 Fuchsia 准则？ 做法？

• 该工具是否遵循用户体验指南？
• 该工具是否为用户提供了可靠文档和帮助 是否符合 CLI 帮助要求？
• 该工具是否提供清晰实用的错误消息？
• 您考虑过无障碍功能吗？

是否有其他用户测试过该工具？

• 请团队之外的人员试一试命令和输出 看看它们是否可用

技术要求

该工具是否经过编译并且独立于运行时环境？

• 该工具是否会最大限度地减少运行时链接依赖项？
• 该工具是否基于 fuchsia.git 源代码树构建？

该工具是否支持机器接口？

• 有没有关于机器接口的全面文档？
• 该工具是否包含机器输入的清单或 JSON 文件？

该工具的兼容性保证是什么？

该工具是否收集指标？

• 收集指标是否符合隐私权要求？

产品管理

您将如何分发该工具？

• 它是仅在树内可用还是包含在 SDK 中？

谁将负责工具的维护工作？

• Google 是否制定了更新、改进或弃用该工具的计划？

用户可以在哪里找到常见问题的答案或提出新问题 问题？

您如何跟踪用户报告的问题？

• 帮助输出和错误输出是否包含 bug 链接？

已对哪些事件进行了插桩测试？在哪里可以找到 工具？

CLI 工具开发评分准则

键

1. 需要显著改进
2. 需要改进
3. 满足最低要求
4. 超出了预期
5. 极佳

用户体验指南

提供清晰、一致且一致的工具，对于确保更好的 提升工作效率和满意度， 紫红色。这些用户体验指南旨在帮助人们 集成 CLI 工具可为用户带来一致的开发者体验。 这些指南使用 Fuchsia 的主要开发者工具 ffx 来详细说明 做法。

设计原则

始终以尽可能简化 ffx 界面为目标。

• 将用户放在首位：考虑所有潜在用户的需求：工具 用户、工具集成商、工具开发商和工具平台开发商。
• 清楚明确：确保工具的用途、用途和反馈简单 易于理解。提供实用且实用的错误消息和帮助文本。
• 保持一致：在输入/输出模式、语言 和 Fuchsia 核心概念。
• 采取整体方法：确保工具有效运行 独立并与其他产品集成，在 Google Cloud 上的行为一致 上下文。
• 提高效率：设计出性能出色、响应迅速的工具， 最大限度地减少延迟并实现快速迭代周期。
• 将无障碍放在首位：使用通俗易懂的语言并遵循无障碍理念 CLI 的准则，确保残障用户的易用性。
• 提前规划：力求提高灵活性、可扩展性和可伸缩性， 以满足未来的需求和增长。

ffx 用户选区

• 工具用户：用于 Fuchsia 工作流程的 ffx 工具的直接用户（ 平台或产品）
• 工具集成商：通过与其他工具集成来使用 ffx 工具，或 特定环境下这包括编写更高级的新工具， 封装 ffx 功能。
• 工具制作工具：编写和维护由 ffx 托管的一个或多个工具
• 工具平台构建工具：改进和维护底层工具 运行 FFX 工具的平台

命令结构

ffx 命令在根 ffx 命令下以树状结构表示。这支持 采用分层式组织可简化用户体验：无需反复进行迭代 用户就可以通过一系列工具遍历命令树， 与预期功能无关的路径。

ffx 命令树上的路径应该跟在 noun noun... verb（名词）之后。 结构。命令路径由内部节点组成，这些节点 增加特异性，最终形成一个叶节点，该叶节点也是一个动词， 实际的命令

例如，ffx component run <URL> 中有根命令名词 (ffx)， 子命令名词（组件）、子命令动词（运行）和参数（网址）， 是执行时传递给命令的值。

ffx component run /core/ffx-laboratory:hello-world fuchsia-pkg://fuchsia.com/hello-world-rust#meta/hello-world-rust.cm

命令结构设计注意事项

在开发新的 CLI 工具时，请务必考虑开发者 打造卓越的体验确保工具下的命令数量 组织和合理的请避免在列表中输入重复或向 工具。在帮助内容和 文档。

一般来说，对于涵盖常见工作流（例如主机到目标）的工具， 互动、系统集成和发布），则更倾向于扩展现有的 而无需创建新的独立工具添加标志、选项或 子命令以利用共享的代码和功能。

但是，如果整个工作流已启用，则考虑使用新命令 或更高级别的子分组查看现有的命令界面参考文档 文档来了解 新命令或工具的适用场景。

受众群体

工具可用于不同的开发任务。对于大型团队来说，这些角色 可能都是独立的人考虑哪些用户可能会使用某种工具，并为该工具提供餐饮服务 。

示例

• 组件开发
• 驱动程序开发
• Fuchsia 开发 (SDK)
• build 集成（GN 等）
• 系统集成商（例如设备上的网络工具）
• 发布（从开发主机到服务器）
• 部署（从服务器到客户）

工具的集成预期可能不同。例如，开发者 进行组件开发时，可能会期望工具与其集成的 开发环境 (IDE) 集成，而 build 集成工具也可以从 脚本。

将相关命令归为一组

应将 Fuchsia 工作流的相关命令归到一个常用工具下。 例如， ffx 被整理成映射到 的子工具和命令组， 高级 Fuchsia 子系统。这有助于鼓励团队朝着共享的 工作流，并提供单一发现点。

范围

命令行工具的范围可能会因用户需求和目标而异。创建 符合人体工程学用途的工具。有时，为了实现目标， 工具可能有助于自动处理耗时的过程。更大，功能更强大 工具应在用户（开发者）级别涵盖整个任务。

示例

• 避免让工具只能完成一个任务中的一小步； 而是设计一个能够执行完整任务的工具。
  • 例如，在开发 C++ 应用时：运行预处理器， 运行编译器，运行链接器，启动构建的可执行文件。
• 最好使用可默认完成所有必要步骤的工具， 允许高级用户执行部分步骤。
  • 例如，传递一个参数来要求 C++ 编译器仅运行 预处理器。

ffx 子工具设计注意事项

ffx 子工具（以前称为插件）被整理成命令组， 映射到高级 Fuchsia 子系统。在 ffx target 中，ffx 是根命令 而 target 是子工具（子命令）。ffx 子工具可能有自己的 参数和选项（例如ffx target list --format [format] [nodename]）。

ffx CLI 应遵循标准的结构和词汇表，以便用户 将 ffx 视为一个整体，而不是将各个工具拼凑在一起。 熟悉一种 ffx 工具的用户应该能够预测和理解 另一个工具中的命令名称

设计 ffx 子工具时，您需要在复杂性和 简明扼要。一般来说，ffx 子工具应映射到文档化的 Fuchsia 概念或 子系统（例如target, package, bluetooth）。如果可能的话 应仅限于一项主要特性或功能，还应提供额外的 已添加为标志的选项不建议添加辅助命令组 有时是不可避免的。清晰比简洁更重要。

命名

为 ffx 命令使用众所周知的美国英语名词（也称为 ffx） 子工具。子命令应该是命令式动词。

• 众所周知的名词是文档中出现的常见名词， 紫红色概念或子系统。请参阅 ffx 参考文档 了解当前 ffx 命令的列表。
• ffx 子工具名称应不少于 3 个字符。（例如，ffx bluetooth，而非 ffx bt）
• 命令和选项应始终采用小写字母 (a-z)
• 子工具名称不得包含连字符。选项（标志）可以使用单个 必要时可使用连字符分隔字词（例如，--log-level）。

结构

遵循名词-名词-动词结构。将相关命令嵌套为以下子命令： 一种家长工具

不要创建名称带有连字符的工具，例如 add-foo 和 remove-foo。 请改为创建接受 add 和 remove 子命令的 foo 命令。

操作

使用简洁明了的动词，准确反映命令的操作。

首选用子命令而不是用连字符连接的多个工具（例如，避免使用 foo-start, foo-stop, foo-reset；改用可接受命令的 foo） start|stop|reset)

一致性

与成熟的 Fuchsia 术语和模式保持一致，以最大限度地减少认知 加载。使用常见的动词对（例如，start/stop, add/remove, import/export) 并遵循现有的 ffx 命令格式。

简洁

力求在不牺牲清晰度的前提下使用最短的命令和选项名称 提高曝光度命令名称应至少包含 3 个字符。

避免使用定义不明确的首字母缩写词或缩写（例如，“bt”可能意味着 蓝牙、Bigtable 或英国电信）。

命令行参数

实参是执行命令时要传递给命令的值。 ffx 中的参数可以是确切文本、有序（也称为定位） 参数）或无序选项（也称为标志）。

选项

选项（也称为标志）无序，可以出现在 组或命令中，包括末尾。请参阅 顶级 ffx 选项。

• 选项应至少包含 3 个字符，并且便于用户阅读
• 必要时，可使用单个连字符分隔各个字词。使用单个 （例如，--log-level)
• 前导选项带有双连字符 (--)。可以使用单个连字符 (-) ，但应谨慎使用短标记， 避免歧义请参阅短别名指南

选项请勿使用大写字母。请勿使用数字选项。如果 需要数值，请创建键控选项，例如 --repeat <number>。

开关

开关的存在意味着其代表的功能已“开启”而 表示已“关闭”。将默认开关切换为“关闭”。

• 必须记录所有开关（不允许使用隐藏开关）
• 与键控选项不同，开关不接受值。例如：-v 是比较常见的 switch，表示“冗长”；它没有值

使用开关改进工具的功能。切换更轻松 比功能标志更精细

不允许同时运行多个开关，例如-xzf 或 -vv（每个 必须相互独立：-x -z -f 或 -v -v。

短别名

一般来说，用户体验建议避免使用短标记。但我们知道 如果专家在一些常用别名中使用短别名 选项。过度使用短别名可能会导致混淆和含糊不清（例如， -b 是 --bootloader、--product-bundle 还是 --build-dir？）。短 请谨慎使用别名。

• 每个选项都不需要别名。如有疑问，请说出。
• 具有严重且不可逆后果的命令应该具有长名称，因此 它们不会因排版错误而调用
• 只能使用小写字母；不使用数字

应在整个 ffx CLI 中以一致的方式使用短别名 （例如，-c 不应是主 ffx 工具中的 --config 的简写形式， 在一个子工具中使用 --command，在另一个子工具中使用 --font-color）。

位置参数

位置参数或有序参数必须显示在命令名称之后，并且 按照显示顺序确定仅对 序列对于理解至关重要的参数（例如， copy <source> <destination>）。一般来说，应避免使用位置参数和 首选包含特定选项的确切文本参数。

帮助输出

CLI 帮助文本可通过 --help 访问，是 用户。它应清晰简洁，并以 并根据需要提供更深入的文档。请参阅 CLI 工具帮助要求 了解详情和示例。

正在撰写帮助文本

终端是一个极简的文字环境。提供的信息过多 可能会让用户难以立即获得所需帮助。帮助 输出应进行标准化，以为用户提供切实可行的指导和 方便查找更多信息的清晰路径。

必需元素

• 说明 - 工具功能和用途的摘要，包括关键 以及使用方面的信息。
• 用法 - 清晰概述了该命令的使用方法，包括语法和 参数，使用 <&gt;以表示必需元素，使用 [ ] 表示可选元素。
• 选项 - 所有选项、其效果和默认设置的明细 价值
• 子命令 - 所有可用子命令的列表和摘要

推荐元素

• 记事 - 重要详情和提醒
• 示例 - 说明如何使用该工具的示例
• 错误代码 - 工具特定错误及其含义列表

格式设置帮助文本

帮助文本应采用清晰的结构和样式，以获得最佳效果 可读性，包括在 80 处时保持一致的缩进和换行 字符。文字应使用清晰且语法正确的美式英语 英语，并遵循 Fuchsia 的文档标准。

错误消息

当设备无法正常运行时，错误可为开发者提供关键信息 符合预期。通过错误消息和警告，开发者可以 准确了解系统或工具的工作原理及其预期 。Fuchsia 错误消息应有助于合理技术用户了解 快速轻松地解决问题。

这些准则适用于作为 Fuchsia 平台一部分产生的错误。错误 由特定运行时或 Fuchsia 之外的语言创建的内容可能无法遵循 这些准则。

写入错误

• 陈述问题 - 找出问题所在、发生的原因以及问题所在 解决问题。
• 帮助用户解决问题 - 提供清晰明了、 合理和可操作性提供链接以获取更多帮助。
• 采用人性化的文字撰写 - 避免使用行话，保持积极的语气，并简明扼要 和一致性

确定原因并推荐解决方案

用户应该明确知道哪里出了问题、哪里出了问题以及为什么出了问题。错误消息 应提供解决方案、后续步骤，或说明具体错误是如何 已更正。

包含短链接

使用短链接将用户重定向到正确的文档并协助处理 进一步说明问题所在。遵循这些准则 来创建短链接

州/省/自治区/直辖市要求

指明是否满足特定限制条件或先决条件。用户应该 了解输入验证是否出现错误（例如， 处理（例如文件中的语法错误）或其他意外原因， （例如文件损坏，无法从磁盘读取）。

具体明确

如果错误涉及用户可以修改的值（文本、设置、 行参数等），那么错误消息应指明违规内容 值。以便更轻松地调试问题。不过，如果值 只能逐渐披露或截断。

使用一致的术语和结构

日志数据可以帮助用户详细了解错误发生的方式和原因。使用 规范名称、类别和值，并在 以便轻松引用错误。

推荐：创建错误代码目录

除 消息可帮助用户轻松识别错误，并在 错误索引或错误目录。例如，FIDL 中的错误代码始终为 会呈现为前缀 fi- 后跟四位数代码，如 fi-0123。

• 请参阅示例：FIDL 编译器错误目录

技术指南

为了跨 Fuchsia 提供一致的开发者体验，CLI 工具应 使用标准库、一致的配置、通用日志记录和错误 处理能力和持续为用户提供支持。

编程语言

Fuchsia CLI 工具可以使用 C++、Rust 和 Go 编写。必须编译工具 并且不依赖于运行时环境例如 Bash、 不支持 Python、Perl 和 JavaScript。

运行时链接依赖项

为了使已编译工具更易于分发和维护，请尽量减少运行时链接 依赖项最好改为静态链接依赖项。在 Linux 上 可以接受针对 glibc 库套件（libm 等）的运行时链接； 不允许使用其他运行时链接依赖项。

从源代码构建

Fuchsia 工具应从 fuchsia.git 源代码树构建。使用相同的 构建和依赖项结构作为平台源代码树中的代码。错误做法 创建单独的系统来构建工具。

指标

指标对于提升质量和做出业务决策至关重要。类型和 必须谨慎选择所收集指标的内容

与指标相关的疑问

• 我们的用户使用的是哪种操作系统？- 确定不同平台的工作优先级
• 他们使用了哪些工具？- 确定各项投资的优先级，并了解 目前正在使用哪些工作流，以便我们确定投资优先级或 找出薄弱环节
• 他们多久使用一次工具？- 让我们知道如何确定各项投资的优先级， 并了解目前正在使用哪些工作流程，以便我们确定 或找出薄弱环节
• 我们的工具在野外会崩溃吗？频率- 这样我们知道如何确定优先级 工具维护
• 他们如何使用工具？- 假设某个工具可以执行一项或多项操作， 我们想要了解一下如何确定特定工作流程 工具

。

配置和环境

工具通常需要知道一些关于实验的环境和上下文信息 它们的运行状态这一部分就如何收集这些信息提供了 应收集和/或存储的数据。

如何阅读

工具不应尝试直接从该 API 中收集或读取设置 它们的运行环境例如所附的 目标的 IP 地址、构建产品的输出目录或 应从平台独立来源收集。 分离执行针对具体平台的工作的代码可以让工具 在不同平台之间保持可移植性

在实际情况下，应以熟悉的方式存储配置信息 主机的用户（例如，在 Windows 上，使用注册表）。工具应该 封装 SDK 文件或平台专用工具的信息 从 Windows 注册表或 Linux 环境中读取数据。

工具应对任何构建系统或环境公正。访问 通用文件，例如 build 输入依赖项文件。

写入信息

工具不应修改配置或环境设置，除非 明显旨在修改 环境

如果在该工具的正常范围之外修改环境可能有助于 则该工具可能会在获得用户明确许可的情况下执行此操作。

测试

在 SDK 中分发或包含在构建系统中的工具必须 包含可保证行为正确无误的测试。添加单元测试和 进行集成测试测试将在 Fuchsia 连续运行 集成。

文档

所有 Fuchsia 工具都需要提供工具使用说明文档， 问题排查指南。标准 --help 输出必须包含：

• 说明：工具功能和用途的摘要信息，包括工具的关键 以及使用方面的信息
• 用法：清晰概述了命令的使用方法，包括语法和 参数，使用 <>以表示必需元素，使用 [ ] 表示可选元素。
• 选项：所有选项及其效果和默认选项的明细 价值
• 子命令：所有可用子命令的列表和摘要

更详细的用法示例和说明应记录在 fuchsia.dev.

用户互动与程序化互动

工具可以由真人用户以交互方式运行，也可以通过脚本以编程方式运行 （或其他工具）。

虽然每个工具默认会进入交互模式或非交互模式（如果可以） 确定首选方式，还必须接受明确的指令，以便在其中运行 指定模式（例如，允许用户执行编程界面，即使 工具在交互式 shell 中运行）。

标准输入

对于通常不具有互动性的工具，请避免请求用户输入（例如， readline 或 linenoise）。不要通过添加非预期提示来要求用户 问题。

对于交互式工具（例如 zxdb），需要提示用户输入。

标准输出

在 stdout 上向用户发送输出时，请使用正确的拼写和语法。 避免使用不常见的缩写。如果使用了不常用的缩写或术语， 在术语库中有一个对应的条目。

斯特尔

使用 stderr 报告无效的操作（诊断输出），即 工具出现异常。如果该工具的目的是为了报告问题（例如 linter、 工具未失败的位置）将这些结果输出到 stdout，而不是 stderr。

退出代码

退出代码 0 始终被视为“无错误”退出代码 1 始终是“常规”， 错误。”请勿依赖于特定的非零值。使用机器输出 具体的错误代码和消息。如需查看示例，请参阅 FIDL 错误目录。

• 如果成功，则返回值 0 的退出代码
• 如果失败，则返回非零退出代码

避免在成功完成时产生不必要的输出，除非输出包括 特定的、重要的信息，以便用户完成 工作流（例如文件路径）。不输出“成功”除非用户要求 以获取详细输出。

日志记录

日志记录与正常输出不同，通常配置为 重定向到某个文件，或者应写入 stderr。受众群体 日志记录工具通常是工具开发者或尝试调试问题的用户。

• 从多个线程记录日志不会交错一行内的字词。通过 最小输出单位是全文行。
• 每行都带有一个表示严重程度的前缀：detail, info, warning, error, fatal

自动化

在合理的范围内添加程序化界面，以实现自动化。如果 该域已有协议，请尝试遵循相同的协议（或者 有充分的理由不要这样做）。MachineWriter (--machine) 可用于支持 JSON 格式的结构化输出。

样式指南

为了在 Fuchsia 中实现一致的开发者体验，CLI 工具应 遵循编程语言的现有样式指南 和 Fuchsia 文档。对于 例如，如果该工具包含在 Zircon 中并使用 C++ 编写，请使用样式 Zircon 中的 C++ 指南。避免创建 不同样式指南。

所有 CLI 工具、输出和文档都应遵循规定的准则 违反 Fuchsia 的规范政策。了解详情 Fuchsia 上的文档标准。

文件路径中的大小写区分

请勿在文件路径中区分大小写。不同的平台处理 大小写形式不同。Windows 不区分大小写，Linux 是 区分大小写。明确说明具体的文件名。别指望 src/BUILD 和 src/build 是不同的文件。

颜色

您可以在命令行界面中使用 ANSI 颜色，使文本更易于阅读 或突出显示重要信息。使用颜色时，务必使用颜色 对于可能无法看到全部颜色的读者 （例如色盲）

• 使用标准 8/16 色， 与 256 色相比，256 种颜色更便于用户重新映射
• 如果可能，检查终端是否支持颜色，并禁止显示 颜色输出。
• 始终允许用户手动抑制彩色输出，例如使用 --no-color 标志和/或设置 NO_COLOR 环境变量 (no-color.org)

切勿仅依赖颜色来传达信息。仅将颜色用作 增强功能。必须看到颜色才能正确解读 输出。详细了解 Fuchsia 上的无障碍功能。

ASCII 字符图形

所有 Fuchsia 工具都应使用具有一致外观的标准输出格式 感受请勿使用 ASCII 图片设置表格格式或以其他方式增强输出。 ASCII 码图片可能会使您的界面难以阅读，并且 屏幕阅读器，实现无障碍功能。