聊到 Spring Boot 做前后端连接很多人第一个想到的就是后端写个接口返回 JSON前端拿 Axios 请求一下数据出来了就算连接上了。这话没毛病但真到项目里你会遇到一堆“文档里不会写”的破事跨域报错、日期格式对不上、接口路径总变、前后端各改各的没人理接口规范……这篇文章就把“前后端连接”这件事从头到尾拆开讲清楚 Spring Boot 做后端时前后端到底是怎么连起来的每一环的底层逻辑是什么以及我实际项目里踩过的坑。适合刚接触 Spring Boot 的实习生、准备做前后端分离毕设的学生以及被前后端联调折磨过但没系统梳理过的同学。1. 这个项目到底在做什么Spring Boot 连接前后端的完整思路1.1 前后端分离是怎么一步步变成主流方案的先说一个很多人没意识到的问题你现在觉得“前后端连接”是理所当然的事但放在十年前这个词根本不存在。那时候的主流做法是服务端渲染Java Web 项目用 JSP 或者 Thymeleaf 模板引擎前端页面嵌在后端工程里浏览器请求进来后端把 HTML 拼好再返回给浏览器。这种模式下前后端根本不需要“连接”因为大家住在同一个工程里任何一方改动都会直接影响另一方。但是随着移动端兴起、前端工程化成熟大家发现这种耦合根本扛不住需求变化。手机 App 需要接口、网页需要接口、小程序还需要接口同一个后端逻辑要服务多个客户端总不能给每个端都写一套 JSP 页面吧于是前后端分离慢慢成了主流前端是一个独立工程Vue、React、或者最简单的 HTML 页面后端是一个独立工程Spring Boot两者之间只通过 HTTP 接口通信数据格式统一用 JSON。这就是你现在看到的所有“Spring Boot Vue 前后端分离”项目的底层逻辑。Spring Boot 在这套架构里扮演的角色非常纯粹后端服务提供方。它不关心你的前端长什么样、是 Vue 还是 React 还是原生 HTML它只负责接收 HTTP 请求、处理业务逻辑、返回标准格式的数据。这种职责单一的设计让前后端团队可以完全并行开发只要事先把接口约定好后端写好接口丢给前端前端拿到接口地址就能干活两边互不阻塞。1.2 技术选型背后为什么大家都选 Spring BootSpring Boot 能从 Java 后端生态里杀出来成为前后端分离项目的默认选项我理解有几个核心原因。第一个是它大幅降低了 Spring 的使用门槛。早期用 Spring MVC 写一个 Web 接口你要配置 web.xml、要配 Spring 容器、要配数据源、要配视图解析器光是把项目跑起来就得折腾半天。Spring Boot 直接用“约定大于配置”的思路干掉了一堆 XML 配置依赖写在 pom.xml 里启动类一跑服务就起来了。我见过接触 Spring Boot 不到一周的新人就能写接口调通换成传统 Spring 项目没一个月他连配置文件都理不清。第二个是它的生态集成能力极强。前后端连接不光是一个接口的事中间还涉及参数校验、权限认证、日志记录、文件上传、消息队列、分布式锁等等。Spring Boot 的 Starter 机制把这些东西全部封装成“依赖 自动配置”的模式你往 pom 里加一个依赖对应的能力就自动装配好了不需要像以前那样手动写一大堆配置类。比如后面要说的跨域问题Spring Boot 里加一个配置类就搞定传统 Spring 项目你还得折腾拦截器。第三个是它的工程规范非常标准化。Spring Boot 项目天然按 controller / service / mapperdao分层这个结构在国内 Java 项目里几乎成了行业标准。新人进来看到这样的项目结构很快就知道哪个 class 是干什么的。对前后端连接来说Controller 层是唯一跟前端直接打交道的层接口入口清晰文件位置固定排查问题的时候非常舒服。1.3 前后端连接的完整链路一次请求到底经历了什么我建议每个做前后端联调的人都先在脑子里建立起这条链路后面所有的问题排查都靠它。一个完整的前后端交互过程是这样的前端页面发起一个 HTTP 请求比如用户点击登录按钮Axios 向/api/login发 POST 请求→ 请求通过网络到达后端服务器 → Spring Boot 的 DispatcherServlet 根据 URL 找到对应的 Controller 方法 → Controller 调用 Service 层处理业务逻辑 → 返回一个对象 → Spring Boot 利用 Jackson 把对象序列化成 JSON 字符串 → 作为 HTTP Response 返回给前端 → 前端拿到响应数据渲染页面或触发下一步操作。这条链路里每一步出问题都会导致“连不上”的现象。前端报 404 往往是 URL 路径有问题报 405 是请求方式不对前端用 GET后端只写了 POST报 403 是权限或跨域问题报 500 是后端代码执行出错。我不知道你看过多少“我的前后端连不上”的求助帖十有八九都是这条链路中某一环配置错了。2. 后端接口设计保证前端好用的底层约定2.1 RESTful 接口规范与 URL 命名策略前后端连接不是后端写几个接口就能完事的连接的前提是“约定”约定的核心就是接口规范。现在国内 Java 项目接口风格基本是 RESTful 范式它的核心思想是用 HTTP 方法表示操作类型用 URL 表示资源用状态码表示结果。举个例子同样是管理用户数据的接口RESTful 风格一般这么设计GET/api/users表示获取用户列表GET/api/users/1表示获取 ID 为 1 的用户详情POST/api/users表示新建用户PUT/api/users/1表示更新 ID 为 1 的用户DELETE/api/users/1表示删除该用户。URL 里全是名词操作语义全集中在 HTTP 方法上。这样做的好处是接口一眼就能看出含义前后端对接口的理解完全一致不容易产生歧义。但是我在真实项目里发现很多团队并没有严格执行 RESTful而是用“动作式 URL”也就是/api/getUserInfo、/api/deleteUserById这种把操作直接写在 URL 里。说实话这不算大问题团队内部约定一致就能跑通。但如果你做的是标准化程度要求高的项目或者有面试官问你“你们接口怎么设计的”RESTful 是加分项。我自己比较推荐的做法是主干资源用 RESTful涉及复杂业务动作比如发布文章、审核通过、批量导入就用 POST 加动作式 URL比如POST /api/articles/publish。纯 RESTful 在某些业务场景下反而是死板务实点更重要。URL 命名还有几个细节值得注意一是统一加/api前缀这样前端代理、后端鉴权过滤都有清晰的边界二是用复数名词表示资源集合三是路径参数用{id}占位而不是拼在 query string 里除非是筛选条件。这些约定一旦在项目早期定下来后面的联调效率能提升一大截。2.2 统一返回结构让前端拿到的数据永远都是同一种形状前后端连接中最让前端头疼的事情之一就是后端接口返回的数据结构不统一。有的返回{code: 200, data: [...]}有的直接返回一个数组报错了返回一段纯文本前端每接一个接口都要单独处理返回格式写得想骂人。解决这个问题的最优解就是设计一个统一的返回结果类。我在项目里一般这么定义Data public class ResponseResultT { private Integer code; private String message; private T data; public static T ResponseResultT success(T data) { ResponseResultT result new ResponseResult(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResponseResultT success(String message, T data) { ResponseResultT result new ResponseResult(); result.setCode(200); result.setMessage(message); result.setData(data); return result; } public static T ResponseResultT error(String message) { ResponseResultT result new ResponseResult(); result.setCode(500); result.setMessage(message); return result; } public static T ResponseResultT error(Integer code, String message) { ResponseResultT result new ResponseResult(); result.setCode(code); result.setMessage(message); return result; } }然后 Controller 里所有的接口返回值统一写成ResponseResultTRestController RequestMapping(/api/users) public class UserController { GetMapping public ResponseResultListUser listUsers() { return ResponseResult.success(userService.list()); } }这样做的好处非常明显不管接口正常还是异常前端拿到的 JSON 结构永远是{code: xxx, message: xxx, data: xxx}三种字段。前端封装一个统一的请求函数几十行代码就能处理所有接口的响应。前端的判断逻辑极其简单code 是 200 就用 data不是 200 就弹 message。我见过很多项目因为没做统一返回结构前端工程师每天都在跟后端确认“这个接口失败返回是什么结构”这种内耗毫无价值。2.3 参数传递的四种形式面试常问联调常用前后端连接中参数传递是最日常、最容易出问题的地方也是后端面试的高频题。Spring Boot Controller 方法接收参数的四种方式最好都搞清楚。第一种是路径参数用PathVariable接收对应 URL 里/api/users/1中的1。前端拼接 URL 时必须动态把值塞进去比如 Axios 里写get(/api/users/${id}”)。我见过有前端把路径参数放在 query string 里传给后端后端用PathVariable 接收结果自然是 404因为路径对不上。第二种是查询参数用RequestParam接收对应 URL 里?page1size10这种。关键是前端传参的 key 必须和后端参数名一致否则就是 null。另外RequestParam默认是必传的前端漏传直接报 400如果想要可传可不传的要设置required false或者给 defaultValue。第三种是请求体参数用RequestBody接收对应前端 POST 请求 body 里的 JSON。这是前后端分离项目里最常用的一种方式前端传一个对象后端用一个对应的实体类或 DTO 接收Spring Boot 用 Jackson 自动把 JSON 反序列化成 Java 对象。这里最常见的坑是 JSON 字段名和 Java 属性名不一致或者日期格式不对比如前端传2024-01-15 00:00:00后端 LocalDateTime 解析失败报错。第四种是请求头参数用RequestHeader接收常用于传递 token、客户端信息这些元数据。做登录认证的时候前端把 token 放在 Header 的 Authorization 字段里后端写一个拦截器统一读取校验对接起来非常自然。提示我建议 Controller 方法的参数设计遵循“GET 优先用 RequestParamPOST 批量数据优先用 RequestBody”的原则。合理使用这四种传参方式前后端对接的绝大部分参数问题都已经解决了一半。3. 前后端连接最关键的环节跨域处理与数据格式3.1 为什么一前后端分离就碰上了跨域问题前后端分离项目第一次联调时十个团队有八个会遇到跨域报错浏览器控制台一片红前端急得直跺脚。这个问题的根源其实很简单浏览器的同源策略。所谓同源就是协议、域名、端口三者完全一致。前后端不分离的老项目页面和接口都在同一个地址下不存在跨域前后端分离之后前端开发服务器跑在http://localhost:8080后端跑在http://localhost:9090或者用 Nginx 部署时前端和后端分在不同域名甚至同一个域名不同端口协议域名端口有一处不一致浏览器就会拦截跨域请求。这里有个容易误解的点HTTP 请求本身并没有被拦截请求已经发到后端了后端也正常处理并返回了但浏览器发现响应头里没有允许跨域的标识就强制把响应拦下来了前端拿不到数据。所以你经常看到的现象是后端日志里明明有请求记录接口也执行成功了但前端控制台依然报跨域错误。理解了这一点排查跨域问题时思路会清晰很多核心就是让后端响应头带上允许跨域的标记或者让前端请求不发跨域请求代理方案。3.2 三种解决跨域的方案选型与配置实操跨域解决方案里有三种是项目里真正用得上的CORS 后端配置、前端开发代理、Nginx 反向代理。生产环境我推荐 Nginx 反向代理方案后端开发调试期我推荐 CORS 或者前端代理下面分别说用法。第一种后端直接开启 CORS。Spring Boot 里写一个配置类统一处理即可Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }这段配置的意思是允许所有来源、常见 HTTP 方式、所有请求头访问后端接口并且允许携带 Cookie。其中的 allowedOriginPatterns 是 Spring Boot 2.4 的写法老版本用 allowedOrigins(*)但需要注意allowCredentials(true)时allowedOrigins(*)会冲突allowedOriginPatterns 则能解决这个问题。另外那个 OPTIONS 方法必须放行因为浏览器在跨域 POST、PUT 请求前会先发一个 OPTIONS 预检请求后端如果不处理这个预检前端正式请求根本发不出去。第二种前端开发服务器代理。前后端分离项目中前端一般跑 Vue 或 React 的 dev serverVue 的配置在vue.config.js里这样写module.exports { devServer: { proxy: { /api: { target: http://localhost:9090, changeOrigin: true } } } }原理是前端请求的 URL 如果是/api开头dev server 帮你转发到后端地址。因为代理转发是服务器到服务器的通信不经过浏览器所以不存在同源策略限制。这种方式的好处是前端代码里只需要写相对路径/api/xxx不依赖后端具体 IP 和端口换后端环境只需改代理配置。我个人在开发环境比较推荐这种方式因为最贴近生产环境的部署方式下面前端基本都是同源还能顺手解决一部分跨域问题。第三种生产环境 Nginx 反向代理。打包后的前端静态文件放在 Nginx 里再把/api请求反向代理到后端服务这样浏览器访问的域名和路径全是同一个域名根本不存在跨域server { listen 80; server_name example.com; location / { root /usr/share/nginx/html; index index.html; } location /api/ { proxy_pass http://backend-server:9090; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这段配置在 Docker 部署 Spring Boot 项目时配合得非常顺畅也是生产环境里最常用、最稳妥的方案。关于 Docker 部署 Spring Boot我放到第六节细讲。3.3 数据格式约定JSON 序列化、日期格式和 null 处理接口打通了不代表连接就成功了数据格式对不上照样白搭。前后端连接中数据格式的问题集中在两个地方日期格式和 null 值处理。日期问题几乎是每个前后端项目都会遇到的经典问题。数据库里的datetime类型Java 实体里是LocalDateTimeJackson 序列化后默认是类似2024-01-15T12:30:00的 ISO-8601 格式带字母 T前端直接展示很丑解析还得专门处理。处理方案是在application.yml里统一配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8但这只能解决java.util.Date的格式对LocalDateTime有时不生效。老手更推荐在实体类的日期字段上加注解一劳永逸JsonFormat(pattern yyyy-MM-dd HH:mm:ss) private LocalDateTime createTime;同时接收前端传来的日期字符串时这个注解同样会让 Jackson 尝试按指定格式解析避免“前端传2024-01-15 00:00:00后端直接报错”的尴尬情况。null 值处理则更多是体验问题。字段值是 null 的时候Jackson 默认序列化成field: null前端拿到之后如果没做判空直接obj.prop.name就会报错。方案有两个一是后端在类上加JsonInclude(JsonInclude.Include.NON_NULL)序列化时自动忽略 null 字段二是在统一返回结构层面data 为 null 也正常输出交给自己定义。我自己习惯用NON_NULL策略因为响应体里满屏的null不仅占用带宽还影响前端排查问题。4. 从零到一完整的前后端连接 Demo 实操4.1 创建 Spring Boot 项目IDEA 里的标准操作先说明一点网上教程里创建 Spring Boot 项目的姿势五花八门有人用网页版 Spring Initializr有人用命令行我下面说最常用的 IDEA 操作路径File - New - Project - Spring Initializr然后填写项目信息Group、Artifact选择 Java 版本和 Spring Boot 版本依赖这里选Spring Web就够跑通前后端连接了。如果后续要连数据库再选MySQL Driver、MyBatis Framework或者Spring Data JPA这些。这里我想多说一嘴版本选择的问题。有段时间 Spring Boot 3.x 刚出来的时候网上好多人按教程创建 3.x 的项目结果引入一些老依赖直接报错因为 Spring Boot 3 要求 Java 17 起步并且使用了 Jakarta 命名空间javax全部变成jakarta很多还没适配的老库根本跑不起来。这就是热搜词里“springboot版本太高”这个现象的来源。我的建议是如果你是学习或者做常规毕业设计不用非要追最新大版本选当前稳定的小版本即可。比如 Spring Boot 2.7.x 和 3.2.x 都有大量资料但 3.x 的坑你心里要有数。创建项目时 IDEA 可以选择版本没必要收到“版本太高”这个问题的困扰。4.2 后端代码实现Controller Service 数据实体为了演示前后端连接我这边做一个最简单的用户管理系统功能就三个查询用户列表、新增用户、删除用户。数据不接数据库先用内存 List 存着聚焦在连接本身。先把用户实体类写好Data NoArgsConstructor AllArgsConstructor public class User { private Long id; private String username; private String email; }注意这里用了 Lombok 的注解IDEA 里需要装 Lombok 插件pom 里引入依赖dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency然后是 Service 层简单模拟数据操作Service public class UserService { private final ListUser userList new CopyOnWriteArrayList(); private final AtomicLong idGenerator new AtomicLong(1); public UserService() { // 初始化两条示例数据 userList.add(new User(idGenerator.getAndIncrement(), zhangsan, zhangsanexample.com)); userList.add(new User(idGenerator.getAndIncrement(), lisi, lisiexample.com)); } public ListUser listUsers() { return userList; } public User addUser(String username, String email) { User user new User(idGenerator.getAndIncrement(), username, email); userList.add(user); return user; } public boolean deleteUser(Long id) { return userList.removeIf(user - user.getId().equals(id)); } }最后是重点Controller 层直接跟前端打交道RestController RequestMapping(/api/users) public class UserController { private final UserService userService; public UserController(UserService userService) { this.userService userService; } GetMapping public ResponseResultListUser listUsers() { return ResponseResult.success(userService.listUsers()); } PostMapping public ResponseResultUser addUser(RequestParam String username, RequestParam String email) { User user userService.addUser(username, email); return ResponseResult.success(用户添加成功, user); } DeleteMapping(/{id}) public ResponseResultVoid deleteUser(PathVariable Long id) { boolean deleted userService.deleteUser(id); if (deleted) { return ResponseResult.success(用户删除成功, null); } return ResponseResult.error(用户不存在); } }这段代码里涵盖了三种 URL 形式路径参数{id}、查询参数username/email、纯路径/api/users。有眼尖的会发现我在 POST 接口里用的是RequestParam而没写前端页面的 Ajax 内容这是故意的为了演示两种传参方式。前端如果用Content-Type: application/x-www-form-urlencoded提交表单后端RequestParam能接到如果前端用 JSON 提交后端应该改成RequestBody。4.3 前端代码实现用纯 HTML Axios 打通连接为了让大家看全链路我这里不用 Vue 工程那是另外一个话题直接用纯 HTML 页面加 CDN 引入 Axios 的方式演示最小化前端环境依赖你在本地双击 HTML 文件就能跑。!DOCTYPE html html langzh-CN head meta charsetUTF-8 titleSpring Boot 前后端连接 Demo/title script srchttps://cdn.jsdelivr.net/npm/axios/dist/axios.min.js/script /head body stylefont-family: sans-serif; margin: 40px; h2用户列表/h2 ul iduserList/ul h3新增用户/h3 form idaddForm input typetext idusername placeholder用户名 required input typetext idemail placeholder邮箱 required button typesubmit添加/button /form script const API_BASE http://localhost:9090/api/users; async function loadUsers() { const response await axios.get(API_BASE); const result response.data; if (result.code 200) { const ul document.getElementById(userList); ul.innerHTML ; result.data.forEach(user { const li document.createElement(li); li.textContent ${user.id} - ${user.username} (${user.email}) ; const delBtn document.createElement(button); delBtn.textContent 删除; delBtn.onclick () deleteUser(user.id); li.appendChild(delBtn); ul.appendChild(li); }); } else { alert(result.message); } } async function deleteUser(id) { await axios.delete(${API_BASE}/${id}); loadUsers(); } document.getElementById(addForm).addEventListener(submit, async (e) { e.preventDefault(); const username document.getElementById(username).value; const email document.getElementById(email).value; // 使用 URLSearchParams 以表单形式提交对应后端的 RequestParam const formData new URLSearchParams(); formData.append(username, username); formData.append(email, email); await axios.post(API_BASE, formData); loadUsers(); }); loadUsers(); /script /body /html这里有个非常关键的点这个 HTML 文件是通过file://协议直接打开的页面地址是file:///.../index.html而后端是http://localhost:9090协议不同、域名file vs localhost也不同必然触发跨域。所以如果你用第一节的 CorsConfig 配置打开后端前端就能通如果没配 CORS这里就会报跨域错误。这就是我们刚才讲过的知识点的实战体现。4.4 联调效果与抓包验证眼见为实启动 Spring Boot 项目假设端口配的是 9090在application.yml里写server.port: 9090然后打开 HTML 页面应该能正常看到两条示例数据。添加一个用户列表刷新后多一条记录点击删除对应记录消失。但我想提醒的是业务正常跑通只是表面你要学会用浏览器开发者工具F12里的 Network 面板观察真实的请求响应。点一下某个请求可以看到 Request URL、Request Method、Status Code、Response Headers、Response Body。比如正常响应的 Response 长这样{ code: 200, message: 操作成功, data: [ { id: 1, username: zhangsan, email: zhangsanexample.com }, { id: 2, username: lisi, email: lisiexample.com } ] }如果跨域没配置好Network 面板里这条请求大概率显示 CORS error 或者 Status 是 (failed)Response 里看不到数据。如果后端 9090 端口没启动前端会报ERR_CONNECTION_REFUSED。这些现象对应的根因你多抓几次包就心里有数了。4.5 补充前端用 JSON 提交时后端应该怎么收上面 Demo 里前端用的是表单形式提交Content-Type是application/x-www-form-urlencoded后端对应RequestParam。但真实项目里大多数前端框架默认的 POST 提交格式是 JSON也就是Content-Type: application/jsonbody 是标准 JSON 字符串。这种格式下后端要改成PostMapping public ResponseResultUser addUser(RequestBody User user) { User savedUser userService.addUser(user.getUsername(), user.getEmail()); return ResponseResult.success(用户添加成功, savedUser); }同时前端 Axios 写axios.post(API_BASE, { username, email })直接传对象就行。两种方案没有绝对的好坏但我个人建议接口比较简单的用RequestParam更直观接口字段多、有嵌套结构就用RequestBody接 DTO。你只要牢记住“form 格式对应 RequestParamJSON 格式对应 RequestBody”前后端连接时的传参问题基本就捋顺了。5. 常见问题与排查技巧实录5.1 问题速查表前后端连接典型症状及根治方法这里我把做前后端连接时遇到频率最高的几个问题整理成表格方便你直接对号入座快速定位问题根因。每个问题都是我在项目里真实踩过的坑值得收藏。现象可能原因排查思路解决办法前端请求报 404URL 路径写错或 Controller 未匹配看 Network 面板确认实际请求 URL对照 Controller 的 RequestMapping修正路径注意 RequestMapping 放在类上时 /api/users 是完整前缀报 405 Method Not Allowed请求方法不对GET/POST 写错了看请求方法检查后端方法上的 GetMapping/PostMapping统一接口方法约定或接受 OPTIONS 预检CORS 跨域报错协议/域名/端口不一致后端未开启 CORS看响应头是否包含 Access-Control-Allow-*配置 CorsConfig开发期用前端代理后端接口报 500代码执行异常NPE、数据格式错误、SQL 错误看后端控制台堆栈日志根据异常修代码建议配全局异常处理前端拿到的 data 为 null后端返回的字段名和前端取用不一致或 JSON 序列化配置忽略字段打开 Network 看 Response 实际 JSON统一字段命名推荐驼峰或前端按实际字段取值日期格式对不上前后端约定的日期格式不一致看 JSON 里的日期格式和前端期望格式用 JsonFormat 统一yyyy-MM-dd HH:mm:ss请求跨域时被 OPTIONS 挡住CORS 配置没放行 OPTIONS浏览器 Network 里看有没有预检请求在 allowedMethods 中加入 OPTIONS或处理预检请求后端能收到请求但响应被浏览器拦截CORS 配置缺失或 allowedOrigins 与 credentials 冲突看浏览器 Console 具体错误信息allowedOriginPatterns allowCredentials(true)这张表不是让你背的重点是培养“根据现象反推链路中哪一环出问题”的思维习惯。所有连接问题都能归因到链路中的某一环URL 匹配、方法匹配、参数解析、权限、跨域、序列化、网络可达。锁定阶段之后再去搜解决方案效率高得多。5.2 版本与依赖相关疑难杂症动手前先看环境还有一个容易踩雷的领域是版本问题。很多时候不是代码错了是环境不对。这里把高频的几个总结一下。Spring Boot 版本太高导致老项目依赖不兼容。比如 Spring Boot 3.x 需要 Java 17 起步但教室里装的是 JDK 8IDEA 编译直接报错或者你的项目里引进了springfox-swagger2Swagger 的老牌库在 Spring Boot 3 里没法用因为它基于 javax。遇到这类问题我先看 Spring Boot 的版本和 JDK 版本再决定是否降级到 2.7.x。记住一个原则学习阶段跟着教程走教程用什么版本你就用什么版本没必要追最新。IDEA 里创建 Spring Boot 项目报 “Cannot download” 或初始化失败大概率是网络问题或者 Spring Initializr 地址被墙了。解决办法是在 IDEA 的Settings - Plugins里换个镜像地址国内有 Spring Initializr 镜像或者直接用阿里云的脚手架地址创建项目。这类问题卡时间很多不是技术难题是环境信息差。还有热搜词里出现的springboot banner 生成器可能有些同学喜欢在启动时打一个 ASCII 艺术字 banner这个不影响功能纯属项目趣味遇到问题把banner.txt删了就行搜索词里的springdoc关闭问题也可以提一句如果你用了 springdoc 但不想看接口文档在 application.yml 里设springdoc.api-docs.enabledfalse和springdoc.swagger-ui.enabledfalse即可。这些看着八竿子打不着的热搜词本质上反映的都是中国开发者用 Spring Boot 时的真实痛点。5.3 排查方法论前后端联调不传谣不甩锅最后分享一套我实际用的排查流程我自己叫“三层定位法”。第一层先在浏览器 Network 面板里看请求有没有发出去、状态码是什么。这能确认问题出在请求链路还是响应链路。第二层再看 Response Body。如果是后端返回的能直接看到统一返回结构里的 code 和 message一半的问题光靠 message 就能解决。如果 Response 是空或红色报错问题可能出在跨域或网络。第三层最后再看后端控制台日志。我不止一次遇到过前端甩锅说“后端接口没通”结果后端控制台清清楚楚打印着 NullPointerException 的堆栈。所以在团队里做联调第一件事是统一日志输出格式第二件事是任何一方改完接口先自测再交付第三件事是排查问题时不猜用数据说话。注意我见过最浪费时间的前后端联调方式就是前端说“报错了”然后把截图丢过来后端说“我这边是好的啊”。两边各看各的扯皮半小时。正确的姿势是前端把 Network 面板里这条请求的 Request、Response、Console 报错一次性截全后端把控制台日志一次性贴出来两个人对一遍就定位了。6. 上线之前还要做的事从 Demo 到可用项目6.1 配置分离不同环境不同配置这个 Demo 能跑通但你不可能一直把它跑在本地上。真正要上线的时候第一个要改掉的就是“所有配置写死在 application.yml”的做法。开发环境的数据库地址、日志级别、端口可能和生产环境完全不一样最简单的方案是在application.yml里写公共配置然后在application-dev.yml、application-prod.yml里写环境差异配置启动时通过--spring.profiles.activeprod指定当前环境。对于前后端连接来说最重要的配置项无非是server.port后端端口以及如果接数据库时的连接地址。把这些东西按环境拆分配合 CI/CD 流水线上线时只改一个环境参数不会因为误改配置把生产环境搞坏。这一步看起来不起眼但能避免非常多上线事故。6.2 Docker 部署 Spring Boot 项目一键起服务前后端分离项目最主流的部署方式就是 Docker 了。Spring Boot 项目常规部署有几种方式直接java -jar启动、用 systemd 托管、放进 Docker 容器。我个人强烈推荐 Docker因为环境一致性、启动速度、回滚协议都是最优的。部署过程分三步先用 Maven 打包mvn clean package在target目录下得到可执行的 jar 包然后在项目根目录写一个 DockerfileFROM openjdk:17-jdk-alpine VOLUME /tmp COPY target/user-demo-0.0.1-SNAPSHOT.jar app.jar ENTRYPOINT [java,-jar,/app.jar]构建镜像命令docker build -t user-demo:latest .后台启动docker run -d -p 9090:9090 --name user-demo user-demo:latest这里-p 9090:9090表示把宿主机的 9090 端口映射到容器的 9090 端口这样前端不管是开发环境还是 Nginx 部署都能通过宿主机 IP 加 9090 访问后端接口。如果生产环境按前面说的用 Nginx 做同源代理Nginx 和后端容器在同一个 Docker 内网里直接用容器名互相访问前端根本不需要知道后端端口从源头上又少了一层跨域问题。6.3 从 Demo 到真实项目的差距中间件、鉴权、错误码Demo 跑通只是起点一个真实可用的前后端连接项目还需要补充几块内容。一是持久化把内存 List 换成 MySQL MyBatis 或 JPA二是统一异常处理用RestControllerAdvice加ExceptionHandler把异常转换成统一返回结构三是登录鉴权用 JWT 或者 Spring Security 把接口保护起来前端请求带 token后端拦截器校验四是接口文档引入 springdoc 或 knife4j让后端写的接口能自动生成文档省去口头传话。这些内容每一个单拎出来都能写几千字但核心思路不会变前后端连接仅仅是整个系统的“通信层”连接之外的业务逻辑、数据管理、安全性才是把项目做扎实的重点。很多毕设项目给我的感觉是接口能通、页面能显示但一追问“你们鉴权怎么做、异常怎么处理、上线怎么搞”就答不上来了。做技术先跑通再深入这个节奏是对的但不能只停在跑通。个人体会是前后端连接的问题从来不复杂绝大多数坑都来自约定不清和环境差异。把接口规范定好、返回结构统一、跨域配置提前放好这个项目在连接层面的麻烦就能消掉七八成。你要是现在正在被联调折磨建议别急着改代码先把协议、接口文档、返回结构拉通再一头扎进去调会轻松很多。这套方法论我用了好几年真觉得比任何一劳永逸的框架都管用。