图片资料：官方来源
在以太坊交易里，input data（也常写作 data 或 input）是交易对象中的一个可选字段，用来携带任意字节数据。它和 value（随交易发送的 ETH 数量）是两个独立字段。input data 不是“转账备注”，也不是可以随手改写的文本说明。对于调用合约的交易，它通常承载“要执行哪个函数、带什么参数”的指令；改掉它，可能直接改变交易的实际行为。
| 字段 | 含义 | 能否当备注 |
|---|---|---|
value |
发送的 ETH 数量，以 wei 计 | 不是备注，是资产数量 |
input data |
可选字节数据，合约调用时承载 calldata | 不是自由文本备注 |
to |
交易接收地址，可能用于调用合约 | 决定调用对象，不是备注 |
gasLimit |
交易最多可消耗的 gas | 影响执行上限与费用 |
以太坊文档把交易描述为由账户发起的签名指令，并列出 value 是转账 ETH 数量、input data 是可选任意数据字段（来源：ethereum.org《Transactions》）。这说明二者在协议层就承担不同职责。需要补充的是，input data 确实可以编码一段文本，但“能放字节”不等于“能像备注一样随意改”：一旦接收方是合约，这段字节往往会被当作调用指令解释，而不是被当作无害说明。
常见合约调用中，input data 的前 4 个字节是函数选择器，后面是按 ABI 编码的参数。比如一次 ERC-20 转账调用，选择器可能是 0xa9059cbb，后面依次编码收款地址和数量。钱包或浏览器能借助 ABI 把它解码成“调用 transfer，向某地址转多少代币”。但选择器只是函数签名哈希的前 4 字节，不同函数可能碰撞；仅凭 4 字节不能保证唯一确定语义，必须结合目标合约的实际 ABI 或已验证源码判断。没有对应 ABI 时，看到的只是一串十六进制。
这里有一个容易混淆的点：合约地址是 to，不等于最终代币收款人。以 ERC-20 的 transfer 为例，交易里的 to 是代币合约地址，真正的收款地址编码在 input data 的参数里。若有人把 input data 当成“备注”改掉参数，代币可能转给另一个地址，或者调用失败。普通 ETH 转账也可以附带非空 input data，所以“data 非空”不能单独证明这是一次合约调用，更不能证明调用成功；还要看 to 的实际代码、调用是否成功、事件日志是否吻合。
一个实用的判定方法是：先看 to 指向的地址是什么，是否可能执行合约代码；再看 input data 是否为空；非空时，用目标合约 ABI 解码前 4 字节和参数；最后核对解码结果与钱包展示、事件日志是否一致。浏览器里的“解码”只是辅助展示，不是安全保证；遇到无法解码或选择器多义时，应按高风险交易处理。
假设一笔交易 value = 0，to 是某 ERC-20 合约，input data 以 0xa9059cbb 开头，后接 32 字节收款地址和 32 字节数量。按 ABI 规则，地址参数左侧补零，数量按最小单位编码。这里 value = 0 表示这笔交易本身不附带 ETH，但 input data 里的参数仍会指示代币合约执行转账；真正变动的是代币余额，而不是交易层的 ETH 数量。若把数量字段改成别的值，语义就变了；若把收款地址参数改掉，代币去向也变了。所以 input data 不能像备注一样随便改。
还可以从“谁解释这段数据”来理解。普通转账的接收方如果不执行代码，input data 可能只是附带的字节，不会自动变成对方账户里的文字备注；而合约接收方会按自己的代码和 ABI 去解释它。同一串字节，在不同合约、不同 ABI 下可能有不同含义，甚至无法解码。因此，看到一笔交易的 input data 非空，不能直接下结论说“这是一次成功的合约调用”，也不能只看浏览器给出的摘要就放心签名。
对普通用户来说，最稳妥的做法不是记住某个选择器，而是确认三件事：to 是不是你预期交互的合约；钱包展示的调用内容能否与 ABI 解码结果对应；交易成功后的事件日志是否与预期一致。若钱包只能显示原始十六进制，或解码结果与页面描述不一致，应暂停操作。input data 是交易指令的一部分，不是可随便编辑的备注栏。