孙建华2008最近帮一个学弟看了套毕设项目，正好赶上他自己折腾了几晚上没跑起来，我远程帮他排了一圈环境问题，最后才算把整个系统完整跑通。说实话这项目挺典型的——SpringBoot+Vue前后端分离的狱内罪犯危险性评估系统，属于Java Web方向的毕设热门选题，既涉及后端业务建模，又涉及前端交互展示，还有完整的数据库设计和接口文档，非常适合拿来练手或者直接作为毕业设计参考。
这套系统核心解决的问题是：把狱内罪犯危险性评估这个原本靠纸质问卷和人工统计的流程，转化成一套可量化、可跟踪、可分析的系统。管理员和民警可以通过系统录入罪犯基础信息，开展多维度危险性评估，自动计算风险得分，给出风险等级结论，还能按监区、风险等级等维度做统计分析，生成可视化图表。说白了，就是用工程化的手段解决一个具体的业务问题。
不管你是正在找毕设方向，还是想学习SpringBoot+Vue前后端分离项目的完整落地过程，这篇文章都值得耐心看完。我会把项目的整体设计、数据库建模、后端核心逻辑、前端页面实现、部署运行流程以及我实际踩过的坑，全部掰开揉碎讲清楚。
1. 项目整体设计与思路拆解
1.1 狱内罪犯危险性评估系统的业务逻辑
做这类管理系统的第一步，不是急着写代码，而是先把业务逻辑理顺。罪犯危险性评估在实际业务中是一个相对标准化的流程：首先要建立罪犯的基础档案，包括身份信息、犯罪类型、刑期、所在监区等；然后围绕几个核心评估维度展开测评，包括心理健康状态、近期行为表现、违规违纪记录、劳动改造态度等；每个维度下设置若干个评估指标，由民警根据实际情况打分；系统汇总所有指标得分，按照预设的阈值区间自动判定风险等级（高风险、中风险、低风险），最终生成评估结论。
这套逻辑映射到系统功能上就清晰了，主要包括五大模块：罪犯档案管理（增删改查），评估维度与指标管理（评估模板配置），评估任务执行（录入评分、自动计算），评估记录查询（历史数据跟踪），数据统计分析（风险等级分布、监区对比等）。我拿到项目源码后第一件事就是对照这个业务模型查看代码目录结构，能快速判断出这套系统的完整程度和代码组织是否规范。
1.2 为什么选择SpringBoot+Vue前后端分离架构
这个项目的技术选型很有代表性，SpringBoot负责后端接口服务，Vue负责前端页面渲染，中间通过JSON格式的RESTful API通信。SpringBoot的优势在于启动快、配置少、生态成熟，特别适合快速搭建业务系统后端；Vue作为渐进式JavaScript框架，组件化开发让前端代码的维护性大幅提升，配合Element UI组件库可以快速实现管理后台风格界面。
前后端分离架构最大的好处是职责清晰，后端只关心数据处理和业务逻辑，前端只关心页面交互和展示。在实际开发中，前端团队和后端团队可以并行工作，只要提前约定好接口规范。对于毕设项目来说，这种架构还能很好地展示你对Java Web全栈开发的理解——面试官和答辩老师通常会重点关注你对前后端交互流程、接口设计规范、数据流向的理解深度。
我这个项目里还引入了JWT（JSON Web Token）做登录认证，这是目前主流的前后端分离鉴权方案。用户在登录成功后，后端签发一个令牌返回给前端，前端在后续请求的请求头中携带这个令牌，后端通过拦截器校验令牌合法性，从而识别用户身份。相比传统的Session方案，更好地适配了前后端分离场景，也体现了项目的完整性。
1.3 系统功能模块与角色权限规划
整个系统围绕“评估”这个核心业务来组织功能，我从源码中整理了完整的模块划分：登录认证模块负责用户登录和权限校验；罪犯档案管理模块负责罪犯信息的录入、编辑、查询和删除；评估维度管理模块维护评估维度和指标信息，相当于配置评估模板；评估任务模块是核心，支持创建评估任务、填写评估表、自动计算得分并生成风险等级；记录查询模块支持按罪犯、按时间、按风险等级等条件筛选历史评估记录；统计分析模块用ECharts图表展示风险评估结果分布。
角色权限上，系统设计了管理员和普通民警两类角色。管理员拥有全部功能权限，包括用户管理、评估维度配置、数据统计查看等；普通民警主要负责罪犯档案录入和评估任务的执行。这个权限设计比较常规，但很实用，解决了“谁能看什么、谁能改什么”的基本管控需求。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据库设计与SQL脚本核心细节
2.1 主要数据表结构解析
拿到项目的第一件事，我建议先把SQL脚本完整执行一遍，再仔细研究表结构。这套系统的数据库设计比较规范，以MySQL为例，核心表有：用户表（sys_user）存储系统账号、密码（BCrypt加密后保存）、角色类型；罪犯信息表（prisoner_info）存储编号、姓名、年龄、犯罪类型、刑期、监区等字段，其中罪犯编号设置了唯一索引；评估维度表（eval_dimension）定义评估维度名称、排序号；评估指标表（eval_indicator）关联所属维度，包含指标名称、满分值、评估说明；评估记录表（eval_record）存储每次评估的总体结果，包括总得分、风险等级、评估人、评估时间；评估明细表（eval_detail）存储每项指标的得分明细，通过外键关联评估记录表。
这里面最值得学习的是主表和明细表的设计思路，评估记录表是主表记录整体结论，评估明细表是子表记录每项得分。这种“一主多子”的表结构在业务系统中极其常见，比如订单表和订单明细表就是同样的设计模式。如果毕设答辩时老师问数据库设计的合理性，这就是一个很好的切入点。
2.2 初始化数据与SQL脚本的完整落地
SQL脚本里通常包含三部分内容：建库语句（CREATE DATABASE）、建表语句（CREATE TABLE）、初始化数据（INSERT INTO）。执行脚本前务必注意MySQL版本和字符集问题。我实践下来，推荐用Navicat或者命令行执行，先把脚本里的所有注释看一遍，了解表之间的依赖关系，然后按顺序执行。如果脚本里写了外键约束，执行顺序不对会报错，这时候不要慌，看报错信息定位到对应的表调整执行顺序即可。
初始化数据部分一般会预置管理员账号，常见的是admin/123456。但我要提醒一个关键点：密码字段在数据库里存储的不是明文，而是BCrypt加密后的字符串，所以不要直接在数据库里改密码，要通过系统提供的修改密码接口来操作。我当时第一次看到这个细节时还愣了一下，后来想明白了——这是Spring Security的标准做法，也说明这个项目的安全性设计是合格的。
2.3 数据库设计中的几个细节思考
在查看表结构时，有三处细节值得留意。第一，字符集统一使用utf8mb4而不是utf8，前者能完整支持中文、emoji以及生僻字，这是实际开发中很容易踩的坑；第二，时间字段用datetime类型而不用timestamp，后端处理起来更方便，同时配合DEFAULT CURRENT_TIMESTAMP实现自动填充；第三，逻辑外键而非物理外键，大多数表之间的关联通过逻辑字段维护，不在数据库层面建物理外键约束，这样做的好处是删除数据时不用顾虑外键约束阻断，符合企业级开发的普遍做法。
这三个细节看起来微不足道，但体现的是工程经验的积累。答辩时如果能主动讲出这些设计意图，会明显加分。
3. 后端核心实现：SpringBoot项目拆解
3.1 后端项目结构与基础配置
后端工程采用标准的Maven目录结构，按功能模块分包。com.xxx.prison下分controller、service、mapper、entity、config、common等子包，这种分包方式简洁清晰，适合大多数毕设业务体量。我实际用IDEA导入项目时发现配套了较新版本的SpringBoot（2.7.x左右），JDK环境要求1.8以上，推荐直接用JDK1.8运行，稳定省心。
核心配置文件application.yml决定了一套项目的运行底座，主要包括服务端口（默认8080，注意防止端口冲突）、数据库连接配置（IP、端口、库名、用户名、密码）、MyBatis-Plus相关配置（日志输出、驼峰命名映射）、JWT密钥和过期时间配置。这里我强烈建议一个操作：实际运行时先在application.yml里把数据库密码换成你自己的本地密码，确保数据库连接信息准确，这是后端能否成功启动的首要前提。
3.2 登录鉴权与JWT实现细节
登录流程是后端代码里最值得细读的部分。用户提交账号密码后，后端通过UserService查询用户信息，然后用BCryptPasswordEncoder匹配密码是否一致（注意这里不是解密，而是重新加密比对）。匹配成功后，JwtUtil生成一个包含用户ID和用户名的令牌，返回给前端，前端存储在本地并在后续请求中附带。后端的JWT拦截器会拦截所有需要鉴权的接口（通常排除登录接口和Swagger相关路径），校验请求头中的token是否存在、是否过期、是否被篡改。
我建议你把这段代码完整读一遍，因为这是整个后端项目中概念最集中、面试最容易问的部分。尤其要理解JWT的签名算法，它本质上是一个携带声明的JSON对象，通过服务端密钥进行签名，保证内容无法被伪造。你不需要深入密码学原理，但至少要能讲清楚“签发”和“校验”这两个环节。
3.3 危险性评估业务逻辑实现分析
评估功能的业务逻辑是系统的心脏。从代码实现来看，评估执行的流程是：前端提交评估明细得分列表到后端，后端接收后先创建评估记录主表（保存总得分和等级结论为空），再逐条保存评估明细数据，最后遍历所有指标得分累加总分，根据阈值区间自动判定风险等级。业务层用@Transactional注解将这个过程包成一个事务——要么全部成功，要么全部回滚，避免出现主表有记录但明细缺失的数据脏状态。
风险等级判定的阈值规则一般在common包或service层中定义，常见做法是总得分80以上为高风险，50到80之间为中风险，50以下为低风险。这个阈值可以按实际业务需求调整，建议做成可供前台配置的参数。用代码实现的计分逻辑可以用一个简单的Java示例来说明：
java复制public RiskLevel evaluateRiskLevel(List<EvalDetail> details) {
int totalScore = details.stream()
.mapToInt(EvalDetail::getScore)
.sum();
if (totalScore >= 80) {
return RiskLevel.HIGH;
} else if (totalScore >= 50) {
return RiskLevel.MEDIUM;
}
return RiskLevel.LOW;
}
这段逻辑简单直接，但在项目中扮演着核心决策的角色。理解了这个之后，整个系统的业务主线就串起来了。
3.4 Swagger接口文档的配置与使用
接口文档对一个前后端分离项目来说必不可少。这个项目集成了Swagger（具体可能是Springfox或springdoc），启动后访问对应的Swagger UI地址即可看到所有接口的在线文档。每个接口的请求方法、请求路径、参数说明、返回结构一目了然，还能直接在线调试接口，给前后端联调带来很大便利。
我强烈建议你把Swagger生成接口文档这件事学会，不只是为了这项目能用，任何Java Web项目都用得上。在项目里加依赖、加配置类、在Controller上写注解三步就能搞定。如果要做离线文档，Swagger还支持导出JSON格式的接口定义文件，配合工具可以转成Word或PDF，特别适合毕设文档撰写时使用。
4. 前端核心实现：Vue项目拆解
4.1 前端项目结构与初始化配置
前端工程是标准的Vue CLI搭建的SPA单页应用，src目录下按api、router、store、views、components等目录组织。api目录封装了所有后端接口调用方法，router目录定义了路由映射关系，store目录用Vuex做全局状态管理（主要管理用户token和用户信息），views目录存放页面组件，components目录是公共组件和一些可复用的表单组件。
拿到前端源码后，第一件事是执行npm install安装依赖。这里我用了一大坑要提醒你：Node.js版本别追新，推荐用14.x或16.x的LTS版本，太高的Node版本容易导致依赖安装失败报错。如果网络环境下载慢，可以设置npm淘宝镜像，把安装速度提升一个量级。装完依赖后，用npm run serve启动开发服务器。
4.2 核心页面实现细节
我从页面组织上看到这套系统覆盖了比较完整的管理后台页面。登录页是典型的居中卡片式设计，提交表单时校验必填项，登录成功后把token存到localStorage，然后跳转到首页。首页放置统计面板，展示风险等级分布、评估人数等核心数据，用ECharts柱状图和饼图直观呈现。罪犯档案管理页面是一张标准的Crud表格，支持搜索、分页、弹窗编辑，重点是用到了表单校验规则，提交前对关键字段做了合法性校验。评估任务页面相对复杂，需要加载评估维度、动态渲染表单，每一项指标对应一个分数输入框，提交后展示评估结果。统计分析页面是多张图表的组合，展示不同维度下的数据分布情况。
这些页面本身难度不大，但组合在一起就是一个完整的中后台应用。对Vue的学习来说，我建议重点关注这三块：路由配置（尤其动态路由和路由守卫）、Vuex状态管理（为什么token放store里、为什么还要持久化到本地）、组件通信方式（父传子props、子传父emit）。把这三块搞清楚了，Vue的核心思想就掌握了一半。
4.3 前后端联调与代理配置方法
前后端联调是很多初学者搞不定的环节。前端开发服务器跑在8081端口，后端接口服务在8080端口，跨域问题看似存在，实际上Vue CLI的开发服务器已经内置了代理方案。在项目根目录的vue.config.js中配置proxy代理，把请求统一转发到后端的8080端口即可，前端代码里请求的地址以/api开头，代理会自动把/api前缀移除后透传到后端。这是解决开发环境跨域问题的最标准做法。
这里有一个值得注意的细节：接口地址到底带不带/api前缀，取决于后端Controller的RequestMapping是怎么写的。如果后端接口路径就是/api开头，代理配置里就不要做路径重写；如果后端接口没有/api前缀，则需要用pathRewrite把前缀去掉。实际操作时先看后端接口的真实路径，再对照调整代理配置，这样才能一次配通。
5. 系统部署与运行全流程记录
5.1 环境准备清单
我把整套环境跑通的步骤整理成一份清单，照着做基本不会出错。JDK要求1.8及以上版本，推荐直接用1.8；MySQL建议5.7或8.0版本，务必记住安装时设置的root密码；Node.js推荐14.x或16.x LTS版本；后端开发工具推荐IDEA；前端开发工具推荐VSCode；数据库管理工具推荐Navicat或DataGrip。这些工具都齐了以后，就可以开始部署了。
5.2 后端启动步骤详解
后端启动分四步走。第一步，用IDEA导入后端项目文件夹，等待Maven自动下载依赖，这里在网络环境较差的环境下可能要等较长时间，建议配Maven阿里云镜像；第二步，在Navicat中新建数据库，字符集选择utf8mb4，然后导入SQL脚本，执行所有表结构和初始化数据；第三步，修改application.yml中的数据库账号密码，确保和本地一致；第四步，运行主启动类，看到“Started XXXApplication”的日志输出，说明后端跑起来了。此时访问Swagger接口文档地址，能看到所有接口列表就说明完全正常。
5.3 前端启动步骤详解
前端启动更简单。用VSCode打开前端项目文件夹，在终端执行npm install安装依赖，首次安装可能要等几分钟；接着执行npm run serve启动开发服务器。看到“Compiled successfully”提示后，浏览器访问前端地址即可进入系统首页，用初始化数据里的管理员账号登录，就能体验到完整流程了。
5.4 完整功能演示测试路径
我建议新手按照以下路径完整走一遍，确认系统没有大问题：登录系统；进入罪犯档案管理，新增一名罪犯信息；进入评估任务页，为刚创建的罪犯创建评估，填写每个维度的指标得分；提交后查看评估结果，确认风险等级是否正确判定；进入记录查询页，能查到刚才的评估记录；进入统计分析页，查看图表数据是否有更新。这套流程走完，基本可以确认系统功能是能用的。如果某一步报错，可以根据报错信息定位到问题点，大概率是数据库连接、接口路径或依赖版本三类问题。
6. 常见问题与排查技巧实录
6.1 后端启动常见的三类报错
后端启动报错基本集中在三类。端口被占用是最常见的，报错信息类似Port 8080 was already in use，解决方法是杀掉占用进程或修改application.yml里的服务端口。数据库连接失败是第二类，报错是Access denied或Unknown database，检查application.yml里的账号密码是否输入正确、数据库是否建好、字符集是否匹配。依赖下载失败是第三类，主要表现是Maven控制台满屏红字，检查IDEA的Maven配置是否正确，换用阿里云镜像源能解决绝大多数依赖问题。
6.2 前端安装依赖时的版本兼容问题
前端遇到问题最多的时刻就是npm install。我见过太多初学者卡在这里，明明代码没问题，就是依赖装不上。常见原因是Node版本太高，如果Node是18以上版本还报node-sass相关错误，大概率是node-sass没对应的编译版本，建议改成dart-sass或者直接切换Node 14.x。还有一处是package-lock.json文件版本冲突，如果拉取源码后npm install失败，可以删掉node_modules和package-lock.json再重新安装，通常能解决。
6.3 前后端联调时的跨域与404问题
联调阶段最常见的问题是404。前端请求能发出，但后端找不到接口，说明代理配置或者接口路径有问题。先在浏览器开发者工具里看Network请求的URL，确认请求落到哪个地址；再比对后端Swagger里的接口路径，看两者是否一致；最后看代理配置的路径重写规则是否正确。另外要检查启动前端的vue.config.js是否生效，改完配置一定要重启前端服务，因为这不是热更新能覆盖的内容。跨域报错（CORS错误）在配好代理的情况下基本不会出现，如果出现，优先检查请求路径是否走了代理。
6.4 毕设答辩准备经验
项目跑通后，应付答辩还需要提前备好几个关键问题的答案。为什么要做这个系统——从业务痛点出发，说清楚纸质评估的弊端和系统化的价值；技术架构怎么设计的——前后端分离，模块化分层，遵循MVC思想；风险评估的逻辑是什么——基于维度打分累加得到总分，再通过阈值判定等级；JWT相比传统Session有什么优势——无状态、适合前后端分离、跨域友好；数据库设计上做了哪些考虑——主明细表设计、索引优化、字符集选择、时间字段处理。这些内容在代码里都能找到对应实现，提前过一遍心中有数，怎么问都不慌。
最后关于这套项目的一些个人思考
我完整梳理完这套系统之后最大的感受是，它不是那种“为了毕设而毕设”的拼凑项目，而是真的按照企业级开发方式组织的：技术栈主流、分层清晰、数据库规范、接口文档齐备。对要交毕设的同学来说，最聪明的使用方法是把压缩包里没有任何乱码的源码当作大型课设作业来精读，不是改个名字就提交，而是理解每一层为什么要这么写，然后把导师可能问的每个技术点吃透。
我自己在实际帮人部署的过程中也有个心得：所有的代码问题最终都回归到排查思路，遇到报错别急着去网上搜，先看日志定位到具体模块，再看相关配置是否和本地环境匹配，最后才是查代码逻辑。这套排查思路比项目本身更能沉淀成你的核心能力。
祝所有正在为毕设折腾的兄弟们顺利跑通，答辩全过。