后端框架Backend Framework

你可能会说

写后端有没有现成的架子,别让我从零搭。

开发后端时使用的现成项目骨架,帮助组织请求、处理代码和错误例如,注册请求到来后,框架会把它交给注册功能的代码,并在出错时返回明确结果。框架不是一门新语言,应优先沿用项目已经选择的方案。
入口路由GET /api/signup 框架代办公共处理日志 · 身份 · 错误 你写的业务处理函数创建账号
框架给骨架;业务规则仍要你写清楚

什么时候用

  • 优先使用项目已经选好的框架,遵循现有目录和写法
    先沿用项目结构
    src/├─ routes/orders.ts├─ services/payment.ts└─ app.ts
    新代码放进团队已经熟悉的位置
  • 小项目选简单方案;团队大、规则多时再考虑更强约束
    规模决定约束
    小型 APIExpress · 少量目录多人项目NestJS · 明确模块
  • 先读官方最小示例:一条 GET、一条 POST、一种错误处理
    先跑通官方最小示例
    GET /hello200 OKPOST /items201 Created错误400 Bad Request
  • 让 AI 说明代码放在哪个文件、由谁调用、如何验证
    让 AI 交代上下文
    放在哪routes/orders.ts谁调用POST /api/orders怎么验npm test

什么时候不用

  • 把框架名字当能力:换框架不会自动解决业务设计问题
    框架不能替你决定业务
    换成 NestJS✓ 目录更整齐 退款规则? 仍未定义
  • 一个项目同时混用多个后端框架,路由和配置各管一套
    一条请求穿过三套框架
    Next RouteExpressFastify
    路由、插件和错误处理各管一套
  • 不看版本就复制旧教程:配置和 API 很可能已经变化
    教程版本与项目版本不一致
    旧教程Framework v3 当前项目Framework v5
    先查当前版本的官方文档
  • 只会运行模板却不理解请求入口、处理过程和响应出口,排错时会缺少判断依据
    模板能启动,但请求流程说不清
    请求从哪进?谁处理?响应从哪出?
组成结构 · Anatomy
路由入口公共处理业务处理
根据 HTTP 方法和路径,把请求交给对应处理函数
在业务代码前后统一完成日志、身份、校验或错误转换
执行这条端点自己的业务规则,并返回明确响应
常见变体 · Variants
全栈框架Full-stack
Next.js · Nuxt
页面和后端放在一个项目里
轻量 API 框架Minimal API
Express · Fastify · Flask
快速搭几条清晰接口
带结构的框架Structured
NestJS · Django
模块和规则较多的团队项目
典型使用场景
Next.js Route Handler
Next.js Route Handler页面与接口放在同一项目
app/api/posts/route.tsexport async function GET() { return Response.json(posts)}
访问 GET /api/posts
Express 小型 API
Express API用少量路由构建小服务
app.get("/api/tasks", listTasks)app.post("/api/tasks", createTask)app.use(errorHandler)
FastAPI 数据接口
FastAPISchema 自动生成接口文档
POST /items创建商品Request bodyItemSchemaResponse201
Swagger 文档可直接调试
Django 内容管理后台
Django 后台成熟内容项目的管理界面
文章1,284 条作者42 人待审核18 条
框架自带模型、权限和管理后台
延伸阅读 · 权威出处