SpringBoot+Vue+MySQL企业客户管理系统毕业设计全流程实践

好的，我理解了。这篇博文将以真实从业者分享个人毕业设计经验的口吻，围绕“SpringBoot+Vue+MySQL企业客户管理系统”从选题思路、技术选型、系统设计、核心模块实现到部署答辩全程展开。以下是完整博文。

1. 项目概述与选题背景

1.1 为什么选企业客户管理系统

做毕业设计的时候，很多同学第一反应是做个商城、做个博客、做个点餐小程序，我一开始也这么想过。但后来真正动手之前，我认真权衡了一下：毕设这东西，不只是用来“过关”的，它其实是找工作时候最能拿得出手的一个完整项目。企业客户管理系统（Customer Relationship Management，也就是常说的CRM系统）属于典型的企业级信息管理系统，这类系统的优势非常明显：业务流程清晰、模块边界分明、技术栈覆盖面广、可扩展空间大，特别适合用来展示一个应届生的全栈开发能力。

你在简历上写“我做了一个商城”，面试官大概率会追问“秒杀怎么实现”“库存怎么防止超卖”“支付回调怎么保证幂等”，这些对于没有真实生产经验的应届生来说，很容易被问穿。但如果你写“我做了一套企业客户管理系统，包含客户全生命周期管理、商机跟进、数据可视化和权限控制”，面试官的第一反应通常是你对企业业务有认知，而不是单纯会CRUD。

这套系统我前前后后花了两三个月，从选题、设计、编码到部署、写论文、准备答辩，踩了不少坑，也总结了不少经验。这篇博客就把整个从0到1的过程完整记录下来，包括为什么选SpringBoot+Vue+MySQL这套组合、数据库表怎么设计才合理、核心业务流程怎么落地、部署文档怎么一步步写清楚，希望能给正在做同类题目或者正准备开题的同学提供一份能直接参考的实操方案。

1.2 这套系统的核心价值

先说说这套企业客户管理系统到底做了什么。简单来说，它就是解决一个很实际的问题：企业销售团队如何管好手里的客户资源、跟进记录、商机阶段和合同回款。

传统的Excel管理模式存在几个明显的痛点：客户资料分散在销售的私人电脑里，离职就带走；跟进记录靠聊天记录和邮件，完全没沉淀；领导想看团队业绩，只能一个个问，效率极低。这套系统要做的，就是把客户信息、跟进动态、商机推进和统计分析全部线上化、流程化、可视化。

从技术角度来说，这个项目覆盖了以下核心知识点：

• 后端基于SpringBoot 2.7，整合MyBatis-Plus做数据持久层，Spring Security + JWT做认证授权
• 前端采用Vue 2 + Element-UI，配合Axios做接口请求，ECharts做数据可视化
• 数据库使用MySQL 8.0，核心业务表设计、索引优化、事务处理都在项目中具体落地
• 支持多角色权限体系：管理员、销售主管、普通销售，不同角色看到的数据和可执行的操作不同

从求职角度来说，这套系统足够你在简历上写三条项目经历：客户管理模块、商机跟进模块、数据统计看板。而且每个模块都有比较明确的业务复杂度，完全不是只拿框架demo来糊弄。

2. 技术选型的逻辑与避坑

2.1 为什么是SpringBoot+Vue+MySQL

技术选型不能只看哪个火选哪个，要看它能体现你的什么能力。我选这套组合的理由有三个。

第一，SpringBoot是目前企业级Java后端的事实标准。它解决了传统SSM框架的大量配置问题，内置Tomcat，起步依赖一键引入，开发体验和对新手的友好程度都很好。更重要的是，市面上大多数中小企业的业务系统就是SpringBoot做后端，学完能直接迁移到工作中。

第二，前后端分离是当前主流的开发模式。Vue负责渲染和数据交互，SpringBoot只提供JSON接口，两边通过HTTP通信。这样做的好处是职责清晰、并行开发效率高，而且能直接作为简历上“前后端分离项目”的例证。

第三，MySQL作为关系型数据库，对于客户、订单这种强事务、强一致性的业务场景是最合适的。虽然现在NoSQL很热，但CRM系统这类业务核心就是结构化数据和复杂查询，MySQL配合合理索引和事务机制，完全能扛住毕设这个量级的需求，而且面试被问到数据库优化的时候可讲的东西也足够多。

