Avalanche CLI

什么是 Avalanche CLI？

Avalanche CLI 是一款命令行工具，开发者可使用它创建、测试、部署、管理和升级 Avalanche L1 区块链。

在加密货币领域，CLI 是一种基于终端的工具，开发者可以通过命令执行区块链操作，而无需使用图形界面。

官方 Avalanche CLI GitHub 仓库将 Avalanche CLI 描述为一款可让开发者访问 Avalanche 的命令行工具，专门帮助开发者开发和测试 L1。

官方创建 Avalanche L1 指南指出，学习 Avalanche L1 开发的第一步是学会使用 Avalanche CLI。

Avalanche CLI 可以帮助开发者生成链配置、将链部署到本地网络或 Fuji 测试网、为主网部署做准备、管理节点、处理密钥、部署跨链消息工具，以及查看验证者信息。

对于构建 Avalanche L1 的团队来说，该工具尤其有用。旧版文档和工具曾将 Avalanche L1 称为 Subnet。

Avalanche L1 可以拥有自己的虚拟机、验证者集合、Gas 代币、权限、费用规则和特定于应用的设置。

Avalanche CLI 通过引导式命令流程和可重复使用的配置文件，帮助开发者管理这些复杂内容。

对于初学者而言，Avalanche CLI 通常是了解 Avalanche L1 如何创建和部署的最快方式。

对于生产团队而言，Avalanche CLI 可以支持重要工作流程，但必须配合严格的安全控制和审慎的运维审查使用。

Avalanche CLI 的当前状态

Avalanche CLI 对 Avalanche 开发者仍然很重要，但其维护状态在 2025 年末发生了变化。

官方 Avalanche CLI 版本发布页面称，截至 2025 年 12 月，Avalanche CLI 已进入维护模式。

同一公告称，Ava Labs 团队将不再开发新功能，只处理安全补丁和关键错误修复。

这对 2026 年的开发者很重要，因为 Avalanche CLI 不应被视为会持续快速迭代、不断扩展功能的产品。

应将其视为一款成熟工具：它可能仍适用于现有工作流程，但用户需要关注版本发布说明、文档更新和较新的工具建议。

进入维护模式并不意味着该工具毫无用处。

这意味着开发者应理性看待未来支持情况，并避免在关键生产系统中依赖不受支持的行为。

团队在生产环境使用 CLI 前，应确认其与当前 AvalancheGo 版本、现行 L1 部署规则、当前验证者管理要求以及自身基础设施兼容。

这一状态也让审查文档变得更加重要。

开发者应查看官方 Avalanche Builder Hub 页面和 GitHub 仓库，不要想当然地认为旧教程仍符合当前最佳实践。

Avalanche CLI 为何重要

Avalanche CLI 之所以重要，是因为启动区块链比部署普通智能合约复杂得多。

Avalanche L1 可能需要创世配置、虚拟机选择、验证者管理器设置、验证者节点、网络参数、Gas 规则、RPC 端点、监控、升级以及跨链消息配置。

如果没有 CLI，开发者就必须手动创建文件、运行节点、准备交易、跟踪 ID、配置虚拟机，并在多个系统间协调验证者。

Avalanche CLI 通过命令和交互式向导简化了其中许多步骤。

这有助于开发者更快上手，并减少部分手动配置错误。

CLI 对本地开发尤其有用，因为开发者可以先创建链配置并进行测试，再使用公共测试网或主网资源。

它还有助于团队以更有条理的方式重复部署流程。

对于 Avalanche 生态的发展而言，Avalanche CLI 这类工具降低了开发者试验自定义区块链环境的门槛。

对于已经熟悉 EVM 工具、但需要 Avalanche 特定链设置支持的开发者来说，这类工具让应用专属 L1 更具可操作性。

该工具不能取代安全工程，但它是 Avalanche 开发者工作流程中的重要组成部分。

Avalanche CLI 的工作原理

Avalanche CLI 允许开发者运行终端命令，以生成配置文件、启动本地网络、部署 Avalanche L1、管理密钥，并与 Avalanche 基础设施交互。

开发者通常会先在受支持的系统上安装 CLI 二进制文件。

官方仓库称，该工具已在 Linux 和 Mac 上经过测试，目前不支持 Windows。

安装后，开发者可以通过 avalanche 命令运行各项操作。

常见的初始工作流程是使用 avalanche blockchain create 创建 Avalanche L1 配置。

