TypeScript 后端入门全景:Hono + Zod + Drizzle + PostgreSQL

TypeScript 后端入门全景:Hono + Zod + Drizzle + PostgreSQL

一篇文章看懂 2026 年 TS 后端的主流技术栈。讲清每个工具解决什么问题、怎么用、用法延伸、以及一个后端工程师该有的心智模型。

写在前面

如果你已经会 TS / Node,但没真正写过后端项目------这篇文章是为你写的。

后端的水比想象中深:HTTP 协议、数据库、错误处理、性能、安全......一上来全堆给你会被劝退。这篇文章把这些拆成 4 个工具 + 6 个心智模型,看完你能:

• 知道 TS 后端"标准技术栈"长什么样
• 理解每个工具解决什么问题(不只是 "怎么用")
• 能搭出自己的第一个生产级项目
• 知道下一步该学什么、不该学什么

---

目录

• 一、技术栈全景
• 二、Hono:HTTP 框架
• 三、Zod:数据验证 + 类型推导
• 四、Drizzle ORM:数据库操作层
• 五、PostgreSQL:数据存储
• 六、把它们串起来
• 七、6 个后端工程师必备心智模型
• 八、扩展技术栈
• 九、常见误区

---

一、技术栈全景

1. 后端做的事

去掉所有花哨的术语,后端就在做 4 件事:

┌───────────────────────────────────────────┐
│                                            │
│   1. 接收请求(HTTP)                       │
│      ↓                                     │
│   2. 验证数据(防止脏数据进来)              │
│      ↓                                     │
│   3. 操作数据(存/取/算)                   │
│      ↓                                     │
│   4. 返回结果(JSON / 流式 / 文件)         │
│                                            │
└───────────────────────────────────────────┘

对应 4 个核心工具:

步骤	工具	包名
HTTP 框架	Hono	hono
数据验证	Zod	zod
数据库操作	Drizzle ORM	drizzle-orm
数据存储	PostgreSQL	(Docker 跑)

这 4 个组合就是2026 年 TS 后端的"现代主流栈" ------轻量、类型安全、生态成熟。

2. 完整文件结构

my-backend/
├── docker-compose.yml          # PostgreSQL 容器
├── drizzle.config.ts           # Drizzle 配置
├── .env                        # 环境变量(不进 Git)
├── .gitignore
├── package.json
├── tsconfig.json
└── src/
    ├── index.ts                # Hono 入口
    ├── routes/                 # 路由文件
    ├── schemas/                # Zod schema
    ├── db/
    │   ├── index.ts            # DB 连接
    │   ├── schema.ts           # 表结构定义
    │   └── migrations/         # 数据库变更历史
    └── middlewares/            # 中间件

---

二、Hono:HTTP 框架

1. 它是什么

Hono = 现代化的 Web 框架,定位类似 Express,但 2020 年代重新设计的版本。

对比:

Express(2010 年代):  Hono(2020 年代):
├─ 回调式 API         ├─ 基于 Web 标准
├─ TS 支持靠社区       ├─ 原生 TS,类型推导强  
├─ 仅 Node            ├─ Node / Bun / Deno / Cloudflare
└─ 老牌、稳定          └─ 轻量、性能更好

2. 为什么选它

维度	Express	Hono
类型支持	弱	强(全链路类型推导)
体积	大(几百 KB + 依赖)	小(< 50KB,零依赖)
性能	中等	高(基于 Web Fetch API)
部署目标	仅 Node	多平台(Edge/Serverless)
学习曲线	易	易

新项目优先 Hono。老项目 Express 也能用,没必要硬切。

3. 基础用法

import { Hono } from 'hono'
import { serve } from '@hono/node-server'

const app = new Hono()

app.get('/', (c) => c.json({ hello: 'world' }))

app.post('/users', async (c) => {
  const body = await c.req.json()
  return c.json({ data: body }, 201)
})

app.get('/users/:id', (c) => {
  const id = c.req.param('id')
  return c.json({ id })
})

serve({ fetch: app.fetch, port: 3000 })

4. Context(c)的常用方法

// 读取请求
c.req.param('id')           // URL 参数 :id
c.req.query('q')            // query string ?q=xxx
c.req.header('Authorization') // header
c.req.json()                 // 解析 JSON body
c.req.formData()             // 解析 form

