为何uint256(uint160(msg.sender))与uint256(bytes32(bytes20(msg.sender)))返回结果不同？

这两个转换结果不同的核心是字节数组补位方式与数值解析的字节顺序差异，具体拆解如下：

1. uint256(uint160(msg.sender))的转换逻辑 #

msg.sender是address类型，本质等价于uint160。这个转换流程：

• 直接将address转成uint160，完全保留原地址的数值（address本身就是20字节无符号整数）
• 再将uint160转成uint256时，Solidity自动在高位补0（零扩展），最终结果就是原地址对应的uint160数值，无任何位移。

2. uint256(bytes32(bytes20(msg.sender)))的转换逻辑 #

这个转换经过三次类型转换，每一步的处理导致数值被放大：

• 第一步：bytes20(msg.sender)：将address转成20字节数组，按大端序存储（地址最高位字节对应数组第一个元素，最低位字节对应数组最后一个元素）。
• 第二步：bytes32(bytes20(msg.sender))：将20字节的bytes20转成32字节的bytes32时，Solidity会在字节数组末尾（低字节端）补0，也就是在原20字节后添加12个0字节，最终bytes32结构为[原地址20字节][12个0字节]。
• 第三步：uint256(bytes32(...))：将bytes32转成uint256时，Solidity按大端序解析——数组第一个元素对应uint256最高位，最后一个元素对应最低位。这相当于把原地址数值左移了96位（12字节×8位/字节），也就是原数值乘以2^96，所以结果远大于前者。

验证计算 #

你给出的check1结果520786028573371803640530888255888666801131675076，乘以2^96（即79228162514264337593543950336），得到的结果正好是check2的返回值：

520786028573371803640530888255888666801131675076 × 79228162514264337593543950336 = 41260920106969412157321674113669319076297763250177730552014715551905833025536

等价转换的正确写法 #

如果想通过字节数组转换得到和check1一致的结果，可截断高位补位的字节，或直接简化转换步骤：

// 方式1：截断高位补位字节
function check2_fixed() public view returns(uint) {
    return uint256(uint160(bytes20(bytes32(msg.sender))));
}

// 方式2：最简洁的直接转换
function check_simple() public view returns(uint) {
    return uint256(msg.sender);
}

内容的提问来源于stack exchange，提问作者Sami Bouchnafa