官方 CLI 命令参考称，blockchain create 命令会创建新的创世文件，并引导用户完成创建区块链所需的步骤。

创建配置后，开发者可以运行 avalanche blockchain deploy 并选择 Local Network，在本地部署该配置。

官方本地部署指南称，开发者可以将现有 Avalanche L1 配置部署到本地 Avalanche 网络。

链运行后，开发者可以连接应用、测试交易、查看验证者并优化配置。

这一工作流程能帮助团队在转向公共网络前发现问题。

安装 Avalanche CLI

Avalanche CLI 以二进制文件形式安装，开发者可在终端中运行。

官方创建 Avalanche L1 指南称，安装最新 Avalanche CLI 二进制文件最快的方法，是运行 Avalanche CLI 仓库提供的官方安装脚本。

默认情况下，二进制文件会安装在用户主目录下的 bin 目录中。

随后，开发者可以将该目录添加到系统路径，这样就能在任意终端位置运行 avalanche 命令。

安装时应谨慎，因为用于管理密钥、部署和链配置的 CLI 属于敏感开发工具。

开发者应使用官方文档和官方仓库，不要使用来自社交媒体、聊天室或转载教程的随机脚本。

运行会下载并执行软件的 Shell 命令前，应先核实其来源。

这在加密领域尤为重要，因为恶意安装脚本可能窃取私钥、替换二进制文件、更改钱包地址或修改部署参数。

在专业环境中使用 Avalanche CLI 的团队应记录安装来源、版本、操作系统和校验和验证流程。

可复现的安装流程有助于降低供应链风险。

Avalanche CLI 的主要使用场景

第一个主要使用场景是创建 Avalanche L1 配置。

第二个主要使用场景是将该 L1 部署到本地网络进行测试。

第三个主要使用场景是在部署到主网之前先部署到 Fuji 测试网。

第四个主要使用场景是准备并执行主网部署步骤。

第五个主要使用场景是管理验证者节点并检查节点状态。

第六个主要使用场景是处理开发密钥和交易签名。

第七个主要使用场景是管理链升级和虚拟机变更。

第八个主要使用场景是部署和测试 Avalanche Interchain Messaging 工具。

第九个主要使用场景是在不同机器或团队之间导出和导入链配置数据。

这些使用场景说明，Avalanche CLI 是一款完整的开发者工作流程工具，而不仅仅是链创建向导。

创建 Avalanche L1

使用 Avalanche CLI 创建 Avalanche L1，通常从 blockchain create 命令开始。

官方命令参考称，avalanche blockchain create 会创建用于配置区块链的新创世文件，并默认运行交互式向导。

向导可能会要求开发者选择虚拟机、验证者管理类型、控制器地址、Gas 代币设置、预编译选项及其他链参数。

创建 Avalanche L1 指南说明，面向初学者的教程使用 Subnet-EVM（Avalanche 对 EVM 的 L1 分叉）来创建基于 EVM 的 Avalanche L1。

这很重要，因为许多开发者希望获得兼容 Ethereum 的执行环境，同时保留 Avalanche L1 的自定义能力。

链配置不等于一条正在运行的链。

它是一组文件和参数，用于说明链应如何启动和运行。

开发者应将该配置视为关键基础设施。

错误的创世设置、控制器地址、Gas 代币选择或权限设置，都可能在部署后造成难以修复的问题。

在进行任何公共部署前，都应先完成本地测试。

本地部署

创建 Avalanche L1 配置后，本地部署是最稳妥的第一步。

官方本地部署指南称，开发者可以将已创建的 Avalanche L1 配置部署到本地 Avalanche 网络。

该指南还展示了如何使用 avalanche blockchain deploy 命令，后接区块链名称和 local 选项进行部署。

通过本地网络，开发者可以测试链的运行情况，而不会面临真实资金风险。

团队还可以快速测试钱包、RPC 端点、合约、Gas 规则、验证者、预编译和应用流程。

本地部署很有用，因为在区块链公开前，启动问题更容易修复。

开发者可以多次删除并重建本地环境。

在主网上，无法以同样方式自由操作。

本地测试应涵盖正常交易和故障情况。

团队应测试节点重启、Gas 设置错误、合约执行失败、验证者尚未就绪，以及用户使用错误网络设置时会发生什么。

部署到 Fuji 测试网

Fuji 测试网是 Avalanche 在部署主网前使用的公共测试网络。

