企业官网建设流程全解析

1. 项目概述与需求解析

1.1 核心需求解读

作为一个常年混迹于全栈开发一线的老手，当我看到“t3code”这个项目名时，第一反应就是——这又是一个围绕T3 Stack生态展开的实战项目。T3 这个概念在近两年的前端圈子里热度一直不减，它并不是一个框架，而是一套由社区头部开发者（尤其是 Theo 及其团队）强力推荐的全栈技术栈组合方案：TypeScript、Tailwind CSS、tRPC，再加上通常配套的 Next.js、Prisma、NextAuth.js 和 TanStack Query。如果你把这些技术的关键字母拼在一起，恰好就是“T3”，而围绕这套组合去写业务代码，本质就是在实践一种端到端类型安全的开发理念。

“t3code”这个名字，直白一点理解，就是“在 T3 架构下写代码”或者说“T3 风格的代码实践”。这类项目最典型的诉求非常集中：解决前后端协作中接口类型不同步、联调成本高、运行时才暴露错误这些痛点。我见过太多团队，后端用 Java/Go 写接口，前端用 TypeScript 强类型开发，结果一联调就难免出现字段对不上、类型不一致的混乱局面。而在 T3 这个体系里，你可以做到从数据库到 API 再到前端组件拿数据，全程类型自动推导，几乎不需要手动维护任何一份接口定义文档。这个价值，用一句话概括就是——TypeScript 的类型安全能力被贯穿到了全栈的每一个角落。

这篇文章适合谁来读？如果你是刚接触 T3 生态、想找一个完整实践案例参考的前端全栈开发者，或者你是一个技术管理者，正在调研新一代全栈开发方案，又或者你只是想在 Next.js 基础上把数据层和服务层串起来、解决手头项目重复写类型的心烦问题，那这篇内容就是为你准备的。我会把这个项目从架构选型到底层实现、从关键参数设计到部署细节，完整拆解一遍，其中会穿插大量我实测踩坑的经验，保证不会让你看完还是一头雾水。

1.2 行业背景与个人动机

说实话，我在早期做全栈项目时，最喜欢也最痛恨的都是“复制粘贴”——喜欢是因为效率高，痛恨是因为只要后端接口结构一调整，前端所有相关的类型定义、mock 数据、联调逻辑全都要跟着改，漏一处就是运行时白屏或 undefined 报错。后来我逐渐意识到，很多问题的根源不在于代码写得不好，而在于前后端之间缺乏一种单一可信的类型来源。

t3code 这个项目的出发点，其实就是我在经历几次痛苦的接口重构之后，决定认真拥抱 T3 生态，把一套完整业务从零写出来的总结。我选择 T3 不是因为想追新，而是因为这几个现实原因。第一，它把 TypeScript 的收益真正拉满了——你不需要额外写 schema 校验库或者代码生成工具，tRPC 直接从服务端 router 定义里推导出客户端可用的类型；第二，它是React/Next.js 生态里集成成本最低的组合方案——不需要自己拼装一堆中间件和胶水代码，社区已经帮你把最佳实践沉淀好了；第三，它的模式足够通用，不管是写个人博客、SaaS 应用还是内部管理系统，这套骨架都能拿起来就用，可复用性极高。

当然，T3 也不是没有缺点。网上有些评论会说它“绑定太深”“不适合大型团队”，这个我部分同意，但也要看场景。对于中小型产品、起步阶段的创业项目、或者个人作品集级别的全栈应用，T3 提供的内聚式开发体验是我用过最爽的方案之一。t3code 这个项目存在的意义，正是验证这种方案在实际业务中的可行性，同时把过程中的关键决策和参数取舍记录下来，方便后来者少走弯路。

2. 技术选型深度分析与架构设计

2.1 为什么是 T3 这一套组合

把 t3code 的技术底座拆开看，它的核心成员每个都负责一块非常明确的职责。Next.js负责应用框架层，提供文件路由、服务端渲染、API 路由这些基础设施，同时它是支持全栈开发的最成熟 React 框架之一，生态庞大，长尾问题基本都能搜到答案。TypeScript是贯穿一切的静态类型语言，它的作用这里不光是“给变量加类型”，更重要的是作为整个项目的“契约语言”，让数据和函数之间的调用关系可以被编译器校验。Tailwind CSS负责样式层，它允许你在组件内部直接完成排版、布局和视觉调整，不需要频繁切换 CSS 文件，大幅提升 UI 开发的沉浸感。

