Next.js DApp 缓存链上数据不是普通 CMS 内容一、缓存策略不能照搬传统页面Next.js 提供了很多缓存能力静态生成、服务端缓存、路由缓存都能提升性能。但 DApp 里的链上数据不是普通 CMS 内容。余额、授权、订单、池子状态、交易确认都和区块高度相关缓存过期策略如果不清楚用户看到的就是错误资产状态。缓存不是不能用而是要明确数据新鲜度。不同链上数据对实时性的要求差异很大不能统一设置一个 revalidate。传统站点缓存的一条基本原则是内容更新频率低、用户对时效性不敏感。链上数据正好相反。一个 DApp 首页可能同时展示24 小时交易量和代币 logo URL前者每 12 秒一个区块都在变后者可能一年不换。如果同一页面用了同一个 revalidate要么交易量一直落后要么对静态资源频繁触发不必要的 RPC 调用。缓存策略的粒度必须跟着数据的链上变更频率走而不是跟着页面路径走。这意味着 Next.js 里的fetch缓存选项不能按 API 路由统一设置而要按数据类型在服务层做决策。二、按数据类型分缓存flowchart TD A[链上数据] -- B[低频元数据] A -- C[账户相关数据] A -- D[交易状态] A -- E[价格与池子] B -- F[长缓存] C -- G[短缓存或不缓存] D -- H[按区块轮询] E -- I[订阅或短缓存]代币名称、合约 ABI、项目介绍可以长缓存用户余额、授权额度、交易状态需要短缓存甚至实时查询价格和池子状态要看产品风险交易类页面通常要求更高新鲜度。缓存键也要包含链 ID、地址、区块高度或数据版本。只用接口路径做缓存键很容易在多链场景下串数据。三、代码里表达新鲜度type ChainCachePolicy { key: string chainId: number blockTag?: bigint ttlSeconds: number staleWhileRevalidate: boolean }页面可以把链上读取封装成带策略的函数而不是在组件里随手 fetch。export async function getTokenMetadata(chainId: number, token: string) { return fetch(/api/token/${chainId}/${token}, { next: { revalidate: 3600 } }) }对于用户余额通常不要用长缓存。即使服务端缓存命中也要在客户端根据钱包地址和最新区块做二次刷新。四、交易后要主动失效用户刚提交交易后缓存最容易误导。页面不能等 TTL 自然过期而应该根据交易哈希监听确认状态在成功后主动刷新相关余额、授权和列表数据。还要处理链重组和 RPC 不一致。不同 RPC 节点可能返回略有延迟的数据所以交易状态确认最好设置确认数而不是看到一次成功就永久写死。页面状态也要告诉用户数据来源。比如“数据来自第 18,234,120 个区块”“交易已确认 3 个区块”这些信息能降低误解。对交易类页面用户看到旧余额时如果没有提示很容易重复操作。function ChainDataBadge({ block }: { block: bigint }) { return span数据区块{block.toString()}/span }缓存观测同样重要。记录缓存命中率、主动失效次数、交易后刷新耗时和 RPC 错误率才能判断缓存是否真的提升体验而不是制造旧数据。多标签页场景也要考虑。用户在一个页面提交交易另一个页面的缓存也应收到刷新信号。可以用广播通道或全局状态同步让同一钱包下的资产视图保持一致。如果用户切换链或钱包旧缓存应立即隔离不能继续复用上一身份的数据。增量数据获取如 Infura/Alchemy 的 websocket 订阅与 HTTP 缓存的配合也需要考虑。订阅推送的新区块事件可以用来触发缓存刷新但不能用推送直接覆盖缓存——因为推送可能乱序、丢失或重复。正确做法是推送作为建议刷新信号实际数据仍然走 RPC 查询验证确保缓存更新的幂等性。此外缓存层应对部分 RPC 故障有降级策略主 RPC 不可用时切换到备用节点请求缓存过期后如备用节点也失败则继续返回旧数据并标注数据可能过期。五、总结Next.js DApp 缓存要按链上数据类型、链 ID、地址和区块语义设计不能照搬普通内容站的缓存策略。性能优化的前提是资产状态可信。缓存越激进失效机制越要明确。