Avalanche CLI 支持测试网工作流程，开发者可以从本地测试过渡到更接近真实情况的网络环境。

测试网部署有助于发现本地部署可能无法暴露的问题。

例如网络延迟、公共 RPC 配置、外部钱包设置、验证者协调、水龙头资金、监控、部署时机和用户界面假设等问题。

本地部署成功并不意味着测试网部署也一定成功。

应将 Fuji 测试视为主网运维的预演。

开发者应记录每条命令、配置文件、所用密钥、网络 ID、链 ID、节点设置和合约地址。

他们还应测试命令执行到一半失败时的恢复步骤。

官方主网部署指南称，开发者应先在 Fuji 测试网上部署并测试 Avalanche L1，再部署到主网。

这是务实的做法，因为主网错误可能造成高昂代价，而且会公开发生。

部署到 Avalanche 主网

主网部署是 Avalanche CLI 工作流程中风险最高的环节。

官方主网部署指南警告称，将 Avalanche L1 部署到主网存在诸多风险，必须高度重视安全问题。

主网部署可能涉及真实 AVAX、真实验证者、真实节点基础设施、真实用户以及不可逆的配置选择。

指南还指出，教程仅供学习参考，并不保证部署安全。

应认真对待这一警告。

Avalanche CLI 可以引导部署，但无法判断验证者密钥是否安全、治理机制是否可靠、基础设施是否具备韧性，或链的经济模型是否合理。

主网部署前，团队应在 Fuji 上进行测试、审计合约、保护密钥、编写运行手册、监控节点、验证备份并准备事件响应方案。

团队还应了解其验证者管理器设计，以及更改验证者可能造成的后果。

切勿将主网部署当作一次快速的命令行试验。

Avalanche L1 与 Subnet

Avalanche L1 是目前常用的术语，在早期 Avalanche 文档和工具中通常称为 Subnet。

官方 ACP-77 文档讨论了 Subnet 的重新设计，并介绍了 L1 验证者要求和验证者集合控制方面的变化。

这一术语差异很重要，因为开发者仍可能在旧命令、旧指南或旧代码注释中看到 Subnet 一词。

使用 Avalanche CLI 时，开发者应了解，许多旧资料中提到的 Subnet 工作流程对应于如今的 Avalanche L1 工作流程。

Avalanche L1 可以针对特定应用、行业、游戏、机构、资产类别或社区进行设计。

它可以使用兼容 EVM 的虚拟机，也可以使用自定义虚拟机。

它可以采用自定义验证者规则和自定义运行假设。

这种灵活性十分强大，但也意味着责任更大。

每个 Avalanche L1 都应清楚记录其验证者模型、代币模型、治理机制、跨链桥假设和升级流程。

Avalanche CLI 可以帮助创建和部署 L1，但不会默认确保每个 L1 都安全。

Avalanche CLI 中的 Subnet-EVM

Subnet-EVM 是一种兼容 EVM 的虚拟机，常用于 Avalanche L1 开发流程。

创建 Avalanche L1 指南称，教程使用 Subnet-EVM 创建基于 EVM 的 Avalanche L1，并指出它支持自定义费用代币、可配置 Gas 参数和有状态预编译等功能。

这很重要，因为许多加密开发者已经熟悉 EVM 合约和 Solidity 风格的工具。

Subnet-EVM 让这些开发者能够使用熟悉的智能合约模式构建自定义 Avalanche L1。

不过，兼容 EVM 的 Avalanche L1 并不自动等同于 Avalanche C-Chain 或其他 EVM 链。

Gas 代币设置、预编译、链 ID、验证者规则、RPC 端点和跨链桥路径都可能不同。

开发者必须针对所使用的特定 Avalanche L1 配置钱包和应用。

他们还应根据该 L1 选择的 Gas 和预编译配置测试智能合约。

合约即使在一种 EVM 环境中运行正常，在目标 Avalanche L1 上仍可能需要测试。

兼容性可以降低使用门槛，但不会免除部署责任。

自定义虚拟机

Avalanche CLI 也支持自定义虚拟机工作流程。

CLI 命令参考称，blockchain create 命令支持 Subnet-EVM 和自定义 VM，包括用户提供的创世文件和 VM 二进制文件。

自定义虚拟机让团队能够定义不同于普通 EVM 环境的执行规则。

这适用于需要自定义状态转换、自定义交易格式、隐私功能、高性能逻辑或行业专属规则的特殊应用。

