一个人做项目，前端和后端到底怎么配合

这一篇的目标：让你明白前端和后端不是各写各的，而是先把约定定清楚，再分别实现。

很多人做项目时，都会遇到一个很真实的问题：

• 前端说后端没给字段
• 后端说前端传的参数不对
• 页面看起来能点，但数据对不上
• 功能明明写了，最后却联不起来

这类问题，大部分不是代码能力差，而是前后端没有提前讲清楚。
为了让新手也能真正跟着学会，下面会继续用“分块式教学”的方式来讲。

---

知识块 1：先弄懂前端和后端分别负责什么

本块结论：前端负责“展示和操作”，后端负责“规则和数据”。

1. 这是什么

你可以先把一个项目想成一间店铺：

• 前端像柜台和门面
• 后端像仓库和管理系统
• 数据库像长期存货本

更白话一点：

部分	主要工作	你可以怎么理解
前端	页面、按钮、表单、展示	用户看得见、点得到
后端	接口、业务逻辑、权限、校验	处理规则和数据
数据库	存储用户、商品、订单等信息	长期保存数据

2. 为什么要分开

如果不分开，代码会很容易乱成一团。

比如一个“发布商品”功能，如果全写在一个文件里，可能会同时出现：

• 页面布局
• 表单校验
• 接口请求
• 数据库存储
• 登录判断
• 成功跳转

这样短期看起来快，长期维护会很痛苦。

分开以后，前端只负责把表单收好、把按钮点好。
后端只负责判断数据对不对、能不能存、存到哪里。

3. 你可以怎么做

以后做任何功能，先问自己这三个问题：

前端负责展示什么？
后端负责处理什么？
数据库负责保存什么？

只要这三件事分清了，协作就会顺很多。

---

知识块 2：前后端配合的核心不是“同时写”，而是“先约定”

本块结论：先定接口，再写代码，前后端才不会互相猜。

1. 这是什么

前后端配合，最关键的是“接口约定”。
接口约定就是双方提前说好：

• 调哪个地址
• 用什么方法
• 传什么参数
• 返回什么数据
• 出错时怎么提示

2. 为什么重要

如果不先约定，前端会自己猜字段名，后端也会自己想返回格式。
结果就是：

• 前端写了 price，后端返回 itemPrice
• 前端传了 id，后端要的是 item_id
• 前端期待数组，后端返回对象
• 前端想要成功码，后端返回了另一套格式

这就是很多联调问题的来源。

3. 一个最简单的接口约定

以“发布商品”为例，先把接口定成这样：

项目	内容
接口名称	发布商品
请求方法	POST
请求路径	/items
请求参数	title, price, description, category_id, image_url
返回内容	code, message, data

4. 你可以怎么做

每次写功能前，先做一份接口表：

接口名称：
请求方法：
请求路径：
请求参数：
返回字段：
错误提示：

这张表就是前后端沟通的基础。

---

知识块 3：用“发布商品”把整条流程走一遍

本块结论：真正的前后端配合，是从页面到接口、再到数据库、再回到页面的完整闭环。

我们继续用校园二手交易平台举例。

1. 前端先做什么

前端页面上通常会有这些内容：

• 商品标题输入框
• 商品价格输入框
• 商品描述输入框
• 商品分类选择框
• 图片上传
• 发布按钮

前端先做最基础的本地校验：

• 标题不能为空
• 价格不能小于 0
• 描述不能太短
• 分类必须选择

2. 前端再做什么

当用户点“发布”时，前端把数据整理成请求体，比如：

{
  "title": "九成新英语教材",
  "price": 20,
  "description": "适合下学期使用，几乎全新",
  "category_id": 3,
  "image_url": "https://example.com/a.jpg"
}

然后把这个请求发给后端。

3. 后端做什么

后端收到请求后，通常会按这个顺序处理：

1. 检查用户是否登录
2. 检查参数是否完整
3. 检查价格是否合理
4. 检查分类是否存在
5. 生成商品记录
6. 保存到数据库
7. 返回处理结果

4. 数据库做什么

数据库只管保存结果。
它不关心页面长什么样，也不关心按钮点得漂不漂亮。

它只关心：

• 谁发布的
• 标题是什么
• 价格是多少
• 属于哪个分类
• 当前状态是什么

5. 最后页面怎么变

如果成功，前端通常会：

• 弹出提示“发布成功”
• 跳转到商品列表页
• 或者跳转到商品详情页

如果失败，前端就把后端返回的错误信息展示出来。

---

知识块 4：接口返回格式要统一

本块结论：前后端配合时，返回格式统一，会让调试轻很多。

1. 什么叫统一

