摘要
Alchemy RPC 是一种托管的 JSON-RPC 服务，它让你的应用连接到区块链节点，而无需你自己运行节点。你在 Alchemy 仪表板中创建一个应用，获得一个限定到某个网络的 HTTPS 端点（通常还有 WebSocket 端点），然后向该 URL 发送标准 JSON-RPC 调用，例如 eth_call、eth_getLogs 或 eth_sendRawTransaction。Alchemy 还在原始 RPC 之上叠加了产品功能，包括增强 API、webhooks 和账户工具。
大多数搜索“Alchemy RPC”的开发者试图回答三个实际问题之一：我如何获取端点并调用它，托管服务有哪些限制或功能，以及它是否适合我的工作负载。本页按此顺序回答这些问题，然后提供一个评估清单，你可以将其应用于 Alchemy 或任何其他 RPC 提供商，包括 OnFinality 的 RPC API 服务 和 专用节点。
提前说明：定价层级、速率限制和支持的网络经常变化。将你在第三方博客上看到的任何数字视为起点，并在承诺之前确认提供商自己的定价和文档页面上的当前详细信息。
关键要点
- Alchemy RPC 是一个托管的 JSON-RPC 网关：你获得每个应用、每个网络的 URL，并对其调用标准的以太坊风格方法。
- 端点 URL 是集成点，因此切换提供商通常是配置更改而非代码重写——如果你将 URL 保存在一个地方。
- 评估任何 RPC 提供商时，关注方法覆盖（归档、追踪、日志）、传输支持（HTTPS 与 WebSocket）、吞吐量限制以及故障如何呈现。
- 托管 RPC 是最快的起步方式；当你需要可预测的容量或与其他客户隔离时，专用节点更有意义。
- OnFinality 在许多网络上提供 RPC API 和专用节点基础设施，因此你可以按照与 Alchemy 相同的标准进行比较。
- 在承诺之前，始终在提供商自己的页面上确认当前定价、速率限制和网络支持。
Alchemy RPC 端点如何实际融入你的应用
RPC 端点只是一个接受 JSON-RPC 负载的 HTTP（或 WebSocket）URL。在 Alchemy 设置中，你注册、创建应用、选择网络，Alchemy 会发放一个嵌入了你的 API 密钥的 URL。然后你的应用向该 URL 发送诸如 eth_blockNumber 或 eth_getBalance 的请求。提供商在后台处理节点操作、同步和路由。
这意味着集成面很小。大多数库——ethers、viem、web3.js 或原始 fetch 调用——接受一个 URL 和一个链 ID，然后完成其余工作。实际结果是，你的提供商选择主要是一个配置决策，而不是架构决策，前提是你将端点保存在一个地方。
- HTTPS 端点：用于请求/响应调用，例如读取、gas 估算和交易提交。
- WebSocket 端点：用于订阅，例如新区块、待处理交易或日志。
- API 密钥：嵌入在 URL 中或作为标头发送；将其视为机密，尽可能不要放在客户端捆绑包中。
- 网络选择：每个应用通常限定到一个网络，因此多链应用持有多个端点。
快速建议：何时 Alchemy RPC 是合理的默认选择
如果你在原型设计、运行黑客松项目或在主要 EVM 链上发布小型 dApp，像 Alchemy 这样的托管 RPC 提供商通常是最快的路径。你可以在几分钟内获得端点、常见方法的文档以及用于密钥和使用的仪表板。
一旦你有生产流量，决策就变得更有趣。此时问题不是“它是否工作”，而是“它在我的工作负载下是否表现可预测”。使用下面的清单来决定是留在共享托管层级、在同一提供商内升级，还是评估替代方案，例如 OnFinality 的托管 RPC 和专用节点。
| 标准 | 检查内容 | 为什么重要 |
|---|---|---|
| 原型或小型 dApp | 免费层级限制、支持的网络、文档质量 | 托管 RPC 在你验证产品时将节点操作从关键路径中移除 |
| 生产读取流量 | 吞吐量限制、缓存选项、多区域行为 | 读取密集型应用在流量高峰时可能触及共享限制 |
| 归档或追踪查询 | 归档数据和追踪/调试方法是否包含在你的计划中 | 历史余额和交易追踪通常需要归档节点，并且经常受到限制 |
| 实时功能 | WebSocket 订阅支持和连接限制 | 实时仪表板和机器人依赖稳定的订阅，而不是轮询 |
| 可预测的容量 | 专用节点选项和与其他客户的隔离 | 吵闹邻居效应是共享层级上不明原因延迟的常见原因 |
针对 Alchemy 风格端点的最小调用
请求形状是标准 JSON-RPC，因此一旦你替换 URL，相同的代码可以在任何兼容的提供商上工作。下面的示例使用占位符 URL；将其替换为你提供商仪表板中的端点。
curl -X POST "$RPC_URL" -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'- 在 viem 中：
createPublicClient({ transport: http(process.env.RPC_URL) })然后client.getBlockNumber()。 - 在 ethers 中：
new JsonRpcProvider(process.env.RPC_URL)然后provider.getBlockNumber()。 - 将 RPC_URL 保存在环境变量中，以便切换提供商只需一行更改。
托管 RPC 计划通常在哪里划线
大多数托管 RPC 提供商（包括 Alchemy）围绕计算单元或请求计数构建计划，并带有方法级权重。便宜的方法如 eth_blockNumber 成本低；昂贵的方法如跨宽区块范围的 eth_getLogs 或追踪调用成本更高。理解这种权重比标题请求限制更重要。
另一个常见边界是数据范围。归档数据、调试/追踪 API 和大日志查询通常限制在更高层级或需要显式启用。如果你的应用依赖历史状态或交易追踪，在围绕它们构建之前，确认这些方法在你的计划中可用。
| 标准 | 检查内容 | 为什么重要 |
|---|---|---|
| 方法 | 典型成本概况 | 加权计费意味着几个重调用可能主导你的使用量 |
| eth_blockNumber / eth_chainId | 低权重，通常在所有地方都包含 | 健康检查和简单读取很少是瓶颈 |
| eth_getLogs | 范围限制和每个区块跨度的权重 | 索引器和分析作业可能快速耗尽配额 |
| debug_traceTransaction | 按计划和网络的可用性 | 追踪成本高昂，通常限制在更高层级 |
| eth_getBalance（历史区块） | 归档节点要求 | 非归档节点无法回答历史状态查询 |
承诺前的生产就绪清单
使用此列表在平等基础上将 Alchemy 与任何替代方案进行比较。它故意保持提供商中立，因此你也可以将其应用于 OnFinality 的 RPC API 或 专用节点。
- 方法覆盖：确认目标网络上的归档、追踪和日志查询支持。
- 传输：如果你需要订阅，验证 WebSocket 可用性和连接限制。
- 故障行为：了解过载端点返回什么（HTTP 429、JSON-RPC 错误或超时）以及你的客户端如何重试。
- 可观测性：检查仪表板是否暴露每个方法的使用情况和错误率。
- 故障转移：决定你是否需要辅助提供商或专用节点作为后备。
- 退出成本：将端点保存在配置中，以便迁移是 URL 交换，而不是重构。
何时从共享 RPC 迁移到专用基础设施
共享托管 RPC 效率高，因为许多客户共享一个节点池。这没问题，直到你的工作负载对其他客户的流量变得敏感，或者你需要共享池无法提供的保证。是时候考虑专用节点的迹象包括持续高请求量、交易或实时用户体验的严格延迟要求，以及在发布期间需要隔离容量。
OnFinality 同时提供托管 RPC 端点和专用节点基础设施，因此你可以从共享端点开始，将特定工作负载迁移到专用节点，而无需更改应用代码。查看 RPC 定价 和 支持的网络 以了解适合你技术栈的内容。
| 标准 | 检查内容 | 为什么重要 |
|---|---|---|
| 信号 | 共享 RPC | 专用节点 |
| 流量模式 | 稳定、中等量 | 突发或持续高量且容量需求可预测 |
| 延迟敏感性 | 一般用户体验容忍偶尔变化 | 交易、清算或实时仪表板需要稳定的响应时间 |
| 隔离 | 可接受共享节点池 | 工作负载不得受其他客户影响 |
| 成本模型 | 按请求或计算单元付费 | 固定基础设施成本在规模上更容易预测 |
切换提供商时的迁移检查点
由于集成面是一个 URL，切换 RPC 提供商通常很简单。风险在于细节：方法差异、错误格式和订阅行为。在切换之前运行这些检查点。
- 清点你的应用调用的每个 RPC 方法，包括后台作业和索引器。
- 针对你最重的查询测试新端点，尤其是
eth_getLogs范围和追踪调用。 - 确认 WebSocket 订阅行为和连接断开时的重连逻辑。
- 比较速率限制和无效参数的错误响应，以便你的重试逻辑仍然有效。
- 在一段时间内并行运行两个端点，并比较相同区块上的结果。
- 将旧端点配置为后备，直到新端点在 production 中证明稳定。
常见问题
Alchemy RPC 免费使用吗？
Alchemy 提供有使用限制的免费层级，以及更高量和附加功能的付费计划。确切的限制和定价会随时间变化，因此在围绕特定层级规划之前，请查看 Alchemy 当前的定价页面。
Alchemy RPC 和运行自己的节点有什么区别？
像 Alchemy 这样的托管 RPC 服务为你操作节点、同步和可用性，你按使用量或计划付费。运行自己的节点给你完全的控制和隔离，但需要持续的运营、存储和监控工作。
我可以将 Alchemy RPC 与 ethers 或 viem 一起使用吗？
是的。Alchemy 端点使用标准 JSON-RPC，因此任何接受 RPC URL 的库都可以工作。你将端点 URL 和链 ID 传递给库的 provider 或 transport 构造函数。
Alchemy RPC 支持 WebSocket 订阅吗？
Alchemy 为支持的网络提供 WebSocket 端点，你用于订阅如 new heads 或 logs。可用性和限制取决于你的计划和网络，因此在仪表板中确认。
OnFinality 与 Alchemy 在 RPC 方面如何比较？
两者都提供托管 JSON-RPC 访问。OnFinality 还在支持的网络中提供专用节点基础设施，当你需要隔离容量时很有用。根据你的具体工作负载，在方法覆盖、传输支持、限制和定价方面进行比较。
如何从 Alchemy 切换到另一个 RPC 提供商？
将你的 RPC URL 保存在环境变量中，将其指向新提供商的端点，并在切换之前测试你最重的方法。短暂并行运行两个端点，以捕捉方法或错误格式的差异。
Ethereum
Solana
Polygon
Base
Arbitrum
BNB链
Polkadot
Optimism
