很多前端开发者或编程初学者对后端开发的认知是模糊的 —— 后端到底在做什么？API 是什么？RESTful 怎么理解？Docker 又是干嘛的？本文用最通俗的语言，系统梳理后端开发的核心知识框架，帮你建立清晰的全局认知。

一、前端与后端的分工

1.1 一句话理解

前端：负责数据的展示和用户交互（你看到的页面、按钮、表单） 后端：负责数据的存储、处理，以及给前端提供接口（你看不到的逻辑）

1.2 数据交互流程

用户操作
   │
   ▼
┌──────────┐   request    ┌──────────┐   response   ┌──────────┐
│  客户端   │ ──────────▶ │  网络     │ ──────────▶ │  服务端   │
│ (前端)    │ ◀────────── │           │ ◀────────── │ (后端)    │
└──────────┘   response   └──────────┘   request    └────┬─────┘
                                                         │
                                                         ▼
                                                   ┌──────────┐
                                                   │  数据库   │
                                                   └──────────┘

用户在前端点击一个按钮 → 前端向后端发送请求（request）→ 后端处理请求、操作数据库 → 后端返回响应（response）→ 前端拿到数据渲染页面。

二、后端技术栈速览

2.1 编程语言

几乎所有主流编程语言都能写后端：

语言	代表框架	特点
Python	Django、Flask、FastAPI	语法简洁，开发速度快
Java	Spring Boot	企业级首选，生态最成熟
JavaScript	Express.js、Nest.js	前后端统一语言
C#	ASP.NET	微软生态，Windows 友好
Go	Gin、Fiber	高性能，并发能力强

2.2 数据库

类型	代表	特点
关系型	MySQL、PostgreSQL、SQLite	表结构，SQL 查询，强一致性
非关系型	MongoDB、Redis	灵活文档结构，高性能缓存

2.3 Node.js 是什么

Node.js 不是一门新语言，它就是 JavaScript 在服务端的运行环境。

以前 JavaScript 只能在浏览器里跑，有了 Node.js，JavaScript 也能写后端了。安装 Node.js 后，可以用 npm（包管理器）安装各种依赖：

npm install express    # 安装 Express 框架

三、路由：URL 怎么找到对应的处理逻辑

3.1 什么是路由

路由就是 URL 路径与处理函数的映射关系。后端收到请求时，根据 URL 路径决定由哪个函数来处理。

http://localhost:8989        → 主路由（首页）
http://localhost:8989/a/b    → 子路由（具体功能）

3.2 路由示例

以一个待办事项（ToDo List）应用为例，需要以下路由：

功能	路由
用户注册 / 登录	/auth/register、/auth/login
获取所有 ToDo	GET /todos
获取单个 ToDo	GET /todos/1
创建 ToDo	POST /todos
更新 ToDo	PUT /todos/1
删除 ToDo	DELETE /todos/1
搜索 ToDo	GET /todos?keyword = 购物

四、API 设计模式

4.1 什么是 API

API（Application Programming Interface）就是后端提供给前端调用的接口。前端通过 API 向后端发送请求、获取数据。

你可以把 API 理解为餐厅的菜单 —— 你不需要知道厨房怎么做菜（后端逻辑），只需要按菜单点菜（调用 API），服务员就会把菜端给你（返回数据）。

4.2 常见 API 设计模式

模式	特点
RESTful	最主流，基于 HTTP 方法 + 资源路径，简单直观
GraphQL	前端自由选择需要的字段，灵活但学习成本高
RPC	远程过程调用，性能高，适合内部服务通信
SOAP	老牌企业级协议，XML 格式，重但规范

4.3 RESTful API 核心思想

RESTful 的设计哲学用两个维度理解：

维度一：资源（Resource）—— 你在操作什么东西？

todos    → 待办事项
users    → 用户
orders   → 订单
products → 商品

维度二：HTTP 方法（Method）—— 你对这个资源做什么操作？

HTTP 方法	动作	语义
GET	查询	获取资源
POST	创建	新建资源
PUT	更新	替换整个资源
PATCH	部分更新	修改资源的部分字段
DELETE	删除	删除资源

4.4 RESTful 实战示例

以 ToDo 应用为例：

GET    /todos          → 获取所有待办事项
GET    /todos/1        → 获取 ID 为 1 的待办事项
POST   /todos          → 创建一个新的待办事项
PUT    /todos/1        → 更新 ID 为 1 的待办事项
DELETE /todos/1        → 删除 ID 为 1 的待办事项

URL 表示资源，HTTP 方法表示动作，两者组合就表达了完整的操作语义。

五、如何测试 API 接口

写好后端 API 后，需要测试它是否正常工作。常用工具：

5.1 curl（命令行）

最基础的测试方式，直接在终端发请求：

# GET 请求
curl http://localhost:8000/todos

# POST 请求
curl -X POST http://localhost:8000/todos \
  -H "Content-Type: application/json" \
  -d '{"title": "学习后端开发"}'

# DELETE 请求
curl -X DELETE http://localhost:8000/todos/1

5.2 Swagger（项目自带）

很多后端框架自带 Swagger 文档，启动服务后访问 /docs 路径就能看到交互式 API 文档，可以直接在页面上测试接口。方便但功能有限。

5.3 Postman（专业工具）

专业的接口测试工具，功能齐全：

• 图形化界面，不需要写命令
• 支持保存请求集合，方便重复测试
• 支持环境变量、自动化测试
• 适合长期使用和团队协作