2.2 版本选择与参数踩坑

直接说版本，这是我踩了坑之后的结论，帮助大家少走弯路：

这几个版本看上去不是最新的，但绝对是最稳的组合。我做毕设的时候一开始后端用了SpringBoot 3.0，结果很多第三方库还没适配，报错都找不到资料，浪费了整整两天。后来老老实实退回2.7，一切顺畅。

2.3 数据库选型与连接参数

MySQL 8.0和5.7在毕业设计里都是一个量级的选择。但如果用MySQL 8.0，连接串一定要特别注意时区问题。我第一次连数据库的时候，项目启动报错“The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized”，就是因为时区没设置。

正确的JDBC连接串写法是：

spring.datasource.url=jdbc:mysql://localhost:3306/crm_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true spring.datasource.username=root spring.datasource.password=你的密码 spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

allowPublicKeyRetrieval=true这个参数是我后来处理8.0公钥检索问题的时候加上的。对于本地开发环境来说，这个参数是必要的，不加的话有时会报Authentication plugin错误。

3. 系统整体架构与设计思路

3.1 功能模块划分

整套系统我按照“客户全生命周期管理”的思路来拆模块。一个客户从线索进入系统，到成为正式客户、建立联系、推进商机、签单回款，每个环节都要有对应的功能支撑。

核心功能模块图是这样的（用文字描述结构）：

• 系统管理：用户管理、角色管理、菜单权限、操作日志
• 客户管理：客户信息登记、客户分配、公海客户池、客户转移
• 跟进记录：跟进计划、跟进记录列表、跟进提醒
• 商机管理：商机阶段（初步接触、需求确认、方案报价、谈判、赢单/输单）
• 合同管理：合同创建、合同审批、回款记录
• 统计分析：客户来源统计、商机转化漏斗图、销售业绩排行、跟进频率热力图

3.2 关系型数据库设计要点

先聊聊数据库设计。做这种系统，最重要的就是把客户、联系人、跟进记录、商机这些实体之间的关系理清楚。我最终设计出的核心表结构包括11张表，下面重点讲几张大表的设计思路。

第一张是客户表，字段包括客户名称、客户编号、所属行业、客户规模、来源渠道、客户等级（A/B/C）、负责人ID（可以为空，表示未分配）、创建时间和更新时间。核心的索引建在负责人ID和客户等级上，因为系统里“查我名下的客户”“查A级客户”是最高频的查询。

第二张是跟进记录表，字段包括客户ID、跟进人ID、跟进方式（电话/拜访/邮件/微信）、跟进内容、下次跟进时间。这里有个细节：跟进内容必然要用text类型，因为客户沟通的内容可能很长，用varchar(255)根本不够用。另外，每次查询“某个客户最近的跟进记录”都非常频繁，所以客户ID+跟进时间的联合索引是必须的。

第三张是商机表，字段包括商机名称、关联客户ID、预计金额、销售阶段、赢单概率、预计成交日期、负责人ID。商机表和客户表是多对一的关系，一个客户可以同时有多个商机在推进，这是完全正常的业务情况。赢单概率是跟着阶段走的，比如初步接触阶段概率10%，方案报价阶段概率40%，谈判阶段概率70%，这也是后面做漏斗分析的数据基础。

有一张表我建议一定要设计，就是公海客户池。它的逻辑是这样的：新增的客户可以先进公海，销售主管再把公海里的客户分配给具体的销售；同时，如果销售手上有超过30天没有跟进的客户，系统自动把客户释放回公海，让其他同事有机会接手。这个功能虽然加了一点开发量，但它是这个项目的亮点之一，面试聊到这个的时候很容易出彩，因为体现的是业务思考，而不是单纯的CRUD。

3.3 前后端交互与接口设计

接口设计我统一采用RESTful风格，返回结构用统一的JSON格式：

{ "code": 200, "message": "操作成功", "data": { } }

前端在Axios拦截器里统一处理后端返回的code，如果code是401就自动跳转到登录页，如果code是500就弹出错误提示。这样前后端联调的时候思路极其清晰，不需要每个接口单独写错误处理。