在这个基础之上，tRPC是整套组合的灵魂所在。它的核心思路是让客户端直连服务端的函数调用，像调用本地函数一样，同时利用 TypeScript 的泛型和类型推导能力来自动生成端到端的类型定义。你用 Prisma 定义数据模型，用 tRPC 写查询和变更逻辑，然后再在前端组件里直接调用这些函数，鼠标悬停就能看到完整的入参和返回类型，字段写错了编译立刻报错。Prisma在这里负责数据库访问层，它以 schema 文件为中心，自动生成类型安全的查询客户端，迁移管理也比手写 SQL 要直观得多。整套体系还包括NextAuth.js做认证、TanStack Query做服务端状态管理，它们和前面的核心成员组合在一起，形成一个完整的全栈循环。

2.2 与主流替代方案的横向对比

很多朋友在搭建新项目时，第一反应是用create-next-app默认模板，然后自己往里面集成各种库。这条路能走通，但集成成本和时间成本并不低。我见过不少人花了一整天时间配置 Prisma、tRPC、NextAuth 的胶水代码，中间各种踩版本兼容性的坑。而create-t3-app这种脚手架把所有配套一次性集成完毕，你拿到手就是一套可运行的完整骨架，不用再折腾最折磨人的初始化阶段。

和另一类主流方案——比如在 Next.js 之上自建 API 路由加 React Query，或者单独引入 GraphQL——相比，T3 的优势在于省掉了大量模板代码。GraphQL 固然强大，但带来的学习曲线和 schema 维护成本对于很多中小型项目来说是过重的。传统 REST API 需要你手动定义路由处理器和客户端请求函数，类型共享还得靠额外工具。tRPC 没有这些复杂度，它就是简单的函数调用，而且类型推导是天然的。

我这里列一个对比表，直观展示不同方案在几个关键维度的差距：

这个对比不是我凭空拍的，而是我在多个项目里真实切换后的体感。如果你目前还在犹豫技术选型，我的建议是：项目规模不大、团队以 TypeScript 为主、希望快速看到业务效果，那 t3code 这种模式会给你非常顺畅的体验。如果团队里非前端成员经常需要阅读接口文档、项目已有大量 REST 基础设施，那保持 REST 也是合理选择。技术没有绝对的好坏，只有匹配度的问题。

3. 核心细节解析与实操要点

3.1 项目初始化与目录结构设计

在开始写任何业务代码之前，一个清爽的项目骨架能省掉后续大量重构时间。t3code 项目建议直接使用官方脚手架初始化，命令行操作非常简洁：

npm create t3-app@latest

初始化过程中有几个关键选项值得多说几句。TypeScript 是强制选择项，这也是 T3 的灵魂；Tailwind CSS 对于本类项目建议选上——即使你不用它写全部样式，至少可以用它快速搭出管理后台这类内部工具的界面。tRPC 和 Prisma 是核心必选。NextAuth.js 如果项目需要用户登录体系就选上，否则可以先不加，减少初次上手的认知负担。我个人的习惯是第一次搭建时全选，跑通再裁剪，这样你能对完整链路有个整体感知。

接下来是目录结构。T3 脚手架的 src 目录结构经过社区大量实践沉淀，组织非常清晰：

• src/server/存放所有服务端代码，包括 tRPC router 的定义、Prisma 客户端实例、鉴权逻辑；
• src/pages/或src/app/是 Next.js 的页面/路由目录；
• src/components/放共享 React 组件；
• src/utils/放工具函数和通用类型；
• src/styles/放全局样式文件。

这种结构最大的好处是清晰地划分了服务端边界。服务端代码默认不会被打包进客户端 bundle，避免敏感逻辑泄露。我在实际项目里见过有人把 Prisma Client 直接暴露在页面组件里调用，这是非常危险的做法，相当于把数据库连接口直接敞开了。T3 的目录设计天然通过命名规范规避了这个问题，这也是为什么我一直强调，新手不要随意打乱脚手架默认结构。每个文件夹放什么，背后都有安全性和可维护性的考量。

3.2 数据模型设计与 Prisma Schema 编写要点

