先说清楚这篇东西的定位它不是那种“跟着敲一遍就能跑起来”的教程而是我从实际项目里提炼出来的全栈开发经验总结。如果你正准备用 Spring Boot 和 Vue 搭一套前后端分离的系统或者已经在这条路上踩坑那这篇内容应该能帮你省下不少时间。我会从技术选型讲到前后端联调再讲到部署上线中间穿插大量实际项目中遇到的问题和对应的解决办法。内容偏实战代码会贴但不会通篇堆代码重点放在“为什么这么做”上。1. 技术选型与整体设计思路1.1 为什么选 Spring Boot Vue 这套组合很多人在选型阶段就容易纠结后端用 Spring Boot 还是 Node.js前端用 Vue 还是 React。我的看法是这套组合之所以在国内中小型团队里那么流行核心原因是“稳定”和“好招人”。Spring Boot 的生态太成熟了从数据库访问到消息队列、从缓存到定时任务几乎你能想到的需求都能找到现成的 starter。Vue 的上手门槛比 React 低模板语法直观对后端出身的开发者特别友好。团队里如果都是 Java 背景Vue 的模板风格和传统的 JSP 之类的东西有相似之处转型成本低。从项目维护角度讲Spring Boot 的自动配置机制让服务端代码的“约定”感很强新成员看代码时不需要太多上下文就能找到入口。而 Vue 的单文件组件方式把模板、脚本、样式收拢在一个文件里职责边界清晰。这套组合的另外一个优势是前后端可以完全独立开发、独立部署只要接口文档定得够详细两边并行推进的效率非常高。1.2 前后端分离架构里的职责边界前后端分离这个词被喊了很多年但真正落地的时候很多人还是搞混。我见过不少项目前端页面里直接拼 RESTful URL后端 Controller 里返回视图跳转本质上还是耦合的。正确做法是后端只负责提供数据接口和业务逻辑不关心前端页面怎么渲染前端只负责用户交互和数据展示不直接操作数据库。我习惯的职责切分是这样的后端负责身份认证、权限校验、业务规则、数据持久化、事务管理前端负责路由管理、状态管理、接口调用、表单校验、交互反馈两边共同遵守接口文档里约定的请求格式、响应格式、错误码这套切分做完之后一个很直接的好处是后端接口写好了可以直接用 Postman 或者 Apifox 自测前端也可以用 mock 数据先跑起来两边互不阻塞。项目进度条拉快了不少。1.3 项目结构规划从单体到模块化的渐进式拆分很多人一上来就按“controller/service/mapper”三层结构堆代码小项目还好一旦业务复杂起来包越来越多层级越来越深最后改一个功能要翻十几个文件。我的建议是先按“业务模块”划分顶层包再在模块内部做三层结构。举个例子一个电商系统的后端包结构可以这么设计com.example.mall ├── common // 通用组件统一返回、异常处理、工具类 ├── config // 配置类拦截器、CORS、安全配置 ├── module │ ├── user // 用户模块 │ │ ├── controller │ │ ├── service │ │ ├── mapper │ │ └── entity │ ├── order // 订单模块 │ ├── product // 商品模块 │ └── payment // 支付模块 └── security // 安全相关JWT工具、认证过滤器这样做的优势在于每个模块的业务代码内聚在一起模块之间通过接口交互降低耦合。等到将来需要拆微服务直接把这个模块抽出去变成独立服务就行改造工作量比从三层结构里硬拆要小得多。1.4 环境版本选择别踩版本坑版本兼容问题是我在实际开发中最头疼的问题之一。Spring Boot 和 Vue 的生态更新节奏快不同大版本之间的 API 变化有时很隐晦。我目前生产环境比较稳的一套组合是Java 17 Spring Boot 2.7.x3.x 也用过但有些第三方 starter 还没跟进建议团队先用 2.7 过渡Vue 3.x Vite Element PlusNode.js 16.x 或 18.x LTS数据库 MySQL 8.0.xORM 用 MyBatis Plus这个组合有个好处网上踩坑资料最多。你遇到任何奇奇怪怪的问题基本都能搜到前人留下的经验。那些追求最新版本的同学建议先在测试环境玩通了再上生产不然一个依赖升级引发的连锁兼容问题排查起来很狼狈。2. 后端核心实现与开发经验2.1 Spring Boot 项目搭建和分层实践项目搭建我用的是 Spring Initializr 生成基础骨架然后按第一章节的模块结构调整包名。依赖选择上Web、Validation、MyBatis Plus 启动依赖是必须的JWT 相关的我直接引入 jjwt 库省得自己去实现签名算法。这里要重点说下分层代码怎么写才规范。以用户注册为例Controller 层只做参数接收Service 层做业务逻辑Mapper 层只负责数据库操作。千万别图省事在 Controller 里写一大串业务代码后期维护会非常痛苦。比如用户注册接口规范的写法是RestController RequestMapping(/api/user) public class UserController { private final UserService userService; public UserController(UserService userService) { this.userService userService; } PostMapping(/register) public ResultVoid register(RequestBody Valid RegisterRequest request) { userService.register(request); return Result.success(); } }Service 里负责校验用户名唯一性、加密密码、保存用户记录事务的管理也在这一层用Transactional注解控制。这样接口层非常薄看着舒服出了问题也好排查——先看 Controller 参数对不对再看 Service 逻辑最后才查 SQL。2.2 统一返回格式前端少踩一半坑接口返回格式如果不统一前端每次拿到响应都要猜结构联调效率低得一塌糊涂。我见过最离谱的接口有的返回{code:0,data:...}有的返回{status:success,result:...}前端封装 Axios 拦截器时没法做统一处理只能到处写判断逻辑。我推荐一个简单可靠的统一返回结构{ code: 200, message: 操作成功, data: {} }其中 code 是业务状态码200 代表成功其它值代表各种业务异常比如 401 未认证、403 无权限、400 参数错误。message 是给前端提示用的文案data 是真正的业务数据。后端代码上定义一个泛型类ResultT包含静态方法success()、success(T data)、error(String message)然后在所有 Controller 的返回值里都用它。另外再用一个全局异常处理器RestControllerAdvice把各种校验异常、业务异常、未知异常统一兜底转成上面的格式返回。前端只需要在 Axios 响应拦截器里判断 code 是否为 200其它情况统一弹提示或跳转登录页省心很多。2.3 参数校验后端校验是第一道防线也是最后一道关于参数校验网上有个常见争论前端已经做了表单校验后端还需要校验吗答案是必须做而且要做全套。前端校验只是为了用户体验只要有人绕过前端直接调接口后端不校验的话脏数据就直接进了数据库。这种问题一旦发生后续排查的成本远高于当初写校验的功夫。Spring Boot 里做参数校验很方便利用 Bean Validation 注解在实体类字段上加上约束注解public class RegisterRequest { NotBlank(message 用户名不能为空) Size(min 4, max 20, message 用户名长度必须在4到20之间) private String username; NotBlank(message 密码不能为空) Size(min 6, max 32, message 密码长度必须在6到32之间) private String password; NotBlank(message 邮箱不能为空) Email(message 邮箱格式不正确) private String email; }然后在 Controller 参数上加上Valid注解Spring 会在进入方法前自动完成校验。校验失败抛出的异常在全局异常处理器里统一捕获把 message 返回给前端。这里有个细节分组校验。比如用户 ID 在更新接口里必须传但新增接口里不能传就可以用Validated的分组功能来区分不要为了省事写两套实体类。2.4 JWT 身份认证从登录到请求鉴权的完整链路JWTJSON Web Token是前后端分离场景下最常用的认证方案。它的原理不复杂用户登录成功后后端生成一个带有签名信息的 token 字符串返回给前端前端之后每次请求都在 header 里带上这个 token后端通过验签来确认用户身份。整个过程中后端不需要存 session天然适合横向扩展。我这里分享一个生产可用的实现链路登录接口校验用户名密码成功后用 jjwt 生成 tokentoken 里面包含 userId、username 等非敏感信息token 设置过期时间我一般给 24 小时具体业务可以自己调后端写一个拦截器HandlerInterceptor拦截除了登录接口和静态资源之外的所有请求拦截器里读取 header 的 Authorization 字段校验 token 签名和过期时间校验通过后从 token 里解析出 userId放入 ThreadLocal 或 Request attribute 中方便后续业务代码获取当前登录用户有一个关键点想特别提醒禁止把敏感信息放进 token比如手机号、身份证号这些。因为 JWT 的 payload 只是 Base64 编码不是加密的任何人拿到 token 都能解码看到内容。token 泄露的风险本来就存在再放敏感信息就是雪上加霜。2.5 数据库交互优化分页查询和防止 SQL 注入MyBatis Plus 在单表 CRUD 上能省大量模板代码BaseMapper 里已经内置了插入、更新、按 ID 查询这些方法。但多表关联查询、复杂 SQL 还是需要自己写 XML。这里有两个日常开发最容易忽略的点第一个是分页插件配置。MyBatis Plus 的分页需要显式引入分页插件否则 Page 对象不会生效。配置方法很简单在配置类里加一个 MybatisPlusInterceptor 的 bean。分页查询的好处不只是用户体验更重要的是避免一次性把几万条数据加载到内存里把数据库和服务器内存打爆。第二个是防 SQL 注入。我见过不少人在 XML 里用${}拼接参数这是非常危险的行为。${}是直接文本替换如果参数来自用户输入有心人构造一个恶意字符串就能把 SQL 改得面目全非。正确做法是尽量用#{}预编译参数如果某处确实需要动态排序字段这样的场景必须在代码层做白名单校验只允许传入白名单里的列名。3. 前端工程化与核心实现3.1 基于 Vite 的 Vue3 项目搭建取代 Webpack 后的真实体验现在新建 Vue 项目我推荐直接用 Vite。Vite 基于原生 ES Module冷启动速度比 Webpack 快一个数量级开发体验是质的提升。创建命令很简单npm create vitelatest frontend -- --template vue生成的项目结构很清爽之后我需要做几件事装 vue-router、pinia、axios、element-plus 这些核心库配置路径别名指向src目录。路径别名这个配置建议第一时间做不然后期代码里到处都是../../../../看着心烦也容易引错路径。Vite 的代理配置是联调阶段的神器。在vite.config.js里加个 server.proxy把/api开头的请求转发到后端地址就能完美解决开发环境下的跨域问题。前端代码里写的请求地址直接是/api/user/list这种相对路径联调时后端换个端口只需要改配置文件前端一行代码不用动。3.2 组件化设计从页面到组件的拆分思路Vue 的组件化开发最核心的是一句话一个组件只干一件事。页面拆得细每个组件的逻辑就简单清晰出了问题也容易定位。我常用的拆分策略分三层页面级组件对应一个路由负责数据加载和页面布局比如登录页、商品列表页业务组件处理特定的业务功能比如用户信息卡片、订单状态标签基础组件纯粹展示型组件不掺业务逻辑比如自定义的分页组件、空状态占位组件之间通信我用 props 和 emit 解决绝大多数场景。props 传数据、emit 抛事件单向数据流很清晰。遇到跨多层组件传值才考虑用 Pinia 或者 provide/inject。这里有个原则别为了图省事随便引入全局状态很多东西其实用 props 传递就够用了过度设计同样会增加维护成本。3.3 Axios 封装统一请求拦截和响应处理Axios 的封装质量直接决定了联调效率。我会把 Axios 实例单独放在一个文件里统一配置 baseURL、超时时间、请求拦截器、响应拦截器。请求拦截器里做一件事从 localStorage 里拿 token如果有就加到请求头的 Authorization 字段。响应拦截器里做的事稍微多一点判断 HTTP 状态码如果不是 2xx 就直接抛错再根据业务 code 判断是否成功如果不成功统一弹 Element Plus 的 Message 提示特殊处理 401清除本地 token跳转登录页这个封装做完之后业务代码里的接口调用会非常简洁比如// API 层 export function getUserList(params) { return request.get(/user/list, { params }) } // 页面里调用 const getList async () { const res await getUserList(pageParams.value) tableData.value res.data }不需要每个接口都重复处理错误也不需要在每个页面判断登录状态。这些横切关注点一次性处理好开发效率能提升不少。3.4 Pinia 状态管理Vuex 之后的轻量选择Pinia 是目前 Vue 官方推荐的状态管理库相比 Vuex 最大的优势是API 更简洁TypeScript 支持更好模块化默认就是按 store 拆分的不再需要麻烦的 module 注册逻辑。我的实际项目里 Pinia 主要管理两类数据一类是登录用户的全局信息用户ID、昵称、权限列表另一类是跨页面共享的业务数据比如购物车数据。定义 store 的写法很直接export const useUserStore defineStore(user, { state: () ({ token: localStorage.getItem(token) || , userInfo: null }), actions: { async login(formData) { const res await loginApi(formData) this.token res.data.token localStorage.setItem(token, res.data.token) }, async logout() { this.token this.userInfo null localStorage.removeItem(token) } } })有个和 localStorage 同步的细节提醒state 初始化和突变时都要同步到 localStorage否则页面刷新后 store 数据就丢了又要重新登录。3.5 路由权限控制动态路由如何加进项目前端项目只要涉及登录就一定绕不开路由权限控制。思路分为两种简单场景用导航守卫判断是否登录复杂场景用动态路由按角色加载可访问页面。导航守卫的方案比较直接在router.beforeEach里做拦截判断目标路由是否需要认证。如果需要并且本地没 token就跳转到登录页如果有 token 直接放行。这个方案适合后台管理系统中大部分页面都需要登录的情况。动态路由适合权限区分明确的系统。用户登录后从接口拿到角色和权限标识前端根据这些信息动态 addRoute。比如管理员登录能看到用户管理页普通用户看不到。这个方案实现难度高一些但灵活性强。我建议一开始就把权限模块设计好哪怕初期权限很简单也先用统一方案做不然后面加需求改起来很痛。4. 前后端联调从接口文档到跨域处理4.1 接口文档先行别让联调变成灾难前后端并行开发的团队里最大的矛盾点往往不是技术难点而是接口约定不一致。前端按自己的理解调接口后端按自己的理解返回数据两边各写各的联调时互相甩锅。要解决这个问题唯一的出路是接口文档先于代码。我的工作流程是先和前端一起梳理页面需要的所有接口列出接口清单包括 URL、请求方式、请求参数、返回数据结构、错误码含义。然后按这个清单开发前端也按它做 mock。接口文档用 Apifox 这类工具维护它支持从代码注解自动生成文档也能在线调试还能生成 mock 数据效率比 Word 文档高太多了。4.2 开发环境跨域问题的几种解法前后端分离之后开发阶段跨域几乎是必踩的坑。前端跑在 5173 端口后端跑在 8080 端口浏览器的同源策略直接把请求拦了。解决办法有两种思路第一种后端开启 CORS。在 Spring Boot 里写一个配置类实现 WebMvcConfigurer 的 addCorsMappings 方法配置允许的域名、请求头和请求方法。这个方案适合简单场景但生产环境一般不推荐全放开的配置如果有安全需求要严格限制来源。第二种前端 Vite 配置代理这也是我更推荐的开发环境方案。Vite 启动的服务收到/api开头的请求后转发到后端服务浏览器眼里请求是同源的根本没触发跨域机制。配置在vite.config.js里export default defineConfig({ server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })生产环境用 Nginx 做反向代理原理一样把/api转发到后端服务。整个链路下来前后端代码里不需要处理任何跨域逻辑跨域问题在网关层就解决得干干净净。4.3 高频联调问题清单字段不一致、时间格式、null 处理联调阶段最容易出问题的往往在小细节上。我总结几个高频问题类型字段命名不一致后端习惯下划线命名user_name前端习惯驼峰userName。解决方案是后端在全局配置里开启 Map 下划线转驼峰MyBatis Plus 有现成配置或者序列化时用命名策略转换。提前约定好这事能省大量修改工作。时间格式不统一后端返回的是2025-03-20T10:30:00前端要显示2025-03-20 10:30两边各做各的转换容易出幺蛾子。建议后端统一返回特定格式在application.yml里配置全局时间格式化或者在 Jackson 的配置类里统一指定格式。null 处理列表接口里某条数据的某个字段是 null前端渲染出来显示成空页面或者“undefined”。这个在开发阶段就得小心前端的展示逻辑要兼容 null 值后端的返回数据里能去掉的空字段也可以直接用JsonInclude(Include.NON_NULL)全局忽略。4.4 调试技巧前后端联合排查的思路联调时接口有问题先别急着提交代码按照固定顺序排查能节省大量时间第一看浏览器 Network 面板确认请求是否发出、URL 是否正确、请求头和参数是什么第二看请求响应状态码4xx 大概率是参数或权限问题5xx 大概率是后端代码问题第三看响应内容把接口返回的 JSON 复制到格式化工具里确认返回结构是否符合预期第四如果是 5xx看后端日志重点看异常堆栈的第一行一般就能定位问题这个排查顺序的逻辑是从请求出发确认前端的锅然后到响应确认后端的锅最后到异常定位代码问题。有了合理流程就不会出现两边对着同一个接口猜来猜去的情况。5. 生产环境部署与上线检查清单5.1 前端构建与 Nginx 配置的最佳实践前端部署的本质只有一个把源码编译成静态文件然后用 Web 服务器托管。Vue 项目执行npm run build生成一个 dist 目录里面是打包好的 HTML、JS、CSS。关键点是 Nginx 的配置。第一个要点单页应用的路由是前端控制的刷新页面时浏览器会按 URL 去找资源但是服务器上并没有这个路径对应的文件所以 Nginx 必须配置 try_files 把所有请求回退到 index.html让前端路由接管。location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; }第二个要点/api 开头的请求要反向代理到后端服务不要直接去找静态文件。location /api/ { proxy_pass http://localhost:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }第三个要点静态资源缓存。JS、CSS、图片这些打包出来的文件文件名带了 hash 值内容变了文件名就变可以放心设置长时间缓存。HTML 文件设置为不缓存保证用户能拿到最新的入口文件。5.2 后端打包从 Jar 包到 Docker 容器化Spring Boot 项目的部署方式我经历了从“手动跑 Jar 包”到“Docker 容器化”的过程。手动跑 Jar 包很简单mvn clean package生成 jar然后java -jar启动。但问题也明显环境依赖不一致、日志管理麻烦、进程挂掉没人管、升级要手动操作。现在我的标准做法是写 Dockerfile把应用做成镜像FROM openjdk:17-jdk-alpine WORKDIR /app COPY target/mall-server.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]再用 docker-compose 把后端和数据库编排在一起一条docker-compose up -d命令搞定整套环境。数据库用独立的容器挂了数据卷数据不会丢。这套方案的好处是本地环境、测试环境、生产环境完全一致不会出现“我本地跑得好好的到你那里就报错”的问题。5.3 反向代理与 HTTPS上线前必须确认的安全项部署上线前有几个安全项一定要过一遍。首先是 HTTPS。现在的浏览器对 HTTP 网站越来越不友好很多新特性都被限制而且用户在地址栏看到“不安全”的标识对产品信任感影响很大。用 Nginx 加证书的过程不复杂证书可以通过各种云服务商免费申请。其次是敏感信息的保护。数据库连接串、密码、密钥这些本来写在 application.yml 里的配置建议改用环境变量注入避免打包后的 Jar 包里藏着生产环境凭据。Docker 环境里可以用环境变量或者 Docker Secrets 来管理不要图方便硬编码在镜像里。最后是日志的合理配置。Spring Boot 默认日志输出到控制台容器化环境下靠 docker logs 查看文件一多就难查。建议配置 logback 把日志输出到文件按天滚动同时保留最近 N 份。配合问题排查时这些日志就是救命稻草。5.4 上线检查清单避免“上线即事故”的实操经验我把自己踩过坑之后的教训总结成一张检查清单每次上线前逐项确认数据库执行过最新版本的初始化脚本字段变更用迁移工具管理配置文件使用环境变量没有敏感信息硬编码后端接口做过简单的并发测试确认没有明显的性能瓶颈前端打包产物上传到了 CDN 或服务器不存在绕开缓存的问题Nginx 配置的 try_files 和 /api 代理都验证过登录流程完整走一遍注册、登录、token 过期、刷新登录退出登录后不能通过浏览器返回键看到敏感页面挂掉一个后端实例不影响整体可用性如果有多实例部署每次照着这个清单过一遍上线后的突发事故率降得特别明显。清单看着简单但每一条背后都是真金白银的教训。6. 常见问题排查与避坑记录6.1 典型问题速查表照着排查省时间整理一个高频问题速查表遇到问题先对着看问题现象可能原因解决思路登录后请求一直 401token 没存到请求头检查 axios 拦截器是否在每次请求时加 Authorization跨域请求被拦截后端 CORS 未配置或配置错误开发环境优先用 vite 代理生产用 Nginx刷新页面 404Nginx 没有配 try_files把所有路由回退到 index.html前端拿到的时间格式不对前后端时间格式约定不一致后端全局配置时间格式化中文乱码请求或响应编码不一致统一 UTF-8检查 Nginx 配置的 charset接口返回慢SQL 缺索引或 N1 查询慢日志定位 SQL看执行计划文件上传失败Nginx 的 client_max_body_size 限制调大配置项单独解释一个高频问题404。很多人部署 Vue 项目上线之后访问首页没问题一点页面刷新就 404。这个基本就是 Nginx 配置的 try_files 没写或者写完 Nginx 没重载。我之前第一次部署时也踩过一次后来理解前端路由和静态文件服务器的关系之后再也没犯过。6.2 Security 相关坑认证过滤器与静态资源放行集成了权限认证的框架之后最大的坑就是过滤器拦截了不该拦截的路径。最典型的是登录页面、注册接口、验证码接口、静态资源图片、CSS、JS全部被拦截导致前端打开登录页就报 401。解决思路是梳理好“白名单”路径。在拦截器配置里把所有公开访问的接口和资源路径放行剩下的才走认证逻辑。维护这个白名单要细心新增公共接口时顺手加进去不然后端上线一个公开的接口却被认证拦截莫名其妙多一个 bug。另一个坑是过滤器的执行顺序。如果同时有多个过滤器顺序调整起来很麻烦尤其是 Spring 的 OncePerRequestFilter 和各种第三方过滤器混在一起时要确保认证过滤器在正确的位置执行不然 token 解析的结果还没放进上下文接口就被后面的过滤器拦了。6.3 事务和并发问题的几个复盘业务系统里最容易翻车的两类坑事务不生效和并发覆盖。事务不生效最常见的三种情况方法不是 public 的、同类内部直接调用导致代理失效、异常被捕获后事务感知不到。我复盘过一次典型的例子删除订单的业务里删除订单和写操作日志放到了同一个类里的两个方法日志那个方法异常被 try catch 吞了整个事务回滚不了订单删了但日志没了。改法很简单把操作日志做成独立服务类注入调用或者用编程式事务手动控制。并发覆盖的典型场景是库存扣减。两个用户同时下单都读取到库存为 1都执行减库存操作最后库存变 0 但卖出了两单。解决思路一般是用数据库乐观锁在库存表加 version 字段update 时带上条件判断 version 是否有变化如果变化说明被别的请求修改过重试或者报错。这个问题的本质是先读后写这种模式必须处理并发环境下的数据一致性不能想当然。6.4 前端的几个隐蔽 Bug 复盘前端也有一些看着诡异实际是细节没处理好的问题。第一个是异步更新问题数组里一个对象的属性改完之后页面没更新。原因是 Vue 3 的响应式代理可以捕获数组下标修改了但深层的嵌套属性如果初始化时不存在且没通过响应式 API 添加就不会触发更新。解决办法是初始化时把整个对象结构定义完整或者用this.$set的思路在 Vue3 里就是直接重新赋值一个新的对象引用。第二个是路由切换后页面数据残留。列表页滚动加载过的数据跳到详情页再返回列表还在原来的位置虽然这是个体验优化点但没有需求时可能导致数据状态不一致的问题。可以监听路由变化重新初始化页面数据来避免。第三个是组件卸载后的异步回调。页面里发起了一个请求用户等不及直接跳走了请求回来之后的代码还在执行容易报 “Cannot read properties of null” 这类错误。应对方法是在组件卸载时标记状态或者在异步回调里做组件销毁的判断防止对话更新已经不存在的 DOM。7. 项目质量的最后防线测试与代码评审7.1 后端接口测试不止是单元测试提到测试很多人第一反应是写单元测试。但实际项目里投入产出比最高的其实是接口级测试。我习惯用 Apifox 或者写一个简单的集成测试类直接调用 Controller 接口验证请求响应是否符合预期。接口测试覆盖的是完整链路参数校验、业务逻辑、数据库操作、返回格式。一个接口一条测试用例跑一次能发现的问题比写几十个单测还多。关键接口我建议必须测登录、注册、数据列表、提交订单这类核心链路。写测试用例时正常路径要测异常路径更要测——参数缺失、参数类型错误、未登录访问、无权限访问。这些异常场景才是用户最容易触发的。7.2 前端代码规范从命名到状态管理的约定前端项目人多之后代码风格不统一是必然的事。我建议从一开始就立好规范强制执行。我记忆中踩过最烦的坑是命名混乱有的组件用 PascalCase有的用 kebab-case有的接口函数用中文拼音缩写。维护起来像是拆盲盒。规范至少要覆盖这些方面组件文件名统一 PascalCase比如 UserTable.vue变量和函数用 camelCase常量用大写 下划线页面路由 path 全部小写多单词用连字符API 接口单独放 api 目录按业务模块拆分文件状态管理统一走 Pinia禁止随手在组件里写全局变量规范落到代码里最有效的做法是用 ESLint 和 Prettier提交代码前自动检查、自动格式化从规则层面保证代码质量。7.3 代码评审应该关注什么而不是走过场代码评审如果只是走过场值不了多少钱。真正有效的评审我觉得应该关注几个重点业务逻辑的正确性实现是否覆盖了所有分支边界条件是否处理数据安全问题有没有 SQL 注入风险、越权访问风险异常处理该捕获的异常有没有捕获不该吞的异常是不是被吞了性能和资源释放有没有在循环里查数据库、有没有内存泄漏隐患可测试性代码能不能方便地写测试评审中发现问题建议直接说“这里有个问题”不要纠结是不是某人的锅。评的是代码不是人。氛围融洽的团队代码质量才提得上去。8. 个人经验总结与后续扩展建议做完几个全栈项目之后我的体会是全栈开发最重要的不是会用多少个框架而是能把前后端的边界理清楚。这个边界一旦清晰很多问题都变得简单了——接口文档、联调协作、权限控制、异常处理都是在边界上做文章。回头来看这套技术选型Spring Boot Vue 在日常业务系统里具备足够的灵活性和可靠性。遇到高并发场景可以在后端引入 Redis 做缓存、引入消息队列做异步削峰遇到复杂交互场景前端可以引入更重的状态管理方案或组件库。底层骨架不变扩展能力都由生态提供。后续想在这个项目上继续深入学习我建议按这几条线走一是把权限模型升级为 RBAC 完整模型支持多角色多权限的动态路由方案二是引入 Redis 缓存热点数据再做接口幂等性设计三是把部署升级为自动化流水线提交代码自动构建、自动测试、自动部署到测试环境四是补充完善的日志监控体系生产环境出问题能快速告警定位。全栈这条路没有捷径但通过一个个项目的积累踩过的坑会慢慢变成经验。上面写到的这些细节和方法都是我实际项目中反复验证过的希望能帮你少走一些弯路。最后想多说一句不管技术栈怎么变真正拿得出手的永远是解决问题的能力。框架学得多不如用得扎实把一个项目从开发到上线完整走一遍比看一百篇教程都有用。