上周三晚，陈某用 TPWallet 转一笔 USDT。Gas 设到网络均值上方，界面却一直显示“打包中”的。他切 Wi-Fi、重启 App，tpwallet 节点延迟仍平时 180ms 跳还有 2100ms。链上浏览器里交易已经广播，余额也正常了，问题出在客户端连上的 RPC 节点响应太慢。这个案例不复杂，却暴露一个常见误会，tpwallet 节点延迟不等于链拥堵了，更多时候是入口节点在排队，用户感受到的卡顿被放大成“转账失败”。TPWallet 一般内置多个公共节点，默认按测速结果选的。测速快只说明握手快，不代表 eth_call 和 eth_getTransactionReceipt 不被限流。
陈某手动换到另一个节点后。nonce 和 pending 状态刷新明显变快的，那笔交易确认仍要等矿工打包。tpwallet 节点延迟至少分两层，连接延迟与查询延迟的。
低连接延迟，可能换来高查询延迟，特别的在免费 RPC 被大量请求挤满时。我让他先看节点区块高度的。一个节点显示高度落后十几块吧？另一个和主网同步，却查不到交易哈希。差别来自缓存与索引策略的。tpwallet 节点延迟，如果伴随高度落后，不要急着反复点“加速”，先换节点、再查哈希。然后对比待处理交易数。他那笔转账在第三个节点上三分钟显示成功，前两个节点一个卡 pending，一个没有回执。
节点切换不是玄学，是查询路径变了。换节点也解决不了所有问题。
Gas 低于当前 base fee，再快的节点也救不了。对普通用户，稳定私有 RPC 一般比免费公共节点省心，代价是成本或信任。遇到 tpwallet 节点延迟反复出现，保留交易哈希，多节点交叉验证，改 RPC。延迟只是信号。根因可能在节点、链上状态或交易本身。