对于大部分业务系统来说，数据模型是整个应用的基石。在 t3code 项目中，Prisma schema 文件就是定义数据模型的核心资产。下面是一个典型的多用户博客场景的 schema 示例：

generator client { provider = "prisma-client-js" } datasource db { provider = "sqlite" url = env("DATABASE_URL") } model User { id String @id @default(cuid()) email String @unique name String? password String? createdAt DateTime @default(now()) updatedAt DateTime @updatedAt posts Post[] } 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 }

这里有几个实操上的要点。主键选择：我强烈建议用cuid()或uuid，而不是自增数字。自增主键在小型项目里很省事，但一旦涉及数据迁移、多库合并或者避免端点枚举攻击时，cuid 的优势就会显现。数据源配置：开发环境用 SQLite 非常方便，零配置启动，但部署到生产环境一定要换成 PostgreSQL，SQLite 在并发写入场景下容易报锁错误。关系命名：Prisma 的关系字段命名是有讲究的，比如posts和author这种，必须确保与另一侧的字段对应一致，不然很容易在迁移时报关系歧义错误。

写完 schema 之后，需要执行两条命令让数据库和应用同步：

npx prisma migrate dev --name init npx prisma generate

第一条会根据 schema 生成迁移文件，并应用到本地数据库；第二条会生成 Prisma Client，更新后的类型会同步反映到 TypeScript 编译环境中。这里提醒一个常见坑：迁移后如果出现类型报错，别慌，多半是 Prisma Client 没重新生成，跑一遍prisma generate就好。

3.3 tRPC Router 定义与查询流程拆解

tRPC 是 t3code 项目里最让我惊喜的部分。它的编程模型极其直观——你在服务端定义一个子路由，里面是普通的 async 函数，然后在客户端直接调用。让我用一个实际的博客查询场景来演示。

首先看服务端 router 的定义：

import { z } from "zod"; import { createTRPCRouter, publicProcedure } from "~/server/api/trpc"; export const postRouter = createTRPCRouter({ getAll: publicProcedure.query(async ({ ctx }) => { return ctx.prisma.post.findMany({ orderBy: { createdAt: "desc" }, include: { author: true }, }); }), getById: publicProcedure .input(z.object({ id: z.string() })) .query(async ({ ctx, input }) => { return ctx.prisma.post.findUnique({ where: { id: input.id }, include: { author: true }, }); }), });

注意到publicProcedure和zod的 input 校验是这套体系的关键设计。publicProcedure表示无需登录即可访问；如果要加权限保护，就换成protectedProcedure。zod 对象定义了入参的结构和校验规则，它既充当了类型来源，也充当了运行时校验器——两全其美，无需额外引入 yup 或 joi 之类的工具。

再看客户端如何调用。以 React 组件为例：

import { api } from "~/utils/api"; export function PostList() { const { data: posts, isLoading } = api.post.getAll.useQuery(); if (isLoading) return <div>加载中...</div>; return ( <ul> {posts?.map((post) => ( <li key={post.id}>{post.title} - {post.author?.name}</li> ))} </ul> ); }

这里最核心的亮点是：api.post.getAll.useQuery()里的data类型是完全由服务端返回类型自动推导出来的。你在 JSX 里用了post.author?.name，如果服务端没有 include author，这行代码再到编译阶段就会直接报错。这种体验真的太省心了，我每天都在受益。此外，React Query 的缓存机制也帮了大忙——同一个查询 key 在多个组件里使用，不会重复发请求，而是共享缓存，性能上天然有保障。

3.4 认证体系集成与安全细节处理

在 t3code 这类全栈应用中，认证是绕不开的模块。NextAuth.js 是 T3 生态默认推荐的认证库，它提供了一套完整的会话管理和多提供商接入方案。集成过程并不复杂，但有几个细节必须处理好。

第一，环境变量。GitHub 或 Google 登录需要GITHUB_CLIENT_ID和GITHUB_CLIENT_SECRET这类凭证，开发环境放在.env文件里，生产环境则要配置在 Vercel 或云服务器环境变量面板中。千万别把密钥硬编码在代码里，更别提交到 Git 仓库。

第二，会话回传机制。NextAuth 在 T3 中的典型模式是：客户端通过useSession()拿会话状态，服务端 tRPC 的protectedProcedure从请求上下文里读取 session 并校验用户身份。下面是一个典型的 protected procedure 定义：

