thirdweb v5 查不到 tokenURI：核对版本、签名和读取状态
链小知 · 进阶 · 核验 · 依官方文档整理
从 v4/v5 混用、客户端初始化和 uint256 参数入手，确认读取到底得到 URI 还是遇到 RPC/合约错误。
开始前准备
- 准备锁定版本的 thirdweb 工程、目标 chain/address/tokenId 和已有错误记录。
- 浏览器只使用已配置的 Client ID；服务器 Secret Key 不进入前端。RPC/托管服务配额按账号现状核对，不用钱包签名排查读取。
1. 先统一到 v5 的导入方式
检查 package 和 imports：本篇用 thirdweb、thirdweb/chains、thirdweb/react，不能混着使用 @thirdweb-dev/sdk 的 contract.call 或旧 useContractRead。v5 getContract 同步取得合约对象，而 readContract 是异步读取；迁移时分别核对，避免 await 放错位置掩盖类型问题。
检查结果：实际依赖、导入与 getContract/readContract 调用属于同一代 SDK。
2. 核对 Client 与链地址组合
createThirdwebClient 在浏览器用 clientId，在服务器才可用 secretKey；getContract({client, chain, address}) 的三个输入都要明确。官方示例 chain 为 Sepolia，不能只换 tokenId 就去读主网合约；保存脱敏认证错误和当前服务额度信息。
检查结果：Client 初始化成功路径明确；chain/address 与目标合约证据一致。
3. 写完整函数签名并给 bigint 参数
按 ABI 用 method: "function tokenURI(uint256 tokenId) returns (string)"、params: [1n]，把 1n 换成已知 tokenId。uint256 用 bigint，地址不能放到 tokenId 参数位置。签名明确时 SDK 可推导参数类型；resolveMethod("tokenURI") 则需额外解析 ABI，不能期待同样的类型保障。
检查结果：函数名、参数类型、返回类型与实际 ABI 对上；tokenId 保留整数精度。
4. 把 Promise、加载态和 revert 分开
脚本用 await readContract 获取结果；React 使用 useReadContract 的 data/isLoading 及返回错误状态。RPC 认证失败、节点请求失败或合约 revert 都不能兜底成空字符串来当成功。先查网络、地址和函数是否存在，再核对 tokenId 是否属于该合约的可读范围。
检查结果：记录实际 URI 或具体错误；尚未完成读取时不展示成功状态。
5. 只按读取结果下结论
保存返回 URI、chain/address/tokenId 与读取时间。URI 字符串返回不保证它指向的元数据已可访问，也不证明当前账户拥有 NFT。排查状态读取无需 prepareContractCall/sendTransaction；如果代码跳到了这些 API，应先把读取与写入路径分开。
检查结果：最终记录能证明哪一个合约和 tokenId 返回了什么，且未把读取当签名或交易成交。
怎样确认完成
- 有同版本 imports、chain/address、完整签名、整数 tokenId 和结果/错误。
- 教程基于官方文档；未连接钱包、调用付费 API 或执行实网读值。
常见错误与边界
- 免费创建 Client ID 不等于全部托管服务不限量免费。
- resolveMethod 会多一次 ABI 解析，失败位置可能早于 eth_call。
- 函数签名可描述调用，但不证明目标地址真的实现该函数。