摘要
“NEAR 检查”通常指以下三种情况之一：在 NEAR 区块链上确认某笔交易或某个账户、验证你的 RPC 端点是否正常响应，或者在上线前验证钱包或合约交互。最快的路径是：用区块浏览器进行人类可读的查询，用 JSON-RPC 调用进行程序化检查。
本页提供开发者在 NEAR 上最常执行的实用检查：读取账户余额、获取交易结果、确认区块高度，以及探测 RPC 端点的健康状态。它还会说明何时公共端点就足够，以及何时应迁移到专用 RPC 提供商（例如 OnFinality）以获得稳定访问。
NEAR 使用 JSON-RPC 接口，提供 query、block 和 tx 等方法。下面的示例展示如何用 curl 和 JavaScript 执行这些检查，以及如何解读响应，从而区分网络问题、RPC 问题和应用缺陷。
关键要点
- NEAR 检查可以指交易查询、账户余额读取或 RPC 健康探测；每种用途使用不同的方法。
- NEAR JSON-RPC 的
query、block和tx等方法无需自定义索引器即可覆盖大多数验证需求。 - 区块浏览器最适合人类可读的查询；JSON-RPC 更适合 CI、监控或后端服务中的自动化检查。
- 通过检查响应结构和区块高度，区分交易失败、RPC 节点滞后和请求格式错误。
- 公共端点适合开发和低频检查；生产检查通常需要具有可预测访问能力的专用 RPC 提供商。
- OnFinality 提供 NEAR RPC API 访问和专用节点选项；请查看支持的网络页面了解当前可用性。
你实际需要哪种 NEAR 检查？
在编写请求之前，先确定你要验证什么。大多数“NEAR 检查”任务分为四类：确认交易结果、读取账户或合约状态、检查 RPC 端点是否健康，以及验证钱包或 dApp 连接。每类都有不同的方法和不同的失败模式。
使用下表选择正确的工具。如果你需要人类可读的视图，区块浏览器更快。如果你需要自动化检查，JSON-RPC 是正确的层级。
| 标准 | 检查内容 | 为什么重要 |
|---|---|---|
| 交易结果 | 交易哈希、最终执行状态，以及失败发生在交易还是 receipt 中 | 交易可以被打包进区块，但在执行期间仍然失败；只检查是否打包会产生误报 |
| 账户余额 | 账户 ID、可用余额、质押余额和存储使用量 | NEAR 账户分别持有流动余额和质押余额；忽略存储或质押的余额检查可能产生误导 |
| RPC 健康状态 | 最新区块高度、响应时间，以及重复调用中的错误率 | 能响应但落后于链的节点会返回过期状态，并静默破坏检查 |
| 钱包或 dApp 连接 | 网络 ID、账户访问密钥，以及钱包指向 mainnet 还是 testnet | 开发中大多数“失败”的检查是网络不匹配，而不是链错误 |
使用 curl 执行 NEAR JSON-RPC 检查
NEAR 暴露 JSON-RPC 接口。具体端点取决于提供商和网络。对于生产或重复检查，请使用你信任的提供商的端点，并将其保存在环境变量中，而不是硬编码。
下面的示例展示区块高度检查的请求结构。将端点替换为你的提供商的 NEAR RPC URL。如果你正在评估 OnFinality，请在围绕它构建之前，在支持的网络页面上确认当前的 NEAR 端点和网络支持。
- 使用
block并设置finality: "final"获取最近的最终区块，确认节点正在跟随链。 - 使用
query并设置request_type: "view_account"读取账户余额。 - 使用
tx并传入交易哈希和发送方账户 ID 获取交易结果。 - 保持 JSON-RPC 的
id字段在每个请求中唯一，以便在日志中关联响应。
正确解读 NEAR 交易结果
NEAR 交易响应包含的不仅仅是成功标志。顶层的 status 描述交易本身，而 transaction_outcome 和 receipts_outcome 描述执行情况。交易可以有效并被打包，而其某个 receipt 失败。
在构建检查时，检查 receipt 结果中的失败状态，而不是只信任顶层结果。这是 NEAR 集成中误报“成功”的最常见来源。
| 标准 | 检查内容 | 为什么重要 |
|---|---|---|
| 顶层状态 | 交易是否被打包并接受 | 告诉你交易已到达链上，而不是其效果已成功 |
| Receipt 结果 | 每个 receipt 的状态和任何失败原因 | 跨合约调用可能在交易被接受后失败 |
| 日志 | 执行日志中的 panic 消息或合约级错误 | 日志通常包含检查失败的实际原因 |
| 区块最终性 | 区块是最终状态还是乐观状态 | 乐观结果可能变化；最终结果对结算检查更安全 |
从脚本探测 NEAR RPC 健康状态
如果你的检查实际上是关于端点是否可用，请按照应用程序使用它的方式探测。随时间重复执行简单的区块高度调用，比单次请求更能揭示滞后、超时和间歇性错误。
从与应用程序相同的区域和网络路径运行探测。从笔记本电脑通过但从生产环境失败的检查，通常指向网络出口、DNS 或提供商侧访问规则，而不是 NEAR 链本身。
- 记录最新区块高度，并与第二个提供商或区块浏览器比较以检测滞后。
- 将错误码与超时分开跟踪；它们表示不同的问题。
- 探测你依赖的两个读取方法，例如
query和block，而不仅仅是一个。 - 对持续失败告警，而不是单次未命中请求，以避免噪音。
何时公共 NEAR 端点足够，何时不够
公共端点适合学习、一次性检查和早期开发。它们是共享的，因此行为可能随负载变化，并且可能不支持你需要的每个方法或历史查询。
当检查是生产工作流的一部分、在流量高峰期间需要稳定访问，或需要归档数据进行历史验证时，应迁移到专用或托管 RPC 提供商。OnFinality 提供 RPC API 访问和专用节点基础设施；请查看支持的网络页面确认 NEAR 可用性，并查看定价页面将请求量映射到套餐。
| 标准 | 检查内容 | 为什么重要 |
|---|---|---|
| 开发和一次性检查 | 公共端点可用性和方法覆盖范围 | 低流量很少需要专用基础设施 |
| 自动化生产检查 | 可预测的访问、故障转移和监控 | 共享端点可能引入可变延迟和速率限制 |
| 历史验证 | 较旧区块和交易的归档数据可用性 | 修剪节点无法回答历史查询 |
| 高频探测 | 请求限制和与其他工作负载的隔离 | 健康探测不应与用户流量竞争容量 |
NEAR 检查失败的调试路径
当 NEAR 检查失败时，从外到内排查：确认网络、确认端点、确认请求，然后确认结果解读。大多数失败在这四个步骤之一得到解决。
| 标准 | 检查内容 | 为什么重要 |
|---|---|---|
| 网络不匹配 | 端点和钱包配置中的 Mainnet 与 testnet | 账户和交易不存在于跨网络 |
| 请求格式错误 | JSON-RPC 方法名、参数类型和必填字段 | NEAR 对无效参数返回结构化错误，很容易被忽略 |
| 节点滞后 | 最新区块高度与参考值比较 | 滞后节点返回旧状态，使有效交易看起来缺失 |
| 结果误读 | Receipt 结果和日志，而不仅仅是顶层状态 | 已接受的交易在执行期间仍可能失败 |
常见问题
“NEAR 检查”是什么意思？
它通常指在 NEAR 区块链上验证某些内容：交易、账户余额、合约状态或 RPC 端点的健康状态。正确的方法取决于你要检查什么。
如何检查 NEAR 交易？
使用 NEAR 区块浏览器获得人类可读的视图，或使用交易哈希和发送方账户 ID 调用 tx JSON-RPC 方法。检查 receipt 结果，而不仅仅是顶层状态。
如何检查 NEAR 账户余额？
使用 request_type: "view_account" 和账户 ID 调用 query 方法。响应包含流动余额、质押余额和存储使用量，应一起解读。
我可以用简单请求检查 NEAR RPC 健康状态吗？
单次 block 调用确认端点有响应，但随时间重复探测更适合检测滞后和间歇性错误。将区块高度与第二个来源比较。
NEAR 检查需要专用 RPC 提供商吗？
开发和偶尔检查不需要。对于生产工作流、高频探测或历史验证，托管或专用 RPC 提供商提供更可预测的访问。查看 OnFinality 的支持网络和定价页面了解当前选项。
Ethereum
Solana
Polygon
Base
Arbitrum
BNB链
Polkadot
Optimism