import { createTRPCRouter, protectedProcedure, publicProcedure } from "~/server/api/trpc"; export const userRouter = createTRPCRouter({ getMe: protectedProcedure.query(({ ctx }) => { return ctx.prisma.user.findUnique({ where: { id: ctx.session?.user?.id }, }); }), });

这里ctx.session是服务端从请求头里的 cookie 解析出来的 session 对象，protectedProcedure内部已经判断了 session 是否存在，不存在会直接抛错。这种封装省去了每个接口手动判断登录状态的重复劳动，非常干净。

第三件重要的事是CSRF 防护和回调 URL 配置。NextAuth 默认对会话相关的 POST 请求做了 CSRF 校验，但你在配置 OAuth 提供商时，回调地址（比如http://localhost:3000/api/auth/callback/github）必须和供应商后台设置保持一致，否则会经常踩“登录跳转但进不来”的怪坑。我在本地开发时改过端口，结果每次登录都会报 redirect_uri_mismatch，排查了半小时才发现是回调地址写死了。

4. 实操过程与核心环节实现

4.1 完整开发流程闭门实录

现在我把 t3code 项目的完整开发流程从零走一遍。这个流程是我多次实践后总结的最顺滑的路径，你照着做基本不会卡壳。

首先，初始化项目并安装依赖。脚手架会让你选想集成的功能，此时全选即可。初始化完成后，先跑一次开发服务器，确认默认页面正常打开。接下来，最优先做的事是设计数据模型，而不是先写页面。我会先画一个简单的 ER 图，列出核心实体和它们的关系，然后用 Prisma schema 把它表达出来。比如做博客系统，至少要有 User 和 Post 两个模型；如果要加评论或标签，再继续扩充。数据模型稳定后，马上执行 migrate 命令，生成数据库表。

下一步，使用 Prisma Studio 可视化数据库（命令npx prisma studio会在浏览器打开一个数据库可视化界面），在这里添加几条测试数据。这一步很多人会跳过，但我强烈不建议——因为后续调试时，有数据可查远比对着空列表猜逻辑要高效。数据准备好后，回到代码层面，在 server 目录下创建postRouter和userRouter，把查询和变更逻辑写出来。

然后，把服务端数据暴露给前端页面。我会先实现一个最简单的文章列表页，调通 getAll 查询，确认数据能正常渲染。这里有一个我自己摸索出来的开发习惯：先把读操作全部做完，再做写操作。因为读操作能快速验证整个数据链路是否打通，链路通了，后面写操作就水到渠成了。写操作包括创建、编辑、删除文章，每个操作对应 tRPC 的useMutation，完成后再配合 React Query 的缓存失效机制刷新列表。

最后，加上登录注册流程，把部分页面转换成需要登录才能访问。这样一套下来，一个可用的应用雏形就出来了。

4.2 环境变量配置与数据库连接细节

项目能否在陌生环境跑起来，环境变量这一关是重中之重。t3code 项目的.env文件看起来大致像这样：

DATABASE_URL="file:./db.sqlite" NEXTAUTH_SECRET="your-secret-key" NEXTAUTH_URL="http://localhost:3000" GITHUB_CLIENT_ID="your-github-client-id" GITHUB_CLIENT_SECRET="your-github-client-secret"

这里每个变量背后都有讲究。DATABASE_URL是数据库连接串，开发期用 SQLite 文件路径即可；生产部署到 Vercel 时，如果使用 Postgres 托管服务（比如 Neon、Supabase），这个字符串需要替换成对应 Postgres 的连接串。注意 Prisma 不支持 SQLite 的远程部署，Vercel 的无服务器环境通常只读文件系统，所以生产库必须用线上可访问的网络数据库。

NEXTAUTH_SECRET是加密会话 token 的密钥，它是在 NextAuth 体系里最容易被忽略的安全项。开发环境可以随便填一个长随机字符串，生产环境必须使用足够随机且不公开的值，否则会话容易被伪造。NEXTAUTH_URL指定应用的基础地址，本地开发是 localhost，部署后就是正式域名，改端口时必须同步改这里，否则登录后跳转会异常。

我建议在项目根目录维护一份.env.example文件，里面列出所有环境变量但值是空的，提交到 Git 仓库，方便新成员加入时快速复制配置。实际的.env文件必须通过.gitignore排除，确保密钥永远不上传。

