Sui 公共 RPC：它能提供什么以及何时该升级

Sui 公共 RPC 端点是一个共享的、无需认证的 JSON-RPC URL，与 Sui 全节点通信。你将钱包、脚本或索引器指向它，发送方法调用，然后获取链上数据。无需注册、无需密钥、无需合约。这种便利性正是公共端点成为任何在 Sui 上构建的人默认首选的原因——也正是当你的工作负载背后有真实用户时，它们不再是正确答案的原因。

本页涵盖了公共端点实际做什么、Sui JSON-RPC 的结构、你将首先遇到的故障模式，以及托管 RPC API 或专用 Sui 节点在工程时间上成为更便宜决策的临界点。

公共 Sui RPC 端点对你的工作负载足够吗？

在将 URL 复制到配置之前，先确定你属于以下三种情况中的哪一种。答案会改变你接下来应该做什么。

如果你属于第一行，公共端点是合理的选择，你可以在下面的请求示例后停止阅读。如果你属于第二或第三行，本页其余部分将讨论哪些地方会出问题以及如何替换。

核心权衡不是速度——而是责任。公共端点没有你可以呼叫的负责人，没有容量保证，也无法看到你的流量是否与成千上万的其他调用者竞争。托管或专用端点为你提供了一个指定的对接人、一个容量模型，以及当出现缓慢时可以查看的地方。

Sui JSON-RPC 实际长什么样

Sui 通过 HTTP 暴露 JSON-RPC 接口。请求是 POST 正文，包含 jsonrpc 版本、method、params 和 id。响应遵循标准 JSON-RPC 信封，包含 result 或 error。

一个最小的读取调用如下所示：

curl -sS -X POST "$SUI_RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "sui_getLatestCheckpointSequenceNumber",
    "params": []
  }'

有几点需要注意。首先，Sui 方法名以 sui_ 为前缀，因此你会看到诸如 sui_getObject、sui_getTransactionBlock、sui_getBalance 和 sui_multiGetObjects 之类的调用。其次，许多方法接受结构化参数——对象 ID、所有者地址或选项对象——而不是单个位置参数。第三，对象和交易区块的响应结构比典型的 EVM 收据更丰富，因为 Sui 跟踪对象及其版本，而不是扁平的账户余额。

在 JavaScript 中，通过 fetch 包装器的相同调用如下所示：

async function suiRpc(url, method, params = []) {
  const res = await fetch(url, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: Date.now(), method, params })
  });
  const json = await res.json();
  if (json.error) throw new Error(`${json.error.code}: ${json.error.message}`);
  return json.result;
}

const checkpoint = await suiRpc(process.env.SUI_RPC_URL, "sui_getLatestCheckpointSequenceNumber");
console.log("latest checkpoint", checkpoint);

从第一天起就将 URL 放在环境变量中。将公共端点硬编码到源代码中是团队在以后需要轮换到托管提供商时陷入困境的最常见原因。

Sui 主网和测试网：它们之间有什么变化

Sui 运行主网和测试网，具有独立的状态、独立的对象 ID 和独立的 RPC 端点。它们不可互换，为一个网络构建的交易不会在另一个网络上执行。

OnFinality 通过其网络页面暴露 Sui，你可以在 Sui RPC 网络页面 上查看当前端点和传输详细信息。由于公共端点及其可用性会随时间变化，请将你在博客文章中发现的任何 URL 视为起点，并在发布前从网络页面或提供商仪表板确认当前 URL。

一个实用规则：永远不要让测试网端点泄漏到生产构建中。使用不同的环境变量，例如 SUI_MAINNET_RPC_URL 和 SUI_TESTNET_RPC_URL，这样配置错误的部署会大声失败，而不是静默地写入错误的网络。

你会在共享端点上遇到的故障模式

公共端点上的第一个问题很少是戏剧性的。它们表现为间歇性错误、缓慢的响应以及本地工作但在生产中失败的调用。

其中两个值得更详细地说明。对象版本不匹配是 Sui 特有的陷阱：如果你读取一个对象，然后针对该版本构建交易，而对象在提交前发生变化，交易就会失败。这不是公共端点的问题，但公共端点的可变延迟使窗口更宽。使用新的读取重试，而不是重新提交相同的交易。

速率限制是另一个。公共端点是共享的，因此来自你的应用或其他调用者的流量高峰可能会将你推入节流。如果你看到 429 响应，修复方法不是更长的重试循环——而是容量决策。带密钥的托管 RPC API 为你提供可预测的容量份额，而专用节点完全消除了共享租户问题。

何时迁移到托管 RPC API 或专用 Sui 节点

没有单一的阈值，但有明确的信号。当以下任一情况为真时，从公共端点迁移：

• 你有真实用户，无法容忍无法解释的失败。
• 你需要的请求量会被共享端点节流。
• 你想要支持路径和端点的指定负责人。
• 你需要存档式历史读取或更重的查询模式。
• 你正在运行具有稳定负载的索引器、机器人或后端服务。