统一就是：不管成功还是失败，后端都尽量用同一种结构返回数据。

比如可以这样：

{
  "code": 0,
  "message": "ok",
  "data": {
    "id": 12,
    "title": "九成新英语教材"
  }
}

出错时可以这样：

{
  "code": 400,
  "message": "标题不能为空",
  "data": null
}

2. 为什么要统一

因为前端写代码时，就能按固定规则处理：

• code == 0 说明成功
• code != 0 说明失败
• message 直接显示提示
• data 用来展示具体内容

这样前端不需要每个接口都重新猜结构。

3. 你可以怎么做

先在项目里定一套统一返回格式，后面所有接口都尽量遵守它。

---

知识块 5：前端和后端分别该怎么配合

本块结论：前端和后端不是同时乱写，而是按步骤接力。

1. 前端该做的事

前端的职责可以记成四步：

步骤	具体工作
第一步	做页面布局
第二步	做本地校验
第三步	调接口请求数据
第四步	处理成功和失败状态

2. 后端该做的事

后端的职责也可以记成四步：

步骤	具体工作
第一步	接收参数
第二步	校验参数
第三步	处理业务逻辑并存库
第四步	返回统一结果

3. 协作顺序

推荐的顺序是：

先定接口
再写前端页面
再写后端逻辑
最后联调

如果你反过来做，很容易出现：

• 前端写完发现接口不对
• 后端写完发现字段不一致
• 数据库改了，前端也要一起改

---

知识块 6：前后端联调时最容易出的问题

本块结论：联调出问题很正常，关键是知道问题通常出在哪一层。

1. 常见问题

问题	可能原因	怎么检查
页面不显示数据	请求没发出去、接口地址错	看浏览器 Network
接口返回错误	参数不对、后端校验失败	看后端日志
登录总失败	token 或密码校验有问题	看请求和返回
发布后看不到内容	数据没存成功或没刷新列表	看数据库和列表接口
图片上传失败	上传接口或文件路径有问题	看上传接口和返回值

2. 排查顺序

联调时，建议按这个顺序查：

前端有没有发请求？
请求地址对不对？
后端有没有收到？
参数对不对？
数据库有没有保存？
返回格式对不对？
前端有没有正确处理返回值？

这样排查，比盲目改代码快很多。

3. 你可以怎么做

联调时最好先只测一个功能，比如“发布商品”，不要一口气全测。
一个功能通了，再测下一个，问题会更容易定位。

---

知识块 7：单人项目怎么让前后端协作更轻松

本块结论：一个人做项目，最重要的是把接口表、字段表、状态表先定好。

1. 接口表

先列清楚有哪些接口、每个接口干什么。

2. 字段表

把每个接口返回哪些字段先约定清楚。

3. 状态表

比如商品状态可以先定成：

状态值	含义
0	待审核
1	已发布
2	已下架

这样前端展示时就不会乱猜。

4. 错误码表

可以简单约定：

错误码	含义
0	成功
400	参数错误
401	未登录
500	系统异常

这些约定写清楚，项目后面会顺很多。

---

知识块 8：AI 可以怎么帮你配合前后端

本块结论：AI 很适合帮你生成接口草案、字段草案和联调检查清单。

1. 让 AI 帮你列接口

请根据“校园二手交易平台”的商品模块，
列出前端和后端协作需要的接口表，
包括接口名称、方法、路径、请求参数和返回字段。

2. 让 AI 帮你统一字段

请帮我检查下面这些字段名是否统一，
并把前端和后端容易不一致的地方找出来。

3. 让 AI 帮你做联调清单

请为一个“发布商品”功能生成联调检查清单，
要求覆盖前端、接口、数据库、返回值和错误处理。

AI 的作用不是替你写完，而是让你更快看清哪些地方容易出错。

---

今天就能开始的最小清单

本块结论：如果你今天就要开工，先把这 7 件事写出来。

1. 定一个功能，比如“发布商品”
2. 写出前端页面要有哪些输入项
3. 写出请求接口的路径和方法
4. 写出请求参数
5. 写出返回格式
6. 写出数据库要存哪些字段
7. 写出成功和失败时页面怎么提示

你可以直接照着填：

功能名称：
前端页面项：
请求方法：
请求路径：
请求参数：
返回格式：
数据库字段：
成功提示：
失败提示：

---

最后总结

前后端配合，真正重要的不是谁先写，而是先把约定定清楚。

你可以把这件事记成一句话：

先定接口，再分工；先统一格式，再开始写。

当你能把前端、后端、数据库和返回格式都讲明白时，一个项目就不再是“东一块西一块”的代码，而是一个能顺利跑起来、也能顺利维护的系统。