尽管通过 @next 标签发布的 tRPC v11 早已具备生产就绪状态，但我们一直沉迷于添加新功能而没有严格遵守语义化版本规范。今天，我们激动地宣布，终于要正式发布 tRPC v11 了！

我们激动地宣布，全新的 TanStack React Query 集成方案已在 tRPC 的 next 版本中推出。相较于传统的 React Query 集成方案，新版方案更加简洁且更贴近 TanStack Query 原生范式。它选择直接采用 TanStack React Query 原生的 QueryOptions 和 MutationOptions 接口，而非通过封装 useQuery 和 useMutation 实现自定义客户端。

tRPC v10 引入的过程创建器模式（builder-pattern）获得了社区的高度认可，许多库都采用了类似模式。甚至出现了tRPC like XYZ这样的术语，证明该模式日益流行。事实上，最近我看到有人询问是否能用类似 tRPC 的 API 编写 CLI 应用。顺带一提，你甚至可以直接使用 tRPC 实现这个需求。但今天我们要讨论的重点不是这个，而是如何在 Next.js 的服务器动作中使用 tRPC。

你是否好奇过 tRPC 的工作原理？或许你想为项目贡献代码，却被内部实现吓退？本文旨在通过编写一个覆盖 tRPC 核心机制的微型客户端，带你深入理解 tRPC 的内部运作。

作为库作者，我们的目标是为同行提供最佳的开发者体验（DX）。减少错误排查时间并提供直观的API，能够消除开发者的心智负担，让他们专注于最重要的目标：打造出色的终端用户体验。

tRPC 通过 TypeScript 的强大能力强制执行严格的全栈类型绑定，提供卓越的开发者体验。无需担心 API 契约漂移，也无需代码生成。

tRPC 让你在（Node）服务器和客户端之间实现端到端的类型安全，甚至无需声明类型。在服务端只需返回函数数据，前端即可根据端点名称直接使用对应数据。