图片原始来源 · 官方文档局部引用 · 公开页面局部截图；未修改页面内容
浏览器显示1000000，钱包却是1：先分清两个数
同一个代币余额，区块浏览器上写着 1000000，钱包里却显示 1，最可能的原因是两处展示的层次不同：一处给出合约中的原始整数，另一处已经按 decimals 做了格式化。换算关系是：
显示数量 = 原始整数 ÷ 10^decimals
以 decimals = 6 为例，1000000 ÷ 10^6 = 1。这只是假设示例，不代表某个具体代币的取值。
需要先修正一个常见预设：浏览器并不一定展示原始整数。很多区块浏览器、钱包和资产页面默认就会按代币元数据格式化，只有合约调用结果、原始交易数据或明确标注为最小单位的字段，才更可能是未换算的整数。因此看到“浏览器一个数、钱包另一个数”，第一步不是套公式，而是确认这两个数各自处于哪一层。
decimals 是什么，不是什么
ERC-20 标准把 decimals 定义为可选方法，用于返回代币使用的小数位数；标准举例说，返回 8 表示将代币数量除以 100000000 得到用户表示。标准同时提示，接口和其他合约不应假定这些可选值一定存在。转述到这里即可，其余需要自己判断：decimals 是展示元数据，不改变链上记录的整数余额，也不改变转账时传入的整数值。
因此不能把所有代币都按 18 位处理。18 位很常见，但只是某些合约的选择；decimals = 6、8、0 都合法。把 18 当默认值，遇到 6 位代币就会把数量算小一万亿倍。
几个可直接验算的例子
| 原始整数 | decimals | 计算 | 显示数量 |
|---|---|---|---|
| 1000000 | 6 | 1000000 ÷ 10^6 | 1 |
| 1000000 | 18 | 1000000 ÷ 10^18 | 0.000000000001 |
| 1234500 | 6 | 1234500 ÷ 10^6 | 1.2345 |
| 1234500 | 4 | 1234500 ÷ 10^4 | 123.45 |
| 42 | 0 | 42 ÷ 10^0 | 42 |
同一原始整数 1000000，6 位精度下是 1 个代币，18 位精度下是 0.000000000001 个。差别只来自 decimals，不是余额发生了变化。
反过来，若要在 decimals = 6 的代币中转 1 个，调用参数应写 1000000；写 1 实际只转 0.000001 个。看到一笔转账数值为 2500000，在 6 位精度下应读作 2.5 个，而不是两百五十万个。
数字吻合不能证明 decimals 正确
这是最容易出错的一步。假设钱包显示 5、某处原始整数是 5000000000000000000，用 18 位反推正好吻合，但这只能说明“18 位与该显示一致”，不能证明合约的 decimals 就是 18。别的组合也可能在四舍五入或显示截断后得到相同结果。确定 decimals 的唯一可靠途径，是核对所在链上该代币合约的元数据，例如读取合约的 decimals() 返回值，或查看与该合约地址对应的可信元数据记录。链不同、合约地址不同，同名代币也可能有不同精度。
同理，也不要对同一个数重复换算。如果某个界面已经显示 1，再拿它除以 10^6 就错了；换算只对原始整数做一次。
核对顺序
- 确认数字来源：是合约返回值、交易原始字段，还是界面已格式化的显示值。已格式化的值不再除以
10^decimals。 - 核对链与合约地址：在对应链上读取该合约的
decimals()，不要凭代币名称或常见惯例推断。 - 只换算一次：原始整数 ÷ 10^decimals，与另一处显示比对。
- 反向验算：显示数量 × 10^decimals，应能还原原始整数；末尾差异通常来自显示精度截断，而不是余额丢失。
- 检查显示精度：钱包可能只展示有限位小数，被省略的尾数仍存在于原始整数中。
常见误解
decimals不改变链上整数，转账、余额、授权额度始终以原始整数记录和传递。- 不是所有代币都是 18 位，ERC-20 中该方法是可选的，取值由合约决定。
- 浏览器不必然显示原始整数，很多界面已经格式化；判断前先看字段说明。
- 显示截断不等于余额减少，也不等于换算错误。
- 数字恰好吻合只是线索，不是
decimals的证明，仍须回到链和合约元数据核对。
记住“原始整数 ÷ 10^decimals，且只除一次”，再确认数字来源与合约元数据，这类显示差异通常就能解释清楚。