接口设计还有一个很重要的原则：分页查询的接口统一使用POST而不是GET。原因很简单，查询条件多了之后，用GET方式传参会把URL搞得很长，而且数组类型的参数处理很麻烦。全部用POST+JSON body传参，前端后端都清爽。

4. 核心模块实现与代码解析

4.1 JWT认证与权限控制

权限控制这块，我采用的是Spring Security + JWT的方案。为什么要用这个组合？因为如果每个请求都带上后端Session，跨域和前后端分离的场景会很麻烦。JWT把用户身份信息加密放在Token里，服务端不存Session，天然支持横向扩展。

JWT的主要工作流程：

1. 用户输入账号密码，后端校验通过后生成Token，有效期设置为2小时
2. Token中包含用户ID、用户名、角色编码
3. 前端把Token存在localStorage，每个请求在Axios拦截器里自动带上Authorization头
4. 后端写一个JWT过滤器，解析Token并把用户信息放入请求上下文
5. 在Spring Security配置里对接口做角色控制

核心配置代码逻辑：

http.csrf().disable() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeRequests() .antMatchers("/api/auth/login", "/api/auth/register").permitAll() .antMatchers("/api/admin/**").hasRole("ADMIN") .antMatchers("/api/employee/**").hasAnyRole("ADMIN", "MANAGER", "SALE") .anyRequest().authenticated();

这里有一个血泪教训：Spring Security的配置很容易踩坑，特别是放行接口的顺序。antMatchers的规则写错了，后面的会被前面的覆盖，导致某些接口永远要登录才能访问。当时我调试了好久，最后才发现把permitAll写在了authenticated的后面，接口永远被拦截。所以写权限配置的时候，放行的规则一定要写在拦截规则前面。

密码加密用的是BCryptPasswordEncoder，这是Spring Security自带的安全加密算法。明文密码绝对不能存数据库，这一点不用多说，是基本的安全底线。

4.2 客户分配的并发控制

客户分配这个功能表面上很简单：管理员把一个公海客户指派给某个销售，就是更新客户表的负责人ID字段。但是，如果两个管理员同时把同一个公海客户分配给了不同的人，数据就出问题了。

这个场景里我必须用乐观锁来解决。具体做法是在客户表增加一个version字段，更新的时候带上版本号，SQL语句是：

UPDATE customer SET owner_id = #{newOwnerId}, version = version + 1 WHERE id = #{customerId} AND version = #{oldVersion}

如果更新的影响行数为0，说明版本号已经变了，有其他请求抢先修改了这条数据，后端就返回错误提示“该客户已被其他管理员分配，请刷新后重试”。

虽然MySQL在高并发下的实际并发写量很小，但写这套逻辑体现的是对数据一致性的思考。面试的时候如果面试官问“怎么解决并发分配客户的问题”，直接讲这个乐观锁方案，基本上是加分项。

4.3 商业机会漏斗统计的实现

统计模块我做了商机转化漏斗图。这个功能的实现逻辑是：按商机阶段分组，统计每个阶段有多少商机、总金额是多少。核心SQL语句大概是：

SELECT stage, COUNT(*) as count, SUM(expected_amount) as total_amount FROM business_opportunity WHERE deleted = 0 GROUP BY stage ORDER BY FIELD(stage, '初步接触', '需求确认', '方案报价', '谈判', '赢单');

这里用到了MySQL的FIELD函数，可以按照自定义顺序排列分组结果，保证漏斗图从上到下的顺序是固定的。

前端ECharts的漏斗图配置只要提供数据就行：

const chart = echarts.init(document.getElementById('funnelChart')); chart.setOption({ series: [{ type: 'funnel', data: funnelData }] });

这个模块虽然代码量不大，但视觉效果很好，放在论文的截图里和答辩PPT里都非常能打。

4.4 公海客户自动回收的定时任务

公海客户自动回收功能，我用的是SpringBoot自带的@Scheduled定时任务。每天凌晨执行一次，扫描所有负责人ID不为空且最近跟进时间超过30天的客户，把负责人ID置空并记录一条操作日志。

定时任务的配置很简单：

