每年到毕业设计季就会有人反复问我客户关系管理系统这种出现频率极高的题目到底选什么技术栈最稳妥我的答案一直很一致SpringBoot Vue.js Java MySQL。这套组合项目结构清晰、技术覆盖面广、可演示效果强而且市面上资料多、踩坑记录全非常适合毕设、课设以及想系统学习前后端分离开发的人拿来学习和二次改造。今天就把这套系统的设计思路、核心代码逻辑、完整运行流程以及运行过程中最容易踩的坑一次性讲清楚。这套系统本质上是一个典型的“前端展示 后端接口 数据库存储”的Web管理平台业务范围覆盖客户信息管理、跟进记录、商机管理、合同管理、统计报表、系统用户与权限管理等。从课程设计角度来说它能覆盖SpringBoot框架、MyBatis-Plus数据库操作、Vue组件化开发、Axios异步请求、JWT身份认证等核心技术点从毕业设计角度来说它同时具备业务完整性和技术深度甚至可以在权限模块、报表模块上做扩展。这篇文章不是给你贴一堆无可奉告的代码而是把整套系统从零到一拆开讲透重点说清楚每一步为什么这么做以及出问题时怎么快速定位。1. 项目背景与定位拆解1.1 客户关系管理系统到底在管理什么很多同学对客户关系管理系统CRM的理解停留在“录入客户名字和电话”这个层面这其实低估了这个业务模型的价值。一个完整的客户关系管理系统至少需要覆盖“获客→跟进→转化→成交→服务”这条完整链路。客户信息只是最底层的数据真正体现业务价值的是围绕客户产生的行为记录谁在哪天跟进了哪个客户聊到了什么阶段客户有没有购买意向商机预计什么时候落地合同金额是多少回款周期大概多长。毕业设计如果只做成一个单纯的增删改查评委一眼就能看穿。所以我在这套系统设计里把数据模型拆成了用户、客户、跟进记录、商机、合同、数据统计几个维度让业务流程能串起来。比如销售录入一个客户后可以创建跟进计划每一次电话、拜访都留下时间戳和内容摘要当客户有明确购买意向时可以新建一条商机记录商机状态从“初步接触”推进到“方案报价”再到“赢单”或“输单”合同则与商机关联记录金额和签订日期。这样一来演示的时候就不是念PPT似的“点个增删改查”而是能讲出一个完整的业务故事。1.2 为什么SpringBootVue.jsMySQL是毕设最稳的搭配先说结论这个组合不是性能最强、也不是最前沿的但它一定是容错率最高的。SpringBoot解决了传统Java Web开发里配置地狱的问题内嵌Tomcat、自动装配、约定大于配置让开发者不用花费大量精力在XML配置上可以直接写业务代码。这也是整个Java生态在中小型系统里普及度极高的原因。Vue.js则把前端开发从繁琐的DOM操作中解放出来采用组件化开发、响应式数据绑定前后端分离后前端只关心界面和数据展示后端只提供JSON接口联调边界非常清晰。MySQL作为关系型数据库对于客户、跟进、合同这类强结构化数据是天然合适的而且MySQL安装、运维、SQL调优的资料多到看不完对于学生党来说遇到问题搜一下就能找到答案。有个非常现实的点很多评委或答辩老师自己最熟的就是Java和MySQL这套技术栈。你用这套组合在答辩时讲技术细节老师很容易听懂甚至能给出有价值的建议如果你用了一个小众框架或非主流数据库老师不熟悉反而容易追问到冷门细节到时候答不上来就很被动。技术选型这件事实用性和兼容性比新鲜感更重要。1.3 什么人适合直接拿来学习和改造这套系统最适合三类人。第一类是正在准备毕业设计的学生时间紧、任务重需要一个架构合理、能跑通、能演示、还能往上加功能的基础项目。第二类是正在上Java Web课程、想搭建一个完整项目来练手的同学通过阅读和修改这套代码能真正理解前后端是怎么配合的而不只是停留在“写Controller返回hello world”的阶段。第三类是刚进入Java开发岗位、想做项目经验储备的初级工程师通过二次开发能把SpringBoot Vue的常用套路摸熟。如果你有更长远的想法比如未来想做数据可视化大屏、想接入消息推送、想部署到云服务器给更多人用这套系统的扩展点也都预留得比较清晰。基础打牢了往上加东西只是时间和成本问题。2. 系统架构设计与核心技术拆解2.1 前后端分离架构的请求流转逻辑我见过不少学生的课设项目前端页面和后端Java代码混在同一个工程里模板引擎渲染页面Session管理登录状态。那样做不是说不行但代码耦合度高前端想改个样式都要小心别碰到后端逻辑分工也不清晰。这套系统选择的是前后端分离方案前端是一个独立的Vue.js工程后端是一个独立的SpringBoot工程两者之间只通过HTTP JSON通信。一次完整的请求是这样的用户在浏览器里登录前端把用户名密码组装成JSON通过Axios发送到后端接口后端控制器接收请求调用Service层处理业务再通过Mapper层与MySQL交互数据返回后逐层回传Controller把Java对象序列化为JSON前端拿到JSON后更新页面数据。整个过程里前端完全不关心SQL语句是怎么写的后端也完全不关心按钮点击后在页面上产生了什么效果。这种解耦方式也让两边的开发可以并行后端团队专注于接口前端团队专注于页面。要做到这一点跨域问题是绕不开的。前端开发服务器默认跑在8080端口后端接口跑在8081或者9090端口浏览器会因为同源策略拦截请求。解决方案有两个一个是在后端配置CorsFilter允许跨域另一个是在前端Vue的devServer里配置代理把前端请求转发到后端地址。前者适合正式部署后者适合本地联调。我的习惯是本地开发用代理避免后端CORS配置不严谨时把接口暴露给所有来源部署时再保证后端进行合理的跨域设置。2.2 后端SpringBoot分层设计与MyBatis-Plus的巧妙之处后端工程按照经典的三层架构拆分Controller层负责接收请求和参数校验Service层处理业务规则Mapper层负责持久化操作。作为一个学习型项目每一层的职责必须清晰。我最烦看到的就是Controller里直接写SQL或业务判断几百行的Controller不仅难读排查问题时也会抓瞎。持久层我选择MyBatis-Plus而不是原生MyBatis是因为它把常见的单表CRUD操作封装好了开发者只需要继承BaseMapper接口就能直接调用selectById、insert、updateById这类方法不用自己写重复的SQL。它同时又保留了MyBatis写自定义SQL的灵活性复杂查询、多表联查还是可以用注解或XML实现。而且MyBatis-Plus内置分页插件这比手动拼接LIMIT参数要安全得多能有效避免分页查询时的SQL注入风险。实体类与数据表通过注解或驼峰命名规则自动映射。例如实体类中的customerName字段会自动映射到customer_name列。这个机制用好了能省大量时间但也要注意规则冲突。如果你数据库表字段命名不规范比如有的字段用下划线、有的又一个单词首字母大写驼峰MyBatis-Plus会经常映射失败SQL报Unknown column错误。所以设计数据库时字段命名统一用下划线风格实体类统一用驼峰风格这是一个值得从开始就坚持的编码规范。2.3 前端Vue.js的组件化与状态管理前端工程不是简简单单的HTML JS脚本而是用Vue CLI或者Vite搭建的标准工程目录结构大致分几块views放页面组件components放公共组件router放路由配置api集中放Axios请求封装store用Vuex/Pinia管理全局状态。为什么需要组件化就拿客户列表页来说搜索条件、表格、分页器、新增弹窗、删除确认框如果全写在一个文件里文件可能几百上千行后续维护会非常痛苦。组件化的思路是把可复用部分抽出来比如分页器、状态标签、图表卡片做成独立组件页面通过这些组件的组合拼装出来。改分页器的样式只需要在一处修改全站生效。状态管理解决的是非父子组件之间的数据共享问题。比如登录成功后用户信息和权限标识需要被导航栏、路由守卫、接口请求拦截器共同使用如果靠参数一层层传递会很别扭。用Vuex或Pinia存一份全局状态不同组件各自读取逻辑清爽很多。这里有一个新手容易犯的毛病把什么都塞进状态管理。其实只有多页面共享的数据才适合放全局状态比如登录状态、用户身份、系统配置而像表单临时输入内容老老实实放在组件本地data里就行过度设计也是成本。2.4 数据库核心表设计与关系的建立数据库是这个系统的心脏。表结构设计合理后面写业务代码会顺风顺水表结构设计混乱比如缺少外键约束、字段类型乱用、大字段被频繁查询哪怕代码写得再好也会出问题。我在这套系统里最主要的几张表包括sys_user用户表存储登录账号、密码密文、真实姓名、角色标识customer客户表存储客户名称、联系电话、所属行业、客户来源、创建人与时间customer_follow跟进记录表存储跟进内容、下次跟进时间、关联的客户IDbusiness商机表存储商机名称、预计金额、所处阶段、关联客户、负责人contract合同表存储合同编号、签约金额、签订日期、关联商机。再加一张sys_role或者直接在用户表里搞role字段对于学习型项目来说后者更简单实用。表与表之间是典型的一对多关系。一个客户对应多条跟进记录一个客户可以有多个商机一个商机最终可能归属到一份合同。在数据库层面我习惯保留外键约束而不是只靠代码逻辑去维护数据一致性。很多人图省事不用外键结果删除一个客户后跟进记录变成脏数据统计报表突然多出一些关联不上的孤儿记录。演示的时候数据一查跳出一堆null非常尴尬。外键的性能开销没那么可怕学生项目的数据量根本到不了需要牺牲一致性来换性能的规模。3. 核心功能实现与关键细节解析3.1 JWT认证与后端权限拦截登录认证这块我用的是JWT方案而不是传统的Session。每当我们成功登录后端就生成一个JSON Web Token返回给前端前端把它存在本地存储里之后每次请求都在请求头带上Authorization: Bearer 。后端有一个拦截器统一校验这个Token是否存在、是否过期、签名是否合法。为什么不用SessionSession状态是存在服务器的用户一多、服务一多Session同步就是麻烦事而JWT本身就是无状态认证服务器只需要用密钥验证Token的合法性不需要额外存储会话状态。这对前后端分离和未来的横向扩展都更友好。JWT有一个必须注意的安全点不要在Token里塞明文密码、身份证号这类敏感信息因为JWT的Payload只是Base64编码不是加密任何人拿到Token都能解码看到内容。我一般只放userId、username和过期时间。另外Token的过期时间建议设成2小时左右前端再通过Axios响应拦截器做“登录状态失效跳转登录页”的提示。过期时间设置太短会导致体验差设置太长又会增加安全风险这也是一个值得在答辩时讲的权衡细节。3.2 客户管理的CRUD与分页查询客户管理是整个系统里最基础的模块但就是这样一个看似简单的模块做得好不好很能体现工程素养。查询接口的设计上我提供了一个分页查询接口接收pageNum、pageSize、keyword、industry等参数。MyBatis-Plus的分页插件会自动帮我们在查询前拼接LIMIT语句然后返回一个Page对象里面包含了当前页数据、总记录数、总页数等信息。前端拿到这些数据后就能在表格下方渲染出完整的分页条。这套逻辑在答辩时特别好讲你从数据库层面、到后端分页插件、再到前端分页组件一条完整链路都能说清楚。新增和修改可以共用一个表单组件通过判断是否有customerId来决定是走insert还是update。这里有一个特别值得说的小细节新增时主键由数据库自动生成修改时必须带上ID否则后端不知道更新哪一条。很多新手在写修改功能时前端把ID丢了后端更新能执行成功但影响行数为0查了半天才发现问题。为了避免这个问题我在前端表单里始终保留ID字段并在提交时取出同时后端在update方法加一个判断敏感字段比如createBy是创建人ID一律不允许通过更新接口被修改。3.3 跟进记录与商机的状态流转设计跟进记录是客户管理系统的灵魂。如果没有跟进记录这个系统就只是一个通讯录毫无业务灵魂。在设计上我让跟进记录归属于客户每条记录包含跟进方式比如电话、微信、上门拜访、跟进内容、下次跟进时间、跟进人。列表按时间倒序排列并且用不同标签颜色区分跟进方式让销售一打开客户详情页就能快速了解最近的沟通情况。商机模块我设计成一条生命线。商机状态用字典值管理比如1表示初步接触2表示需求确认3表示方案报价4表示赢单0表示输单。这样设计的好处是前端可以通过一个状态标签组件统一渲染状态文本和颜色后端也能在统计模块轻松做分组统计。状态流转时需要在Service层写校验逻辑已经赢单的商机不能再推回初步接触输单的商机需要填写输单原因。这套规则让业务逻辑有了可探讨的深度也是答辩时的加分项。3.4 数据统计报表的实现思路如果时间充裕一定要在系统里加一个统计报表页哪怕只是一个基础版本答辩效果都会有明显提升。评委最愿意看到的不只是“能录入数据”而是“数据能形成闭环、能辅助决策”。我的实现方案是后端提供一个统计接口按月份统计新增客户数、按阶段统计商机数量、按销售统计合同金额。SQL用GROUP BY CASE WHEN或者简单的COUNT聚合就能完成。前端用ECharts展示柱状图、折线图、饼图。ECharts本身是百度开源、现在由Apache维护的图表库中文文档齐全学习成本很低。比如合同金额按销售统计用柱状图展示商机阶段分布用饼图展示客户增长趋势用折线图展示。这三种图表基本就能撑起一个标准的销售看板。报表模块有一个容易被忽视的地方数据库时间字段的时区问题。SQL里统计日期如果直接拿系统时间而前后端传参时又有时差很容易出现数据对不上的情况。我在连接数据库的URL里显式配置了serverTimezoneAsia/Shanghai同时建议前端展示日期都统一格式化为yyyy-MM-dd避免后端返回的时间被前端解析出错。4. 环境准备与项目运行全流程4.1 本地开发环境清单与版本选择在动手跑项目之前先把环境准备好。这是一个看似简单但能卡住很多人半天的环节因为不同版本的工具之间兼容性问题很多比如SpringBoot 3.x要求JDK 17但你按旧教程写的代码可能还停留在SpringBoot 2.x的写法。我推荐的组合是JDK 8或JDK 11Maven 3.6以上SpringBoot 2.7.xMyBatis-Plus 3.5.xMySQL 5.7或8.0Node.js 16或18npm或yarn任选。为什么主推SpringBoot 2.7而不是3.x因为目前大量教程、开源项目、毕设论文资料都是围绕2.x写的遇到问题时搜到的解决方案基本能直接套用。SpringBoot 3.x用JDK 17虽然版本更新但很多旧依赖比如某些MyBatis-Plus版本和新版SpringBoot之间会有一堆兼容性报错。对于追求快速出结果的项目来说稳定第一。如果你本身就想尝鲜3.x那我建议先把这套基础项目跑通之后再单独去升级。MySQL安装在Windows和Linux上都有人用我两种环境都试过。Windows下最需要注意的坑是安装时选了“不设置MySQL为服务”导致mysql无法自启或者navicat连接时端口被防火墙拦了。Linux比如CentOS下需要额外处理配置文件字符集和服务启动权限问题。总之装好后第一件事就是用命令行先验证能连接mysql -uroot -p输入密码能进入客户端再说其他。4.2 数据库初始化与后端配置拿到源码后先找SQL脚本文件通常叫db_crm.sql或者init.sql。用Navicat、DataGrip或命令行都可以导入。执行完脚本后打开后端工程的application.yml或application.properties修改数据源配置。这里最常见的灵魂三问数据库名改没改、端口号改没改、账号密码改没改。如果你连数据库名都不改就用起来项目能启动但一查数据就是空如果密码不对启动时会直接报Access denied for user。我建议在配置里把tomcat的max-active设为10initial-size设为2即可别把这些连接池参数调得太大学生项目根本不需要那么高的并发预设。后端配置里的关键项包括spring.datasource.url里指定数据库地址、端口、库名、useSSLfalsespring.datasource.username和password还有MyBatis-Plus的配置其中map-underscore-to-camel-case一定要设置为true这会开启下划线到驼峰字段的自动映射。如果这个配置漏了你会发现实体类所有多单词字段的值都查不出来一片空白。4.3 后端启动步骤与调试技巧在项目根目录先确认pom.xml里的依赖是不是已经下载完成。用IDEA打开项目后右上角会有一个Maven面板点一下刷新按钮让它同步依赖。如果网络状况不好就耐心等待首次下载或者在IDEA设置里配置阿里云Maven镜像这一步能极大提升下载速度。后端启动很简单找到标注了SpringBootApplication的启动类右键运行。如果控制台出现Spring Boot的Logo、Tomcat started on port 8081这样的日志就算启动成功了。调试时最实用的技巧是不要用System.out.println去打印数据用Lombok的Slf4j注解注入日志对象用日志的info和error方法记录关键信息。日志的好处是能看到时间戳和日志级别排查问题时会清楚很多。如果启动时报BeanCreationException多半是某张表查不到或字段名对不上。这时候先在数据库客户端手动执行SQL验证SELECT * FROM customer LIMIT 1确认表存在且有数据再看实体类字段名是否匹配。还有一个偏门但我踩过的坑实体类里写了带下划线风格的字段名比如private String customerName被写错成customer_nameMyBatis-Plus会把下划线再映射一次结果每次都查不到字段。4.4 前端启动与跨域联调配置后端跑起来以后另开一个终端进入前端目录。先执行npm install安装依赖如果遇到权限不对或安装卡住把npm registry切换成国内镜像npm config set registry https://registry.npmmirror.com。依赖装好后npm run serve启动Vue开发服务器。默认页面地址是localhost:8080。但这时后端在8081前端请求后端接口肯定遇到跨域。我的方案是在前端根目录vue.config.js里配置devServer代理module.exports { devServer: { port: 8080, proxy: { /api: { target: http://localhost:8081, changeOrigin: true, pathRewrite: { ^/api: } } } } }这样前端请求/api/login会被代理转发到后端http://localhost:8081/login。后端不需要开启CORS前端也不需要在所有请求地址里写全后端域名。这种配置方式在本地联调时很顺手部署时再把代理去掉、改用Nginx反向代理即可。启动前端后用浏览器打开页面输入初始管理员账号比如admin/admin123如果能正常跳到首页并展示客户数据说明前后端打通了。如果页面能打开但登录请求报404先看控制台请求的URL是否被正确代理到了后端端口再用Postman直接请求后端接口验证后端是不是好的。这种“前端问题还是后端问题”的二分类排查法是联调时最基础也最有效的思路。5. 常见问题排查与避坑实录5.1 后端启动失败的几种典型报错No active profile set这是提示信息而不是错误虽然默认没配置指定环境但项目能正常跑。SpringBoot默认使用application.yml或application.properties配置。Table xxx doesnt exist说明数据库里没建表或连错了库。用数据库客户端执行SHOW TABLES;确认表是否存在同时检查application.yml里配置的数据库名是否正确。Unknown column customer_name in field list实体类字段与数据库字段映射失败。检查实体类里字段命名是否为驼峰风格同时确认MyBatis-Plus的map-underscore-to-camel-case已开启。端口被占用启动日志里报Web server failed to start. Port 8081 was already in use。执行netstat -ano | findstr 8081Windows或lsof -i:8081Mac/Linux找到占用进程并结束或者直接改配置里的端口。Failed to bind properties under spring.datasource要么是配置里的缩进或格式错了要么是依赖没引入完整。这种问题优先检查pom.xml里有没有mysql-connector-java或mysql的驱动依赖。5.2 前端页面拉不到数据前端问题里出现频率最高的是白屏、Console报错和网络请求403或404。白屏时先看浏览器Console通常能看到Uncaught TypeError这种报错多半是某个组件引用的属性为null检查数据初始化部分。403往往是接口需要登录Token而前端没有把Token放进请求头404则是接口路径不对按下F12看Network面板的请求URL认真对比后端Controller的RequestMapping路径。还有一个很隐蔽的问题前端用了Vue 3 Element Plus但表格列的prop名与后端返回的字段名不一致。后端返回字段是customerName前端却写成customer_name自然显示为空。这种问题检查一下后端返回的JSON字段名和前端的绑定属性名就能解决。Axios拦截器也很关键我一般在拦截器里统一处理Token附加和响应状态码判断。比如后端返回401时拦截器直接把用户状态清掉并跳转到登录页。如果不做统一处理每个页面都要自己判断返回值很容易漏。类似这种“统一出问题”的代码最好封装在api/request.js里而不是散落各处。前端代理配置改完后记得重启npm run serve因为vue.config.js的修改不会热更新需要重启才能生效。这也是一个经常被忽略的细节。5.3 分页组件显示异常的处理经验分页最常见的一个问题总记录数对但总页数和页码显示不对。多半是前端分页组件接收了错误的字段名。Element Plus的分页组件接收total总条数、current-page当前页等参数而后端MP分页返回的是一个Page对象里面常见字段是total、current、size。直接塞给前端还需要做一层映射。我的习惯是前端自己维护page和limit两个变量请求时传入响应里读取后端返回的total字段即可。数据能查到但分页永远返回所有数据说明后端分页插件没生效。常见原因是MyBatis-Plus版本新老接口不一样比如MybatisPlusInterceptor在3.4以上版本是标准配置而旧版用的是PaginationInterceptor。我在配置类里注入MybatisPlusInterceptor并添加PaginationInnerInterceptor(DbType.MYSQL)确保分页插件被正确加载。检查Service层查询时是否传了Page对象否则分页插件根本不知道你的分页条件。删除一条数据后总页数没变当前页可能已经是最后一页删除后数据为空应该跳回上一页。我在前端删除成功回调里加了一个判断如果当前页只剩1条记录且页码大于1就把页码减1再重新查询。这个细节别小看它演示时特别容易显得考虑不周。5.4 答辩和演示时的加分小技巧既然是毕设或课设代码能跑只是基础演示效果和答辩表达往往决定了成绩上限。整理几个经验先演示登录和权限拦截。输入端州的账号密码故意输错一次让大家看到错误提示再输入正确的展示登录成功后首页的变化。这能立刻说明你有认证逻辑。再做一次新增和修改。新增客户时先录一个不完整的数据触发前端校验看到必填项红框提示再补全保存。这会展示你做了表单验证而不是只写了CRUD。然后展示跟进记录。打开一个客户详情页添加一条跟进记录再回到客户列表。用表格的刷新变化证明“新增一条数据真实落库了”不要只是口头说。最后展示统计报表。切到看板页按月份切换数据能看到柱状图和饼图变化。这里很加分因为老师看到的不再是孤立的表单而是数据的汇聚分析能力。答辩时如果被问到“这个系统有什么不足”别直接说“没有不足”这种话那样反而显得没有思考。我常用的一句目前的权限只有角色区分下一步可以细化到菜单级权限和数据范围权限比如每个销售只能看自己负责的客户。既承认了现状又给出了后续改进方向这一招几乎不会出错。5.5 代码里我刻意留下的通用扩展点写这套系统时我特意留了几个方便二次开发的扩展位置。如果你想加功能优先从这几个地方动手一个是前端路由文件router/index.js加页面和菜单就在这里注册另一个是后端Controller层新增用户模块时照着现有Controller抄就行还有一个是公共字典配置在系统表里维护一个字典项就可以给商机状态、客户来源增加选项。接口返回结构我统一封装成{ code, message, data }格式。这样做的好处是前端拦截器可以直接根据code判断成功或失败不用每个接口单独解析。如果你自己从头写我也强烈建议一开始就统一返回结构不然后期改起来是大工程。前端通用组件里分页组件和状态标签是可以重点复用的部分。如果你给商机状态新增一种颜色只需要改一个公共标签组件的映射函数比每页改代码省事得多。这个思想在团队开发里尤其重要也是初学者容易忽略的地方。回想我自己最初接触这类系统的时候最焦虑的就是“不知道跑不起来的问题出在哪里”。后来做了无数个项目才明白大部分报错本质是环境配置、字段映射、路径拼接这三类问题。现在拿到一套源码不会急着看业务代码而是先看配置、再看表结构、最后看请求链路。这套项目的设计思路和代码结构就是按这个顺序组织的所以拿去学习时建议你顺着这个路径走先跑通再改着玩最后再研究哪里可以加功能。Java和MySQL这套组合之所以经久不衰就是因为它足够扎实能承载你从新手到入门的完整成长路径。希望这篇文章能让你少走一些弯路也祝你的项目答辩顺顺利利。