// 返回响应
c.json(data)                 // 返回 JSON
c.json(data, 201)            // 带状态码
c.text('hello')              // 返回纯文本
c.redirect('/login')         // 重定向
c.html('<h1>Hi</h1>')        // 返回 HTML

// 流式响应(AI 应用必备)
import { streamText, streamSSE } from 'hono/streaming'

c.streamText(async (stream) => {
  await stream.write('chunk 1\n')
  await stream.write('chunk 2\n')
})

5. 中间件

中间件是 Hono 的核心机制------请求经过一层层中间件,最后到 handler。

import { logger } from 'hono/logger'
import { cors } from 'hono/cors'

// 全局中间件
app.use('*', logger())     // 所有请求打印日志
app.use('*', cors())       // 全部允许跨域

// 局部中间件
app.use('/admin/*', authMiddleware)   // 只对 /admin 开头的路由鉴权

// 单接口中间件
app.post(
  '/users',
  authMiddleware,        // 1. 先鉴权
  zValidator('json', schema),  // 2. 再验证
  (c) => { /* handler */ }     // 3. 业务
)

6. 用法延伸:RESTful 路由设计

RESTful = 用 HTTP 方法 + 复数资源名 表达操作:

app.get('/users')          // 列表
app.post('/users')         // 创建
app.get('/users/:id')      // 详情
app.patch('/users/:id')    // 更新
app.delete('/users/:id')   // 删除

// 子资源
app.get('/users/:id/posts')        // 用户的帖子列表
app.post('/users/:id/posts')       // 给用户创建帖子

方法	含义
GET	查
POST	创建
PUT	全量替换
PATCH	部分更新
DELETE	删除

实践:用 PATCH 不用 PUT(更灵活,只传变化的字段)。

7. 用法延伸:统一错误处理

app.onError((err, c) => {
  console.error(err)
  return c.json({ error: err.message }, 500)
})

app.notFound((c) => {
  return c.json({ error: 'Not Found', path: c.req.path }, 404)
})

业务代码里直接 throw new Error(...),onError 统一处理。

---

三、Zod:数据验证 + 类型推导

1. 它是什么

Zod = TS 生态最流行的"数据验证库" 。一句话:用 Schema 描述数据,Zod 帮你验证 + 推导类型。

const UserSchema = z.object({
  name: z.string().min(1).max(50),
  email: z.string().email(),
  age: z.number().int().positive(),
})

// 自动推导出类型
type User = z.infer<typeof UserSchema>
// = { name: string, email: string, age: number }

// 验证未知数据
const result = UserSchema.parse(unknownData)
// 如果不合法,抛异常
// 如果合法,result 类型自动是 User

2. 为什么需要

后端接收的数据都是不可信的------前端传啥都可能,故意搞破坏的也存在。

// ❌ 没验证:危险
app.post('/users', async (c) => {
  const body = await c.req.json()   // body 是 any
  await db.insert(users).values(body)  // 用户传啥就存啥
})
// 后果:
// 用户传 {name: 100000 字} → 数据库炸
// 用户传 {role: 'admin'} → 提权
// 用户传 {createdAt: '不是日期'} → 类型不对

// ✅ 有验证:安全
app.post(
  '/users',
  zValidator('json', UserSchema),    // 验证中间件
  async (c) => {
    const body = c.req.valid('json') // 已验证,类型安全
    await db.insert(users).values(body)
  }
)

3. 常用 Schema

// 基础类型
z.string()
z.number()
z.boolean()
z.date()

// 字符串约束
z.string().min(1).max(100)        // 长度
z.string().email()                 // 邮箱
z.string().url()                   // URL
z.string().uuid()                  // UUID
z.string().regex(/^\d+$/)          // 正则

// 数字约束
z.number().int()                   // 整数
z.number().positive()              // 正数
z.number().min(0).max(100)         // 范围

// 复杂结构
z.array(z.string())                // 字符串数组
z.object({ name: z.string() })     // 对象
z.enum(['a', 'b', 'c'])            // 枚举
z.union([z.string(), z.number()])  // 联合

// 修饰符
z.string().optional()              // 可选(可不传)
z.string().nullable()              // 可为 null
z.string().default('hello')        // 默认值

4. 跟 Hono 集成

import { zValidator } from '@hono/zod-validator'

