NEAR 浏览器：如何读取、验证和查询 NEAR 区块链数据

NEAR 浏览器实际展示的内容

NEAR 浏览器是索引后的 NEAR 数据的前端。它以人类可读的布局呈现区块、交易、执行结果、收据、账户余额、访问密钥和合约调用。公共浏览器如 NEAR Explorer Selector、NearBlocks 以及 NEAR Intents 浏览器等专用视图各自索引并呈现链的不同部分，因此同一笔交易在不同视图中可能看起来不同。

重要的区别在于浏览器作为展示层与 NEAR RPC 作为真相来源之间的差异。浏览器通常运行自己的索引器，可能落后链头几秒或几分钟，可能修剪历史细节，或使用启发式方法标记数据。当准确性至关重要时，请通过直接 RPC 调用确认浏览器视图。关于端点选择，RPC 助手涵盖了具体的提供商选择；本文侧重于方法。

• 区块浏览器显示区块高度、时间戳和生产者。
• 交易视图显示已签名交易及其结果。
• 收据视图显示跨合约执行，这是 NEAR 与账户模型链的不同之处。
• 账户视图显示余额、存储使用量、代码哈希和访问密钥。

假设和先决条件

以下步骤假设您有一个 NEAR RPC 端点 URL，如果包含 API 密钥，应将其视为机密。您需要 curl 或带有 fetch 的 JavaScript 运行时，以及可选的 Python 用于脚本编写。只读查询不需要私钥；签名仅在提交交易时需要，这不在本文范围内。

设置环境变量以使示例保持可移植性。切勿将带密钥的端点提交到代码仓库。如果您正在选择提供商，请从 OnFinality NEAR 网络页面和 RPC 端点指南开始，然后使用 RPC 助手获取直接推荐。

export RPC_URL="https://your-near-rpc-endpoint"
# Optional: confirm the endpoint responds
echo $RPC_URL

一个心智模型理解 NEAR 执行模型

在 NEAR 上，交易与执行并不相同。已签名交易被包含在区块中，产生包含一个或多个收据的结果。收据是跨合约工作的单位：函数调用可以生成在后续区块中执行的收据。这就是为什么浏览器可能显示交易已最终确定，而收据仍在处理中，以及为什么成功的交易结果并不保证所有下游收据都成功。

当您阅读浏览器时，请遵循链条：交易哈希，然后结果，然后每个收据 ID，然后每个收据结果。当您查询 RPC 时，使用相同的顺序。将交易视为全部故事是 NEAR 故障排除中最常见的混淆来源。

• 交易：用户或服务提交的签名请求。
• 执行结果：在区块中应用该交易的结果。
• 收据：工作单位，通常是跨合约调用。
• 收据结果：该单位的成功或失败，包含日志和消耗的 gas。

使用 curl 验证交易

NEAR RPC 暴露了与浏览器显示内容相对应的 JSON-RPC 方法。要检查交易，请使用交易哈希和签名账户调用 tx。将占位符替换为来自浏览器 URL 或您自己日志的值。

响应包括交易、其执行结果以及任何收据。读取 status.SuccessValue 获取顶层结果，然后检查 receipts_outcome 了解下游工作。非空的 Failure 对象表示执行错误，日志通常包含合约级别的理由。

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": "near-explorer-guide",
    "method": "tx",
    "params": {
      "tx_hash": "TRANSACTION_HASH",
      "sender_account_id": "SENDER_ACCOUNT.near",
      "wait_until": "FINAL"
    }
  }' | python3 -m json.tool

在 JavaScript 中复现浏览器视图

一个小脚本使验证可重复。下面的函数获取交易，打印顶层状态，并列出收据结果及其状态和消耗的 gas。这与浏览器渲染的数据相同，只是缺少索引器的标签和格式。

使用 Node 18 或更高版本运行，它包含 fetch。将端点保留在环境变量中，如果粘贴输出到工单中，只记录非敏感字段。

const RPC_URL = process.env.RPC_URL;

async function inspectTx(txHash, sender) {
  const res = await fetch(RPC_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      jsonrpc: '2.0',
      id: 'near-explorer-guide',
      method: 'tx',
      params: { tx_hash: txHash, sender_account_id: sender, wait_until: 'FINAL' }
    })
  });
  const { result, error } = await res.json();
  if (error) throw new Error(JSON.stringify(error));

  const outcome = result.status;
  console.log('top-level:', outcome.SuccessValue !== undefined ? 'success' : 'failure');
  for (const r of result.receipts_outcome || []) {
    const s = r.outcome.status;
    console.log(r.id, s.SuccessValue !== undefined ? 'ok' : 'failed', 'gas:', r.outcome.gas_burnt);
  }
}

