T3 · 一次交易从代码到链上

一个现实问题

你给产品上了一个提现功能。用户填金额，点确认，按钮转圈。

上线第一周，客服转来三类投诉：

• **「钱扣了，但对方没收到。」**你去区块浏览器一查，交易确实在链上，页面上有个红色的小图标，手续费扣了，金额一分没动。
• **「点了半小时，一直在处理中。」**你查日志，交易发出去了，哈希也有，但链上查不到这笔交易——它不在任何一个区块里，也没有报错。
• **「我怎么提了两次？」**用户等急了，又点了一次。两笔都成功了。

三件事的共同点是：你的代码只知道「我把请求发出去了」，不知道后面发生了什么。

一笔交易从你的进程里出发，到用户真的能说「到账了」，中间到底经过了哪几步？每一步各自会怎么坏？

思想实验

把一笔交易想成一封需要付邮费的挂号信，寄给一个按规矩办事到有些死板的邮局。

规矩有四条：

**第一，每封信必须写一个编号，从 0 开始，一封一个，不能跳号。**邮局严格按编号投递。如果 5 号还没处理，你寄出去的 6 号就只能在分拣间躺着——它不会报错，就是不动。

**第二，邮费由你自己填，填多少由你决定。**分拣员每次只挑当前出价最高的一批信来处理。填低了，信不会被退回来，它会一直躺着，直到某一刻路上没人了，才轮到它。

第三，同一个编号可以寄第二封。新的那封只要邮费明显更高，就会把旧的顶掉。这是取消和加速的唯一手段——你没有办法把一封已经交出去的信要回来，只能用同号的新信覆盖它。

**第四，最要命的一条：邮局收到信、按规矩投递了，不代表收件人签收成功。**信送到了，对方拒收，邮费照收。从邮局的账本上看，这封信「已投递」；从你的业务上看，这件事没成。

现在把这四条规矩和开头三类投诉对一下：

• 「钱扣了没到账」= 第四条，信送到了但被拒收。
• 「一直在处理中」= 第一条或第二条，跳号了，或者邮费太低。
• 「提了两次」= 用户重试时你用了新编号，于是那是两封独立的信，两封都投递了。

三个问题不是三个 bug，是同一个模型缺失的三种表现。

你来决定

回到那个提现功能。界面上什么时候可以显示「提现成功」？

观察结果

四个选项其实是在同一条流水线上的四个不同位置按下暂停键。

结论是：这条流水线有五步，而不是一步。每一步都有自己独立的失败模式，而且这些失败模式的表现形式完全不一样——有的会抛异常，有的会返回错误码，有的什么都不返回，就是不动。

最危险的是最后这一类。抛异常的你会处理，静默卡住的你不会——直到客服找上门。

建立模型

五步流水线：

每一步要做什么、会怎么坏：

有四件事值得单独拿出来说，它们是这一章真正的密度所在。

一、编号有两种读法，用错一种就会卡住。

查「这个地址下一个可用编号」时，你可以问节点「按已上链的算」还是「按包括内存池里待处理的算」。连续发多笔时必须用后者，否则第二笔会用和第一笔相同的编号，直接被拒。但用后者也有陷阱：如果第一笔永远不会上链，后面所有笔都会被它堵死。

二、费用不够不会报错，只会不动。

这是最反直觉的一点。传统系统里，请求要么成功要么失败；这里有第三种状态：被接受了，但无限期挂起。你的代码拿到了哈希，一切看起来正常，实际上什么都没发生。

三、交易失败照样扣费，而且扣的是已经执行掉的那部分。

从链的角度看这很合理：节点确实花了算力去执行它。但从用户角度看，这是「我付了钱，什么也没得到」。你的错误文案必须诚实地说明这一点，否则用户会认为是你吞了钱。

四、取消一笔交易的唯一方法，是用同一个编号发一笔新的。

没有「撤回」这个操作。你能做的只有：用相同编号、更高费用，发一笔把钱转给自己、金额为零的交易。哪一笔先被打包，另一笔就自动作废。注意新交易的哈希和旧的不同——你的系统必须同时追踪这两个哈希，否则会出现「明明成功了，系统显示失败」。

它叫什么

动手

curl -s -X POST <你的测试网-RPC-地址> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionCount",
       "params":["<你的地址>","latest"]}'

curl -s -X POST <你的测试网-RPC-地址> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionCount",
       "params":["<你的地址>","pending"]}'

curl -s -X POST <你的测试网-RPC-地址> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_gasPrice","params":[]}'

curl -s -X POST <你的测试网-RPC-地址> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionByHash","params":["<哈希>"]}'

curl -s -X POST <你的测试网-RPC-地址> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["<新哈希>"]}'

AI Lab

第一步：
列出一笔以太坊交易从构造到确认可能出现的十种失败情形。
每种给出：发生在哪一步、节点返回的典型错误信息原文、
用户侧看到的现象、手续费扣不扣、正确的处理方式。
用表格。

第二步：
这十种里，哪几种不会抛出任何错误，只会表现为「一直没动」？
对这几种，说明我的后端该用什么方法检测出来，检测周期设多久。

第三步：
给我一个在测试网上复现第 2、5、8 种的具体操作步骤，
只用 JSON-RPC 和一个普通钱包，不要用任何 SDK。

真实案例

改一个变量

带走的问题

本章自测