4.3 部署流程与生产环境优化

t3code 项目部署到 Vercel 的流程可以用“傻瓜式”来形容，但背后有两个常见坑值得单独拿出来说。

第一步，在 Vercel 后台新建项目，连接你的 Git 仓库。Vercel 会自动识别 Next.js 项目，这没什么问题。第二步，在项目的 Environment Variables 面板里，把.env里的配置逐条加进去。注意数据库连接串必须指向生产数据库，NEXTAUTH_URL要填正式域名。第三步，点击 Deploy，等一两分钟就能拿到线上地址。

第一个常见的坑是冷启动延迟。Vercel 的无服务器函数在闲置一段时间后，再次调用需要冷启动，第一个请求可能慢上几秒。如果业务对响应延迟敏感，可以考虑使用 Vercel 的 Fluid Computing 模式，或者改用常驻服务器（比如一台便宜的云 VPS）。第二个坑是数据库连接数管理。Prisma 在无服务器环境中每个请求可能新建一个连接，而很多数据库服务对并发连接数有限制。解决方法是启用 Prisma 的连接池扩展，或者在数据库服务商那边开通连接池功能。Neon 和 Supabase 都提供连接池 URL，把该地址填进 DATABASE_URL 即可缓解。

数据库连接串的配置范围要注意，比如直接使用本地 Postgres 的postgresql://user:pass@localhost:5432/db，生产环境千万不能这么干，一定要替换成线上实例。我见过有人本地开发时比较顺，结果一部署就 500 错误，查了半天是开发库和生产库混了。

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

5.1 类型报错的常规排查路径

在 t3code 这个体系里，类型报错是日常开发中最常见的事情。频率最高的场景是：你在 Prisma schema 里改了字段，重新迁移后页面里调用查询的组件开始飘红。绝大多数情况下，问题是Prisma Client 没有重新生成。排查路径很简单，先跑一遍npx prisma generate，如果报错消失，那就是这个原因。

还有一类类型报错来自 tRPC 的 input 定义与调用端不一致。比如服务端定义了z.object({ id: z.string() })，但客户端调用时传的是number类型，编译器立刻会给出明确提示。这种报错本质上是在帮你发现数据契约的断裂，正确的做法是修改调用端的业务逻辑，而不是用 as 关键字强行断言。as 断言是类型安全体系的敌人，它会让你绕过编译器检查，把错误推迟到运行时才暴露——这与 T3 的核心理念背道而驰。

第三类常见报错和 Next.js 的 fetch 缓存有关。在 Next.js 14+ 中，fetch 请求默认会进行静态缓存，如果你的页面是静态渲染的，tRPC 查询可能只跑一次，之后数据再也不更新。这时候要在页面组件里显式声明export const dynamic = "force-dynamic"，确保每次访问都拿最新数据。这个问题非常隐蔽，我一度以为是自己缓存配置错了，后来才发现是 Next.js 默认行为导致的。

5.2 表单校验和错误提示的边界情况

我在 make t3code 时，表单校验是 bug 高发区。一个典型的场景是：注册表单要求密码至少 6 位，但接口只返回一个笼统的 400 错误，用户体验很差。tRPC 配合 zod 的校验能力其实可以做得非常精细。比如：

