企业官网建设流程全解析

1. t3code是什么，为什么这几年的新项目都在往它上面靠

先说结论：t3code这个方向，指的是一套以TypeScript 为底座、前后端全链路类型安全为核心理念的现代 Web 全栈开发组合，也就是社区里常说的 T3 Stack 实践。凡是按这个思路搭建的代码工程，你都可以叫它 t3code 风格的项目。它由 Next.js、TypeScript、Tailwind CSS、tRPC、Prisma 这些具体技术组成，但真正让它在开发者圈子里火起来的，不是某一个框架，而是“类型安全贯穿到底”这件事本身。

我第一次接触 t3code 是在一个中型 SaaS 项目上。当时团队还在用传统的前后端分离架构：React 前端 + Node 后端 + REST API，前后端各维护一套类型定义。前端改了字段类型，后端忘了同步，线上直接数据满天飞；后端改了接口结构，前端编译期完全不知道，直到运行时才炸。后来我把项目迁到 t3code 这套体系下，最大的感受是：原来那种“约定靠文档、同步靠自觉”的协作模式，真的可以被工具自动兜住。

一句话说清它能做什么：你从数据库表结构开始定义类型，然后 API、前端调用、页面渲染，全程只有一套类型源，任何一处改了类型，编译器和 IDE 会在所有相关位置同时报错。这种体验用过了就回不去。

这套方案适合谁？适合正在做全栈项目的个人开发者、小团队，也适合想给项目打牢基础的中型团队。如果你正处于“选型纠结期”，每天在 REST 和 GraphQL 之间摇摆，在 Redux 和 React Query 之间反复横跳，那 t3code 的思路会直接替你砍掉大多数选择——它用一套默认路径把你带到最佳实践上。

但注意，它不是一个开箱即用的“平台”，而是一组选型组合 + 一套工程约束。要真正驾驭它，你需要理解每个零件为什么被选中，而不是只会跑create-t3-app这条命令。下面我把这个组合背后的逻辑拆开讲。

2. 选型背后的逻辑：为什么偏偏是这四件套

2.1 技术栈构成与各自分工

t3code 的典型技术栈构成很固定，但每个成员承担的角色完全不同：

你可能会问：Next.js 自己不是有 API Routes 吗？为什么还要引入 tRPC？这其实是 t3code 理念的核心。Next.js 的 API Routes 本质上还是 REST 风格，你得自己定义 URL、自己处理参数序列化、自己维护错误码。而 tRPC 的思路是你定义一个函数，前端直接调用这个函数——连 URL 都不用写。

更关键的是，tRPC 的函数签名天然携带类型信息。你在后端定义getUserById(input: { id: string })，前端代码里敲trpc.getUserById.useQuery({ id: "1" })，编辑器会立刻推断出返回值的完整类型。这带来的开发效率提升不是一点点，而是根本性的：你少写了一整类“类型维护”的代码。

2.2 为什么 TypeScript 是这个组合的地基

很多人把 TypeScript 当成“能写类型注解的 JavaScript”，这个理解不够。在 t3code 体系里，TypeScript 承担的是一个全局约束系统的角色。

你可以想象一条流水线：Prisma Schema 里的User模型，自动生成User类型 → tRPC 路由函数引用这个类型，于是 API 入参和返回值都带上了类型 → 前端useQuery拿到类型化返回值 → 页面组件渲染时字段提示齐全。这条链路上每一环都是 TypeScript 在背后撑着。

如果中间任何一环断了类型，后果就是回到老路：运行时才发现字段不对。所以 t3code 项目的tsconfig.json里经常把strict设为true，许多项目还会额外开启noUncheckedIndexedAccess，宁可编译时报错，也不要线上数据出错。

这里分享一个我实际踩过的坑：早期我为了“灵活”，在某个 tRPC 路由的返回里用了any类型，前端拿到数据后调了一个不存在的字段，编译没报错，线上渲染直接白屏，用户反馈来了我才查出来。从那以后我给自己定了一条规矩：t3code 项目里永远不允许显式any。真遇到复杂类型，用zod做运行时校验，而不是用any逃避。

2.3 这套组合在架构上帮你避免了什么

从架构角度看，t3code 实际上帮你规避了两大问题。

