做 TRON 对接时，文档里会出现好几套「都能查链、都能发交易」的入口。它们不是重复造轮子，而是 同一套链，四种不同的对外「协议皮肤」：有的偏 TRON 原生钱包接口，有的偏 以太坊工具兼容，有的是 托管索引产品。理清这四类，排错和选型会省很多时间。
一、先放总表：四者是什么、各干什么
一句话：前两个是「TRON 原生钱包 HTTP 协议」的两张脸（新 vs 稳）；第四个是「ETH 语法的读链面」；第三个是「Tron 官方托管的产品 API」。
二、FullNode HTTP：协议主入口（/wallet）
- 定位：TRON 自诞生以来文档里最核心的 FullNode HTTP。
- 特点：
- 路径以
/wallet/ 为前缀；
- 可读可写：大量接口用于 创建未签名交易、广播、资源操作、智能合约调用；
- 数据 最新：适合「交易刚进块就给用户反馈」、和链尖强相关的逻辑。
- 注意：链尖附近 理论上 仍有重组空间，动账一般要叠加「回执成功 + 确认深度 + 是否走更稳的读路径」等策略，而不是单靠「看见交易」。
三、Solidity HTTP：同一协议下的「稳读」侧（/walletsolidity）
- 定位：仍是 java-tron 官方 HTTP，不是另一条链。
- 特点：
- 前缀
/walletsolidity/；
- 几乎只读，不负责广播；
- 是已经确认的，和FullNodeHttp相差19个确认区块的确认数据
- 文档与工程习惯上，更常承担 已更充分确认一侧 的查询，适合 交易所充值入账、结算、审计式历史读。
- 和 FullNode 的关系：不是「谁更标准」——两个都标准，是 读写与数据视角分工；很多团队会把 写 + 追新读 打 FullNode，对账读 打 Solidity。
四、Full Node JSON-RPC：以太坊语法的「兼容面」
- 定位：TRON 节点上提供的 JSON-RPC 2.0 接口，方法集合以
eth_* 为主（如 eth_chainId、eth_getBlockByNumber、eth_call 等），目的是 兼容以太坊工具链的调用方式。
- 和
/wallet 的区别：
/wallet：TRON 自己的 protobuf/JSON 习惯、合约地址与参数风格都是 TRON 原生；- JSON-RPC：调用习惯贴近 以太坊节点（Geth 等），便于同一套脚本、库在多条 EVM 系链上迁移。
- 注意：
- 它是 「兼容层」，覆盖范围与
/wallet 全量能力并不一一等同；复杂 TRON 特有操作往往仍要回到 /wallet 或 SDK。
- 实际部署里 端口、是否开启、是否对外 取决于节点与托管方文档。
五、TronGrid v1：节点之上的「索引 + 产品 REST」
- 定位：TronGrid 在节点前做的
/v1 REST，例如按账户查 TRX/TRC20 流水、按合约查事件等。
- 和前三者的根本不同：
- 前三者都是 「你连的是 TRON 节点协议（HTTP 或 JSON-RPC）」；
- TronGrid v1 是 「你连的是 TronGrid 服务」——URL、分页（如 fingerprint）、限流、API Key、字段命名都以 TronGrid 文档为准。
- 最擅长：充值监控、运营后台、列表型查询；代价是 依赖第三方与索引延迟，业务上要定义「何时算到账」（例如
only_confirmed + 自家确认数）。
六、用一张「选择流程」收束（写进团队规范里）
七、结尾：别混用「标准」这个词
- 协议标准：FullNode HTTP + Solidity HTTP（以及节点上的 JSON-RPC 层）都属于 链节点暴露的能力，由 java-tron / 部署方式 决定你能否访问。
- 产品标准：TronGrid v1 是 官方生态里常用的托管产品面，方便但不等于链上唯一真理；入账规则仍要你自己闭环。
- JSON-RPC：是 「调用形态标准」（像以太坊），不是替你把 TRON 特有流程都包圆。
把四类分清楚后，再读 TRON API Reference 侧栏，你会很自然知道：该点进哪一章、报错该去查节点日志还是 TronGrid 限流。