自定义 VM 部署比 Subnet-EVM 部署更复杂。

这需要深入了解 AvalancheGo、虚拟机接口、二进制文件分发、节点升级、共识行为和测试。

自定义 VM 中的错误可能影响整条链，因为 VM 决定了交易如何处理。

构建自定义 VM 的团队应进行严格的工程审查，并在公开部署前开展充分测试。

Avalanche CLI 可以帮助打包和部署自定义 VM 配置，但不能取代协议层面的安全审查。

自定义 VM 部署应视为高级区块链工程工作。

验证者管理

验证者管理是运行 Avalanche L1 最重要的环节之一。

验证者负责参与共识，并确保 L1 持续运行且保持正确。

Avalanche CLI 可以帮助处理验证者相关工作流程，包括列出验证者和执行验证命令。

CLI 命令参考称，blockchain validators 命令会列出某条区块链的验证者并提供相关统计信息。

node validate 命令组可帮助节点加入 Primary Network 和 Subnet 并成为验证者，不过命令参考中部分 node 命令标有 alpha 警告。

开发者应特别留意这些警告，因为实验性命令可能发生变化，或无法提供充分保证。

验证者管理不仅是技术工作。

它也是经济和治理工作。

L1 必须决定谁可以成为验证者、如何添加或移除验证者、需要什么质押或权限、如何处理停机，以及如何应对不当行为。

Avalanche CLI 可以支持相关运维，但必须谨慎设计链的验证者模型。

密钥与签名

Avalanche CLI 包含密钥管理命令，可创建、列出、导出、导入和删除签名密钥。

CLI 命令参考称，key create 命令可以生成签名密钥，也可以从文件导入现有密钥。

参考文档还称，key export 命令可以导出已创建的签名密钥。

这些功能便于开发，但若操作不慎也会带来危险。

私钥可能控制资金、部署权限、验证者权限或合约管理权限。

开发密钥不应重复用于主网部署。

主网密钥不应以明文形式存储、提交到代码仓库、在聊天中分享或保存在不安全的设备上。

主网部署指南将硬件签名设备列为前置条件，这反映了生产环境工作对安全性的更高要求。

团队应将本地测试密钥、测试网密钥、部署密钥、验证者密钥和金库密钥分开管理。

安全管理密钥是负责任地使用 Avalanche CLI 最重要的环节之一。

节点管理

Avalanche CLI 包含与节点相关的命令，可用于管理本地节点、集群、状态检查、更新、升级、SSH 访问和验证流程。

CLI 命令参考称，node local 命令组提供本地节点相关命令，包括启动、停止、查看状态、跟踪、销毁和验证。

参考文档还称，node status 命令可以检查节点和区块链的引导状态。

这很重要，因为 Avalanche L1 只有在节点正常运行、完成同步并保持连接时才有用。

要求节点验证 L1 前，开发者需要确认节点是否已完成引导。

生产环境中的节点管理应包括监控、日志、警报、备份、升级流程、磁盘规划、网络安全和密钥隔离。

命令行工具可以帮助执行操作，但不应成为唯一的运维控制手段。

团队应维护运行手册，说明节点落后、失去连接、无法重启或需要升级版本时应如何处理。

节点可靠性会影响用户体验、验证者表现和网络安全。

Avalanche CLI 可以帮助管理节点，但仍需遵循严格的基础设施管理规范。

链升级

链升级是 Avalanche CLI 可以帮助开发者处理的另一项工作。

CLI 命令参考称，blockchain upgrade generate 命令会生成 upgrade.json 文件，并通过交互式向导引导用户完成操作。

同一参考文档称，blockchain upgrade vm 命令可以升级本地区块链以及已部署到 Fuji 和主网的公共区块链所使用的 VM 二进制文件。

升级需要谨慎处理，因为它可能改变区块链处理交易的方式。

VM 升级可能修复错误、增加功能、改变 Gas 行为或引入新风险。

团队绝不能不经审查就把升级当作常规命令执行。

他们应先在本地和测试网上测试升级。

他们应在激活前协调验证者。

升级后应监控区块链。

条件允许时，还应准备回滚或事件响应计划。

升级失败可能导致应用中断、用户资金受限、验证者行为分化，或损害用户对 L1 的信任。

Avalanche CLI 与 Interchain Messaging

Avalanche CLI 提供支持 Interchain Messaging 工作流程的命令。

CLI 命令参考称，avalanche icm 命令组提供了与 ICM messenger 合约交互的工具。