第一，API 版本管理问题。REST 接口做得越大，版本管理越痛苦，/api/v1、/api/v2的分叉会让前后端协作陷入泥潭。tRPC 的调用方式让 API 更像“函数签名变更”而不是“接口协议变更”，类型检查器会逼着你在前端同步修改调用点，不存在“旧版本还挂在线上被调用”的尴尬。

第二，前后端类型割裂问题。传统项目里前端有src/types/api.ts，后端有src/types/models.ts，两边各写各的，一旦不一致，只能靠人工检查。t3code 把这套类型合并成了一处来源，数据库 Schema 即类型定义，tRPC 路由函数的签名即接口文档，彻底消灭了“重复维护两份类型”这种毫无价值的工作。

风格虽好，但也要说句公道话：这套组合并不适合所有场景。如果你们的项目需要开放 API 给第三方开发者调用，tRPC 这种内部函数式调用就不太合适，因为外部开发者没法直接“调用你的函数”，他们需要标准的 HTTP 接口和文档。所以 t3code 更偏向内部全栈应用场景，比如管理后台、内部工具、SaaS 前端，而不是开放平台。

3. 初始化项目：从 create-t3-app 到工程落地

3.1 创建项目的完整流程

t3code 项目有一个官方脚手架，通过一条命令就能拉起完整工程：

npm create t3-app@latest

运行这条命令后，CLI 会问你几个问题，这里把选项和我的推荐一起列出来：

• 项目名称：按你的项目名填，比如my-t3-app。
• 是否启用 Next.js：默认启用，这就是应用的主框架。
• 是否启用 TypeScript：默认启用，千万保持开启，关掉它这套体系就失去意义了。
• 是否启用 Tailwind CSS：建议启用，后续写样式非常顺手。
• 是否启用 tRPC：核心选项，必须启用。
• 是否启用 Prisma：如果你需要数据库操作，就启用。
• 是否启用 NextAuth.js：需要用户登录认证就启用，不需要就先跳过。
• 是否使用 App Router 还是 Pages Router：新项目建议 App Router，它是 Next.js 的未来方向，t3code 的很多新特性也优先适配 App Router。
• 是否使用 ESLint / Prettier：都启用，代码规范和格式化交给工具，省心。

这些选项不是“全选就完事”，而是要按需选择。比如一个小型展示型项目，不需要数据库登录，那 Prisma 和 NextAuth 就可以不开，减少无谓的复杂度。我见过不少人一上来全选，生成了一大堆用不上的依赖，项目跑起来又慢又乱。

3.2 生成后的项目结构

初始化完成后，你会看到一个按“关注点分离”组织得很清晰的目录结构。我以典型 t3code 项目为例：

├── prisma/ │ └── schema.prisma # 数据库表结构定义 ├── src/ │ ├── server/ │ │ ├── api/ │ │ │ └── routers/ # tRPC 路由定义 │ │ ├── auth.ts # 认证配置 │ │ └── db.ts # Prisma Client 实例 │ ├── pages/ # 前端页面 │ ├── styles/ │ └── utils/ └── package.json

这个结构最值得注意的地方是，它把“服务端代码”独立放进src/server目录。这个隔离不是摆设，而是为了坚持一个原则：只有src/server下代码可以访问数据库和敏感逻辑，其他部分永远不能直接操作 Prisma Client。

这个约定听起来简单，但实际非常有价值。我在做代码评审时，经常看到有人在前端组件里直接import { prisma } from "@/server/db"，然后试图查询数据库。这在 t3code 架构里是大忌，因为前端组件代码可能在客户端执行，直接访问数据库意味着凭据暴露，这在浏览器环境下非常危险。正确做法永远是：通过 tRPC 路由暴露你需要的操作，让框架来处理服务端调用。

3.3 首次启动与基础配置确认

依赖安装完成后，先跑一下：

npm run dev

默认情况下开发服务器跑在http://localhost:3000。启动成功后，你应该能看到默认首页。这时先别急着写业务，做两件基础配置的事：

第一，检查.env文件。脚手架生成时可能已经填好了数据库连接串占位符，你需要把它改成真实数据库地址，比如：

DATABASE_URL="mysql://user:password@localhost:3306/myapp"

第二，如果启用了 Prisma，先同步一次数据库：

npx prisma db push

这条命令会根据schema.prisma里的定义，把表结构直接同步到数据库。注意：db push适合开发阶段快速迭代，如果是生产环境的正式表结构变更，更推荐用npx prisma migrate来管理迁移记录。

