企业官网建设流程全解析

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、地址和区块语义设计，不能照搬普通内容站的缓存策略。

性能优化的前提是资产状态可信。缓存越激进，失效机制越要明确。