5.4 测试流程

前端发起请求 → 后端接收处理 → 查询 / 操作数据库 → 返回响应 → 前端展示结果 ↑ 用 curl / Postman 在这一步直接测试

六、服务器地址与端口

6.1 localhost 是什么

localhost = 127.0.0.1 = 你自己的电脑 localhost 是一个特殊域名，永远指向本机。访问 http://localhost:8000 就是在访问你自己电脑上 8000 端口运行的服务。

6.2 端口号是什么

一台电脑可以同时运行多个服务（Web 服务、数据库、Redis 等），端口号用来区分它们：

http://localhost:8000
              └── 端口号，标识具体是哪个服务

常见端口：

端口	常见用途
80	HTTP 默认端口
443	HTTPS 默认端口
3000	Node.js 开发服务器
5000	Flask 默认端口
8000	Django / Uvicorn 默认端口
3306	MySQL 数据库
5432	PostgreSQL 数据库
6379	Redis 缓存

6.3 让别人访问你的服务

localhost 只能本机访问。如果想让同局域网的其他电脑访问你的服务，需要用你的局域网 IP 地址：

# Windows 查看 IP
ipconfig

# macOS / Linux 查看 IP
ifconfig

找到 IPv4 地址，如 192.168.1.100，别人访问 http://192.168.1.100:8000 就能连上你的服务。

七、WSL：Windows 上的 Linux

7.1 什么是 WSL

WSL（Windows Subsystem for Linux）是 Windows 内置的 Linux 子系统，让你在 Windows 上直接运行 Linux 程序，不需要装虚拟机。

7.2 为什么需要它

很多后端工具和教程默认在 Linux/macOS 环境下运行。Windows 用户用 WSL 可以：

• 使用 Linux 命令行工具
• 运行 Linux 版本的开发环境
• 保持与生产服务器（通常是 Linux）一致的环境

# 安装 WSL（Windows 终端执行）
wsl --install

# 进入 Linux 环境
wsl

八、Docker：环境一致性终极方案

8.1 一个经典痛点

你开发时用的是：

Python 3.11 + Flask 2.0 + SQLite 3.40  ✔ 一切正常

部署到服务器时：

Python 3.8 + Flask 1.0 + SQLite 3.31  ❌ 各种报错

同事的电脑：

Python 3.12 + Flask 3.0  ❌ 版本不兼容

环境不一样就出问题，而且 "在我电脑上明明能跑" 是后端开发最常见的问题。

8.2 Docker 是什么

Docker 是一个打包工具，把程序 + 运行环境 + 所有依赖全部装进一个 "集装箱"（容器）。无论在哪台电脑上运行，环境都完全一致。

┌─────────────────────────────────┐
│          Docker 容器             │
│  ┌───────────────────────────┐  │
│  │  你的应用程序              │  │
│  ├───────────────────────────┤  │
│  │  Python 3.11              │  │
│  ├───────────────────────────┤  │
│  │  Flask 2.0                │  │
│  ├───────────────────────────┤  │
│  │  SQLite 3.40              │  │
│  ├───────────────────────────┤  │
│  │  所有依赖库               │  │
│  └───────────────────────────┘  │
└─────────────────────────────────┘

这个容器可以在任何安装了 Docker 的电脑上运行，环境完全一致，不会出现 "在我电脑上能跑" 的问题。

8.3 Docker 三步走

第一步：编写 Dockerfile（打包说明）

FROM python:3.11
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]

这个文件告诉 Docker：用 Python 3.11 作为基础环境，安装依赖，复制代码，运行程序。

第二步：打包成镜像（集装箱）

docker build -t my-app .

把代码和环境打包成一个镜像文件。

第三步：运行（任何电脑都能跑）

docker run -p 8000:8000 my-app

在任何安装了 Docker 的电脑上，这条命令都能成功运行，不管那台电脑的原始环境是什么。

8.4 Docker 的核心价值

价值	说明
环境一致	开发、测试、生产环境完全相同
快速部署	一条命令启动服务
隔离性	每个容器独立，互不影响
可移植	打包好的镜像可以在任何机器运行
版本管理	镜像可以打标签，方便回滚

九、完整开发流程串联

把所有知识点串起来，一个后端项目的完整流程：

1. 选择技术栈 语言：Python 框架：FastAPI 数据库：SQLite

2. 设计 API RESTful 风格

   GET    /todos       → 获取所有
   POST   /todos       → 创建
   DELETE /todos/{id}  → 删除
   

3. 编写代码 定义路由 → 编写处理函数 → 操作数据库 → 返回响应

4. 本地测试 启动服务 → 用 curl / Postman 测试 API

5. 容器化打包 编写 Dockerfile → docker build 打包镜像

6. 部署上线 服务器安装 Docker → docker run 运行容器 配置域名 / IP → 外网可访问

十、总结

概念	一句话解释
前端	用户看到和操作的界面
后端	处理数据、操作数据库、提供 API
API	后端提供给前端的接口，按约定格式通信
RESTful	最主流的 API 设计风格，URL 表资源 + HTTP 方法表动作
路由	URL 路径与处理函数的映射
localhost	本机地址，等价于 127.0.0.1
端口	区分同一台机器上不同服务的编号
WSL	Windows 内置的 Linux 子系统
Docker	把程序和环境打包成容器，解决环境不一致问题

后端开发的核心就是：接收请求 → 处理逻辑 → 操作数据 → 返回结果。所有的框架、工具、架构都是围绕这个核心流程展开的。