这里再补充一个细节：t3code 默认的鉴权方案是 NextAuth.js，它的配置里需要填一个NEXTAUTH_SECRET。开发阶段脚手架可能自动生成了临时值，但部署到生产环境前一定要改成一个固定、随机、保密的值。生成方法很简单：

openssl rand -base64 32

把输出填到.env里。漏掉这一步的话，每次重启服务用户的登录会话都可能会失效，排查起来非常痛苦。

4. 核心链路拆解：Schema 到 API 再到页面，类型安全是怎么贯穿的

4.1 第一步：定义数据模型

t3code 项目的起点是prisma/schema.prisma文件。这里定义的每一张表，都会自动变成 TypeScript 类型。拿一个常见的“文章系统”举例，Schema 可以这样写：

model Post { id String @id @default(cuid()) title String content String published Boolean @default(false) author User @relation(fields: [authorId], references: [id]) authorId String createdAt DateTime @default(now()) updatedAt DateTime @updatedAt } model User { id String @id @default(cuid()) name String? email String @unique posts Post[] }

定义好之后，执行：

npx prisma generate

这个命令会读取 Schema 并生成类型安全的 Prisma Client。生成完后，你可以在代码里用prisma.post.create(...)、prisma.user.findUnique(...)这样的调用，而且入参和返回值都有完整的类型提示。

可以这么说：这一步直接把“数据库表结构”转化成了“写代码时编辑器里的自动补全”。它省掉的不只是手写类型定义的时间，更是大量沟通成本。新人接手项目，看一眼 Schema 就知道有哪些表和字段，不用翻数据库文档。

4.2 第二步：在 tRPC 里暴露路由

数据模型建好后，下一步是把操作暴露给前端调用。在src/server/api/routers/post.ts里定义路由：

import { z } from "zod"; import { createTRPCRouter, publicProcedure } from "@/server/api/trpc"; export const postRouter = createTRPCRouter({ getAll: publicProcedure.query(async ({ ctx }) => { const posts = await ctx.db.post.findMany({ where: { published: true }, orderBy: { createdAt: "desc" }, }); return posts; }), create: publicProcedure .input( z.object({ title: z.string().min(1), content: z.string().min(10), }) ) .mutation(async ({ ctx, input }) => { return ctx.db.post.create({ data: { title: input.title, content: input.content, authorId: ctx.session?.user?.id ?? "anonymous", }, }); }), });

把这段代码拆开看，每个元素都有讲究。

createTRPCRouter是路由容器，publicProcedure表示这个接口任何人可调。如果你做了登录鉴权，可以用protectedProcedure替代，未登录用户会被自动拦截。query表示查询操作，mutation表示写操作，这个区分不只是语义上的，还和 React Query 的缓存行为相关：query会被自动缓存，mutation触发后可以主动让 Query 失效刷新。

zod是目前 t3code 默认的输入校验方案。input()方法接收一个 zod schema，它同时做了两件事：一是在运行时校验参数合法性，二是把这个 schema 的类型提取出来给前端调用时做类型提示。你在前端写postRouter.create.useMutation()时，传给mutate的参数会被自动检查是否匹配{ title: string; content: string }，完全不会出现“传错参数到运行时才发现”的情况。

4.3 第三步：前端页面接入 tRPC

后端路由写好了，前端页面的接入方式非常直观，这也是 t3code 最有“爽感”的地方。