官方 Avalanche Interchain Messaging 文档解释说，ICM 是一种底层消息协议，可让 Avalanche L1 向其他 Avalanche L1 发送数据。

同一文档还说明，ICM 使用 BLS 签名和验证者集合信息来验证消息真实性。

这很重要，因为 L1 之间能够相互通信，会增强 Avalanche L1 模型的能力。

ICM 可支持跨链消息、应用指令、资产转移设计和 L1 间协调。

Avalanche CLI 可以帮助开发者部署或测试与 ICM 相关的合约和消息流程。

不过，跨链消息传递涉及敏感的安全问题。

开发者必须了解源链验证、目标链处理、中继器假设、消息重放保护和故障处理。

跨链消息中的错误可能同时影响多条链。

本地网络、测试网与主网的区别

Avalanche CLI 工作流程应按本地网络、测试网、主网的顺序推进。

本地网络最适合快速迭代和早期调试。

Fuji 测试网最适合公共网络预演，以及在更贴近真实情况的基础设施上进行集成测试。

只有在团队完成测试、记录、保护和审查后，才适合部署主网。

不同环境的风险级别各不相同。

本地操作错误通常成本低且不会公开。

测试网操作错误通常成本较低，但可能暴露运维方面的薄弱环节。

主网错误可能造成真实资金损失、影响用户、损害验证者声誉，或需要公开应对事件。

Avalanche CLI 让团队更容易在这些环境之间切换，但无法判断项目何时已准备就绪。

准备情况应根据测试证据、监控、审计、验证者准备情况、密钥安全和治理清晰度来评估。

遵循严谨的部署流程，比从本地演示直接仓促部署主网更稳妥。

Avalanche CLI 与生产基础设施

生产基础设施不只是成功执行一条部署命令。

生产级 Avalanche L1 需要可靠的验证者、安全的节点、稳定的 RPC 访问、监控面板、警报、备份、日志、升级流程、事件响应和用户支持。

Avalanche CLI 可以帮助处理部分节点和链上操作，但它应成为更大运维体系的一部分。

团队应在适当情况下使用版本控制管理配置，但绝不能将机密信息提交到代码仓库。

他们应使用安全的机密管理方式来管理密钥和凭证。

他们应监控节点健康状况、验证者在线率、磁盘使用量、内存使用量、节点对等连接数、区块生成、RPC 错误和应用流量。

在用户依赖该链之前，还应测试灾难恢复能力。

Avalanche CLI 的实用之处在于它能统一许多命令。

但仅靠它不足以安全地运行生产级区块链。

生产团队还需要 DevOps、安全、治理和区块链专属运维方面的规范。

Avalanche CLI 的安全风险

第一个安全风险是安装伪造或被篡改的 CLI 二进制文件。

恶意二进制文件可能窃取密钥、更改地址、篡改部署文件或泄露机密信息。

第二个安全风险是私钥处理不当。

如果存储不当，通过 CLI 工作流程创建或导出的密钥可能遭到泄露。

第三个安全风险是在错误的网络上执行命令。

原本用于本地网络或测试网的命令，如果误在主网上运行，可能造成危险后果。

第四个安全风险是配置错误。

错误的创世文件、验证者管理器地址或 Gas 代币设置可能造成长期问题。

第五个安全风险是过度依赖交互式提示。

开发者可能在没有理解每项选择后果的情况下，直接点击完成提示。

第六个安全风险是工具过时。

由于 Avalanche CLI 已进入维护模式，用户必须留意兼容性和受支持的工作流程。

第七个安全风险是部署后的运维控制薄弱。

即使链成功启动，如果节点、密钥、升级或监控管理不善，仍可能发生故障。

使用 Avalanche CLI 的最佳实践

开发者应仅从 Avalanche 官方渠道安装 Avalanche CLI。

在用于重要工作流程前，开发者应确认已安装的版本。

开发者应了解该工具已于 2025 年 12 月进入维护模式。

开发者应始终先在本地网络上创建新的链配置。

开发者应先在 Fuji 测试网上测试，再使用主网。

开发者应将开发密钥与生产密钥分开管理。

主网操作应使用硬件签名和安全的密钥存储方式。

开发者应妥善整理并备份链配置文件。

开发者应记录每条部署命令和所有重要输出值。

开发者绝不能仅凭 Avalanche CLI 就认定生产链是安全的。