const CreateUserSchema = z.object({
  name: z.string().min(1),
  email: z.string().email(),
})

app.post(
  '/users',
  zValidator('json', CreateUserSchema),
  (c) => {
    const body = c.req.valid('json')
    // body 类型自动是 { name: string, email: string }
    return c.json({ data: body })
  }
)

验证失败时,zValidator 自动返回 400 + 错误详情。

5. 用法延伸:Schema 复用

const UserSchema = z.object({
  id: z.string().uuid(),
  name: z.string(),
  email: z.string().email(),
  password: z.string(),
  createdAt: z.date(),
})

// 创建用户:不需要 id 和 createdAt
const CreateUserSchema = UserSchema.omit({
  id: true,
  createdAt: true,
})

// 公开返回:不要 password
const PublicUserSchema = UserSchema.omit({
  password: true,
})

// 更新:所有字段可选
const UpdateUserSchema = CreateUserSchema.partial()

pick / omit / partial / merge / extend 让 Schema 像 TS 类型一样可组合。

6. 用法延伸:transform 数据转换

const QuerySchema = z.object({
  // URL query 是字符串,但业务要数字
  page: z.string()
    .regex(/^\d+$/)
    .transform(Number)
    .default('1'),
  pageSize: z.string()
    .transform(Number)
    .default('20'),
})

// 验证后 page 自动是 number 类型,不是 string

7. 用法延伸:给 LLM 用

AI 应用里,需要把工具的参数 schema 传给 LLM。Zod schema 可以转 JSON Schema:

import { zodToJsonSchema } from 'zod-to-json-schema'

const SearchSchema = z.object({
  query: z.string(),
  limit: z.number().optional(),
})

const jsonSchema = zodToJsonSchema(SearchSchema)
// 可以直接传给 Claude / OpenAI 的 tool_use

一份 Zod schema 同时给后端验证 + 给 LLM 描述工具------AI 时代的最爽用法。

---

四、Drizzle ORM:数据库操作层

1. 它是什么

ORM = Object-Relational Mapping------把"数据库表"映射成"代码里的对象"。

// 没有 ORM:写 SQL 字符串
await db.query("SELECT * FROM users WHERE id = $1", [id])
// 返回类型是 any,字段拼错运行时才报错

// 有 ORM(Drizzle):
const user = await db.select().from(users).where(eq(users.id, id))
// 类型自动推导,拼错编译期就报错

2. 为什么选 Drizzle

ORM	特点
Drizzle ⭐	新一代,Schema 即类型,无需 codegen,SQL 风格
Prisma	老牌,生态最好,但要 codegen 步骤、运行时性能略差
TypeORM	用装饰器,有点过时
Sequelize	远古选手,不推荐

Drizzle 的核心卖点:

• Schema 即 TS 类型------改 schema 类型立刻变
• 零运行时开销------编译完没有抽象层
• API 像 SQL------会 SQL 的人立刻上手
• 支持 PG / MySQL / SQLite------一套 API,切数据库换包

3. Schema 定义

import { pgTable, uuid, varchar, text, timestamp } from 'drizzle-orm/pg-core'

export const users = pgTable('users', {
  id: uuid('id').defaultRandom().primaryKey(),
  email: varchar('email', { length: 255 }).notNull().unique(),
  name: varchar('name', { length: 100 }).notNull(),
  bio: text('bio'),
  createdAt: timestamp('created_at').defaultNow().notNull(),
})

// 类型自动推导
export type User = typeof users.$inferSelect       // 查询返回的类型
export type NewUser = typeof users.$inferInsert    // 插入时的类型

4. 查询基础

import { db } from './db'
import { users } from './db/schema'
import { eq, and, gt, desc } from 'drizzle-orm'

// 查全部
const all = await db.select().from(users)

// 条件查询
const one = await db
  .select()
  .from(users)
  .where(eq(users.id, '...'))

// 多条件 + 排序 + 分页
const list = await db
  .select()
  .from(users)
  .where(and(
    eq(users.role, 'admin'),
    gt(users.createdAt, new Date('2026-01-01'))
  ))
  .orderBy(desc(users.createdAt))
  .limit(20)
  .offset(0)

// 插入
const [newUser] = await db
  .insert(users)
  .values({ email: '...', name: '...' })
  .returning()    // ← 返回插入后的完整记录

