1. 项目概述与选题拆解
1.1 这套系统到底是什么
简单说，这就是一个典型的 Java 全栈毕业设计项目，后端用 Spring Boot 提供接口服务，前端用 Vue 写页面交互，数据全部存在 MySQL 里，整体是一个面向律师事务所的日常业务管理系统。放在律所场景里，核心管的事情就三件：案件、客户、文书流程。再往下拆，还能覆盖到律师团队的任务分配、案件进度跟踪、卷宗归档、费用登记这些细活儿。
我做这个项目的时候，最深的感受是：它的定位和普通的“管理系统模板”有明显区别。市面上很多毕设题目，比如图书管理、学生选课，本质上就是单表 CRUD 的套壳练习。但这个律所案件管理系统，天然自带业务状态流转的概念——一个案件从咨询、委托、立案、审理到结案归档，中间每一步都有状态变化、角色参与和文档产出。如果你只是把它当增删改查来做，逻辑上能通，但答辩时候面试官或老师一追问业务流程，就容易露怯。反过来，如果真正把案件状态机理清楚了，这个项目在毕设里属于“有业务深度、有技术含量、有展示亮点”的档次。
1.2 为什么这个组合是毕业设计的安全牌
先说个结论：Spring Boot + Vue + MySQL 这个技术栈组合，是目前国内高校软件工程、计算机科学专业出镜率最高、容错率最低、参考资料最全的一套搭配，至少还能再战五年。
- Spring Boot 负责后端：它解决了传统 SSM 项目里大量繁琐的 XML 配置问题，内置 Tomcat，打 jar 包就能跑，对毕设阶段的学生极度友好。而且它的生态成熟，集成 MyBatis-Plus、Spring Security、JWT 这类常用库都有现成方案。
- Vue 负责前端：渐进式框架，学习成本相对低，配合 Element UI 或 Element Plus 组件库，能快速做出后台管理界面那种“正经系统”的观感——这是答辩加分的关键。你光用 JSP 写个页面，和用 Vue 做成 SPA 单页应用，视觉上完全是两个层次。
- MySQL 负责数据：开源、免费、资料多，装好 Navicat 就能可视化操作，对于需要交数据库脚本的毕设来说，导出 SQL 文件直接就能给老师看表结构设计。
这套组合还有一个隐藏优势：部署方式简单。后端打个 jar 包，前端 npm run build 生成 dist 静态文件，放到 Nginx 下就能跑，写完部署文档非常顺畅。比起那些要配置微服务注册中心、消息队列的重型架构，这种单体 + 前后端分离的模式，既撑得起毕设的体量，又不会把自己拖进运维泥潭。
1.3 适不适合你直接拿来用
如果你是下面这几类人，这套项目的思路非常值得参考：
- 正在选题、打算做“管理系统类”毕设的应届生。你可以把律所场景替换成物业、驾校、健身房，但里面的用户角色划分、业务状态管理、权限控制思路是通用的。
- 对前后端分离开发还不太熟，想通过一个完整项目把 Spring Boot + Vue 串起来的自学者。
- 需要快速交付一个能演示、能答辩、能跑通的系统，同时希望数据库设计有层次感、论文有东西可写的同学。
我得把丑话说在前面：这套题目不是“零基础速成”项目。你需要至少掌握 Java 基础语法、Spring Boot 常用注解（@RestController、@Service、@Mapper 这类）、Vue 组件通信的基础用法，再加上 MySQL 的建表与简单查询能力。如果这些还不太熟，建议先花两周补基础，再碰项目，不然全是代码复制粘贴，出了问题根本不知道从哪查起。
2. 系统设计与技术选型详解
2.1 角色权限模型的四种用户
律所系统最先要明确的，就是谁在用什么角色使用这个平台。我设计时把用户分成四类：系统管理员、律师、助理、客户。这个划分基本沿用了绝大多数中小型律所的内部协作习惯。
- 系统管理员：管账号、管部门、管字典数据，不看具体案件内容。
- 律师：核心使用人群，负责案件的办理、进展更新、文书上传、费用登记。
- 助理：辅助角色，可以录入案件信息、协助整理材料，但案件核心状态的修改要有权限边界。
- 客户：最受限的角色，建议只开放案件进度查看、留言沟通、上传补充材料这几个入口。
这里有个关键设计点：不要让助理和客户的角色权限做得过于接近律师，否则系统里最核心的“案件状态控制”就形同虚设了。我在做数据库设计时，用户表（sys_user）里预留了 role_id 字段，权限控制层面用 Spring Security + JWT 做认证，另加一层简单的角色拦截：后端接口用注解或拦截器区分 ADMIN / LAWYER / ASSISTANT / CLIENT 四种角色，而不是单纯在前端隐藏按钮——前端隐藏只是体验优化，后端拦截才是安全底线。这一点写论文和答辩时都可以着重说，因为很多毕设项目的权限就只做了前端判断，答辩老师一问就翻车。
2.2 案件全生命周期的状态机
办案系统不同于普通记录系统，最核心的差异在于案件状态。我把它拆成六个阶段：待分配、办理中、已暂停、待结案、已结案、已归档。每一条案件记录都必须携带当前状态，律师或助理操作案件时，实际上是驱动状态迁移。
这个状态机的设计，建议用一张单独的字典表（case_status）维护，而不是在案件表里写死字符串。好处是：后续论文里可以画出状态流转图，老师会觉得你有“设计意识”；前端下拉框选项也能直接从后端接口读取，不用每次改状态还要动代码再重新打包。
具体流转规则我按业务约束做了限制：
- 案件创建后默认“待分配”，系统管理员或律所主任可以把案件指派给某个律师，变为“办理中”。
- 办理过程中如果等证据或等法院通知，可以置为“已暂停”。
- 办案结束提交结案报告后，变为“待结案”，最终由管理员确认后“已结案”。
- 结案后所有材料检查完成，才能“已归档”。
这套状态机同时解决了另一个毕设常见问题：数据表的逻辑外键关系怎么体现。案件表（case_info）关联客户表、律师表、状态表，每一个关联都有业务含义，论文中写 E-R 图也更容易讲明白。
2.3 案件管理之外的四块周边功能
我再补充几个容易忽略、但实际演示时“有亮点”的功能模块：
- 客户档案管理：记录客户基本资料、历史委托记录。说是客户，其实更接近“当事人”的概念，很多案件是同一个客户反复委托，所以客户表要跟案件表做成一对多。
- 卷宗材料管理：上传 PDF、Word、图片格式的文档材料。上传接口用 MultipartFile 接收，文件落盘到服务器指定目录，数据库里记录文件路径和上传人信息。这个模块是答辩时的“视觉亮点”，评委能看到真实的文件管理形态。
- 开庭日历与待办提醒：律师登录首页能看到近期开庭安排。我的实现方案是把开庭时间存在案件扩展表里，用定时任务（Spring 自带 @Scheduled）每天扫一遍,把三天内要开庭的案件推送提醒消息。这个功能很占便宜，代码量不大，但演示效果非常直观。
- 费用与开票记录：这个模块我建议以“简化版”来实现，记录每笔费用的类型、金额、收支方向、关联案件即可，不要强上财务模块，否则会牵扯到复杂的对账逻辑，毕设控不住。
2.4 为什么选 MyBatis-Plus 而不是 JPA
数据访问层很多毕设会用 Spring Data JPA，理由是“省代码”。但我最终建议用 MyBatis-Plus，原因是它的学习曲线更适合国内学生的知识结构——大家在学校里学的就是 MyBatis 的 SQL 映射思路。MyBatis-Plus 在原生 MyBatis 基础上加了通用 CRUD 方法，不需要自己写简单的增删改查 XML，复杂查询还能用 LambdaQueryWrapper 链式构造条件，对分页也内置了插件支持。
举一个实际例子。案件列表页要支持多条件筛查：按案件编号模糊查询、按客户姓名查询、按案件类型和状态筛选，还要分页。用 MyBatis-Plus 的 QueryWrapper 写起来是这样：
LambdaQueryWrapper<CaseInfo> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.isNotBlank(caseNo), CaseInfo::getCaseNo, caseNo) .like(StringUtils.isNotBlank(clientName), CaseInfo::getClientName, clientName) .eq(caseType != null, CaseInfo::getCaseType, caseType) .eq(caseStatus != null, CaseInfo::getCaseStatus, caseStatus) .orderByDesc(CaseInfo::getCreateTime); Page<CaseInfo> pageInfo = caseInfoMapper.selectPage(new Page<>(pageNum, pageSize), wrapper);五六个条件，三五行代码就搞定了，比手写动态 SQL 省太多事。而且 MyBatis-Plus 的代码生成器可以直接根据数据库表倒推出实体类和 Mapper，前期开发效率直接翻倍。唯一的注意点是：使用逻辑删除和自动填充时，要记得在实体类上添加 @TableLogic 和 @TableField(fill = FieldFill.INSERT) 注解，不然删除数据时留下脏数据，分页统计容易出问题。
3. 核心模块实操与实现要点
3.1 JWT 认证交互流程
系统整体采用前后端分离架构，前端 Vue 和后端 Spring Boot 通过 JSON 格式的 HTTP 接口交互。这里最大的技术点就是登录认证方案——我没有用传统的 Session 方式，而是用了 JWT（JSON Web Token）。
JWT 的交互逻辑大概是这样：客户端提交用户名和密码到 /api/auth/login 接口，后端校验成功后生成一个 token 字符串返回给前端，前端把它存进 localStorage 或 Vuex/Pinia；之后每次请求都带着 Authorization: Bearer 的请求头；后端通过拦截器解析 token，从中取出用户 ID 和角色信息。
后端代码里核心可以拆成三段。第一段是登录接口生成 token：
String token = Jwts.builder() .setSubject(user.getUsername()) .claim("userId", user.getId()) .claim("role", user.getRole()) .setExpiration(new Date(System.currentTimeMillis() + 86400000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();第二段是拦截器校验 token：
@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization").replace("Bearer ", ""); Claims claims = Jwts.parser().setSigningKey(secretKey).parseClaimsJwt(token).getBody(); request.setAttribute("userId", claims.get("userId")); return true; } }第三段是注册拦截器排除登录接口和静态资源：addInterceptor(jwtInterceptor).excludePathPatterns("/api/auth/login", "/static/**", "/error")。
实际操作中有个很典型的坑：JWT 使用的是 HS256 签名，生成和解析时的密钥必须一致，否则会出现 SignatureException。另外密钥字符串长度必须足够，太短会直接启动报错，真实项目中至少用 32 字节以上的随机字符串。
3.2 案件管理的代码分层
案件模块是整个系统的“主菜”，它的代码分层直接决定了项目结构的可读性和扩展性。我的建议是严格按照 Controller -> Service -> Mapper 三层来组织，每一层只做自己该做的事。
Controller 层只接收请求参数、调用 Service、返回统一响应体：
@RestController @RequestMapping("/api/case") public class CaseController { @Autowired private CaseService caseService; @PostMapping("/create") public Result create(@RequestBody CaseInfo caseInfo) { return Result.success(caseService.createCase(caseInfo)); } @GetMapping("/page") public Result page(@RequestParam Integer pageNum, @RequestParam Integer pageSize, @RequestParam(required = false) String caseNo, @RequestParam(required = false) String clientName, @RequestParam(required = false) Integer caseType, @RequestParam(required = false) Integer caseStatus) { return Result.success(caseService.pageQuery(pageNum, pageSize, caseNo, clientName, caseType, caseStatus)); } }Service 层承载业务规则，包括案件编号生成、默认状态赋值、状态流转校验等。案件编号生成这里，我用的是“LS + 年月日 + 四位随机数”的规则，比如 LS202506070123，保证业务上可读且不容易撞号。这也是答辩时可以说两句的设计细节。
Mapper 层就一组继承 BaseMapper 的接口，配合 XML 文件写复杂查询。案件列表需要连表查询客户和律师姓名时，可以在 XML 里写自定义的 ResultMap，避免在 Java 层做内存拼接。
3.3 前端 Vue 核心页面设计
前端页面我采用的是 Vue 2 + Element UI 的组合（当然你机器上装新版也可以用 Vue 3 + Element Plus，思路一样）。页面按功能拆分这么几个：登录页、系统布局页、案件管理页、客户管理页、材料管理页、个人中心页。
案件管理页是整个前端最复杂的部分，我拆成了三个子组件：查询区、表格区、操作区。查询区绑定搜索表单的数据，点“查询”按钮时向父组件抛事件，让父组件重新调用列表接口；表格区用 el-table 渲染，通过列模板显示状态标签，不同的状态用不同颜色的 el-tag 区分；操作区放“详情、编辑、推进状态、上传材料、删除”这些按钮，每个按钮根据当前行数据的状态做 v-if 控制。注意：按钮显示控制只是用户体验，真正的权限校验靠前面说过的后端拦截器。
这里有一个我重复踩过的坑：状态标签的颜色绑定写错会导致页面看起来全都是默认蓝色，很容易被答辩老师挑刺。正确写法是给 el-tag 动态绑定 type：
<el-tag :type="statusTypeMap[row.caseStatus]">{{ statusNameMap[row.caseStatus] }}</el-tag>statusTypeMap 在 data 里定义成 {0: 'info', 1: 'primary', 2: 'warning', 3: 'danger', 4: 'success' } 这样的形式。
3.4 卷宗上传的完整链路
文件上传功能看着简单，但很多同学做到一半会卡壳。我把这条链路完整走了一遍：
前端用 el-upload 组件的 http-request 自定义上传方法，把文件路径交给 FormData：
handleUpload(file) { let formData = new FormData(); formData.append("file", file); formData.append("caseId", this.caseId); axios.post("/api/material/upload", formData, { headers: { "Content-Type": "multipart/form-data" } }); }后端接口这样写：
@PostMapping("/upload") public Result upload(@RequestParam("file") MultipartFile file, @RequestParam Integer caseId) { String originalFilename = file.getOriginalFilename(); String suffix = originalFilename.substring(originalFilename.lastIndexOf(".")); String newFileName = UUID.randomUUID() + suffix; String filePath = uploadDir + "/" + newFileName; file.transferTo(new File(filePath)); // 保存文件记录到数据库 return Result.success(newFileName); }这里面要提前做好三件事：服务器上创建好指定目录，不然 transferTo 会报 FileNotFoundException；在 Spring Boot 配置文件里设置 spring.servlet.multipart.max-file-size 和 max-request-size，默认只有 1MB，传个 PDF 稍微大点就报错；上传接口要加角色限制，不能让普通客户随便传文件到任意案件下。我第一次测试时就是没改 max-file-size，传一个 5MB 的扫描件直接 500，排查了半小时才发现是配置项问题。
3.5 首页统计图表的实现
另一个演示时的加分项是首页的数据看板。不需要做得很复杂，只要四个指标卡加一个图表就够了：案件总数、办理中数量、本月新增案件、客户总数。图表我用的 ECharts，展示案件类型分布饼图和近六个月案件趋势折线图。
这里有一个毕设项目很容易忽略的细节：统计数据接口一个聚合 SQL 就能查出来，尽量别在 Java 里循环统计。
<select id="countByStatus" resultType="map"> SELECT case_status, COUNT(*) AS cnt FROM case_info GROUP BY case_status </select>前端拿到 List
4. 数据库设计要点与初始化流程
4.1 六张核心表的字段规划
数据库设计是论文里的大章节，我直接把我这版表结构的关键字段列出来，你照着建库建表基本可用。
第一张用户表 sys_user，字段包括：id、username、password（存 BCrypt 加密后的密文）、real_name、role、phone、email、status、create_time、update_time。密码这块千万不要明文存储，哪怕毕设项目也要用 BCryptPasswordEncoder 加密，这是最基本的安全素养，答辩老师大概率会问。
第二张客户表 client_info，字段包括：id、client_name、client_type（个人或企业）、phone、id_card、address、remark、create_time。客户和案件的关系是一对多。
第三张案件表 case_info，字段包括：id、case_no、case_title、case_type、case_status、client_id、lawyer_id、assistant_id、case_amount、accept_time、close_time、description、create_time。
第四张案件材料表 case_material，字段包括：id、case_id、file_name、file_path、file_size、uploader_id、upload_time。
第五张费用记录表 case_fee，字段包括：id、case_id、fee_type、fee_amount、direction（收入或支出）、operator_id、create_time。
第六张系统通知表 sys_notice，字段包括：id、title、content、target_user_id、is_read、create_time。
前端页面路由和按钮权限，不需要做成表存数据库，直接用后端接口返回的角色信息在 Vue 路由守卫里判断即可。这一点和小型项目“能跑就行”的定位匹配。
4.2 SQL 脚本执行的顺序与避坑
拿到数据库脚本后，正确的导入顺序是：先创建数据库，再按 sys_user -> client_info -> case_info -> case_material -> case_fee -> sys_notice 的顺序建表。因为存在外键关联，从表必须先于主表创建。
我用 Navicat 演示操作流程：新建连接，填用户名 root 和密码；右键创建数据库，字符集一定要选 utf8mb4，不然案件描述里有生僻字或表情符号会乱码；在新建数据库上右键“运行 SQL 文件”，选择项目带的 xxx.sql 脚本。
这里有个非常容易踩的坑：脚本文件里如果包含 DROP DATABASE 语句，执行时千万看清楚，别把整个库的表都删了。而且初始化数据里通常带一个管理员账号，一般是 admin / admin123，但密码是加密后的字符串，不是明文，直接拿这个密文去登录是登不进去的——后端代码里密码比较逻辑用的是 BCrypt，所以初始数据也必须是 BCrypt 生成的密文。遇到这种情况，最简单的解决办法是直接用项目里提供的注册接口创建新账号，再把新账号的角色改成管理员，避免因密文不对导致的大量排查时间。
5. 环境搭建与部署实操
5.1 后端启动前必须检查的五个配置项
我把部署阶段这套东西整理成一份“检查清单”，按顺序过一遍，启动成功率会高很多：
第一，JDK 版本要匹配。项目如果是基于 Spring Boot 2.7 开发的，JDK 1.8 或 11 都行；如果是 Spring Boot 3.x，JDK 必须 17 及以上。用 java -version 先确认版本，不对就换。
第二，Maven 配置。最新热词里有 springboot 版本太高、maven 项目构建方法这类搜索，说明大家在构建上卡过。建议在项目的 pom.xml 里看一下 parent 标签中的 spring-boot-starter-parent 版本，并确认自己的 Maven 仓库能拉到对应依赖。国内建议配置阿里云镜像：
<mirror> <id>aliyunmaven</id> <mirrorOf>*</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>第三，MySQL 连接配置。在 application.yml 里面确认数据库地址、账号、密码和本机一致，这是后端能连上数据库的前提。注意到热词里有 mysql ssl 连接错误，这个问题通常只需要在连接参数里加 useSSL=false 解决。
spring: datasource: url: jdbc:mysql://localhost:3306/law_firm_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver第四，MyBatis-Plus 的 mapper-locations 配置路径要和 XML 文件实际位置一致。默认是 classpath*:mapper/*.xml，如果 XML 文件放在 resources/mapper 下，就按默认不用改。
第五，启动类的位置注意别放错。Spring Boot 启动类必须放在所有 Controller、Service 所在包的根路径上，不然组件扫描不到。我见过不少同学把启动类随手放在某个子包里，结果一启动就 404，实际就是扫描范围不对。
5.2 前后端分离部署的两种方式
本地联调阶段，前后端分离开发通常这样跑：后端在 IDEA 里直接启动，端口默认 8080；前端在项目目录下执行 npm install，再执行 npm run serve，Vue 开发服务器端口一般是 8081，前端通过 vite.config.js 里的 proxy 配置把 /api 的请求代理到后端地址。
如果要用 nginx 做演示部署，可以执行 npm run build，把生成的 dist 目录拷贝到 Nginx 的 html 目录下，再在 nginx.conf 里配置端口和代理：
server { listen 80; server_name localhost; root /usr/share/nginx/html/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080; } }注意：前端路由用的是 history 模式时，Nginx 需要额外配置 try_files $uri $uri/ /index.html;，不然刷新页面会 404。这是一个显著的坑，不做这个配置，页面第一次能打开，一按 F5 刷新就丢了。如果是用默认的 hash 模式到没有这个烦恼，但 URL 会多一个 # 号，我建议直接用 history + try_files 方案，观感更专业。
5.3 一键启动脚本的积累
开发调试过程中，我习惯把启动步骤固化成脚本，省得每次手动敲命令。项目根目录下创建一个 start.sh：
#!/bin/bash echo "===== 启动后端 =====" cd /app/backend nohup java -jar law-firm-system.jar > backend.log 2>&1 & echo "===== 启动前端 =====" cd /app/frontend/dist python3 -m http.server 8081 & echo "===== 启动 nginx =====" nginx -c /app/nginx/nginx.conf这套脚本尤其适合写进部署文档，评委老师看的时候会觉得你的交付物很完整。就算你不用 Linux，也可以在 windows 下用 bat 文件完成类似功能。
6. 常见问题与排查技巧
6.1 端口占用导致启动失败
后端启动时报端口被占用是非常高频的问题。8080 端口被其他进程占时，报错里会有明显的 Port 8080 was already in use。处理办法：Windows 下用 netstat -ano | findstr 8080 查出占用进程 PID，再用 taskkill /PID /F 强制结束。Linux 下用 lsof -i:8080 查 PID，然后 kill -9 处理。
如果你不想杀进程，也可以直接改端口。在 application.yml 里加 server.port: 8090，前端代理也跟着改成 http://localhost:8090，能绕开大部分冲突。
6.2 前端页面能打开但接口 404
这个问题背后的原因通常是代理配置没生效或后端接口路径写错。先用浏览器开发者工具看 Network 面板里的请求 URL，确认是相对路径还是带完整域名的路径。如果所有接口都返回 404，先从后端日志确认接口确实注册了没有，再到 controller 类上看看 @RequestMapping 是不是漏写了前缀。
还有一个常见的杂音：Spring Boot 内置的 Whitelabel Error Page 会显示 404 错误页，导致很多同学误以为接口没写对。实际上 Whitelabel 表示的是“后端没有匹配到路由”，如果有静态资源目录里的 index.html 倒是能打开，但你的 /api/case/list 路径就是找不到 controller。
6.3 数据库乱码和中文数据异常
数据库乱码八成是字符集不统一造成的。建库时选了 utf8mb4，但 Java 连接串里没写 characterEncoding=utf8，传输过程就会乱码；或者是 MySQL 服务端的默认字符集是 latin1，需要去 my.ini 里修改：
[mysqld] character-set-server=utf8mb4改完之后重启 MySQL 服务，再用 Navicat 查看数据库属性确认字符集，已经存在的表还要单独转一下字符集。如果你打开前端发现中文正常，但后台命令行里查出来是问号，那就是命令行客户端本身的编码问题，在 mysql 命令行执行 set names utf8mb4; 再查就行，程序里的数据实际上没受影响。
6.4 Maven 依赖下载卡住或失败
Maven 依赖下载到一半报错，通常是网络问题。首先检查项目用的 Maven 仓库地址，在 settings.xml 里确认是不是阿里云镜像。如果镜像配了还报错，把本地仓库 ~/.m2/repository 下对应的依赖目录删掉，重新构建，避免残留半个 jar 包导致的冲突。
热词里提到 idea 2026 怎么配置 springboot 服务，其实 IDEA 里要让 Maven 重新加载只需要点一下 Maven 侧边栏的刷新按钮，或者右键项目选择 Maven -> Reload project。
6.5 案件状态更新后前端没反应
这个问题的表现形式是：操作成功提示弹出来了，但表格里的状态没变。通常是因为修改状态后没有重新加载列表数据。在执行成功回调里调用获取列表的方法；或者你对 el-table 绑定了新数据，但没更新对应的行对象。
我的经验是，更新接口返回最新案件对象，前端直接替换当前行：
const res = await updateCaseStatus(caseId, newStatus); if (res.code === 200) { row.caseStatus = newStatus; }这样不用整表刷新，交互上也流畅很多。
7. 论文写作与答辩准备的几个提示
7.1 论文目录怎么组织
论文结构建议按常规软件工程的顺序来写：第一章绪论讲背景与意义，第二章核心技术介绍（Spring Boot、Vue、MySQL、MyBatis-Plus），第三章系统分析包含可行性分析和需求分析，第四章系统设计画整体架构图和数据库 E-R 图，第五章系统实现截核心页面配代码片段，第六章系统测试写功能测试表。
论文的截图要讲究一点：每个模块至少截一张图，但不要全放完成后的大红色页面，要适当展示操作过程，比如弹窗新增、列表筛选后的结果，这能说明系统确实可操作。
7.2 答辩演示的策略
演示时的顺序我建议按这个逻辑走：先用管理员登录，展示用户管理、案件分配；再切换律师账号，展示案件办理与状态推进；最后用客户账号演示查看进度。这个顺序能自然呈现出权限差异、流程设计，也最容易被评委理解系统价值。
提前想好几个问题的答案，十有八九会被问到：“一个案件从委托到归档要经历哪些流程？”“不同角色分别能做什么操作？”“如果两个律师同时处理一个案件，会不会产生冲突？”“密码是怎么加密的？”这四个问题都在前面内容里出现过，答辩前过一遍思路，完全能对付过去。
7.3 最后再讲一句大实话
做了这么多毕设辅导，我觉得这类管理系统项目真正拉开差距的地方，不在代码量多少，而在业务完整性。你把案件状态流转做出来，把文件上传链路跑通，把 JWT 认证加好，这三个亮点已经超过了 70% 的同类毕设。剩下的，就是把你踩过的坑和解决过程写进文档里——那些真实排错细节，恰恰是答辩现场最能体现你确实自己动手做了的证明。
