交易的输入数据字段怎么读：四字节选择器、参数槽位与解不出来的情况

交易详情页那个长字符串

在区块浏览器打开一笔与合约交互的交易，输入数据（input data）栏常是一串以 0x 开头的十六进制长文；纯 ETH 转账时它通常是空的 0x。这串东西是调用方附给合约的“操作说明”：去这个合约，执行哪个函数，参数填什么。合约收到交易后按它执行，看不懂它的人只能看到一个黑盒，所以读懂结构和解码来源很值得花十分钟。

前四个字节是函数名片

按 Solidity ABI 规范，输入数据的开头四个字节是函数选择器（selector），取自函数签名哈希的前四个字节。比如一笔 ERC-20 转账的 calldata 以 0xa9059cbb 开头，对应的就是 transfer(address,uint256)。选择器之后是参数区：每个参数按 ABI 规则放进一个三十二字节的槽位，地址类参数占一槽、靠右对齐，数值类型同样写成三十二字节的大整数。所以“给某地址转 100 枚代币（18 位精度）”的输入数据，肉眼就能看到选择器、一个地址、一个数量值三段结构。字节级细节和 gas 成本在calldata 是什么？交易数据为什么这么贵里另有一篇。

为什么有的能解码有的不能

浏览器把输入数据显示成 transfer(to, tokenId) 这样的可读形式，前提是它把链上字节码和一份“已验证源码”对上了——开发者提交过源码、浏览器比对编译产物一致，才敢按 ABI 反推函数名和参数名。验证状态的含义与陷阱见区块浏览器显示“源码已验证”意味着什么？合约验证状态核对指南。解不出来的常见原因：合约没提交源码、项目自造的批量合约、代理转发后的多层封装，或这段数据根本不属于任何公开接口。解不出来不等于有问题，只是信息量下降；钱包签名页里的“查看详情”依赖同一类识别库，识别不到时显示的就是原始十六进制。

同一选择器不等于同一函数

四字节哈希存在碰撞可能，不同函数签名字节层面撞在一起的概率虽小但存在，浏览器偶尔也会出现解码歧义。可靠的做法是把“选择器→函数名”当作浏览器的推断，而不是事实本身；要看权威口径，就用已验证源码在浏览器里直接对函数名，或读项目方文档里列的接口说明。另外注意交易里的 ETH 价值和代币动账不总在输入数据里直说，代币层面的转入转出要从事件日志和内部交易找，两者的区别可看区块浏览器里的内部交易怎么查？ETH 转账和代币转账的区别。

签名前的防御读法

普通用户不必手拆十六进制，但签字之前至少完成三查：一查 to 地址是否是你预期的合约（对照项目官网、已验证合约页，而不是搜索结果）；二查钱包详情里解码出的方法名——凡是出现 approve、increaseAllowance、setApprovalForAll、permit、swap、withdraw 这类字样，说明这笔交易在处理授权或转出资产，必须停下来单独确认金额与对象；三查金额槽与你的意图量级是否一致，警惕小数位错位。遇到显示不出方法名的交易，把它当成“可能在做任何事”的黑盒，宁可不签。

先验地址，再验数据

读输入数据之前还有一道前提：to 地址本身对不对。输入数据再可疑，只要 to 是你信任的已验证合约，能力范围就被合约代码锁死；反过来，to 是钓鱼部署的合约时，哪怕输入数据看起来人畜无害也可能有坑。先拿地址对照项目官网和浏览器验证页，再去读数据，这个顺序和怎么判断一个地址是不是合约地址？里的核验路径一致。把“地址、方法名、参数”三项都对上，才算把一笔交易从头读到尾。

输入数据是链上交易的“工单原文”，它不承诺善恶，只如实记录要求合约做的事。理解它的结构，是为了在弹窗签名那一刻从被动变主动。本文只提供核验方法，不构成投资建议。