createUser: publicProcedure .input(z.object({ email: z.string().email(), password: z.string().min(6).max(20), name: z.string().min(1).optional(), })) .mutation(async ({ ctx, input }) => { // 业务逻辑... })

如果客户端传了不合法的 email 或过短的密码，tRPC 会返回一个包含字段错误详情的响应。前端可以利用这个响应结构，把错误映射到对应表单控件上显示，体验接近本地校验。但要注意，不要把运行时校验当作唯一的校验手段。任何用户输入都必须先经过客户端基础校验（比如必填、格式），再通过 tRPC 输入层校验，最后在业务逻辑里做二次检查。三层各司其职，才能组成一个足够强壮的防御体系。

另一个边界问题是并发提交。用户在创建文章时连续点击提交按钮，会产生多条重复记录。解决办法是在服务端 mutation 里对关键字段加唯一约束，或者在前端提交后立即禁用按钮，等请求返回后再恢复。我更推荐前者——服务端约束才是真正防止脏数据的保险，前端防重只是在帮用户避免误触。

5.3 缓存更新与数据一致性的实践经验

React Query 的缓存策略是 t3code 项目中容易踩坑的重灾区。以文章列表为例，你调用了api.post.getAll.useQuery()把列表数据缓存下来了，之后新建文章成功后，必须让这个缓存失效，否则 UI 上不会自动出现新文章。标准解法是在 mutation 的onSuccess回调里调用utils.post.getAll.invalidate()：

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

invalidate()会把指定 key 的查询标记为过期，并触发现有观察者自动重新拉取数据。这个模式非常清晰，但它要求开发者在每个 mutation 之后都记得做对应查询的失效动作。我一度忘记在删除操作后调用invalidate()，结果前端页面上文章还在，刷新后才发现其实已经删了。排查的时候我一度怀疑是服务端回滚了，后来才意识到是缓存没更新——这种问题在开发期很难发现，因为热更新有时会遮蔽缓存。

如果想要更精细的控制，可以给查询加参数，比如api.post.getById.useQuery({ id: postId })，失效时也要传相同的参数，否则匹配不上。React Query 默认用“模糊匹配”，不带参数调用invalidate()会同时失效所有 post 相关的查询，这在某些场景下会引发多余请求。性能不敏感时问题不大，但如果列表数据量很大，最好还是精确失效，减少不必要的数据拉取。

6. 性能优化与扩展方向

6.1 服务端数据获取的优化手段

在 t3code 项目跑通之后，性能优化就提到日程上来了。最核心的优化点是减少不必要的服务端请求和数据传输量。Prisma 默认会返回记录的所有标量字段，如果你只需要标题和创建时间，却在 select 里没有限制字段，会把 content 这种大字段也拉回来——浪费网络带宽，也增加序列化时间。改进方式很简单，在 Prisma 查询里显式使用 select：

getAll: publicProcedure.query(({ ctx }) => { return ctx.prisma.post.findMany({ select: { id: true, title: true, createdAt: true, }, orderBy: { createdAt: "desc" }, }); })

传输数据量从“整篇文章”缩减到“几行摘要”，对列表页来说性能提升非常明显。

另一个优化点是React Query 的 staleTime 配置。默认情况下，React Query 会将请求过的数据缓存一段时间，但如果 staleTime 较短，用户切换页面后重新进入时，组件会立即重新请求。对于不常变动的数据，比如文章详情，可以把 staleTime 设为 60 秒或更长，减少重复请求压力。设置方法简单：在查询里加一个staleTime配置项：

api.post.getById.useQuery({ id: postId }, { staleTime: 60_000 });

这类优化不需要大动架构，就是几个配置的事，但效果立竿见影，尤其在高频交互页面里感觉明显。

6.2 后续功能扩展的个人建议

t3code 这个项目如果继续往下走，我会优先考虑这几个扩展方向。一是引入文件上传能力。Next.js 的 API 路由可以直接接收 multipart 表单，配合上传服务商（比如 S3 或者 Cloudflare R2）就能实现图片或附件的上传。注意文件上传接口需要单独处理鉴权和大小限制，不能直接套用 tRPC 的 JSON 序列化流程。

二是加入后台任务处理。比如用户注册后发送欢迎邮件、定时生成报表，这类任务应该用消息队列或定时任务来处理，而不应在 tRPC 的 mutation 里同步等待第三方 API 响应。可以引入更轻量的方案，比如用 Vercel Cron 触发一个 API 路由去扫描待处理的队列任务。

三是多语言或国际化支持。Next.js 对 i18n 有一整套内置支持，配合 tRPC 的无缝类型传递，可以轻松把多语言包和用户偏好设置结合到现有数据结构中，不需要对核心逻辑做大改造。

我个人实操下来的体会是，T3 这套体系的最大价值不在于某个单一框架有多强，而在于它把类型安全贯穿了数据生命周期的全线。你在写服务端逻辑时，编译器就在替你检查客户端的使用是否正确；你在写前端页面时，编译器又在帮你校验数据的形状是否合法。这种“编译器当裁判”的开发体验，一旦用习惯，真的回不去手写接口文档和手工维护类型的时代了。希望这篇内容能帮你顺利跑通你的第一个 T3 项目，少踩几个我踩过的坑。