一、简单实战 ：计算机
1. 核心概念：前后端交互接口
- 接口（API）是前后端分离开发中，客户端与服务器约定的 HTTP 请求 / 响应规则，类似 "应用程序的操作说明书"（接口文档）。
- 开发前需约定接口，双方按文档开发；接口文档通常由服务提供方编写，变更需同步对方。
| 约定维度 | 具体例子（加法接口） | 为什么要约定？ |
|---|---|---|
| 请求路径 | calc/sum（不是随便写的add/num） |
前端知道往哪个 "地址" 发请求 |
| 请求方式 | GET/POST（不是前端想发 GET、后端只接 POST） | 确保请求方式匹配，避免 405 错误 |
| 参数名 + 类型 | num1（Integer）、num2（Integer） |
前端传对参数名 / 类型，后端能解析 |
| 参数是否必传 | num1/num2都必传（不是可选） |
避免前端漏传导致后端计算出错 |
| 响应格式 | text/html（不是 JSON/XML） |
前端知道怎么解析返回的内容 |
| 响应内容规则 | "计算机计算结果：X"（不是只返回数字 X） | 前端能按固定格式展示结果 |
| 异常响应 | 比如参数非数字时返回 "参数错误" | 前端知道如何处理异常场景 |
简单说：约定的是 "前端怎么发请求、后端怎么返回响应" 的全流程规则，而非只约定变量 / 方法名。
（2）"方法名字" 不是后端内部的方法名，是接口的 "对外标识"
- 后端内部写的方法名（比如 Java 里的
public int addNumber(int a, int b)）属于 "后端内部实现"，前端完全不用管； - 双方约定的是接口的对外路径 / 标识 （比如
calc/sum），而非后端代码里的方法名 ------ 哪怕后端把内部方法名改成sumTwoNum，只要对外的calc/sum路径不变，前端完全不用改代码。
（3）"不需要一起使用的就不用管"------ 这个边界要明确
- ✅ 后端内部的逻辑：比如计算加法时要不要加日志、要不要校验参数（只要最终按约定返回）、变量命名（比如后端用
n1代替num1）------ 前端完全不用管； - ✅ 前端内部的逻辑：比如输入框的样式、点击按钮的动画、拿到结果后怎么渲染 ------ 后端完全不用管；
- ❌ 只要是 "跨前后端传输的内容"，哪怕是 "异常码"（比如后端返回
code: 500表示计算失败），都必须约定 ------ 否则前端拿到500不知道是什么意思。
1.1 用一句话总结
前后端约定 "数据交互的规则"（请求地址 / 方式 / 参数、响应格式 / 内容 / 异常），前端按规则发请求、后端按规则处理并返回响应；双方各自内部的代码实现（方法名、变量名、业务逻辑细节），只要不违反约定，都可以自由调整，不用互相干涉。
2. 加法计算器案例解析
2.1接口定义
2.2请求参数
2.3响应数据
总结+注意事项：
- ✅ 接口定义的核心是「前端怎么找到后端 + 怎么传参 + 知道后端会返回什么」，而非关注后端 "具体怎么实现"；
- ✅ 路径（URL）+ 请求方式（GET/POST）= 前端定位后端功能的 "唯一标识"；
- ✅ 接口描述 = 这个功能的用途；请求参数 = 传参规则；返回结果 = 响应规则；
- ✅ 后端具体实现（比如用 Java/Python/Go 写、用什么算法、内部调用了哪些工具类），前端完全不用管。
- ✅ 路径绑定的是 "要实现的功能 "，不是 "后端的方法名。(接口定义里的路径（如
user/login）是 "对外暴露的功能地址 "------ 哪怕后端把方法名改成verifyUser()，只要user/login这个路径不变、规则不变，前端完全不用改代码。)
接口定义里的返回规则，不能只写 "成功返回什么"，还要约定 "失败返回什么"：
比如登录接口：
- ✅ 成功：返回 "登录成功"+ 用户信息（JSON 格式）+ 状态码 200；
- ✅ 失败：返回 "账号密码错误"+ 错误码（如 1001）+ 状态码 400；如果只约定 "成功的返回形式"，前端遇到异常时会不知道怎么处理（比如拿到空数据、乱码，没法判断是 "没传参" 还是 "密码错"）。
"请求参数"→ 不止 "参数要求"，还要约定 "参数规则"
请求参数的定义，除了 "要传什么参数"，还要明确：
- 参数类型（比如
username是字符串、age是整数）； - 是否必传（比如登录的
username必传，rememberMe可选）； - 格式约束（比如
password长度 6-16 位、phone符合手机号格式）；这些规则前端要遵守（比如前端校验手机号格式，避免无效请求），后端也要校验（防止恶意传参），但 "怎么校验"（前端用正则、后端用注解）各自实现，不用约定。
接口定义还需约定 "响应格式类型"
比如返回结果是text/html（加法案例）、application/json（登录案例）、application/xml等 ------ 前端要知道用什么方式解析（比如 JSON 要转对象，HTML 可直接渲染），这也是接口定义的必要项。
2.4服务器代码
2.5前端代码
2.6运行测试
二、lombok
2.1lombok介绍
通过注解简化 Java 代码编写，在编译阶段自动生成重复代码（如 getter/setter、构造方法等），减少冗余。
2.2原理解释
1. Lombok 的工作阶段
Lombok 是编译期代码生成工具 ：在 Java 源码编译为字节码（.class 文件）的过程中，Lombok 会识别类上的注解（如@Data），自动生成对应的代码（如 getter/setter、构造方法等），最终生成的字节码包含这些完整代码。
2. 反编译的作用
通过 IDEA 对.class文件反编译（将字节码转换为可读的 Java 代码），可以观察到：添加@Data注解的类，反编译后的代码中已包含自动生成的方法（如getId()、getName()等），证明 Lombok 的代码生成是在编译阶段完成的。
3. Lombok 对 Java 运行流程的影响
- 原生 Java 流程 ：
.java源码 → 编译 →.class字节码 → JVM 加载运行 - 引入 Lombok 后 ：
.java源码 + Lombok → 编译（生成包含自动代码的字节码） →.class字节码 → JVM 加载运行
简言之，Lombok 在编译环节介入，替开发者生成重复代码，而 JVM 运行时使用的仍是完整的字节码文件，不感知 Lombok 的存在。
@Data等价于（@Getter+@Setter+@ToString+@EqualsAndHashCode+@RequiredArgsConstructor+@NoArgsConstructor）
| 注解 | 作用 |
|---|---|
@Getter |
自动生成 getter 方法 |
@Setter |
自动生成 setter 方法 |
@ToString |
自动生成 toString 方法 |
@EqualsAndHashCode |
自动生成 equals 和 hashCode 方法 |
@NoArgsConstructor |
自动生成无参构造方法 |
@AllArgsConstructor |
自动生成全属性构造方法 |
@NonNull |
限制属性不可为 null |
@RequiredArgsConstructor |
生成包含final或@NonNull属性的构造方法 |
3.通过 EditStarters 插件快速引入 Lombok 依赖
-
安装 EditStarters 插件 在 IDEA 的
Settings → Plugins中搜索 "EditStarters" 并安装，重启 IDEA 使插件生效。 -
通过插件添加依赖
- 在
pom.xml文件上右键，选择Generate → Edit Starters； - 在弹出的配置界面中，选择
Developer Tools分类，勾选 "Lombok"，点击 "Add" 后确认，插件会自动将 Lombok 的依赖坐标写入pom.xml。
- 在
3.1插件作用
EditStarters 是针对 Spring Boot 项目的依赖管理插件，可通过可视化界面快速选择并添加依赖（无需手动查找依赖坐标），简化了 Maven/Gradle 的依赖配置流程。
3.2注意事项
该插件仅支持 Spring Boot 生态内的常用依赖（如 Lombok、Spring Web 等）；若需添加非 Spring Boot 相关依赖，仍需手动从 Maven 仓库查找坐标并写入配置文件。