@Scheduled(cron = "0 0 2 * * ?") public void releaseExpiredCustomers() { // 查询所有超过30天未跟进的客户 // 批量更新负责人ID为空 // 写入操作日志 }

cron表达式表示的是每天凌晨2点执行。选凌晨执行是因为这个时间点系统负载最低，不会影响正常业务。这个功能不仅仅是功能点，它还是论文里“系统设计”章节一个很不错的业务亮点。

5. 前端页面设计与实现过程

5.1 项目初始化和路由设计

前端项目用Vue CLI创建，然后安装Element-UI、Axios、Vue Router、ECharts这几个核心依赖。模块化开发是必须用的，最核心的是公共组件和页面的拆分。

路由设计遵循嵌套路由的方式：

• / 登录页
• /layout 主页框架（包含侧边栏、顶部栏、内容区）
  • /layout/dashboard 仪表盘
  • /layout/customer 客户管理
  • /layout/follow-up 跟进管理
  • /layout/opportunity 商机管理
  • /layout/contract 合同管理
  • /layout/statistics 统计分析
  • /layout/system/user 用户管理
  • /layout/system/role 角色管理

路由守卫是必须要写的，以下是最核心的登录拦截逻辑：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); if (to.path === '/login') { next(); } else { if (!token) { next('/login'); } else { next(); } } });

5.2 客户管理页面的实现

客户管理页面是系统工作量最大的一块。页面顶部是筛选条件区，包括客户名称关键词、所属行业、客户等级、负责人；中间是操作按钮区，包括新增客户、批量导入、导出Excel、释放到公海；下面是数据表格，用分页组件展示。

表格的关键列包括：客户编号、客户名称、所属行业、等级、负责人、最近跟进时间、创建时间、操作按钮。最近跟进时间是从跟进记录表关联查询出来的，这在列表查询里是个性能点。我的解决方案是给客户表加一个recent_follow_time字段，每次新增跟进记录的时候同步更新这个字段。这是典型的空间换时间，查询列表的时候就不需要再去关联子查询了。

5.3 数据可视化大屏

数据可视化做的是一个仪表盘页面，放了四类图表：

• 漏斗图：商机转化漏斗、展示各阶段数量
• 柱状图：本月销售业绩排行Top10
• 饼图：客户来源渠道分析
• 折线图：近6个月新增客户趋势

ECharts接入的流程很标准，在组件里引echarts，在mounted钩子里初始化图表，数据从接口拿，拿到数据后setOption。唯一需要注意的地方是：如果页面上有多个图表，切换路由时一定要记得销毁图表实例，否则会报“There is a chart instance already initialized on the dom”的警告。处理方式是在beforeDestroy钩子里调用chart.dispose()。

6. 部署过程和数据库初始化

6.1 本地打包和部署流程

部署这块，毕设的要求一般是能在线演示或者给老师看效果。我采用的是本地打包 + 远程服务器部署的方案。

前端打包命令：

npm run build

打包完成后，在dist目录下会生成一堆静态文件。我需要把这些文件里的接口地址改成服务器的实际地址。这个工作最好在开发的时候就通过环境变量配置，打包时自动注入。

后端打包命令：

mvn clean package -DskipTests

打出来的jar包直接放在服务器指定目录，用nohup命令后台启动：

nohup java -jar crm-system.jar --spring.profiles.active=prod > run.log 2>&1 &

启动完成后，用curl检查服务是否正常：

curl http://localhost:8080/api/auth/login

6.2 数据库脚本的编写

数据库脚本是整个项目交付中的关键部分。我写了一个init.sql文件，里面包含建库建表语句、初始数据、索引创建语句。初始数据里我塞了一些真实感比较强的演示数据，比如20个客户、50条跟进记录、10条商机记录，这样老师打开系统的时候不会是一个空壳子，演示效果也更好看。

如果和我一样用MySQL 8.0，建表语句里加上utf8mb4字符集，这样存emoji表情不会乱码。索引的命名规范建议统一用idx_前缀，主键统一用id，时间字段统一叫create_time和update_time，这个命名规范能直接复制到论文的数据库设计章节。

7. 论文撰写的结构与心得

7.1 论文的章节安排

毕设论文的结构一般学校会有模板，但大体是固定的。我的论文分成了六章，这六章的顺序基本是行业通用的：

第一章是绪论，写选题背景、国内外的研究现状、研究内容和目标。这一章的难点在于研究现状一定要引几篇真实的文献，用知网搜索“CRM系统”和“客户关系管理”能搜到一大堆。

