深入解析create-t3-app中的RSC缓存问题与解决方案

背景介绍

在Next.js应用开发中，create-t3-app作为一个流行的全栈框架，集成了TRPC和React Server Components(RSC)等现代技术栈。然而，在使用过程中，开发者发现了一个关键的性能问题：在多个RSC组件中调用相同的TRPC查询时，会导致重复请求，而不是像Next.js原生fetch那样自动缓存。

问题本质

Next.js的App Router模式中，原生fetch请求会自动进行"per-request"级别的缓存，即在同一次渲染过程中，相同的fetch请求只会执行一次。然而，TRPC的RSC调用目前没有实现这一机制，导致：

1. 多个组件调用相同TRPC查询时会产生重复请求
2. 增加了不必要的后端负载
3. 可能导致数据不一致问题

现有解决方案分析

目前社区提出了几种临时解决方案：

1. 手动React Cache包装

api.post.hello = cache(() => api.post.hello())

这种方法简单直接，但需要为每个TRPC过程手动添加缓存包装，维护成本高。

2. 递归映射TRPC路由

export const trpc = mapLeaves(router, cache);

通过工具函数自动为所有TRPC过程添加缓存包装，比手动方式更优雅，但仍属于应用层解决方案。

3. Node缓存方案

const cache = new NodeCache({ stdTTL: 300, checkperiod: 320 });

使用Node级别的缓存，但需要注意缓存失效和权限问题，可能不适合所有场景。

技术深度分析

RSC缓存机制

React Server Components的缓存是基于React的cache()函数实现的，它能够：

1. 在同一次渲染过程中缓存函数调用
2. 自动处理Promise结果
3. 与React的渲染流程深度集成

TRPC集成挑战

TRPC作为一个独立于React的RPC框架，其设计初衷是通用的，不特定于任何前端框架。因此：

1. 缓存逻辑不应该侵入TRPC核心
2. 需要在TRPC-React集成层实现缓存
3. 需要考虑不同渲染环境(SSR/CSR)的差异

最佳实践建议

基于当前技术状态，建议开发者：

1. 对于简单应用，可以采用手动缓存包装
2. 中等规模项目，考虑实现自动化的过程缓存映射
3. 关注TRPC官方对RSC支持的进展

未来展望

从技术演进角度看，这个问题的最佳解决方案应该是：

1. 在@trpc/react-query/rsc中内置缓存支持
2. 提供细粒度的缓存控制选项
3. 保持与Next.js原生fetch缓存行为的一致性

总结

create-t3-app框架中TRPC与RSC的缓存问题反映了现代全栈开发中的集成挑战。虽然目前有各种临时解决方案，但长期来看需要框架层面的支持。开发者应当根据项目需求选择合适的缓存策略，同时关注TRPC官方对RSC支持的改进。