// 更新
await db
  .update(users)
  .set({ name: 'New' })
  .where(eq(users.id, '...'))

// 删除
await db
  .delete(users)
  .where(eq(users.id, '...'))

5. 用法延伸:外键关联

export const users = pgTable('users', {
  id: uuid('id').defaultRandom().primaryKey(),
  // ...
})

export const posts = pgTable('posts', {
  id: uuid('id').defaultRandom().primaryKey(),
  title: varchar('title', { length: 200 }).notNull(),
  // 外键:posts.user_id 指向 users.id
  userId: uuid('user_id').notNull().references(() => users.id, {
    onDelete: 'cascade',   // 用户删除时,相关 posts 一起删
  }),
})

6. 用法延伸:JOIN 查询

// 查所有 posts 并带上作者信息
const result = await db
  .select({
    post: posts,
    user: users,
  })
  .from(posts)
  .innerJoin(users, eq(posts.userId, users.id))

7. 用法延伸:事务

await db.transaction(async (tx) => {
  const [user] = await tx.insert(users).values({...}).returning()
  await tx.insert(profiles).values({ userId: user.id, ...})
  // 任何一步失败,整个事务回滚
})

8. Migration 工作流

# 1. 改 src/db/schema.ts(加字段、改字段、加表)
# 2. 生成 migration SQL
pnpm drizzle-kit generate
# → 生成 src/db/migrations/0001_xxx.sql

# 3. 应用到数据库
pnpm drizzle-kit migrate

为什么不直接改数据库?

• Migration 文件进 Git,团队同步
• 生产部署可重现(dev → staging → prod 用同一套)
• 出问题可回滚

类比:Git 管代码变更,Migration 管数据库变更。

---

五、PostgreSQL:数据存储

1. 为什么选 PostgreSQL

数据库	一句话定位
PostgreSQL ⭐	功能最强、最稳定的开源数据库
MySQL	老牌,简单稳定,生态广
SQLite	文件型,单机小项目用
MongoDB	NoSQL,文档数据库,简单场景灵活
Redis	内存数据库,主要做缓存

PostgreSQL 的杀手锏:

• 标准 SQL 之外,支持 JSON、向量、全文搜索、地理位置等扩展
• AI 时代刚需:pgvector 让 Postgres 能做向量搜索(RAG 的底层)
• 全开源、社区强、企业级可靠

2. 用 Docker 跑 Postgres

不要直接装到本机,污染环境。用 Docker:

# docker-compose.yml
services:
  postgres:
    image: postgres:16
    container_name: my-postgres
    restart: unless-stopped
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: my_app
    ports:
      - '5432:5432'
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

docker compose up -d        # 启动
docker compose down         # 停止(数据保留)
docker compose down -v      # 停止 + 删数据(危险)

3. 连接字符串

postgresql://username:password@host:port/database

例:

postgresql://postgres:postgres@localhost:5432/my_app

放进 .env:

DATABASE_URL=postgresql://postgres:postgres@localhost:5432/my_app

.env 必须进 .gitignore------里面有密码。

4. 必须了解的 PostgreSQL 概念

概念	一句话理解
Table(表)	像 Excel 表格,有列和行
Column(列)	字段,有名字和类型
Row(行)	一条记录
Primary Key(主键)	唯一标识每一行
Foreign Key(外键)	指向另一张表的主键
Index(索引)	加快查询的"目录"
Migration	数据库结构的变更记录
Transaction(事务)	一组操作"全部成功或全部失败"
JSONB	存 JSON 还能索引和查询

5. 用法延伸:pgvector(AI 必备)

AI 应用(RAG)需要存"向量"(把文本转成 1536 维数字)。pgvector 扩展让 Postgres 支持向量:

CREATE EXTENSION vector;

CREATE TABLE documents (
  id UUID PRIMARY KEY,
  content TEXT,
  embedding vector(1536)   -- ← 向量字段
);

-- 找最相似的 5 条
SELECT * FROM documents
ORDER BY embedding <=> '[0.1, 0.2, ...]'  -- 余弦相似度
LIMIT 5;

为什么 AI 时代选 PG 而不是 MongoDB ?------因为 pgvector 让你一个数据库搞定关系数据 + 向量数据,不用再多搭一个 Pinecone。