第二章是需求分析。按照功能性需求和非功能性需求来写，功能性需求用用例图来描述系统的角色和功能，非功能性需求写性能、安全、易用性方面的要求。

第三章是系统设计。这一章包含总体架构图、功能模块图、数据库E-R图和核心表结构的详细设计。这一章的字数占比最大，也是导师最爱看的部分。

第四章是实现。按照功能模块一个一个写，每个模块配几个关键代码片段和截图，说明核心功能的实现思路。

第五章是系统测试。写测试环境和测试用例表，我用了30多个测试用例覆盖核心功能，用二维码的表格形式展示。

第六章是总结与展望。写项目过程中收获的知识和不足的地方。

7.2 正文的写作技巧

写论文遇到的最大问题是“代码怎么写都行，但论文不知道写什么”。我的经验是：不要从零构思，先画功能图再画流程图，再把流程图的每一步用文字描述出来，就是一段很好的正文。

数据库设计章节是最容易凑字数的地方，每张表列出字段名、数据类型、字段说明，一张表写两段，十几张表就有了三四千字。

测试章节也是同理。每个测试用例写清楚测试步骤、预期结果、实际结果，三个模块15个用例就能写到2000字以上。

8. 常见问题与排查速查表

这里整理一份我在开发和部署阶段遇到过的典型问题，因为踩得多了，把排查思路一起放上来，方便后续的人直接翻：

再补充一个比较隐蔽的坑：Vue项目里用Element-UI的日期选择器，绑定值默认是Date对象，但提交后端的时候需要转成字符串。如果直接传Date对象，Jackson反序列化经常会报JSON parse error。解决办法是给字段加@JsonFormat注解，或者在后端接收的时候用LocalDate类型配合全局Jackson配置。

9. 答辩准备与经验总结

9.1 答辩演示的核心思路

答辩的时候，演示环节不要只点按钮，要会讲故事。我当时的演示流程是：先展示系统登录页和首页仪表盘，再进入客户管理，边说边演示新增客户、把客户分配给销售、填写跟进记录；然后切到商机模块，展示如何推进一个商机到赢单；最后展示漏斗图和报表。

如果你想做个加分项，记得把代码里的注释写好。有的评委老师会现场打开源码看，如果看到类名规范、注释清晰、异常处理到位，对你的评价会明显不一样。我毕业后有个学弟答辩的时候，评委就是直接让他现场打开代码，看到哪里讲到哪里，反而变成了优势。

9.2 面试时的项目介绍角度

这个项目在求职面试中也可以作为核心项目来介绍。讲项目的时候不要只讲功能，重点讲你的设计思考：为什么要做公海自动回收？为什么要用乐观锁？为什么要冗余最近跟进时间？这些问题的回答，能向面试官展示你是一个有业务理解能力的开发者，而不只是会写增删改查。

我实际面试被问到过“如果这个系统要支持高并发，你怎么改造”这个问题。我的思路是分层次回答：数据库层面加索引和连接池，缓存层面用Redis存储热点客户数据，应用层做接口限流，前端做列表虚拟滚动。不一定每个方案都能落地，但表达出系统性的思考就够了。

9.3 最后的经验分享

做毕设最大的体会就是：不要把毕设当成作业，而是当成一个真正的产品来做。需求要站得住脚、代码要写得规范、文档要齐全、演示要流畅。把这套系统认认真真做完，你不仅拿到一个毕业设计的高分，更重要的是收获了一个能完整体现你能力的全栈项目。

我个人的建议是，时间充裕的话可以继续扩展：加上一个审批流（比如合同审批走Activiti或者简单的状态机）、对接微信消息提醒客户跟进任务、用Redis做热点客户缓存、用Docker Compose一键部署环境。这些扩展点，无论写在论文的展望里，还是做进系统的下一个版本里，都是很好的加分项。

最后再分享一个小技巧：部署文档不要等到最后才写，开发到一半就要开始写。当时我一边开发一边记录环境变量、启动命令、注意事项，到最后整理部署文档只花了一个小时。如果开发完再从头回忆，很多细节早就忘了。这个习惯，到了真正工作之后，也会让你受益很多。