Spring Boot + Vue 客户关系管理系统毕设开发全攻略

发布时间:2026/9/20 14:03:23
Spring Boot + Vue 客户关系管理系统毕设开发全攻略 简介这是一份面向计算机相关专业毕业设计或课程项目的完整论文文档主题为基于SpringBoot、Vue.js与MySQL的客户关系管理系统CRM的设计与实现适合需要参考SSM框架与前后端分离项目开发、撰写论文或准备答辩的本科及专科学生使用。资源包内包含1个doc格式的毕业论文全文压缩包大小约1.43MB内容涵盖项目背景、技术选型、系统功能设计、数据库构建与安全方案并附有摘要、目录及章节安排可直接作为论文结构与写作参考。文档从企业内部客户管理痛点出发详细阐述了字典管理、客户管理、客户积分、线索跟踪、员工权限等核心模块的实现思路同时兼顾了界面设计与数据安全问题能够帮助读者快速理解CRM系统的整体开发流程。当前已有75人学习下载对于需要快速梳理同类课题框架的学习者具有较高的实用价值。 Spring Boot Vue 的客户关系管理系统这个选题在毕业设计里可以说是常青树了。每年都有大量计算机专业的学生选它原因很简单业务模型不复杂但技术链路完整从前端交互到后端接口再到数据库设计都能覆盖到。但我见过不少同学卡在同一个地方——搜资料时搜java.js以为是一个具体技术结果越搜越乱。这里先澄清一点标题里的 java.js 其实是Java 后端 JavaScript 前端Vue的组合表述并不是某个叫 java.js 的框架。把这个搞清楚之后项目的整个轮廓就清晰了。这篇文章我会从选题定位、技术选型、数据库设计、环境搭建、常见坑点这几个维度展开把一套可以直接复用的毕设开发思路完整讲一遍。无论你是刚开始做开题报告还是已经写了一半代码卡在某个问题上这篇文章都值得参考。1. 为什么CRM系统是毕业设计的优质选题先看清题目在考察什么很多人觉得CRM客户管理系统太常见了担心答辩时没亮点。这个担心可以放下因为毕业设计的评分逻辑和企业项目完全不同。企业看的是业务复杂度和商业价值而毕设考察的是你有没有完整走通需求分析 → 数据库建模 → 后端接口 → 前端页面 → 部署演示这条全流程链路。CRM恰好能自然地覆盖所有这些环节。从需求层面看CRM系统的核心业务足够清晰客户信息管理、跟进记录、订单/商机管理、统计分析。这些功能不需要多高深的理论但每个模块都能延伸出值得展开的设计点。比如客户列表的批量导入导出怎么实现、跟进记录时间线怎么展示、销售数据图表在前端怎么渲染这些细节在文档和答辩演示里都能变成你的加分项。从工作量角度看CRM属于中等体量项目对个人开发者来说非常友好。你不需要像做电商系统那样处理复杂的库存和支付逻辑也不用像做后台管理系统那样堆大量重复的CRUD。它的模块数量控制在六到十个之间每张业务表的字段也不复杂非常适合作为毕设的项目载体。而设计这两个字在题目里的权重也值得注意——它考察的不只是会调框架还包括表结构设计是否规范、接口是否Restful风格、权限设计是否合理这些到答辩时都是老师爱问的地方。2. Spring Boot Vue 技术栈选型的逻辑不选最火的选最容易讲清楚的现在做 Java 毕设技术栈基本就是 Spring Boot Vue 一统天下。早几年还有人在 JSP Servlet 和 Spring Boot 之间纠结现在基本不用纠结了因为 Spring Boot 极大的简化了后端搭建流程而 Vue 的前后端分离模式也符合当前主流的开发习惯。2.1 后端为什么选 Spring Boot 而不是 SSMSSMSpring SpringMVC MyBatis当然也能做但如果你是拿它当毕设的话需要手动配置的东西太多——XML配置文件、web.xml、DispatcherServlet 映射这些配置对新手并不友好而且出了问题排查成本也高。Spring Boot 把这些都自动化和约定化了内嵌 Tomcat一键启动这在展示和答辩时会节省大量时间。如果你的项目用了 MyBatis-Plus那效率还能再往上提一截。MyBatis-Plus 内置了通用的增删改查方法单表操作基本不用写 SQL这对业务逻辑相对简单的CRM来说非常合适能把精力集中在更复杂的模块上。也有同学在纠结要不要用 Spring Cloud这里我给出明确的建议毕设千万别上微服务一个单机应用拆成多个服务不仅部署麻烦答辩时老师追问分布式事务、服务治理很容易把自己问住。2.2 前后端分离时前端的环境与依赖管理Vue 前端项目的核心是 Node.js 环境。很多同学第一次照着网上的教程安装 Vue 环境时容易把 Vue CLI 和 Vite 混在一起导致创建项目后启动报错。这里建议直接用 Vite 创建 Vue 3 项目命令是npm create vuelatest或npm create vitelatest然后按提示选择 Vue 和 Router。Vue 3 配合 Vite 的启动速度明显快于 Webpack 方案开发体验会好很多。创建项目之后npm install安装依赖npm run dev启动开发服务器。如果你的 Node.js 版本过低会直接报You are using Node.js x.x.x的版本错误而如果 node_modules 安装不完全则会出现组件找不到、路由不生效的怪问题。遇到这些问题不要急着删项目重来先执行npm install或者把package-lock.json和node_modules删掉重新安装大部分依赖问题都能解决。2.3 分层架构面试和答辩会被问到的核心点CRM 项目的后端代码建议严格遵循 Controller → Service → Mapper 三层结构这既是毕设文档里系统设计章节的重要插图素材也是代码规范的基本盘。Controller 只负责接收请求和参数校验Service 层写业务逻辑Mapper 层对接数据库。这样分层的好处是如果答辩时老师问这个查询逻辑改一下哪里动刀你能清楚地指出改 Service 层即可接口和前端不用动。前端也建议做一层组件化拆分比如把客户表格、跟进记录时间线、统计图表分别封装成独立组件通过 props 传参和 emit 触发事件来实现父子通信。这种设计思路在论文的系统实现章节里非常有的写因为你能展示的不只是页面截图还有组件复用的设计思路。3. 核心功能模块与数据库设计把表结构设计对了后面能省一半事CRM 系统最容易犯的错误是只做了一张客户表就开写。这种系统的数据间是有业务逻辑关联的如果不在建表阶段把这层关系理清楚后面做跟进记录、做数据统计的时候会被迫反复改表结构非常痛苦。我在带项目时通常建议先画出功能脑图再对着脑图思考实体关系和字段设计。3.1 CRM 系统的核心业务实体一个能拿得出手的CRM系统至少要包含以下实体系统用户管理者、销售员等不同角色客户信息公司名、联系人、电话、地址、跟进状态等跟进记录每次联系客户的时间、方式、沟通内容、下次跟进时间商机/合同可选模块含成交金额、成交时间用于统计业绩数据统计报表通过ECharts展示客户来源分布、销售业绩趋势从用户表到客户表再到跟进记录表这是一条典型的一对多关系链一个用户可以管理多个客户一个客户可以有多条跟进记录。用外键关联在理论上是合理的但在实际开发中如果字段也没做索引数据量一上来连表查询会变得很慢。对毕设而言逻辑外键不建数据库外键约束只在字段层面对应 id更推荐——既保留了业务关联又避免了外键约束带来的增删改麻烦。3.2 客户表字段设计样例与理由客户表通常命名为customer我建议至少包含以下字段id主键自增customer_name客户公司名contact_name联系人contact_phone联系方式level客户等级高/中/低用于销售筛选status跟进状态未联系/跟进中/已成交/已流失source客户来源广告/转介绍/展会/网络remark备注create_time、update_time这里的level和status建议直接用数字类型如0、1、2然后在代码里通过枚举或常量类做映射。这样做的好处是前端拿到的是数字展示时再翻译成对应文案方便做筛选和图表统计也方便后续扩展更多状态。3.3 跟进记录与统计报表的数据通路跟进记录表follow_record是CRM系统里最能体现业务深度的表字段可以这样设计id、customer_id关联客户、user_id跟进人、follow_type跟进方式电话/拜访/微信/邮件、content跟进内容、next_time下次跟进时间、create_time。这张表建好之后前端就能做一个客户时间线页面按时间倒序展示这个客户的所有跟进历史这个功能在答辩演示时视觉效果好实现成本也不高。报表模块则依赖统计 SQL 来聚合数据。比如统计每个月的成交金额就是SELECT date_format(create_time, %Y-%m) AS month, SUM(amount) FROM contract GROUP BY month。像这类代码提前写好后在文档里附上SQL说明论文的系统测试章节就有活生生的例子了。不用为了图表功能去引入太重的中间件后端查出数据给到前端前端用 ECharts 的折线图、饼图渲染即可。4. 从零搭建项目的实操流程与环境配置细节这一节专门写给对环境配置没有信心的读者。热搜词里关于环境配置的搜索一直居高不下因为这一步确实卡掉了很多人。其实整体流程就是装 JDK、装 Maven、装 MySQL、装 Node.js然后创建前后端两个项目最后把前后端连接起来。每一步都有章可循。4.1 后端环境JDK 与 Maven 版本匹配JDK 推荐使用 1.8 或者 11这也是很多学校的实验环境标配。如果你用的是 JDK 17 及以上要注意 Spring Boot 的版本不能选择 2.x 的旧版本需要换成 Spring Boot 3.x否则启动时会报错。这个细节很多人是在报错之后才发现的提前了解能省去一些时间。Maven 的安装核心是配置settings.xml里的阿里云镜像仓库否则下载依赖会非常慢。装好后在 IDEA 的 Settings 里把 Maven 指向你的本地安装目录并且确认 JDK 版本选了正确的 SDK不然 IDEA 默认的 JBR 会和 jdk 版本不匹配导致编译失败。提示环境变量配置完成后在命令行输入java -version和mvn -v能正常输出版本信息说明后端环境已经就绪。Spring Boot 项目可以通过 IDEA 内置的 Spring Initializr 创建也可以直接去官网下载压缩包导入。选择依赖时勾选 Spring Web、MyBatis Framework、MySQL Driver后续根据功能需要再加其他依赖即可。4.2 前端环境Node.js 与 Vue 项目创建前端环境的核心是 Node.js。安装完成后命令行执行node -v和npm -v能输出版本号就说明 Node 环境没问题。然后全局安装淘宝镜像的 npm 源npm config set registry https://registry.npmmirror.com这一步对国内开发者来说几乎是必须的不然下载依赖的时候会等到怀疑人生。创建 Vue 项目时如果对配置不熟悉推荐一路选择默认预设。项目创建后目录结构大致包括src/views页面文件、src/router路由配置、src/components公共组件、src/api接口请求封装。建议把 axios 实例统一封装在src/utils/request.js里统一配置baseURL和请求拦截器自动携带 token这样在后面接入登录功能时会顺手很多。4.3 前后端联调跨域问题与接口规范前后端分离开发时本地联调最常见的报错就是跨域。前端跑在 5173 端口后端跑在 8080 端口默认情况下浏览器会拦截跨端口请求。解决办法在后端加一个配置类实现WebMvcConfigurer接口重写addCorsMappings设置允许所有来源即可。更规范的做法是在前端配置 Vite 的代理server.proxy把/api开头的请求转发到后端地址这样既能避免跨域也能在部署时灵活切换接口地址。接口设计建议统一前缀用户相关的/api/user、客户相关/api/customer、跟进记录/api/follow、统计报表/api/stats后端 Controller 的 RequestMapping 与之一一对应。规范接口路径带来的好处不只是代码整洁而是 debug 的时候能快速定位——报错看路径就知道是哪个模块的问题。5. 毕设开发过程中最常踩的坑与完整排查链路说实话毕设项目本身功能不多复杂度也不高大部分时间都是耗在这些零散的报错上。下面把这几年见过最多的问题集中讲一遍每个都给到排查思路而不是直接给结论这样你再遇到相似问题的时候自己也能沿着这个思路找到原因。5.1 启动Tomcat报错找不到主类的排查过程这个报错在 Spring Boot 项目里太经典了。顺着报错信息往下看如果你看到Error: Could not find or load main class xxxApplication先不要怀疑代码写错了大概率是 IDEA 编译输出路径或者缓存出了问题。我的排查步骤是第一步确认启动类上有SpringBootApplication注解且位于所有包的最外层第二步IDEA 菜单执行Build → Rebuild Project强制全量编译第三步如果还不行执行File → Invalidate Caches / Restart清掉 IDEA 缓存后重启。按这个顺序排查十次里有九次能在第二步解决问题根本不用重写代码。提示如果在命令行执行mvn spring-boot:run能正常启动但 IDEA 里启动不了问题基本就锁死在 IDEA 的编译链路上按上面的步骤走一定没错。5.2 前端页面空白且控制台报404的排查链路页面空白的问题通常不是页面代码写错了而是路由没有匹配到组件。Vue 3 项目里如果刷新某个二级路由页面出现404多半是没配history模式下的 fallback而如果首次访问就空白检查src/main.js是否正确注册了路由和 pinia/store。还有一个很容易被忽略的细节Vue 文件里的template下必须只有一个根节点如果你复制代码时不小心在 template 下写了两个同级 divVue 编译器不会给你过于明确的报错只会导致整个组件渲染失败。这种问题的排查方式是打开浏览器 DevTools 的 Console 面板任何红色的警告都会有具体文件地址顺着看就能定位到。5.3 MyBatis-Plus 查询结果为 null 的排查链路后端接口启动了数据表里也有数据但接口查出来全是 null。这个问题在 MyBatis-Plus 场景下有个高频触发点数据库表字段使用了snake_case下划线命名但实体类字段用的camelCase驼峰命名而全局配置没有开启map-underscore-to-camel-case。Spring Boot 2.x 中 MyBatis-Plus 默认是开启这个映射的但如果你手动配置了mybatis-plus.configuration相关属性某些版本会覆盖默认行为。排查时先用 SQL 语句直接在数据库客户端执行一遍确定 SQL 本身没问题再到控制台开 SQL 输出日志检查 MyBatis 实际执行的语句最后检查实体类字段和表字段的命名映射。按照这个链路排查完原因基本就自动浮出来了。5.4 登录模块 JWT 的明明登录了却一直被拦截问题登录状态管理是CRM系统必不可少的模块JWT 是毕设文档里很常见的实现方案。但几乎每个人都会遇到一个问题登录接口成功返回了 token但后面访问客户列表依然被拦截。问题出在前后端对 token 的传递约定上。后端拦截器通常从请求头Authorization里取 token但前端如果只把 token 存在了 localStorage却没有在 axios 请求拦截器里把 token 加进请求头那后端当然拿不到登录凭证。排查链路是先在浏览器 DevTools → Network 里看请求头是否带上了 token没有的话检查request.js里的拦截器代码有的话再用 Postman 手动带 token 请求一次接口后端能通就说明问题在前端后端能查的就是拦截器的放行路径配置。5.5 时间日期格式不对导致的前端显示NaN问题时间字段是数据和前端交互时最容易埋雷的地方。Java 后端返回的 LocalDateTime 默认格式是2024-06-01T12:30:00中间带个T前端 new Date() 解析时在部分浏览器里会解析成 Invalid Date然后页面就显示 NaN。解决办法是在后端配置全局的 JSON 序列化格式统一为yyyy-MM-dd HH:mm:ss。Spring Boot 中可以在application.yml里配置spring.jackson.date-format或者为 LocalDateTime 类型注册一个全局的 Jackson 自定义序列化器两种方式都可行。这个坑属于不遇到一次根本想不到的类型提前配置好能省下不少排查时间。5.6 逻辑删除与统计数据的关联坑如果你的系统使用了 MyBatis-Plus 的逻辑删除功能有一个地方要特别留意所有查询和统计 SQLMyBatis-Plus 会自动拼接WHERE deleted 0。这意味着统计成交金额、客户数量的时候接口立刻就能正确排除已删除的数据这当然是好事。但如果你在图报表里用了自定义 SQL 而不是 MyBatis-Plus 的 Wrapper逻辑删除的条件就不会自动带上去导致统计结果把已删除的客户也算进去了。排查这种问题时把控制台打印的 SQL 复制到数据库客户端执行对比一下手工执行结果和接口返回结果差异一目了然。所以建议公司/项目里凡是涉及自定义 SQL 的统计查询都要手动带上deleted 0条件别想着靠框架兜底。6. 论文文档写作代码之外的同样重要环节标题里带有毕业论文.doc说明这个项目的交付物不只有能跑的系统还有一篇完整的论文。很多学生代码写得热血沸腾一到写文档就抓瞎。这里分享几个实操性很强的建议。论文结构上通常分为绪论背景与意义、相关技术介绍Spring Boot、Vue、MySQL、系统分析需求分析、可行性分析、系统设计架构设计、功能设计、数据库设计、系统实现核心功能页面与代码展示、系统测试测试用例与结果。这块内容每个模块都有固定的写作模板可以套但要注意别只贴代码不解释老师更想看到的是为什么这么做。数据库设计章节建议用表格列出每张表的核心字段并解释字段类型选择的理由比如客户状态用 tinyint 不用 varchar 是因为状态可枚举且用数字做统计更方便。系统测试章节不要只写测试通过尽量设计几条有业务逻辑的测试用例比如新增客户后能在列表页正常显示且统计数量1删除客户后跟进记录同步逻辑正确处理等这样的测试描述比空泛的结论有说服力得多。7. 给你的时间规划与最后一点经验分享这套CRM系统如果每天能投入三到四个小时三到四周是能做完的。第一周做需求和数据库设计第二周搭后端接口第三周写前端页面并联调第四周整理文档和测试。关键是把每阶段的目标拆小尽量避免再玩一天明天猛写的节奏因为前后端联调阶段非常需要上下文连续性断个两三天再捡起来光找回思路就要花半天。我个人带过不少用这个题目的学生一个很真实的感受是最后答辩效果好的往往不是功能做得最多的而是每一步都能说清楚为什么的学生。所以在你生成项目的过程中每做一步都多想一下——这里为什么用枚举存状态而不是字符串为什么接口返回统一用 Result 对象包装为什么数据库不加物理外键把这些理由随手记下来后面写文档和准备答辩时你会感谢自己当时的这个习惯。另外一个小建议项目启动阶段就顺手建一个 README 文档把启动步骤、测试账号、功能清单写清楚。这个文档不仅是你写论文时系统运行环境章节的一手素材也是失误重置数据库后快速恢复环境的保命符。毕竟毕设这种东西做到后期最怕的不是代码跑不通而是你自己都忘了之前是怎么把它跑起来的。本文还有配套的精品资源点击获取