inspectTx('TRANSACTION_HASH', 'SENDER_ACCOUNT.near').catch(console.error);

查询区块、账户和合约状态

浏览器还显示区块级和账户级数据。block 方法返回区块头和分块；view_account 方法返回余额和存储使用量；view_state 返回合约状态键。这些调用是只读的，可以安全地针对生产端点运行，但受速率限制。

对于合约状态，优先使用带前缀的 view_state，或使用返回所需字段的视图调用。从大型合约转储完整状态可能很慢，并可能触及响应大小限制。如果需要历史状态，请注意 NEAR RPC 通常提供当前状态；历史查询需要索引器或归档服务。

curl -s -X POST "$RPC_URL" -H 'Content-Type: application/json' -d '{
  "jsonrpc":"2.0","id":"block","method":"block",
  "params":{"finality":"final"}
}' | python3 -c "import sys,json; b=json.load(sys.stdin)['result']; print(b['header']['height'], b['header']['hash'])"

curl -s -X POST "$RPC_URL" -H 'Content-Type: application/json' -d '{
  "jsonrpc":"2.0","id":"acct","method":"view_account",
  "params":{"finality":"final","account_id":"ACCOUNT.near"}
}' | python3 -m json.tool

比较浏览器和 RPC 的结果表流程

当浏览器视图与您的应用程序不一致时，构建一个小型比较表，而不是用截图争论。对于调查中的每笔交易，从两个来源记录以下字段，并记录每次观察的时间戳。不要填写您未观察到的数字；该表是测量记录，不是估计。

最新区块高度的不匹配通常表示索引器滞后。收据数量或状态的不匹配更为严重，应通过信任 RPC 响应来解决，然后检查浏览器的索引器是否已赶上。记录查询时的区块高度，以便比较可重现。

解决常见的浏览器差异

大多数差异属于几类。未知交易错误通常意味着交易尚未被包含，哈希被截断，或发送者账户错误。交易显示成功而用户报告失败通常意味着下游收据失败。余额差异可能来自质押、存储成本或待处理收据。

如果浏览器显示合约调用成功但您的应用程序看到错误，请检查您的应用程序是读取交易结果还是收据结果。如果您按收据 ID 查询，请确认您使用的是收据 ID 和产生收据的账户，而不是原始签名者。

• 未知交易：等待最终性，然后使用确切的哈希和发送者重新查询。
• 成功但用户可见失败：检查 receipts_outcome 中的 Failure 对象和日志。
• 余额不匹配：考虑存储使用量、质押锁定和进行中的收据。
• 缺少历史：端点可能被修剪；使用索引器或归档获取旧数据。
• 速率限制：批量或缓存读取，而不是每个区块轮询。

浏览器优先工作流的局限性和权衡

浏览器非常适合人工调查，但不适合作为记录系统。它们在您和链之间引入了一个索引器，这增加了延迟和第二个可能与 RPC 不一致的实现。它们还应用标签和启发式方法，这些对于浏览很方便，但不适合自动化决策。

对于生产系统，将浏览器视为调试辅助工具，将 RPC 视为接口。如果您需要历史查询、聚合分析或大规模低延迟读取，请考虑专用节点或索引管道，而不是抓取浏览器页面。OnFinality 的专用节点产品和 API 服务页面描述了基础设施选项；RPC 定价单独记录。

• 浏览器数据可能落后于链头。
• 标准 RPC 通常不提供历史状态。
• 标签和标记是启发式的，不是权威的。
• 抓取浏览器 HTML 很脆弱；改用 JSON-RPC。

后续步骤：从浏览到程序化访问

一旦您能通过 RPC 调用复现浏览器视图，下一步是决定您需要托管端点还是自己的节点。对于读密集型应用程序，具有明确速率限制的可靠托管 RPC 端点通常足够。对于索引、归档查询或自定义保留，专用节点让您控制修剪和吞吐量。

查看 NEAR 网络概述，比较 RPC 定价，并使用 RPC 助手获取具体的端点推荐。然后将上述脚本改编到您的监控中：对失败的收据发出警报，通过比较最新区块高度跟踪索引器滞后，并为事件保留比较表。

• 阅读 OnFinality NEAR 网络指南：/en/networks
• 比较托管 RPC 选项：/en/api-service
• 查看 RPC 定价：/en/pricing/rpc
• 探索专用节点：/en/dedicated-node
• 通用端点指南：/en/learn/rpc-endpoints-guide