发现页消失的Sushi：从轻节点到合约调试的一次问题侦察
案例背景：一位用户在TP Wallet“发现”页无法看到Sushi或其交易对。本文以该事件为线索，按侦查流程逐项排查，给出技术与产品层面的深度分析。
第一步——复现与日志采集。复现场景包括网络（主网/侧链）、钱包版本、RPC节点、更换设备与清缓存。记录发现页请求、token-list拉取、Indexer返回和前端过滤规则。
第二步——轻节点限制。轻节点为节省存储与带宽往往不索引全部合约与事件，导致基于链上事件的token探测失效。建议TP Wallet引入远端索引器或混合策https://www.fgqjy.com ,略，并允许按地址手动添加代币。
第三步——高级身份认证与项目治理。Sushi等跨链项目可能更换合约或注册信息。若未通过钱包侧的信任目录或未完成合约验证，前端会屏蔽显示。建立动态信任列表、SBT/ENS联合认证可提高识别率。
第四步——高级支付安全。支付流程需加入交易模拟、EIP-712签名校验、白名单路由检查与多签策略。当发现页涉及桥接或聚合器调用时，钱包应在展示前做安全评分。
第五步——新兴支付技术的影响。Layer2、账户抽象（EIP-4337）、paymaster和gasless交易改变了发现逻辑：原有基于普通tx的索引失准，必须补入rollup索引与打包器兼容层。
第六步——合约调试与工具链。使用Etherscan验证源代码、借助Tenderly/Hardhat回放交易、抓取事件日志确认工厂/路由是否生成了预期池。若合约迁移，需更新ABI与元数据。
第七步——市场趋势分析。Sushi从AMM向聚合器、跨链扩展，listing规则分散化，钱包应跟进治理公告与跨链桥状态以避免误判。
结论与建议：建立可配置的索引器+信任目录、支持手动导入并加强交易前安全评分，将显著减少“在发现页找不到Sushi”的情况。该案例表明，产品体验问题常是轻节点策略、认证机制与新支付技术协同失配的结果，需要跨团队联动解决。
评论
小舟
很实用的排查流程，我按步骤查到是RPC回退导致的，解决了问题。
CryptoSam
关于EIP-4337的补充解释很到位，希望钱包能快点支持AA账号。
李锦
建议把手动添加代币的UX再优化一下，很多新手不敢用地址导入。
Nova
结合Tenderly进行回放是关键，避免了误判合约迁移带来的困惑。
Trader88
市场趋势那段分析透彻，尤其指出了Sushi的跨链策略对钱包展示的影响。