---

六、把它们串起来

1. 一个完整的小项目

// src/db/schema.ts
import { pgTable, uuid, varchar, timestamp } from 'drizzle-orm/pg-core'

export const users = pgTable('users', {
  id: uuid('id').defaultRandom().primaryKey(),
  email: varchar('email', { length: 255 }).notNull().unique(),
  name: varchar('name', { length: 100 }).notNull(),
  createdAt: timestamp('created_at').defaultNow().notNull(),
})

// src/db/index.ts
import { drizzle } from 'drizzle-orm/postgres-js'
import postgres from 'postgres'

const client = postgres(process.env.DATABASE_URL!)
export const db = drizzle(client)

// src/schemas/user.ts
import { z } from 'zod'

export const CreateUserSchema = z.object({
  email: z.string().email(),
  name: z.string().min(1).max(100),
})

// src/index.ts
import { Hono } from 'hono'
import { serve } from '@hono/node-server'
import { zValidator } from '@hono/zod-validator'
import { eq } from 'drizzle-orm'

import { db } from './db'
import { users } from './db/schema'
import { CreateUserSchema } from './schemas/user'

const app = new Hono()

// 列表
app.get('/users', async (c) => {
  const all = await db.select().from(users)
  return c.json({ data: all })
})

// 创建
app.post(
  '/users',
  zValidator('json', CreateUserSchema),
  async (c) => {
    const body = c.req.valid('json')
    const [newUser] = await db.insert(users).values(body).returning()
    return c.json({ data: newUser }, 201)
  }
)

// 详情
app.get('/users/:id', async (c) => {
  const id = c.req.param('id')
  const [user] = await db.select().from(users).where(eq(users.id, id)).limit(1)
  if (!user) return c.json({ error: 'Not found' }, 404)
  return c.json({ data: user })
})

// 错误处理
app.onError((err, c) => {
  console.error(err)
  return c.json({ error: err.message }, 500)
})

serve({ fetch: app.fetch, port: 3000 })

2. 数据流

浏览器
   ↓ POST /users { email, name }
Hono(接收请求)
   ↓
Zod 中间件(验证 body)
   ↓ ✓ 验证通过
Handler(业务逻辑)
   ↓
Drizzle(生成 SQL)
   ↓
PostgreSQL(存数据)
   ↓
Drizzle(返回数据)
   ↓
Handler(返回 JSON)
   ↓
浏览器收到 { data: {...} }

每一步都有类型保证------这是 TS 后端的爽点。

---

七、6 个后端工程师必备心智模型

1. 一切外部输入都不可信

✗ 错误心态:"前端会传对的数据"
✓ 正确心态:"前端可能传任何东西,我必须验证"

实践:

• 所有接口必须用 Zod 验证 body / query / param
• 数据库 schema 加 .notNull() / .unique() 双保险
• 永远不直接拼 SQL(防 SQL 注入)

2. Schema 是唯一真相来源(Single Source of Truth)

✗ 错误做法:Zod schema 一份、TS 类型一份、DB schema 一份、文档一份
✓ 正确做法:从 schema 推导出所有

实践:

• Drizzle schema → 自动推 TS 类型
• Zod schema → 自动推 TS 类型 + 验证 + 文档

3. 错误处理是一等公民,不是 if-else 凑数

✗ 错误做法:每个 handler 写一堆 if-return
✓ 正确做法:全局 onError + 自定义错误类 + 让异常自然冒泡

class NotFoundError extends Error {
  status = 404
}

app.get('/users/:id', async (c) => {
  const user = await findUser(c.req.param('id'))
  if (!user) throw new NotFoundError('User not found')
  return c.json({ data: user })
})

app.onError((err: any, c) => {
  return c.json({ error: err.message }, err.status || 500)
})

4. 数据库变更必须可追溯

✗ 错误做法:直接 ALTER TABLE 改库
✓ 正确做法:Migration 文件进 Git

理由:

• 团队同步(同事拉代码自动同步数据库)
• 生产部署(dev/staging/prod 用一套)
• 回滚(出问题能撤回)

5. 不暴露内部信息

✗ 错误返回:{ error: "Error: ER_DUP_ENTRY: Duplicate entry 'x@y.com'..." }
   (暴露数据库错误码、字段名、SQL 结构)