Avalanche CLI 的优势

Avalanche CLI 的第一个优势是帮助开发者更快学习 Avalanche L1 开发。

第二个优势是通过交互式流程引导链配置。

第三个优势是简化本地网络部署。

第四个优势是支持测试网和主网部署准备工作。

第五个优势是让节点和验证者工作流程更容易管理。

第六个优势是在开发流程中支持密钥处理。

第七个优势是支持链升级和 VM 升级工作流程。

第八个优势是支持与 ICM 相关的开发者操作。

第九个优势是与手动设置相比，能够更容易地重复执行流程。

第十个优势是为开发者提供一种实用方式，在构建完整的生产基础设施前探索 Avalanche L1 设计。

Avalanche CLI 的局限

第一个局限是，截至 2025 年 12 月，Avalanche CLI 已进入维护模式。

第二个局限是，它不能取代安全审计。

第三个局限是，它不保证主网部署安全。

第四个局限是，它无法解决验证者治理设计问题。

第五个局限是，它不会自动保护私钥。

第六个局限是，命令参考中部分节点命令被标记为实验性或 alpha 版本。

第七个局限是，它可能无法将 Avalanche 未来的所有功能都作为一流工作流程予以支持。

第八个局限是，使用者需要熟悉终端操作和区块链配置知识。

第九个局限是，本地部署成功并不能证明项目已具备生产环境部署条件。

第十个局限是，部署后团队仍须维护监控、升级、事件响应和文档。

使用 Avalanche CLI 时的常见错误

一个常见错误是使用过时教程，却不检查当前文档。

另一个常见错误是混淆旧版 Subnet 术语和新版 Avalanche L1 术语。

第三个错误是在 Fuji 测试网完成全面预演前就部署主网。

第四个错误是将同一密钥用于本地测试和生产部署。

第五个错误是在没有安全存储措施的情况下导出私钥。

第六个错误是忽略实验性命令的警告标签。

第七个错误是未经逐项审查就认为生成的链配置安全。

第八个错误是部署后没有记录链 ID、RPC 端点、验证者地址和合约地址。

第九个错误是启动 L1 时没有监控和事件响应计划。

第十个错误是以为 CLI 能保护团队免受治理、代币经济学、验证者或应用层设计缺陷的影响。

面向初学者的 Avalanche CLI

初学者应首先将 Avalanche CLI 用作学习工具。

适合初学者的工作流程是：从官方仓库安装工具，创建基于 EVM 的 Avalanche L1 配置，在本地部署，然后将钱包或应用连接到本地链。

这有助于理解链配置与实际运行的网络之间的区别。

这也有助于理解验证者、Gas 代币、创世文件、链 ID 和 RPC 端点为何重要。

在理解本地和测试网工作流程的每个步骤前，初学者应避免部署主网。

初期练习时也应避免使用真实私钥或真实资金。

Avalanche CLI 可以让高级概念看起来很简单，但底层系统仍然是真实的区块链环境。

新开发者应仔细阅读命令输出，不要复制自己不理解的命令。

目标不仅是让链运行起来。

更重要的是理解每项配置选择为何重要。

面向团队的 Avalanche CLI

团队应通过结构化的开发流程使用 Avalanche CLI。

团队应明确谁可以创建配置、谁可以批准部署、谁控制密钥、谁监控验证者，以及谁有权批准升级。

团队应保存部署日志和配置记录。

条件允许时，应将开发者、运维人员、安全审查人员和治理参与者的职责分开。

团队应在上线前测试灾难恢复和验证者替换流程。

团队还应准备面向用户的文档，说明 L1 的链 ID、RPC 端点、Gas 代币、跨链桥路径、验证者模型和风险假设。

Avalanche CLI 可以加快部署，但团队仍需建立问责机制。

如果用户在生产级 Avalanche L1 上持有真实资产，它就是一个面向公众的金融系统。

达到这一标准，不能只靠成功执行一条终端命令。

还需要成熟的运维能力。

相关加密术语

CLI 是命令行界面的缩写，指通过终端运行软件命令的方式。

Avalanche L1 指具有自身规则、验证者和执行环境的可定制 Avalanche 区块链。

Subnet 是旧术语，过去常用于指如今通常称为 Avalanche L1 的网络。

Subnet-EVM 是一种兼容 EVM 的虚拟机，许多 Avalanche L1 都会使用它。

创世文件指定义区块链初始状态的配置。