托管 RPC API 和专用节点之间的选择归结为隔离和控制。托管 RPC API 为你提供经过认证的端点、容量模型和监控，而无需你操作任何东西。专用节点为你提供隔离的硬件以及对配置和数据访问的完全控制，当你的工作负载很大或有特定要求时，这一点很重要。

OnFinality 两者都提供：面向希望托管端点的团队的 RPC API 服务，以及面向需要隔离的团队的 专用节点。你可以在 RPC 定价页面 上比较成本和容量形态，并在 支持的 RPC 网络 上查看完整的链列表。如果你仍在总体上权衡提供商，提供商选择指南 会介绍评估标准。

不会破坏你的应用的迁移路径

从公共端点迁移到托管端点应该是一个配置更改，而不是重写。组织你的代码，使端点是唯一变化的东西。

1. 将端点放在环境变量中，而不是源代码中。
2. 将所有 RPC 调用包装在单个客户端模块中，以便重试、超时和错误处理集中在一处。
3. 添加一个健康检查，调用像 sui_getLatestCheckpointSequenceNumber 这样的廉价方法，并记录延迟和错误率。
4. 在一段时间内同时运行托管端点和公共端点，并在切换前比较错误率。
5. 保持配置一个备用端点，这样单个提供商的问题不会导致你的应用宕机。

一个简单的监控探针如下所示：

async function probe(url) {
  const start = Date.now();
  try {
    await suiRpc(url, "sui_getLatestCheckpointSequenceNumber");
    return { url, ok: true, ms: Date.now() - start };
  } catch (err) {
    return { url, ok: false, ms: Date.now() - start, error: err.message };
  }
}

对你依赖的每个端点定期运行此探针。趋势比任何单个结果都重要：延迟上升或错误率增长是你需要在用户注意到之前增加容量或切换主端点的信号。

保持 Sui RPC 稳定的操作习惯

一些习惯将很少发生 RPC 事件的团队与每周都发生的团队区分开来。

• 在 API 支持的情况下批量读取，但保持批量适中，这样单个失败不会丢失大量有效负载。
• 对每个调用设置明确的超时。挂起的请求比快速失败更糟糕。
• 对暂时性错误使用退避重试，但不要盲目重试交易提交——先重新读取对象版本。
• 在错误旁边记录端点 URL，以便你能分辨哪个提供商失败了。
• 跟踪每个端点的错误率和 p95 延迟，而不仅仅是总体。
• 如果你的提供商提供不同的端点，将读取流量与写入流量分开，这样繁重的索引器不会减慢用户交易。

这些都不是 Sui 特有的，但 Sui 的对象模型使重试纪律比基于账户的链更重要，因为过时的对象版本会将重试变成必然失败。

关键要点

• Sui 公共 RPC 端点是一个共享的、无需认证的 JSON-RPC URL——适合原型开发，作为生产主要路径有风险。
• Sui JSON-RPC 使用以 sui_ 为前缀的方法和结构化参数；从一开始就将端点放在环境变量中。
• 主网和测试网是独立的网络，具有独立的端点和状态；永远不要让一个泄漏到另一个的构建中。
• 你遇到的第一个失败是速率限制、超时和对象版本不匹配——所有这些都指向容量决策，而不是代码修复。
• 当你需要可预测的容量和支持路径时，迁移到托管 RPC API；当你需要隔离和控制时，迁移到专用 Sui 节点。
• 在迁移中使端点是唯一变化的东西，并监控每个端点的延迟和错误率。

常见问题

Sui 公共 RPC 端点可以免费使用吗？

公共端点通常是开放且无需认证的，这就是它们在原型开发中受欢迎的原因。它们是共享的，因此容量无法保证，大量或突发使用可能会被节流。对于生产流量，托管或专用端点是更可预测的选择。

Sui 主网和测试网 RPC 有什么区别？

它们是独立的网络，具有独立的状态和独立的端点。主网承载真实资产；测试网用于测试，由水龙头资助。来自一个网络的交易或对象 ID 不会在另一个网络上工作。

为什么我的 Sui 交易因对象版本错误而失败？

Sui 跟踪对象版本。如果一个对象在你读取它和提交引用它的交易之间发生变化，交易就会失败。重新读取对象并重建交易，而不是重新提交相同的有效负载。

Sui 需要 WebSocket 连接吗？

这取决于你的用例。如果你需要推送式更新，请检查你的提供商和当前的 Sui 接口是否支持你关心的事件的订阅。如果不支持，使用大小合适的间隔和受监控的端点进行轮询是一种可行的替代方案。

我什么时候应该从公共端点切换到 OnFinality？

当你拥有真实用户、稳定或突发的负载，或者需要支持路径和可预测的容量时，就应该切换。OnFinality 通过其 RPC API 和 专用节点 产品提供 Sui，详细信息见 Sui 网络页面。

我可以同时使用多个 Sui RPC 提供商吗？

可以，对于生产应用来说，这通常是明智的。配置一个主端点和一个备用端点，监控两者，并在出现故障时绕行。这减少了任何单个提供商问题的影响范围。