ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

SpringBoot+Vue兼职网毕设项目:从业务设计到部署调试全攻略

SpringBoot+Vue兼职网毕设项目:从业务设计到部署调试全攻略 每年到这个时间点都会有一大批人被同一个问题卡住Java Web毕设选题。选图书管理太简单答辩老师看不上眼选电商平台又太复杂三个月都写不完。我见过太多人拿到一套SpringBootVue的兼职网源码第一步就栽在环境配置上更别说把整个项目的业务逻辑吃透、顺顺利利地通过答辩了。这篇文章就以蜗牛兼职网这个项目为例从业务设计、数据库建模、后端接口、前端页面到SQL脚本执行和接口文档阅读完整捋一遍。不管你是刚拿到源码准备跑起来的毕业生还是想参考这个项目学着做一个类似平台的开发者都可以照着下面的思路来。1. 选题逻辑兼职平台凭什么成为Java Web毕设的常青树1.1 业务模型拆解三方角色的需求闭环选毕业设计题目最怕的是业务太薄。图书管理、学生信息管理这类系统说白了就是一堆增删改查没有状态流转没有权限差异答辩的时候根本没什么可讲的。兼职平台不一样它天然带着三方角色求职者、企业发布者和平台管理员。求职者要什么要的是浏览兼职、搜索职位、报名申请、收藏感兴趣的工作。企业要什么要的是发布兼职、管理自己发布的职位、查看报名情况、筛选合适的候选人。管理员要什么要的是审核兼职信息是否合规、管理用户状态、处理举报反馈。这三方需求放在一起就形成了一个完整的业务闭环企业发布兼职 - 管理员审核 - 求职者浏览申请 - 企业查看管理 - 平台数据沉淀。每一个环节都有对应的页面、接口和数据库表支撑这就是一个好的毕业设计题目该有的样子——业务不复杂但足够完整能让答辩老师看到你对需求分析的理解深度。1.2 功能模块清单答辩时能讲清楚的设计亮点我建议大家拿到一个项目源码后第一步不是急着去启动而是先画一张功能模块图。蜗牛兼职网这个项目的功能模块可以拆成下面几个大块模块面向角色核心功能用户认证全部角色注册、登录、Token验证、退出兼职大厅求职者兼职列表、关键词搜索、分类筛选、兼职详情个人中心求职者申请记录、收藏列表、个人资料修改企业中心企业用户发布兼职、我的发布、报名人员管理后台管理管理员兼职审核、用户管理、分类管理、统计概览这个功能清单覆盖了SSM阶段学的所有基本操作还加入了JWT鉴权、多角色权限、业务状态流转这些加分项。答辩的时候按这个清单逐项讲每个模块是怎么设计的、表之间是怎么关联的、状态是怎么流转的老师一听就知道你对项目是真做过功课的。2. 技术选型SpringBoot Vue这个组合为什么能打2.1 后端为什么是SpringBoot而不是Spring MVC很多人在毕设开题时会犹豫学校教的是Spring MVC JSP我能不能用能用但没必要。SpringBoot本质上就是Spring生态的自动配置封装它的出现就是为了解决传统SSM整合时那一大堆XML配置。拿一个典型场景来说传统SSM要配置数据源、配置MyBatis的Mapper扫描、配置事务管理器、配置视图解析器每个环节都可能出错。SpringBoot用一个application.yml文件把绝大部分配置集中起来再配合spring-boot-starter-web、spring-boot-starter-data-jpa或mybatis-spring-boot-starter这些起步依赖几行代码就能把一个Web应用跑起来。更重要的是SpringBoot内嵌了Tomcat不需要额外部署WAR包到外部容器。这对毕业设计来说非常友好——你把自己的项目打包成JAR在任何装了JDK的机器上一条java -jar命令就能启动答辩演示的时候根本不用纠结环境问题。2.2 前端为什么选Vue而不是JSP模板传统JSP开发是后端渲染页面HTML和Java代码混在一起改个样式都要重启服务。Vue是前后端分离的组件化开发页面是独立的工程通过Ajax与后端交互。这两者的差异说得直白点就像手工作坊和流水线工厂的区别。Vue的脚手架工具Vue CLI能够快速搭建工程内置了开发服务器和热更新功能。修改代码后浏览器自动刷新不用手动重启。这对调试效率的提升是巨大的。而且Vue的组件化设计让页面复用变得很简单——比如兼职卡片组件列表页用一次收藏页用一次搜索结果页再用一次写一次代码三处生效。蜗牛兼职网的前端用Vue Element UI这套组合Element UI提供了现成的表格、表单、对话框、分页组件不用自己手写复杂的CSS样式。对前端基础相对薄弱的同学来说这是最务实的选型。2.3 前后端分离的联调优势前后端分离还有一个被很多人忽略的好处开发阶段可以并行。后端写好接口文档后前端同学可以先用Mock数据模拟接口返回不用等后端把代码写完。放在毕设的场景下虽然大多数时候是你一个人既写前端又写后端但前后端分离的架构让项目结构更清晰——前端的路由和组件逻辑、后端的接口与业务逻辑互不干扰。这种架构还有一个实际的好处答辩时如果前端页面出了问题你可以打开浏览器开发者工具的Network面板一眼就能看出是请求没有发出去还是接口返回了错误码定位问题的速度比传统JSP项目快得多。3. 数据库设计从业务实体到六张核心表3.1 用户表一个表解决三种角色身份蜗牛兼职网的数据库设计是典型的表驱动开发思路。先想清楚有哪些实体再为每个实体建表。实体很好列用户、兼职分类、兼职信息、报名申请、收藏记录。但用户不是一个简单的实体它需要区分管理员、企业和求职者三种角色。对于这种多角色场景有两种设计方案一种是建三张独立的用户表管理员表、企业表、求职者表另一种是建一张用户表加一个角色字段。兼职平台用后者更合理。因为管理员、企业、求职者之间有很多共性字段——用户名、密码、手机号、头像、注册时间分三张表会造成大量冗余。一张user表加role字段配合JWT在登录时返回角色信息前端根据角色跳转到不同页面后端根据角色鉴权实现起来简单高效。下面是用户表的核心字段设计字段名类型说明idbigint主键自增usernamevarchar(50)登录用户名唯一passwordvarchar(255)BCrypt加密后的密码nicknamevarchar(50)昵称/企业名称phonevarchar(20)手机号avatarvarchar(255)头像URLroletinyint角色0管理员1企业2求职者statustinyint状态0禁用1正常create_timedatetime注册时间有一个细节值得注意password字段的长度要留够。如果用了BCrypt加密生成的字符串长度是60个字符有些老项目的字段长度只给了32存进去直接报错。这也是我在调试很多毕设项目时最常遇到的问题之一。3.2 兼职信息表字段设计里的隐藏考点兼职信息表是这个项目里字段最多的表也是数据库设计里最能看出水平的表。除了常规的id、title、description之外兼职信息表需要重点考虑的字段有这么几个user_id发布者ID关联用户表标识这条兼职是哪家企业发布的category_id所属分类ID关联兼职分类表salary_min和salary_max薪资范围用两个字段而不是一个总薪资字段方便按薪资搜索时用范围条件过滤status状态字段0待审核、1已上架、2已下架、3审核不通过这是整个项目里最关键的状态流转people_count招聘人数企业发布时填写work_address工作地点这个字段在搜索里经常被用到status字段设计特别值得展开讲。很多初学者做一个发布功能只有已发布和未发布两个状态但兼职平台必须有审核环节——企业发布的信息如果不需要管理员的审核平台就失控了。蜗牛兼职网的发布流程是企业提交兼职 - 状态变成待审核 - 管理员在后台审核 - 通过则上架不通过则退回 - 企业可以修改后再提交。这个状态流转逻辑就是答辩时一个非常有含金量的回答点你为什么设计这个字段因为业务上需要平台管控。3.3 申请记录表与收藏表中间表的取舍申请记录表解决的是求职者与兼职信息之间的多对多关系。一个求职者可以申请多个兼职一个兼职可以被多个求职者申请。如果不建中间表直接在兼职表里加一个user_id字段表示谁申请了那么一条兼职就只能被一个人申请显然不现实。申请记录表的设计要点字段名类型说明idbigint主键job_idbigint兼职信息IDuser_idbigint求职者IDstatustinyint0待处理1已通过2已拒绝apply_timedatetime申请时间remarkvarchar(255)求职者备注这里加不加唯一约束是个细节问题user_id和job_id的组合应该加唯一索引防止同一个求职者重复申请同一个兼职。少了这个约束用户疯狂点报名按钮就会产生无数条重复申请记录企业端看到的报名列表会非常难看。收藏表和申请记录表结构类似一个user_id加一个job_id再加一个收藏时间。因为收藏本身没有状态流转所以比申请记录表更简单。稍有追求的同学可以加一个是否有收藏提醒之类的小功能算是加分项。3.4 SQL脚本里的几个关键注意点拿到SQL脚本后不要急着运行。先看一眼脚本里的建库语句、字符集和存储引擎。第一字符集一定要用utf8mb4而不是utf8。utf8在MySQL里最多存3个字节遇到生僻字或者Emoji就会报错。虽然毕设项目里用不到太多特殊字符但这个习惯要从现在养成。第二存储引擎用InnoDB事务支持是MyBatis操作多表时数据一致性的保障。虽然MyBatis默认就是操作InnoDB表但万一脚本里有旧版本的MyISAM建表语句遇到事务回滚就会出问题。第三先看有没有外键约束。我知道很多教材都强调外键但实际开发里外键约束会把数据操作的灵活性卡死。蜗牛兼职网的SQL脚本如果设计合理应该只有索引没有外键——表之间的关联关系在业务代码里控制而不是交给数据库强制约束。这一点在答辩时如果有老师问到你可以明确说出不用外键是为了避免删除用户时外键报错、方便逻辑删除这样有说服力的理由。4. 后端接口与业务实现这些代码是怎么组织的4.1 统一返回结果为什么所有接口都要套一层Result打开后端源码第一步应该看common或util包下有没有一个叫做Result、R或者ResponseResult的类。没有这个类的话这个项目的代码规范就很值得怀疑了。统一返回结果类的作用是让前端在处理所有接口返回时都用同一种方式解析数据。蜗牛兼职网的接口返回结构一般是这样的{ code: 200, message: 操作成功, data: { total: 100, list: [...] } }code是状态码200表示成功500表示服务器错误401表示未登录或Token失效message是提示信息前端可以直接用ElMessage弹出来data才是真正要渲染的数据。这样做的好处是前端Axios拦截器只需要判断一次code就能统一处理所有接口的错误提示不用每个页面都写一遍错误处理逻辑。4.2 JWT登录认证从登录接口到拦截器的完整链路蜗牛兼职网的登录认证用的是JWTJSON Web Token这套机制要理解透了答辩时被问到的概率极高。整个认证链路分四步。第一步用户提交用户名和密码后端校验通过后生成一个Token返回给前端。第二步前端把Token存在本地存储localStorage或sessionStorage里每次发送Ajax请求时在请求头中带上Authorization: Bearer token。第三步后端写一个拦截器Interceptor拦截需要认证的路径从请求头中取出Token并解析验证——验证通过就放行验证失败就返回401。第四步前端在Axios响应拦截器里统一判断401发现Token过期就清除本地登录状态并跳转到登录页。Token里一般不存敏感信息通常只放userId和role两个关键字段。后端拦截器解析出用户ID后可以把它放入ThreadLocal或请求对象中后续的Controller和Service中直接获取当前登录用户不需要每个接口都把用户ID作为参数传递。这个设计细节很实用比如企业发布兼职时后端从Token中解析出企业用户ID作为这条兼职记录的user_id用户根本不需要手动传。4.3 兼职发布与审核的状态机流转兼职发布的Controller层代码看着很简单就是接收参数调用Service保存返回结果。真正的业务逻辑藏在Service层的状态判断里。看蜗牛兼职网的JobServiceImpl时我建议你把状态相关的代码单独拎出来过一遍。企业提交发布请求后端会执行以下逻辑判断当前用户角色是否是企业不是就返回403将兼职记录的status置为0待审核保存到数据库返回提交成功等待审核的提示。管理员审核接口的逻辑则正好相反管理员看到待审核列表后点击通过就把status改为1点击拒绝就把status改为2或3同时可以填写审核意见。这里有一个容易忽略的细节兼职信息一旦上架想要修改怎么办规范的做法是企业端只能操作待审核和已下架状态的兼职。已上架的兼职如果要修改必须先把状态改为已下架改完再重新提交审核。这个规则是由前端按钮的显隐控制加后端的权限校验双重保证的。4.4 多条件检索从SQL写法到接口封装兼职大厅的检索功能是另一个答辩经典问题。前端提供三个条件关键词、分类、排序方式。关键词模糊匹配标题和描述分类精确匹配排序可以按最新发布或薪资从高到低。MyBatis实现多条件检索有两种常见方案。一种是直接写XML里的动态SQL用if标签判断条件是否为空另一种是使用MyBatis-Plus的LambdaQueryWrapper在Java代码里链式拼接查询条件。两种方案各有优劣我个人的建议是条件少用QueryWrapper条件多、逻辑复杂的用XML。分页用PageHelper或MyBatis-Plus的分页插件都行。分页插件拦截SQL自动生成count查询和limit语句前端传pageNum和pageSize两个参数后端返回total总条数和list当前页数据两部分。前端Element UI的分页组件正好对应这个数据格式。5. Vue前端的页面结构与交互实现5.1 路由设计页面间跳转的底层逻辑打开前端项目的src/router/index.js你能看到一个项目的页面全貌。蜗牛兼职网的前端路由通常分成两组普通用户可访问的页面和需要登录才能访问的页面。不需要登录的页面包括首页、兼职详情页、登录页、注册页。需要登录的页面包括个人中心、企业发布中心、管理后台。Vue Router的路由守卫beforeEach在这里派上用场router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next(/login) } else { next() } })这段代码的逻辑很清晰如果目标页面要求登录但本地没有Token就强制跳转到登录页。至于用户角色校验比如你不是管理员就不能访问后台可以在路由守卫里再判断role也可以在路由的meta字段中标记角色然后逐一比对。5.2 组件封装兼职卡片是如何复用的Vue的组件化开发贯穿了这个项目的前端。最容易看出来的组件复用是兼职卡片JobCard。首页大厅、搜索结果页、收藏列表页都要展示兼职信息如果用三套代码写三遍改样式的时候就得改三个地方。抽成一个组件后只需要在组件里定义好job这个props属性三个页面引用组件时分别传不同的数据源样式和逻辑都只维护一份。这个组件的核心逻辑是接收一个兼职对象展示标题、分类、薪资、地点、发布时间点击后跳转到详情页。薪资的展示格式比如200元/天可以在组件的computed中拼好模板里直接渲染这是Vue响应式数据流的典型用法。5.3 Axios封装请求拦截与响应拦截的统一处理前端项目里src/api/request.js或类似名字的文件是Axios的封装层。所有实际请求都从这里发出。它的代码逻辑是这样的axios.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer token } return config }) axios.interceptors.response.use( response { const res response.data if (res.code 200) { return res } else if (res.code 401) { router.push(/login) } else { ElementUI.Message.error(res.message) return Promise.reject(res) } } )请求拦截器自动把Token加到请求头上响应拦截器统一处理返回码。有了这层封装每个页面的业务代码只需要关心成功的数据返回错误和未登录状态都不用重复处理。这既是代码规范问题更是实际开发效率问题。6. SQL脚本执行与源码导入让项目先跑起来6.1 数据库初始化的具体步骤拿到项目的完整资源包后我建议按照先数据库、再后端、最后前端的顺序来启动。数据库是整个项目的地基地基不打牢后面的项目跑不起来都是白搭。第一步确认MySQL版本。蜗牛兼职网如果在pom.xml里用的是mysql-connector-java8.0.x版本那么MySQL建议使用5.7或8.0。用MySQL 5.5或更早版本很可能会遇到驱动兼容问题。第二步创建数据库并执行SQL脚本。你可以用Navicat或命令行执行mysql -u root -p snail_job.sql或者更稳妥的方式先在Navicat中创建一个名为snail_job的数据库注意字符集选utf8mb4然后右键选择运行SQL文件。之所以推荐先用Navicat建库再导入脚本是因为有些SQL脚本里没有CREATE DATABASE语句直接执行会报No database selected的错误。第三步确认脚本执行成功。查看左侧的表列表应该能看到用户表、兼职分类表、兼职信息表、申请记录表等核心表以及一些初始数据。看到表结构后顺手打开用户表检查初始管理员账号是否存在一般是admin/admin123之类这个账号后面测试登录要用。6.2 后端启动前的三个必改配置后端项目启动不成功九成是配置文件的问题。用IDEA打开后端项目后找到src/main/resources/application.yml或者application.properties对照下面的清单检查第一个必改的是数据库连接信息。url中的数据库名、username和password必须和你本地的MySQL保持一致。很多人的MySQL密码设置过特殊字符比如root123直接写在URL后面会冲突需要URL编码或者改复杂密码为简单密码再做项目演示。第二个是端口配置。如果是第一次启动建议先把端口改成8080看看是否被占用。如果你的电脑上装了很多开发环境比如Docker、Nginx8080端口很容易被占。如果8080被占用改成8081、8082都行但要记得和前端代理的地址保持一致。第三个是日志级别和文件上传路径这类辅助配置。日志级别设为DEBUG可以在排查问题时看到更多细节。文件上传路径确定一个可写的本地目录用于存储用户上传的头像和图片。改完这三项后用Maven刷新加载依赖等待下载完成后直接运行启动类。看到Started Application in xxx seconds的日志后端就算启动成功了。6.3 前端依赖安装与启动npm install的大坑前端启动的步骤说起来很简单进入前端目录执行npm install安装依赖然后npm run dev启动开发服务器。但实际操作中npm install这一步能劝退很多人。最常见的坑是版本兼容问题。蜗牛兼职网如果用的是Vue CLI 4或5对Node版本有要求——Node版本过高或过低都可能装不上依赖。我的经验是先用node -v查看版本如果是Vue 2 Element UI的项目Node 14到16之间都比较稳定Vue 3项目建议Node 16以上。第二个坑是网络问题。npm install默认从官方源下载在国内总是很慢甚至失败。建议先配置淘宝镜像源代码改一行npm config set registry https://registry.npmmirror.com第三个坑是node-sass安装失败。这个包需要下载二进制文件在某些环境下会编译失败。最省事的解决方案是如果遇到node-sass相关报错检查安装的node-sass版本和Node版本是否匹配实在不行就换成dart-sasssass包对项目功能没有影响。实际上比较新的项目都已经不再用node-sass了直接用sass包更省心。依赖安装成功后npm run dev会启动一个开发服务器默认地址是http://localhost:8080。由于后端接口地址通常是http://localhost:8080或类似的端口前端需要通过Vue CLI的vue.config.js里的proxy配置把接口请求代理到后端地址解决跨域问题。6.4 演示环境下的浏览器测试清单项目跑起来之后先别急着截图写报告。按下面的顺序要点做一轮完整的冒烟测试用管理员账号登录后台确认能看到用户列表和兼职审核列表。退出后用注册的求职者账号浏览兼职大厅点击一条兼职详情并申请报名。退出后在个人中心查看报名记录确认状态正常。用企业账号登录SQL脚本里一般会有测试企业账号发布一条兼职再用管理员账号审核这条兼职审核通过后回到求职者端确认这条兼职能看到。这一套流程走下来相当于把系统的核心业务链路全部验证了一遍。任何一个环节出了问题在准备答辩PPT之前解决掉都来得及。7. 接口文档怎么用联调前的必读清单7.1 接口文档里到底写了什么接口文档是前后端开发者的合同。蜗牛兼职网的接口文档一般按照模块组织认证模块、兼职模块、申请模块、收藏模块、管理模块。每个接口条目包含五个要素请求URL、请求方法、请求参数、返回数据、状态码说明。举个例子获取兼职列表的接口很可能是这样的GET /api/job/list 参数 pageNum: 页码默认1 pageSize: 每页条数默认10 keyword: 搜索关键词可选 categoryId: 分类ID可选 sort: 排序方式默认latest可选salaryDesc 返回 code: 200 data: { total: 100, list: [...] }看接口文档要学会抓重点先看URL中区分了/api公共前缀这个前缀配合前端代理一起用再看参数哪些是可选的、哪些是必填的、分页参数怎么传最后看返回数据结构里data中是什么格式的对象。看不懂返回结构前端页面就会渲染出一堆undefined。7.2 Swagger与Postman/Apifox接口调试工具的选择如果项目的pom.xml里引入了springfox-swagger2或springdoc-openapi依赖启动后访问http://localhost:8080/swagger-ui.html就能看到可视化的接口列表每个接口可以点击展开查看参数并直接测试。这对理解和验证接口很有帮助。如果没有集成Swagger就用Apifox或Postman调试。Apifox在国产工具里算是很好用的直接导入后端导出的JSON格式接口文档就能生成一个可视化的接口列表。我习惯用Apifox的原因很简单它自带了环境变量功能可以配置多个后端环境切换调试环境时不需要修改接口URL。你还要记住一个重要的点接口文档里的接口参数类型和返回数据格式是前后端对接时的唯一标准。如果前端页面显示的数据对不上先看接口文档是返回字段名变了还是前端少了一个参数。来来回回撕扯的本质都是因为有一方没仔细看文档。7.3 联调时最常见的三类问题按我调试过的项目经验联调阶段的问题集中在三类。第一类是跨域问题。浏览器控制台报CORS policy错误通常是因为后端没有配置CORS或者前端代理没写对。解决方案也有两种后端加CrossOrigin注解或统一配置CorsFilter前端使用Vue CLI的proxy代理解决。我建议两者都做——开发阶段用前端代理部署阶段用后端CORS配置因为部署后前端是静态文件和后端不同域必须靠后端支持跨域。第二类是参数名对不上。后端接口定义的是pageNum前端传的是current结果就是获取不到分页数据。排查方法是在浏览器Network面板看实际发出的请求参数是什么再对比接口文档逐字核对。第三类是Token失效问题。前端403但什么都不显示。排查链路是看Network面板里有没有带上Authorization头部 - 看后端的Token过期时间配置 - 看登录接口返回的Token是否正确保存。三元一次方程解完基本就定位了。8. 调试过程中我踩过的坑完整的排查链路8.1 SpringBoot版本太高引发的依赖连锁问题以前我调试过一个毕设项目pom.xml里写的SpringBoot版本是3.x结果MyBatis-Plus、Swagger这些老牌依赖的版本跟不上启动时报了一大堆找不到类或方法签名不对的错误。这个问题的本质是SpringBoot 3基于Jakarta EE 9规范包名从javax.*改成了jakarta.*很多老库还没适配。如果你拿到的蜗牛兼职网源码在启动时频繁报错第一步就是检查SpringBoot版本——如果是3.x而项目里用了老版本的MyBatis-Plus3.5.3之前的版本大概率就是版本不兼容。解决方案不是去硬啃报错信息而是检查项目的pom.xml把版本回退到2.7.x系列然后改回用javax.*的依赖重新刷新Maven依赖再启动。这不是什么高深的技术纯粹是使用经验毕设项目追求的是稳定可运行追新带来的痛苦远大于收益。8.2 前端npm install反复失败的排查过程有一次我在一台新电脑上部署一个Vue 2项目npm install反复报ERR! code ELIFECYCLE卡在node-sass的安装步骤。我把报错信息贴到搜索引擎上一查发现是Node版本是18但项目里的node-sass是4.x两者根本不兼容。排查链路是这样的先看报错日志末尾提示的包名确认是node-sass然后查package.json里node-sass的版本最后对照node-sass官方兼容表确认哪个Node版本能适配。最终解决方式是用nvm把Node切到14版本然后重新删除node_modules和package-lock.json再执行npm install。如果你不想切换Node版本还有一个思路把package.json里的node-sass改成sass因为dart-sass对Node版本的兼容性要好很多。但注意两者在部分Api上略有差异个别样式写法可能不兼容需要测一下。对兼职网这种后台管理项目来说一般没有复杂样式逻辑替换风险很小。8.3 跨域问题的定位思路先从Network看起跨域问题几乎每个前后端分离项目都会遇到。报错长这样Access to XMLHttpRequest at http://localhost:8080/api/... from origin http://localhost:5173 has been blocked by CORS policy。看完报错的第一个反应不应该是去搜代码而是打开浏览器Network面板看请求的状态。如果请求根本没有发出去Network里看不到这条请求问题在前端如果请求发出去了但被拦截问题在后端——后端没有返回Access-Control-Allow-Origin响应头。蜗牛兼职网解决跨域的方式一般是在后端写一个CorsConfig配置类对所有请求允许跨域。如果你不确定后端有没有配置最简单的验证方式是直接在Controller上临时加一个CrossOrigin注解看跨域报错是否消失。消失就说明全局配置没生效检查配置类是否被SpringBoot扫描到不消失那就不是跨域配置的问题要重新审视是哪个环节报的错。这种从现象倒推、逐步缩小排查范围的方法才是真实的调试思路。8.4 前端打包后布局异常dev环境与生产环境的差异还有一个很邪门的问题本地开发环境一切正常npm run build打包后放到服务器上布局全乱了。这类问题在Vue Element UI项目中比较常见根源通常是打包后的静态资源路径有问题或者CSS样式加载顺序变了。定位思路先看控制台有没有404的CSS或JS请求。如果有说明vue.config.js里的publicPath配置不对打包后静态资源默认路径是/服务器根路径如果部署在子目录下就得改成./相对路径或者实际的子目录路径。如果没有404页面能加载但样式乱套大概率是CSS代码冲突或顺序问题——某些全局样式覆盖了Element UI组件的样式。排查方法有笨办法也有巧办法笨办法是在控制台挨个元素看计算样式巧办法是把全局样式文件的后缀从.css改为.scss用::v-deep或:deep包装组件内部样式覆盖避免污染全局。我在接手任何一套毕设项目时都会先跑一遍npm run build确保打包环节不报错。这个习惯帮我避开了很多答辩前夜的惊喜。最后再分享一个实际的体会。我在调试蜗牛兼职网这样的项目时最大的感受是很多人拿到源码第一反应是赶紧启动看看但我建议你先花两个小时把数据库表结构和接口文档从头到尾过一遍。这看起来是耽误时间实际上是在给自己建立整个项目的认知地图——你知道了数据从哪里来、最终流向哪里后面不管遇到什么Bug都能在几分钟内定位到问题所在的端到端。这个习惯不管是在做毕设还是以后到公司里接手别人的老项目都同样适用。
返回列表