适用范围与阅读思路
这里讨论以太坊 JavaScript 应用的通用概念，不代表某个具体项目的实现。阅读代码时，可以依次问：请求发往哪里、由谁授权、调用什么接口、返回值表示哪一步完成。这四个问题能把分散的术语串起来。
节点、JSON-RPC 与 Provider
节点提供访问区块链的入口，JSON-RPC 规定应用与节点交换请求和结果的方式，Provider 则是库中连接数据访问能力的抽象。ethers.js、viem 等库帮助应用封装这些交互。
可以把这一层理解为通信关系：应用提出查询，连接组件传递请求，服务端返回结果。连接成功只说明具备访问入口，不能据此判断账户已经授权，也不能证明某次链上操作已完成。
Wallet 与 Signer：区分账户和授权
Wallet 涉及账户与密钥管理，Signer 表示签名能力。地址用于标识账户，私钥用于生成签名；知道地址并不意味着拥有签名权限。
阅读接口时，应区分消息签名、交易签名和广播交易。签名产生授权凭据，广播把交易提交给网络，这些动作的完成条件不同。钱包连接也不能直接等同于用户批准了后续所有操作。
ABI、合约调用与 Gas
ABI 描述合约函数、参数和事件等接口信息，帮助 JavaScript 库编码请求、解码结果。Gas 衡量执行所需的计算资源；Wei、Gwei 和 ETH 则属于金额单位。
ABI 可以理解为接口说明书，不能单凭它判断合约业务逻辑是否正确。读取状态与提交状态变更也需要分开理解：读取结果回答查询问题，提交交易涉及后续链上处理。Gas 估算是执行资源的估计，不应当作执行成功的证明。
Promise 与 await：理解结果所处阶段
MDN 对 Promise 的解释强调异步操作的结果：它可能待定、兑现或拒绝。then 处理后续结果，catch 处理拒绝，finally 用于结束时的处理；await 让异步函数等待结果或接收错误。
在区块链应用中，关键是查看接口承诺返回什么。取得查询结果、获得签名、拿到交易提交结果，可能分别对应不同的 Promise。某个 Promise 兑现，只能说明该接口定义的步骤完成，不能自动推导出交易执行成功。
常见问题：为什么示例不能直接套用
同一术语在不同库中可能对应不同对象和方法，库版本也会影响调用形式。以太坊 JavaScript API 文档适合建立交互层次的认识，MDN Promise 文档适合理解异步语义。实际阅读项目时，还需对照所用版本的接口定义，确认参数、返回类型及完成条件。