验证者指参与区块链共识的节点运营者。

Fuji 测试网指 Avalanche 用于开发和测试的公共测试网络。

主网指涉及真实资产和用户的线上网络。

ICM 是 Avalanche Interchain Messaging 的缩写，是用于 Avalanche L1 之间通信的协议。

AvalancheGo 是用于运行 Avalanche 网络节点的节点软件。

常见问题

什么是 Avalanche CLI？

Avalanche CLI 是一款用于创建、测试、部署、管理和升级 Avalanche L1 区块链的命令行工具。

Avalanche CLI 有什么用途？

它可用于 Avalanche L1 配置、本地部署、测试网部署、主网准备、节点管理、验证者工作流程、密钥处理、升级以及 ICM 相关操作。

Avalanche CLI 仍在积极开发吗？

官方 GitHub 版本公告称，Avalanche CLI 于 2025 年 12 月进入维护模式；Ava Labs 不计划开发新功能，只会处理安全补丁或关键错误修复。

Avalanche CLI 能创建 Avalanche L1 吗？

可以，avalanche blockchain create 命令可以通过交互式向导创建新的 Avalanche L1 配置。

Avalanche CLI 可以在本地部署吗？

可以，Avalanche CLI 可以将现有 Avalanche L1 配置部署到本地 Avalanche 网络，用于开发和测试。

Avalanche CLI 可以部署到主网吗？

可以，Avalanche CLI 支持主网部署工作流程，但官方文档警告，主网部署风险较多，必须高度重视安全问题。

Avalanche CLI 支持哪些操作系统？

官方仓库称，Avalanche CLI 已在 Linux 和 Mac 上经过测试，目前不支持 Windows。

Avalanche CLI 和 AvalancheGo 有什么区别？

Avalanche CLI 是开发者使用的命令行工具，而 AvalancheGo 是用于运行 Avalanche 网络节点的节点软件。

Avalanche CLI 能取代审计吗？

不能。Avalanche CLI 可以帮助处理工作流程，但不能取代代码审计、配置审查、密钥安全、验证者规划或生产环境监控。

学习 Avalanche CLI 最稳妥的方式是什么？

最稳妥的方式是从官方渠道安装工具，创建测试用 L1，在本地部署，然后在考虑主网部署前先到 Fuji 测试网进行预演。

Avalanche CLI 支持自定义虚拟机吗？

支持。官方命令参考称，blockchain create 工作流程支持 Subnet-EVM 和自定义虚拟机，并可使用自定义创世文件和 VM 二进制文件。

使用 Avalanche CLI 时最大的风险是什么？

最大的风险是把引导式命令行工作流程当作安全保证，而生产级 L1 部署还需要安全的密钥、经过测试的基础设施、验证者治理、监控和事件响应。

结论

Avalanche CLI 是构建和管理 Avalanche L1 区块链的重要开发者工具。

它可以帮助开发者创建链配置、部署本地网络、在 Fuji 测试网上进行预演、准备主网部署、管理节点、查看验证者、处理密钥、升级虚拟机，并使用 ICM 工作流程。

它最大的优势是将复杂的 Avalanche L1 开发步骤转化为结构化的终端命令和引导式流程。

因此，它适用于学习、原型开发、测试和部分运维任务。

不过，使用 Avalanche CLI 时必须考虑其当前状态。

截至 2025 年 12 月，官方 GitHub 仓库称该工具已进入维护模式。

这意味着开发者不应假设工具会持续开发大量新功能；在将其用于生产工作流程前，应仔细确认当前兼容性。

Avalanche CLI 也不构成安全保证。

它可以帮助部署链，但无法保证该链的验证者设计、密钥管理、治理、代币经济学、升级、跨链桥、合约或基础设施安全。

更稳妥的开发路径是从本地环境开始，在 Fuji 上进行测试，妥善保护密钥，记录所有配置，监控节点，并在经过严格审查后再部署到主网。

对于初学者而言，Avalanche CLI 是了解 Avalanche L1 实际运作方式的有效工具之一。

对于团队而言，它是一款实用的工作流程工具，应与专业 DevOps、安全审计、安全策略和治理控制结合使用。

关键在于：Avalanche CLI 能让 Avalanche L1 开发更容易，但不会让区块链运维变得简单或没有风险。

谨慎使用时，它可以加快开发并减少手动配置工作。

使用不当时，它可能让团队在尚未做好管理准备的情况下，更快部署出不安全的配置。