✓ 正确返回:{ error: "Email already exists" }
   (业务语言,不暴露技术细节)

实践:

• 生产环境 onError 不返回 stack trace
• 敏感字段(password)用 Zod 的 .omit({ password: true }) 过滤
• URL 用 UUID 不用自增 ID

6. 性能优化等"瓶颈出现"再做

✗ 错误做法:一上来就上 Redis + 缓存 + 队列 + K8s
✓ 正确做法:先跑通,再用真实数据找瓶颈

实践:

• 先用 PostgreSQL 单库
• 数据量大了再加索引
• 真的慢了再加 Redis 缓存
• 不要 over-engineering

---

八、扩展技术栈

主线学完后,这些是常用的扩展工具:

1. 认证 / 鉴权

JWT(jsonwebtoken)         → 登录后发 token,后续请求带 token
bcrypt / argon2           → 密码哈希
OAuth(认证第三方登录)     → 微信/Google/GitHub 登录

2. 缓存

Redis(ioredis)            → 缓存 / 限流 / 分布式锁
node-cache                → 进程内缓存(简单场景)

3. 队列 / 异步任务

BullMQ(基于 Redis)        → 任务队列、定时任务
node-cron                 → 简单定时任务

4. 日志 / 监控

pino                      → 高性能结构化日志
Sentry                    → 错误监控
OpenTelemetry             → 分布式追踪

5. 测试

Vitest                    → 单元测试(比 Jest 快,TS 友好)
Supertest                 → HTTP 接口测试

6. 部署

Docker + Docker Compose   → 容器化
Railway / Render          → 简单云部署
Vercel(适合 Edge)         → 前端 + 后端一起部署

7. AI 时代必学

Vercel AI SDK             → LLM 集成 + 流式响应
@anthropic-ai/sdk         → Claude API
openai                    → OpenAI API
pgvector                  → 向量搜索(RAG)
LangChain.js / LangGraph  → Agent 框架

---

九、常见误区

1. "为了性能必须用 Bun"

真相:90% 的场景下,Node 22 + tsx 完全够用。
Bun 性能更好但生态不完整,新手用 Bun 容易踩坑。

2. "ORM 慢,我手写 SQL"

真相:Drizzle 等现代 ORM 几乎零开销,性能瓶颈 99% 在
数据库索引、N+1 查询、网络 IO,不在 ORM 本身。

3. "我用 Prisma 不用 Drizzle"

两个都行。Prisma 生态更成熟,Drizzle 更轻量更接近 SQL。
新项目可以尝试 Drizzle,老项目用 Prisma 也没问题。

4. "MongoDB 比 PostgreSQL 现代"

真相:Postgres 支持 JSONB,能完全替代 MongoDB 大部分场景,
还能做关系查询和向量搜索。一个 DB 搞定所有。

5. "微服务比单体更先进"

真相:99% 的项目用单体就够。微服务的复杂度只在团队/规模
真的需要时才值得。盲目上微服务 = 自找麻烦。

6. "我要学 K8s 才算后端"

真相:不需要。Railway / Render 之类的平台让部署像 push 代码一样
简单。K8s 是大公司基建,小团队用不到。

---

十、学习路径建议

✅ 必学(2 周搞定):
   1. Hono 基础路由 + 中间件
   2. Zod 基础 schema + 验证
   3. Drizzle 基础查询 + Migration
   4. PostgreSQL 用 Docker 跑起来

✅ 进阶(再 1-2 周):
   5. JWT 登录认证
   6. 错误处理 + 日志
   7. 单元测试基础

✅ AI 应用方向:
   8. Vercel AI SDK + LLM 集成
   9. pgvector + RAG
   10. Tool Use / Function Calling

⏸ 暂不学(等真用上再学):
   - K8s / 微服务
   - 消息队列(Kafka 等)
   - 分布式系统
   - 数据库性能调优深度

---

十一、参考资源

• Hono 官方文档:hono.dev
• Zod 官方文档:zod.dev
• Drizzle ORM 官方文档:orm.drizzle.team
• PostgreSQL 文档:www.postgresql.org/docs/16/
• Docker Desktop:www.docker.com/products/do...

---

这一篇是 TS 后端的"全景图"。后续会写各个细分话题的深度文章,包括 AI 应用集成、RAG、Agent 设计、性能优化等。