import { api } from "@/utils/api"; export default function PostsPage() { const { data: posts, isLoading } = api.post.getAll.useQuery(); const createPost = api.post.create.useMutation({ onSuccess: () => { // 刷新列表 }, }); if (isLoading) return <div>加载中...</div>; return ( <div> {posts?.map((post) => ( <div key={post.id}> <h2>{post.title}</h2> <p>{post.content}</p> </div> ))} </div> ); }

注意几个关键点。

api.post.getAll是类型安全的调用入口，api对象是从@/utils/api引入的，它内部已经完成了 tRPC Client 的初始化。写api.post.之后，编辑器会列出所有 router 和 procedure 的提示，输错名字直接编译报错，不用像 REST 那样去翻接口文档确认路径。

useQuery返回的posts类型就是后端query()函数的返回类型。后端Post表里每个字段你在前端都能拿到提示，后端加了字段，前端代码里立刻就能感知到。

这个小例子背后，就是一个完整的数据流闭环：Prisma 定义表结构 → tRPC 路由查询 → 前端自动推断类型 → 页面渲染。全程从数据库到 UI，类型没有断过一次。这是我推荐所有全栈新人优先体验的地方，先把这个链路打通，再考虑更复杂的业务。

4.4 处理器选择：为什么要用 Node.js 运行时

t3code 默认跑在 Node.js 运行时（Service Worker/Node.js），而不是 Edge Runtime。为什么要特别提这个？因为很多追求极致性能的开发者喜欢把 Next.js 部署到 Edge 环境，但 Prisma 和 tRPC 在这种环境下的兼容性还不够好。

Prisma 需要连接数据库，这是一个长连接操作，Edge 的近用户部署对数据库连接来说反而是一种负担，它拉长了连接链路。数据库连接池、事务、迁移这些都依赖 Node.js 的完整运行时能力。所以我在 t3code 项目里几乎不用export const runtime = "edge"这种写法，除非那个接口不涉及数据库并且对冷启动特别敏感。

正确的做法是让 tRPC 路由默认跑 Node.js。这也是 t3code 默认配置的做法，不要轻易改动。很多人架构上踩了大坑，就是因为追求“Edge 性能”而牺牲了 Prisma 的稳定性，线上数据库连接池被打满，性能反而下降。

5. 核心细节实操：从路由到部署的关键经验

5.1 认证路由与受保护操作的正确写法

前面提到了publicProcedure和protectedProcedure，这里展开讲讲实际工程里经常出现的认证问题。

t3code 集成 NextAuth 后，protectedProcedure是这么定义的：

import { createTRPCRouter, protectedProcedure, publicProcedure } from "@/server/api/trpc"; export const userRouter = createTRPCRouter({ getMe: protectedProcedure.query(async ({ ctx }) => { return ctx.session.user; }), });

受保护路由在未登录状态下调用，会自动抛出 UNAUTHORIZED 错误，前端 React Query 会捕获并可以引导用户去登录页。

我在这块遇到过一个很隐蔽的问题：开发环境里一切正常，一部署到生产环境就出现“用户明明登录了，但受保护路由还是报未授权”。后来排查发现是 NextAuth 的NEXTAUTH_URL环境变量没配。如果这个变量和实际部署域名不一致，Cookie 的 domain 就对不上，前端发请求不会带正确的 Session。改好之后问题立刻消失。

经验之谈：部署 t3code 项目时，第一件事检查三个环境变量：DATABASE_URL、NEXTAUTH_SECRET、NEXTAUTH_URL。这三个漏任何一个，生产环境都会以各种诡异姿势挂掉。

5.2 数据库连接池与 Prisma 的配置细节

Prisma 默认会创建数据库连接池，但连接池大小是有限制的。在高并发场景下，如果你的数据库实例连接数上限比较小（比如某些免费数据库只允许 5 个并发连接），那 t3code 应用频繁开连接会直接把连接池打满。

这时你有两个调整方向：一个是把连接池上限调低，控制 Prisma 的并发连接数：

DATABASE_URL="postgresql://user:password@host:5432/dbname?connection_limit=3"

另一个是引入 PgBouncer 这类连接池代理，让应用层的连接复用 DB 层的有限连接。不过后者增加了运维复杂度，如果项目规模不大，我更推荐先调低connection_limit。

另外一个常见的坑是“开发环境连接数爆炸”。原因是开发模式下热更新会导致 Prisma Client 反复创建实例。脚手架其实已经做了全局单例处理，在src/server/db.ts里用globalThis缓存 Prisma Client 实例。不要为了图方便自己新建 PrismaClient，一定要复用这个单例。不然你每改一次代码，连接数就涨一批，最后数据库会被开发环境的死连接拖垮。

5.3 部署到 Vercel 的完整流程与注意事项

t3code 项目最常见的部署方式是 Vercel，因为 Next.js 就是 Vercel 团队维护的，两者结合非常顺畅。部署流程大致是：

1. 把代码推到 Git 仓库（GitHub / GitLab）。
2. 在 Vercel 上导入仓库。
3. 配置环境变量：DATABASE_URL、NEXTAUTH_SECRET、NEXTAUTH_URL。
4. 不熟悉 Prisma 的部署机制时，给 build 命令改成：prisma generate && prisma db push && next build。
5. 部署，完成。

第五步里的prisma db push在部署时执行要慎重。如果生产环境的表结构有严格变更管理要求，不要用db push代替migrate。更稳妥的方式是在构建流程里跑prisma migrate deploy，它只应用迁移记录，不会瞎改结构。

前端部署之外，别忘了数据库也得有备份策略。t3code 这个架构下后端逻辑和数据库是紧耦合的，数据库挂了整个应用就全挂。我个人的做法是至少每天自动备份一次，重要的生产环境还开着时间点恢复功能。

5.4 给 tRPC 路由加缓存和超时保护

默认情况下 t3code 生成的 tRPC 路由是没有缓存策略的。如果你有些数据读取频率特别高，比如首页的推荐列表、配置信息，建议做一下响应缓存，减少数据库压力。

在 tRPC 路由里可以给 query 配置staleTime，控制前端缓存时间：

api.post.getAll.useQuery(undefined, { staleTime: 60 * 1000, // 1分钟内的请求直接用缓存 });

这个参数的意思是：1 分钟之内的重复请求，直接走前端缓存，不重新打后端。但这只对用户侧有效，服务端自身并没有缓存。如果数据一致性要求不高，也可以考虑在路由内部接一层 Redis，或者直接在 Next.js 的fetch层面做缓存。

超时保护这块容易被忽视。一旦数据库出现慢查询，tRPC 路由会一直挂起直到数据库超时，用户体验很差。在生产环境，我习惯于在外层网关做超时控制，或者给数据库连接池设置合理的socket_timeout。不要让一个慢查询拖垮整个服务的响应能力。

6. 增量迁移：已有项目怎么一步步过渡到 t3code

很多团队不是从零开始，而是已经有一套旧系统，想逐步迁到 t3code。这种增量迁移的策略我实际操作过，给你一套可参考的步骤。

第一步，先搭骨架，不迁业务。在旧系统旁边新建一个 t3code 空项目，配置好 Prisma 和 tRPC，把数据库连接指向旧系统的数据库。通过prisma db pull把现有表结构反向生成 Schema，这一招能省掉大量手工建模时间。

npx prisma db pull

执行后，现有表会变成schema.prisma里的模型定义，你只需要调整命名风格和关系配置，就能得到一个可靠的起点。

第二步，挑一个高频读、低频改的功能。比如旧系统的“公告列表”“商品分类”这类功能，先在新系统里用 tRPC 暴露接口，前端用一个过渡页接过去。这样旧系统代码几乎不动，新系统开始承载真实的读流量。

第三步，做双写或迁移脚本。对于写操作，可以在旧系统里把写库操作同步调用新系统的 tRPC 接口，也可以用脚本定时把增量数据同步过去。等新系统的稳定性和功能完整度验证通过后，再把流量全部切过去。

增量迁移最忌讳的是“一步到位式重写”。我见过太多团队雄心勃勃想全量重写，结果旧系统跑得好好的，新系统三个月还没上线。t3code 的价值是帮你理顺新项目的代码组织，不是让你一夜间推翻所有旧代码。渐进替换、以点带面，才是稳健的落地路径。

7. 常见问题与排查技巧实录

7.1 类型错误：routers 里改完类型，前端报错但不知道咋改

这个问题在 t3code 里非常常见，甚至可以说是“新人必经之路”。现象是：后端路由改了入参结构，前端调用点的类型报错，但报错信息一大串，看不太懂。

处理方法其实很简单：跟着 TypeScript 报错信息走，它会精确告诉你哪个字段不匹配。比如你后端加了必填参数，前端调用时没传，报错就会落到mutate({})这一行。补上参数就行。

另一个常见原因是 tRPC 的类型缓存。改完代码后，如果你用的是 Next.js 的 dev server，类型有时候不会立刻刷新。这时重启一下 dev server，或者执行一下npx tsc --noEmit强制全量类型检查，报错位置就清楚了。

7.2 Prisma 查询结果序列化问题

t3code 里 Prisma 返回的数据类型有些特殊，比如DateTime字段默认是Date对象。直接把它扔给前端 JSON 序列化，格式往往和预期不一致。这时候就不要想着改 Prisma 的全局配置了，正确做法是在 tRPC 路由里用 zod 做输出转型，或者在查询时用select明确指定需要的字段。

比如：

getAll: publicProcedure.query(async ({ ctx }) => { const posts = await ctx.db.post.findMany({ select: { id: true, title: true, content: true, createdAt: true, }, }); return posts.map((post) => ({ ...post, createdAt: post.createdAt.toISOString(), })); }),

显式序列化虽然多写几行代码，但能保证前端拿到的数据格式完全可控，不留给运行时任何意外。

7.3 开发环境正常，生产环境 API 报 500

这类问题九成以上是环境变量和生产库表结构不一致导致的。按下面顺序排查，绝大多数都能定位：

1. 检查DATABASE_URL是否指向正确库。
2. 检查生产库是否执行过prisma migrate deploy。
3. 检查NEXTAUTH_URL和域名是否一致。
4. 打开生产日志，看具体异常堆栈，通常信息能直接告诉你是连不上库还是表缺失。

每次排查完我都会提醒自己：部署流程里一定要加上 schema 校验环节。你可以在构建命令里加一步prisma migrate diff，对比本地迁移记录和生产库结构是否一致，不一致就直接构建失败，把问题挡在发布之前，而不是等用户看到 500 再回来查。

7.4 tRPC 请求 404 或 405

出现这个问题，多半是 Next.js API 路径和 tRPC 配置没对齐。t3code 的 tRPC handler 通常挂在/api/trpc下，如果你的 Next.js 版本做了路由调整，比如从 Pages Router 切到 App Router，路径要保持一致。

另一个更隐蔽的原因：前端 tRPC Client 的url配置指向了/api/trpc，但后端 handler 实际挂载在/api/trpc/{trpcPath}，两者不匹配。如果你用了自定义部署前缀，比如部署在/app子路径下，记得把 url 前缀同步改掉。这个问题在本地不出现，一部署到子路径环境就随机出现，特别容易让人摸不着头脑。

7.5 数据库连接过多被拒

生产环境突然报“Too many connections”，最常见的原因是应用的连接池配置过大，超过了数据库上限。如果是 MySQL，可以先查一下当前连接数：

SHOW STATUS LIKE 'Threads_connected';

如果连接数长期接近上限，优先调整connection_limit参数，把连接池限制到数据库能承受的范围。同时检查有没有其他服务也在连同一个库，比如定时任务脚本、数据分析任务，这些都可能是隐形连接消耗者。

8. 我自己用下来的体会和一些小建议

t3code 这套组合我前后用了两年多，踩过不少坑，也沉淀了一些自己的习惯。

第一，不要忽略 zod schema 的价值。很多人把它当成“参数校验工具”就完了，实际上它能承担的远不止校验。用 zod 定义输入类型后，TypeScript 会自动推断出类型，这意味着入参校验逻辑和类型的唯一来源是同一个定义，不存在“接口文档和代码不一致”的问题。

第二，tRPC 的 mutation 完成之后，记得用invalidate让相关 query 失效。我最早经常遇到这种问题：创建完文章后，列表没刷新。原因就是useMutation的onSuccess没有触发invalidate。加上这行代码后，数据自动重新拉取，体验流畅多了。

const utils = api.useUtils(); const createPost = api.post.create.useMutation({ onSuccess: async () => { await utils.post.getAll.invalidate(); }, });

第三，合理控制 t3code 的依赖体积。脚手架默认带了不少依赖，如果你只用到其中一小部分，不要犹豫，直接删掉。比如不需要认证功能就把 NextAuth 相关依赖移除，不需要样式库动画就把无关的 Tailwind 插件清掉。依赖越多，构建越慢，安全风险面也越大。

第四，在团队协作里，prisma schema 的变更要走 review 流程。因为表结构一变，类型全链路都会受影响，一个不经意的字段改名可能连带十几个前端页面报错。把 Schema 变更当成接口变更来对待，凡是改 Schema 必须有人 review，这比任何代码注释都管用。

最后分享一个小技巧：如果你在用了 t3code 之后仍然觉得前后端类型有“断层感”，比如某些地方还是手写了重复类型，那大概率是你绕过了 tRPC 的正规链路——比如直接在服务端组件里查数据库。不是说不可以，但如果你想体验“后端改类型、前端立刻报错”的快感，就尽量把所有数据访问都收敛到 tRPC 路由里。这套框架的高光体验，全部建立在“统一出口”这个约束之上。守住这个约束，它就会一直好用；破坏了它，那你只是在 Next.js 里手忙脚乱。