精度小数位与路由：明明有余额，兑换为什么一直失败

钱包里明明有币，兑换却反复失败，是 DeFi 里最消耗耐心的一类故障。它的难点在于钱包只报一句执行回滚，不告诉你为什么。失败的原因分布在三层——代币层、授权层、路由层——按顺序排查可以把玄学还原成清单。

先说最隐蔽的代币层：小数位。每种 ERC-20 的 decimals 由部署时写死，常见是十八位，稳定币多为六位，长尾资产里见过零位、一位甚至非标准实现。钱包界面显示的十五个币，进链上合约层是一个用整数表达的最小单位数，若前端的精度假设与合约实际 decimals 不一致，提交的金额会整体差若干个数量级：要么变成天文数字触发余额检查失败，要么小到在路由的中间计算里被向下取整为零，任何需要它做输入的步骤直接 revert。排查动作很简单：在区块浏览器读代币合约的 decimals 值，对照失败交易里记录的金额参数，数量级不对就能锁定这一层。复现路径也清楚——凡是金额栏能自由输入的小额兑换，用最小可行金额试一次，失败形态会分化得更明显。

授权层排第二。兑换失败与余额不足长相一致，但成因是调用方没有你代币的支出许可，或许可额度低于订单金额。标准修复是发起一次授权交易把额度设给正确的路由或许可管理合约，再重试兑换。这里有一个容易忽略的变体：部分协议体系要求授权对象是一个中间管理合约而不是路由器本身，钱包若按旧习惯授权给了别的合约地址，兑换依旧失败。核对方法是从协议官方文档确认它使用哪个合约收款，再对照授权记录。还有一类边界场景值得警惕——某些代币采用转账伴随回调的特殊实现，路由合约若不支持回调代币的转账模式，即使授权正确也失败，这类问题通常连其他用户也在同一池子遇到，查区块浏览器的同合约失败记录即可确认。

第三层是路由与池子兼容性。用户点兑换时执行的不是单个池子，而是一条由路由器编排的多跳路径，任何一跳的合约逻辑与你的输入不兼容都会导致全笔回滚。三个常见变体：其一，路由选中一个池子，但该池子对新代币的转账实现有假设（比如要求代币不收费、不回调），你的币恰好不满足；其二，滑点保护被设置得过窄，多跳路径上的正常损耗触发保护性回滚，表现成反复失败但报错不指向价格；其三，输入输出代币的包装或解包装步骤失败，比如用原生币兑换包装代币的池子，路径里需要 wrap 步骤而你的操作环境不支持。

据此可以整理一条通用处理顺序：查失败交易的回滚细节，看 revert 发生在路径第几跳与哪个函数；查代币合约的 decimals 与转账实现；核对授权对象与合约文档要求；把滑点从窄改宽一档再试一次以区分价格保护与结构问题；如果问题在路由选路，切换到手动指定池子的模式或换一条由不同跳数组成的路径。整个过程不依赖任何客服结论，全部证据都在链上和合约文档里。最后提醒一条安全边界：修复过程中若被引导去撤销再重新授权、或安装某浏览器插件来让交易通过，先停下来核对官方公告渠道；失败排查的标准动作只发生在浏览器标签和官方文档之间，不该发生在任何催促你的第三方页面上。

本文只讲解协议机制，不构成投资建议。文中出现的比例、期限与流程均为机制示例，不是实时数据，实际操作前请以协议官方文档与链上参数为准。