SpringBoot+Vue档案管理系统毕业设计完整指南与避坑经验-平芜编程栈

这份“SpringBoot+Vue档案管理系统”是Java Web方向非常典型的毕业设计选题。网上这类源码包很多，但大部分同学拿到手以后，真正卡住的往往不是代码本身，而是“不知道怎么把它变成自己的东西”——数据库怎么初始化、接口文档怎么对照着看、前后端联调报错怎么查、答辩的时候老师会追问哪些点。这篇东西我就按实际开发者的视角，把这个项目的完整脉络、核心设计、部署步骤和避坑经验一次性讲透，让你不仅能跑起来，还能讲清楚。

1. 项目整体设计与选题逻辑

1.1 毕业设计为什么要选档案管理系统

档案管理系统是Java Web方向毕业设计里的常青树。原因很直白：业务场景清晰、功能边界明确、技术栈能够完整覆盖，而且评委老师对这些系统足够熟悉，不会在业务层面刁难你。

档案管理的核心本质就是对“档案实体信息”和“流转过程”的数字化记录。一套完整的档案管理系统，至少要覆盖档案录入、分类存储、检索查询、借阅审批、归还登记、统计汇总这几条主线。这些功能点落在技术实现上，恰好对应了后端的增删改查、关联查询、状态流转，以及前端的表格展示、表单提交、流程反馈。说白了，这就是一个把“CRUD”玩出合理业务逻辑的过程，对毕设来说完全够用。

这类系统真正要比拼的，不是你用了多花哨的框架，而是你对业务完整性的理解。比如借阅审批的流程状态怎么管理、档案编号怎么自动生成、不同角色登录后能看到的菜单和操作按钮有什么区别——这些才是评委关注的东西，也是源码包拉开差距的地方。

1.2 前后端分离架构为什么是当前的主流选择

传统Java Web毕设用的是JSP+Servlet或者Thymeleaf模板渲染，页面和接口全部揉在一起。而现在SpringBoot+Vue前后端分离的架构，已经在实际企业开发中占据绝对主流，毕设选型自然也跟着靠拢了。

前后端分离带来的核心变化是：前端通过Ajax请求调用后端接口获取JSON数据，再由Vue负责渲染渲染到页面上。SpringBoot后端只负责业务逻辑和接口返回，不关心页面是怎么画的。这种架构有几个天然优势：

前端开发和后端开发可以完全并行，互相不阻塞。
后端接口可以被多端复用，网页端、手机端共用一套API。
部署时前端打包成静态文件，后端打包成独立服务，互不干扰。
开发时调试方便，接口返回的JSON直接就能看明白。

在这个项目里，Vue侧采用了vue-cli创建的标准工程结构，配合vue-router做页面路由、axios做HTTP请求、Element-UI做页面组件库，这些组合已经是国内Vue生态最成熟的一套搭配。即使你没学过Vue，照着这组件的套路也能快速上手改页面。

1.3 项目目录结构与模块划分

从源码包解压后的目录布局，通常能看到两个并列的根目录，一个前端一个后端，这个划分本身就是一种架构设计。

后端工程（一般是springboot-archive或类似命名）使用Maven标准目录结构，分包约定如下：

src/main/java ├── com.example.archive │ ├── controller // 控制层，接收请求参数并返回结果 │ ├── service // 业务层，处理核心逻辑 │ ├── mapper // 数据访问层，对接数据库操作 │ ├── entity // 实体类，对应数据库表 │ ├── config // 配置类，放WebConfig、MybatisPlusConfig等 │ ├── common // 通用类，放Result封装、异常处理等 │ └── utils // 工具类 src/main/resources ├── application.yml // SpringBoot核心配置文件 ├── mapper // XML映射文件，放复杂SQL └── sql // 数据库初始化脚本

前端工程（一般是archive-web或vue-archive）按Vue标准结构组织：

src ├── api // 接口请求封装，按模块划分文件 ├── assets // 静态资源 ├── components // 公共组件 ├── router // vue-router路由配置 ├── store // vuex状态管理 ├── views // 页面组件 ├── App.vue // 根组件 └── main.js // 入口文件

这种分包思路本身就是一个加分项。答辩的时候，老师让你介绍项目结构，你如果能按“控制层-业务层-数据访问层”这个链路把后端的请求处理流程讲清楚，比什么空话都管用。

2. 数据库设计与SQL脚本解析

2.1 表结构设计的核心思路

任何复杂的业务系统，底层都是几张核心表在支撑。我先按档案管理这个场景拆解一下一般在SQL脚本里出现的几张核心表结构设计思路，以及为什么这么设计。

第一类是系统基础表，典型的是用户表，我直接贴一个常见的表结构来看看字段设计逻辑：

CREATE TABLE sys_user ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT '主键', username VARCHAR(50) NOT NULL UNIQUE COMMENT '登录名', password VARCHAR(100) NOT NULL COMMENT '密码（MD5加密存储）', real_name VARCHAR(50) COMMENT '真实姓名', role VARCHAR(20) COMMENT '角色：ADMIN-管理员 USER-普通用户', department VARCHAR(100) COMMENT '所属部门', phone VARCHAR(20) COMMENT '联系电话', status INT DEFAULT 1 COMMENT '状态：1启用 0禁用', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间' ) COMMENT '系统用户表';

用户名设置唯一约束，这是防止重复账号的第一道防线。密码字段留了100个长度，是因为不能存明文，需要MD5加密后密文比原始密码长得多。role字段是这个系统权限控制的命根子，管理员和普通用户看到的菜单和按钮就靠它区分。

第二类是档案核心表，一般叫archive_info。它的字段是业务逻辑最集中的地方：

CREATE TABLE archive_info ( id BIGINT AUTO_INCREMENT PRIMARY KEY, archive_no VARCHAR(50) NOT NULL UNIQUE COMMENT '档案编号', title VARCHAR(200) NOT NULL COMMENT '档案标题', category_id BIGINT COMMENT '分类ID，关联archive_category', content TEXT COMMENT '档案内容摘要', file_url VARCHAR(255) COMMENT '电子文件存储路径', secret_level VARCHAR(10) DEFAULT '普通' COMMENT '密级：普通/秘密/机密', status VARCHAR(10) DEFAULT '在库' COMMENT '状态：在库/借出/已销毁', create_by BIGINT COMMENT '创建人ID', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) COMMENT '档案信息表';

archive_no设置唯一约束，并且通常用业务规则生成，比如“DA + 年月日 + 四位流水号”，这是档案业务里最有辨识度的逻辑，也是答辩时值得展开讲的一个点。status字段用来标记档案当前状态，它和借阅表是联动更新关系。

第三类是借阅流程表，一般叫archive_borrow。这张表记录了档案的每一次借阅申请和审批过程：

CREATE TABLE archive_borrow ( id BIGINT AUTO_INCREMENT PRIMARY KEY, archive_id BIGINT NOT NULL COMMENT '档案ID', user_id BIGINT NOT NULL COMMENT '借阅人ID', borrow_reason VARCHAR(255) COMMENT '借阅事由', borrow_time DATETIME COMMENT '借出时间', return_time DATETIME COMMENT '归还时间', status VARCHAR(10) DEFAULT '待审批' COMMENT '状态：待审批/已批准/已驳回/已归还', approver_id BIGINT COMMENT '审批人ID', approve_comment VARCHAR(255) COMMENT '审批意见' ) COMMENT '档案借阅表';

这张表的状态设计是审批流程的核心，从“待审批”流转到“已批准”再到“已归还”，每一步都是一次UPDATE操作。借阅表还有一个隐藏价值：它记录了档案的完整流转历史，方便管理层做借阅统计。

2.2 SQL脚本导入时必须注意的问题

拿到源码包里的.sql文件，很多人第一步就栽在导入上。最常见的报错是版本兼容问题，比如MySQL 5.7能跑的脚本，在MySQL 8.0上面偶尔会因字符集默认值不同而报错。

建议按这个顺序检查SQL脚本：

先确认脚本头部有没有CREATE DATABASE语句，没有的话自己手动建库再选择库执行。
确认表名前缀是否一致，有的脚本统一用sys_前缀，有的直接裸表名，这影响后面的实体类注解。
查看是否有外键约束。外键是双刃剑，维护了数据一致性，但也容易导致测试数据插入顺序错了就报外键冲突。
查看初始数据里有没有统一的初始密码，比如所有用户密码都是123456的MD5加密值，这对接下来的登录测试很重要。

如果是用Navicat导入，右键运行SQL文件前，先手动建好库再选择目标库运行，能避免不少字符集传输上的小毛病。导入完成后，先跑一条SHOW TABLES，确认核心表都在，再进行下一步。

2.3 验证测试数据是否完善

一个合格的毕设源码包，初始化数据至少要覆盖三种角色账号（管理员、普通用户、审批人）和几份状态不同的档案测试数据。这些数据的作用不只是让你登录用，更是演示功能时的“道具”。

我拿到项目之后，习惯先看这几类数据：

用户表里至少3条记录，能测试不同角色登录后的界面差异。
档案分类表至少有层级关系，能验证分类树是否正常渲染。
档案信息表里有不同状态的记录：在库的可以发起借阅流程、借出的能验证归还流程。
借阅表里有几条历史记录，能让借阅列表页面不至于空空荡荡。

如果测试数据不全，我的建议是你自己动手补几条。别嫌麻烦，这个操作会对你理解表结构关系帮助极大——你会被迫去搞清楚每张表的外键到底指向谁。而且答辩时老师一旦问起“系统里有没有测试数据”，你能直接登录演示，比嘴上说“接口能跑”有说服力得多。

3. 后端SpringBoot核心实现

3.1 从pom.xml看技术选型

打开后端工程的pom.xml，你会发现这个项目实际用的是SpringBoot 2.x系列，版本号常见为2.3.x或2.5.x。这个选择不是随意的，是因为2.x版本对MyBatis-Plus等国产框架的适配最成熟，网上能找到的资料也最多。

核心依赖通常包含这几个：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.4.2</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency>

MyBatis-Plus在这个项目里的地位很关键：它提供了BaseMapper接口，让单表CRUD不需要手写SQL，同时自带分页插件。对毕设项目来说，用它能省掉大量重复的Mapper XML编写，把精力放到业务逻辑上。

你要是问这个依赖组合意味着什么，说白了就是：SpringBoot负责HTTP请求处理和对象管理，MyBatis-Plus负责数据库操作，Lombok（如果引入了）负责减少实体类的getter/setter代码，Hutool或Apache Commons负责各种工具方法。这套组合在Java毕设里已经算标准答案了。

3.2 application.yml配置的完整解读

application.yml是SpringBoot项目的命脉。我打开一个典型的配置来看：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/archive_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 servlet: multipart: max-file-size: 50MB max-request-size: 50MB mybatis-plus: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.archive.entity configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true

这里有几处配置很容易让人踩坑：

serverTimezone必须设置，MySQL 8.0驱动强制要求时区，不加直接报警告甚至连不上。
useSSL=false是用来消除SSL握手报错的，本地开发毫无影响。
mapper-locations指定了XML文件位置，如果你的XML放错目录，项目启动时MyBatis会直接报Invalid bound statement。
map-underscore-to-camel-case是下划线转驼峰映射，数据库字段create_time才能正确映射到实体的createTime属性，这也是MyBatis-Plus能帮你做自动填充的基础。

密码别用root/123456这种无所谓，本地开发完全能跑，但部署上线前一定要改。

3.3 统一返回结果与登录认证的设计

后端接口返回给前端的JSON，必须有一个统一的格式结构。这个项目里一般会封装一个Result类：

public class Result<T> { private Integer code; // 200成功，500失败 private String message; // 提示信息 private T data; // 业务数据 public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }

这层封装很有必要：前端axios拦截器可以统一判断code，等于200就直接取data，不等于200就弹出error消息。如果没有这层封装，前端就得在每个请求里自己判断HTTP状态码，一旦后端返回的业务异常是HTTP 200但业务上不成功的情况，处理起来就很混乱。

登录认证这块，核心是用拦截器校验Token。登录成功之后后端返回一个token字符串，前端存在localStorage里，每次请求在请求头带上这个token，后端过滤器校验通过才放行请求。写成代码大致是这样的逻辑：

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token != null && JwtUtil.verify(token)) { return true; } response.setStatus(401); return false; } }

这个拦截器要注册到WebMvcConfigurer里，并配置拦截路径排除登录接口和静态资源路径。注意一个常见错误：如果前端请求带了token但后端拦截器没有在OPTIONS预检请求时直接放行，浏览器的跨域预检就会失败，页面表现为“接口返回401，但后端日志没收到请求”。解决方法是拦截器里先判断请求方法为OPTIONS就直接放行。

3.4 核心接口的Controller写法

档案管理模块的Controller是整个系统的门面。以新增档案接口为例，典型的写法如下：

@RestController @RequestMapping("/api/archive") public class ArchiveController { @Resource private ArchiveService archiveService; @PostMapping public Result<Boolean> add(@RequestBody ArchiveInfo archiveInfo) { String archiveNo = "DA" + new SimpleDateFormat("yyyyMMdd").format(new Date()) + String.format("%04d", archiveService.countToday() + 1); archiveInfo.setArchiveNo(archiveNo); archiveInfo.setStatus("在库"); return Result.success(archiveService.save(archiveInfo)); } @GetMapping("/page") public Result<Page<ArchiveInfo>> page(@RequestParam Integer pageNum, @RequestParam Integer pageSize, @RequestParam(required = false) String keyword) { Page<ArchiveInfo> page = archiveService.queryPage(pageNum, pageSize, keyword); return Result.success(page); } @PutMapping("/{id}") public Result<Boolean> update(@PathVariable Long id, @RequestBody ArchiveInfo archiveInfo) { archiveInfo.setId(id); return Result.success(archiveService.updateById(archiveInfo)); } }

这个Controller有几个值得说的细节：

@RestController注解表示接口返回的是JSON数据，不是页面，这是前后端分离的标志。
分页接口的keyword参数，实现了按标题模糊搜索的能力，通过MyBatis-Plus的like条件完成。
@RequestMapping类的共用前缀“/api/archive”，让所有档案相关接口路径统一。
档案编号生成逻辑放在新增接口里，用时间戳加当日流水号组合，保证唯一性。

3.5 分页查询与条件搜索的SQL实现

分页和搜索是档案列表页的两个核心诉求。用MyBatis-Plus实现分页，先在配置类里装好分页插件：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

然后在Service里写查询逻辑：

public Page<ArchiveInfo> queryPage(int pageNum, int pageSize, String keyword) { LambdaQueryWrapper<ArchiveInfo> wrapper = new LambdaQueryWrapper<>(); if (StringUtils.hasText(keyword)) { wrapper.like(ArchiveInfo::getTitle, keyword) .or().like(ArchiveInfo::getArchiveNo, keyword); } wrapper.orderByDesc(ArchiveInfo::getCreateTime); return archiveMapper.selectPage(new Page<>(pageNum, pageSize), wrapper); }

LambdaQueryWrapper是MyBatis-Plus的类型安全查询构造器，把查询条件是写在Java代码里，不直接拼SQL字符串，防止SQL注入风险。当数据量达到几百条以上，分页是刚需，不然页面渲染几千行表格的效率会很糟糕。

这里我说一个经验：如果你看了源码发现他用的不是LambdaQueryWrapper这种写法，而是直接在XML里写动态SQL，也完全没问题，只是开发效率低一些。毕设答辩时不需要纠结用哪种，只要能说清楚“我是怎么控制查第几页、每页几条的”，就算过关。

4. 前端Vue核心实现

4.1 Vue脚手架结构与运行机制

前端工程是标准的Vue 2.x + Element-UI项目，使用vue-cli手动创建。整个运行机制可以概括为一句话：main.js创建Vue实例，通过router控制页面切换，页面里的Vue组件通过axios向后端接口发请求，拿到数据后渲染到模板里。

main.js入口文件的核心配置大概是这样的：

import Vue from 'vue' import App from './App.vue' import router from './router' import store from './store' import ElementUI from 'element-ui' import 'element-ui/lib/theme-chalk/index.css' Vue.use(ElementUI) Vue.config.productionTip = false new Vue({ router, store, render: h => h(App) }).$mount('#app')

这段代码说明了几个关键点：

ElementUI全局注册后，整个项目的所有Vue文件都可以直接使用el-table、el-form等组件，不需要每个页面单独import。
router全局注入，页面里的路由跳转和导航守卫逻辑就靠它管理。
store注入是Vuex状态管理的入口，用于管理全局状态，比如用户登录信息、菜单权限列表。

4.2 路由设计与管理

路由的配置在router/index.js里，一个典型的router配置长这样：

const routes = [ { path: '/login', component: () => import('@/views/Login.vue') }, { path: '/', component: () => import('@/layout/Layout.vue'), redirect: '/dashboard', children: [ { path: 'dashboard', component: () => import('@/views/Dashboard.vue') }, { path: 'archive/list', component: () => import('@/views/archive/ArchiveList.vue') }, { path: 'archive/category', component: () => import('@/views/archive/ArchiveCategory.vue') }, { path: 'borrow/apply', component: () => import('@/views/borrow/BorrowApply.vue') }, { path: 'borrow/approve', component: () => import('@/views/borrow/BorrowApprove.vue') }, { path: 'user/manage', component: () => import('@/views/user/UserManage.vue') } ] } ]

使用() => import这种按需懒加载方式，让每个页面打包成独立chunk，首屏只加载登录页和框架页，等真正访问某个功能模块时才加载对应JS，启动速度明显更快。

路由守卫是登录拦截的关键机制：

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

这段逻辑的含义是：没有token的用户访问任何非登录页，都会被强制踢回登录界面。这个功能也是后端JwtInterceptor的双保险，前端通过路由守卫拦截一部分，后端通过接口拦截兜底，形成双重安全屏障。

4.3 axios封装与接口调用规范

前端请求后端接口，不能每个页面都直接使用axios.get拼接完整URL，而是应该把axios实例统一封装，配置基础地址和请求拦截器。

项目里的api/request.js一般长这样：

import axios from 'axios' import { Message } from 'element-ui' import router from '@/router' const request = axios.create({ baseURL: 'http://localhost:8080/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = token } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { Message.error(res.message) return Promise.reject(new Error(res.message)) } return res }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } Message.error('请求失败，请检查网络或后端服务') return Promise.reject(error) } ) export default request

这里的关键点在baseURL上，它统一了接口地址前缀为/api。后端Controller的RequestMapping里也是/api开头，这样代理转发时就不需要额外修改路径。

按模块拆分API是一种值得保持的好习惯。比如api/archive.js专门管理档案相关接口：

import request from './request' export function getArchivePage(params) { return request({ url: '/archive/page', method: 'get', params }) } export function addArchive(data) { return request({ url: '/archive', method: 'post', data }) } export function updateArchive(id, data) { return request({ url: `/archive/${id}`, method: 'put', data }) } export function deleteArchive(id) { return request({ url: `/archive/${id}`, method: 'delete' }) }

按模块拆分的好处是页面里引用的方法名简洁，而且接口发生变更时只需要改一处。答辩时老师如果问axios封装的意义，你可以直接说“为了避免每个页面重复写URL和拦截逻辑，统一在这里管理”。

4.4 核心页面实现：档案列表与借阅管理

档案列表页是整个前端的门面页面。它的实现逻辑很典型：进页面先调用后端分页接口，拿到数据渲染成表格，搜索框触发重新查询，操作列按钮触发新增、编辑、删除方法。

用el-table渲染时，需要注意数据格式的对应关系。后端返回的JSON里字段是驼峰命名createTime，前端表格的prop属性也要写createTime，数据才能显示出来。

借阅管理页面稍微复杂一点，它涉及流程状态流转的界面反馈。核心页面里一般有申请借阅按钮和审批操作按钮，审批通过时把状态更新为已批准，驳回时填驳回原因。前端页面根据当前状态控制不同按钮的显示隐藏，比如状态为“已归还”的行就不需要再显示“审批”按钮。

这里用一个条件判断来控制按钮展示：

<el-table-column label="操作" width="200"> <template slot-scope="scope"> <el-button v-if="scope.row.status === '待审批'" type="primary" size="mini" @click="approve(scope.row)">审批</el-button> <el-button v-if="scope.row.status === '已批准'" type="success" size="mini" @click="returnArchive(scope.row)">归还</el-button> </template> </el-table-column>

这种动态按钮的思路是流程系统的设计精髓。整个列表页的状态流转逻辑，考验的是你对前端条件渲染的熟练度：多少种状态对应多少种操作，每种操作完成后调哪个接口。把这些理清楚了，毕设演示环节就能顺利进行下去。

5. 接口文档与前后端联调流程

5.1 接口文档应该怎么读

拿到源码包里的接口文档，第一句话要强调的就是：别看代码，先看文档。一份规范的项目接口文档通常包含以下结构：

接口概述：说明该文档覆盖哪些模块，基础URL是什么。
通用约定：请求头带的认证参数是什么、返回格式是什么样。
详细接口列表：每个接口的URL、Method、请求参数、响应参数、示例。

以档案模块为例，接口文档中应该能看到类似下面的表格：

接口功能	请求方式	接口路径	参数说明
分页查询档案	GET	/api/archive/page	pageNum页码、pageSize每页条数、keyword关键词
新增档案	POST	/api/archive	档案JSON对象
修改档案	PUT	/api/archive/{id}	路径参数id + 档案JSON对象
删除档案	DELETE	/api/archive/{id}	路径参数id

看接口文档时需要重点确认三件事：接口路径是否带/api前缀；GET请求参数是在query里还是路径里；POST请求体是JSON格式还是form格式。这三个点对应前端调用时的三个坑，任何一处不对应，联调必定白跑。

5.2 档案模块接口设计逐个拆解

以借阅审批流程为例，文档里设计的接口一般是：

POST /api/borrow/apply —— 提交借阅申请。参数：archiveId、userId、borrowReason。这个接口做的事情是校验档案当前状态是否为在库，是则插入一条借阅记录，状态设为待审批，同时把archive_info表的status改为借出。注意这里有一个事务问题：插入借阅记录和更新档案状态必须放在一个事务里，否则可能出现借阅记录存在但档案状态没改的脏数据。SpringBoot在Service方法上加上@Transactional注解就能解决。
PUT /api/borrow/approve/{id} —— 审批借阅。参数：approveComment、approveResult。这个接口把借阅记录状态从待审批改成已批准或已驳回。如果驳回，需要把档案状态还原为在库，因为此前申请时已经把它改成了借出状态。
PUT /api/borrow/return/{id} —— 归还档案。这个接口把借阅记录状态改为已归还，同时把档案状态再改回在库。

这三个接口就是一条完整的业务流程闭环。理解了这条链路，整个借阅模块的代码你就全部拿下了。我建议你拿着接口文档，按这个链条在源码里找到对应的Controller和Service方法，画一遍流程图，比自己瞎翻源码高效得多。

5.3 跨域配置与联调常见坑

前后端分离开发模式下，前端地址是localhost:8081，后端地址是localhost:8080，端口不同就产生了跨域问题。浏览器默认情况下不允许跨端口发请求，所以后端必须配置跨域支持。

在SpringBoot里加一个WebMvcConfigurer实现类即可：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

注意allowedHeaders("*")这行很重要，前端请求头里带Authorization，后端必须放开header权限才能接收。

还有一种常见的联调方式：前端通过proxy代理，把/api开头的请求转发到后端8080端口。在vue.config.js里配置：

module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }

使用代理的好处是前端代码里不需要写完整的后端地址，并且通过代理转发后不存在跨域问题。但要注意，后端仍然需要配置CORS，因为直接浏览器访问接口时也可能会用到。

跨域配置上我踩过一个比较典型的坑：allowCredentials(true)和allowedOriginPatterns("")必须配合使用，如果只设置allowedOrigins("")，浏览器会直接拦截并报CORS错误，因为credentials模式下不允许通配符来源。用allowedOriginPatterns就能绕过这个限制。这个问题在联调时出现的频率极高，遇到报错信息里有CORS字样，优先检查这两行配置。

6. 数据库初始化和后端部署排错

6.1 从零初始化数据库的完整操作

拿到SQL脚本，很多人直接双击执行，结果报错一堆，根本分不清是SQL语法问题还是环境问题。我建议你按这套流程操作：

第一步，在Navicat或命令行里创建数据库：

CREATE DATABASE IF NOT EXISTS archive_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

utf8mb4字符集为什么重要？因为如果脚本里有表情符号或特殊字符，utf8mb3（也就是平常说的utf8）存不下，直接报Incorrect string value错误。这也是很多人导入后出现中文乱码的根本原因。

第二步，选择archive_db数据库，运行SQL脚本。Navicat里的操作是：右键数据库 -> 运行SQL文件 -> 选择下载的archive.sql。

第三步，验证导入结果。执行以下查询，确认核心表和初始数据都存在：

SHOW TABLES; SELECT * FROM sys_user; SELECT * FROM archive_info;

如果sys_user表能查到数据，且密码字段是一串MD5密文，就说明初始数据没问题。接下来就可以启动后端了。

6.2 后端启动失败的排查思路

后端项目导入IDEA后，最常遇到的是Maven依赖下载失败。表现为pom.xml文件里某些依赖被标红，项目启动报ClassNotFoundException。

排查方法是：点IDEA右侧Maven面板，执行clean刷新，再执行install重新下载依赖。如果网速慢导致依赖下载超时，可以在Maven的settings.xml里配置国内镜像源，提高下载速度。

另一类启动失败集中在数据库连接上。启动日志里出现“Cannot create PoolableConnectionFactory”之类的报错，优先检查application.yml里的username、password和url配置是否正确。特别是MySQL 8.0的驱动类名已经从com.mysql.jdbc.Driver改成了com.mysql.cj.jdbc.Driver，如果你的依赖版本和驱动类名不匹配，启动必败。

还有一类少见的坑是端口占用。8080端口被其他程序占用了，启动日志会报端口绑定失败。解决方式是在application.yml里换一个端口，比如改成8081，同时记得把前端axios的baseURL同步改掉，否则联调时前端找不到后端。

6.3 前端启动和依赖安装的注意点

前端工程项目，第一步永远是安装依赖。在项目根目录执行：

npm install

这个命令会根据package.json生成node_modules目录，项目才能正常运行。如果安装速度慢，可以临时使用淘宝镜像：

npm install --registry=https://registry.npmmirror.com

或者使用yarn安装：

yarn install

依赖安装完成后执行：

npm run serve

启动成功后会显示本地访问地址，一般是http://localhost:8081。这里要提醒一个前端启动的经典错误：如果你的Node版本过高，Vue 2项目的依赖编译可能报错，常见的是webpack版本兼容问题。解决办法是升级项目里的webpack相关依赖，或者使用Node 16左右的稳定版本。

6.4 打包部署的核心流程

毕设通常需要演示部署流程，或者将项目打包发布到服务器上供老师访问。后端打包用Maven，前端打包用npm。

后端打包：

mvn clean package -DskipTests

打包完成后，target目录下生成一个jar文件。运行方式：

java -jar archive-system-0.0.1.jar

前端打包：

npm run build

打包完成后，dist目录下是整站的静态文件。把dist文件夹直接部署到Nginx或者Tomcat里，就能提供一个可访问的前端站点。

需要注意，前端打包后的接口地址是写死的localhost:8080，部署到服务器上必须把代码里的baseURL改成服务器的实际IP或域名，否则打包产物在服务器上无法正常请求后端接口。

7. 常见问题排查与答辩技巧实录

7.1 后端运行报错速查表

报错现象	可能原因	解决方案
启动报Failed to determine a suitable driver class	数据库连接配置缺失或URL写错	检查application.yml、确认数据库存在且用户名密码正确
接口返回404	路径写错或Mapper.xml没扫描到	检查Controller的RequestMapping和接口路径、确认mapper-locations配置正确
查询报Invalid bound statement	Mapper接口和XML没有正确绑定	检查XML的namespace和id是否对应接口方法
接口返回500但日志无异常	可能被全局异常处理器吞了	看控制台完整堆栈，或用Postman直接调用看返回
前端登录成功但后续请求401	登录后没把token存到localStorage	检查前端登录成功后的处理代码，确认Authorization请求头正确携带

如果是MyBatis-Plus分页查询出了问题，大概率是分页插件没有注册成功。检查配置类里是否加了MybatisPlusInterceptor这个Bean，没有的话Page对象返回的结果是全部数据而不是单页数据，很多人会忽略这个细节。

7.2 前端运行报错速查表

报错现象	可能原因	解决方案
npm install报错ERESOLVE	依赖树冲突	用npm install --legacy-peer-deps安装
npm run serve后页面空白	Node版本和依赖不兼容	尝试Node 16版本或升级webpack相关依赖
控制台报跨域错误	后端没配置CORS或代理没生效	检查CorsConfig配置和vue.config.js代理是否正确
表格不渲染数据	字段名大小写问题或接口数据结构不对	打开浏览器开发者工具Network面板，查看接口返回的JSON结构
路由跳转后页面刷新404	前端路由用的是history模式但服务器没配回退	改成hash模式，或者Nginx配置try_files

7.3 答辩时高频追问的核心问题

答辩环节老师一般不会让你现场写代码，而是通过追问验证你是否真正理解项目。

常见问题第一个是“你这个项目的权限是怎么实现的”。你需要能说清楚：前端通过路由守卫控制页面访问，后端通过JwtInterceptor拦截请求，具体到菜单和按钮的显示权限通过用户角色判断。能按照这三层讲出来，比笼统说“用了SpringSecurity”更有说服力——很多毕设后端其实没接SpringSecurity，而是用简单拦截器实现的，实话实说是最稳妥的。

第二个高频问题是“如果用户借阅了档案但是一直不归还，怎么处理”。这个问题考的是业务思考能力。你可以回答：借阅记录里已经记录了borrow_time，系统可以在定时任务里扫描超过设定天数未归还的记录进行提醒，后续还能扩展逾期处罚逻辑。没实现也不怕，关键是展示出你的扩展思路。

第三个问题“数据库为什么这几张表要这么设计”，需要你讲清楚每张表的核心用途和表间关联关系。建议找一张ER图或者自己画一遍表关系的草图，做到能对着图把这个结构讲明白。

第四个问题“项目里怎么保证接口的安全性”，别被这个问题吓到。你可以答：登录认证用Token验证，SQL层用了预编译的MyBatis-Plus查询构造器规避注入风险，前端有响应拦截器对401做统一处理。这三点就够撑住了。

7.4 让项目在答辩中更出彩的三个小技巧

首先是准备一份带数据的演示脚本。设计好演示路径：用管理员账号登录，新建一个档案，再切换普通用户账号，提交借阅申请，再切回管理员账号审批通过，最后演示归还流程。这一整条链路走下来，系统的主要功能全部展示到了，评委也不会觉得你在念PPT。

其次是提前准备好几个“为什么”的回答。比如问“为什么用JWT而不用Session”，回答要点是前后端分离场景下，后端无法记录每个跨端的会话状态，Token无状态化能让接口天然支持多端访问，扩展性更好。这个回答既讲清了原理，又展示了技术选型的思考深度。

最后是准备一个“扩展计划”。答辩老师几乎必问“后续你怎么改进这个系统”。回答里可以提三个方向：引入Redis做token缓存和高频数据的缓存加速；增加消息提醒模块，利用WebSocket在审批通过时实时通知借阅人；引入更细粒度的文件预览功能，让电子档案可以直接在线预览而不只是下载。能答出这些，整个答辩的深度就上去了。

8. 项目二次开发的四个实战方向

8.1 方向一：引入Redis优化性能和会话管理

当前项目把token放内存里由每个请求解析，登录状态并不是集中管理的。引入Redis后，可以把登录token存到Redis里并设置过期时间，实现登录状态的集中管理和主动失效。另外，档案分类树这种不频繁变更的数据，可以缓存到Redis里，减少数据库压力，页面二次加载的时候明显提速。

代码层面的改动思路是：登录成功后，将userId作为key，token作为value存入Redis并设置过期时间；在JwtInterceptor里从Redis查这个key是否存在，不存在就拦截请求跳转登录。后续增加“踢人下线”功能时，直接删除Redis里的key就能生效。

8.2 方向二：增加档案导入导出功能

这个方向很多人都需要，也是答辩环节的加分项。可以利用EasyExcel或Apache POI实现档案信息的批量导入和Excel导出。导入时先读取Excel的每一行数据，校验必填字段和编号唯一性，再批量插入数据库。导出则是把数据库查询结果转成Excel流下载。

这个功能特别适合档案管理系统，因为档案管理岗的老师或管理员，日常工作就是和各种Excel表格打交道。实现了这个扩展，系统就从“演示demo”变成了“工具型系统”，说服力完全不一样。

8.3 方向三：增加WebSocket实时消息通知

当前系统里借阅审批流程是单向的，申请人提交后只能自己刷新页面查看状态。引入WebSocket后，审批人审批通过那一刻，申请人的页面能收到实时通知，不用刷新就能看到状态更新。

实现思路不算复杂：后端加一个WebSocket配置类，在审批接口里调用消息发送方法推送给指定用户，前端在Layout组件初始化时建立WebSocket连接。这个点如果做出来，演示环节的现场感很强，而且也是企业开发中偏实战的通信能力，简历上也多了一个可写的经验点。

8.4 方向四：可视化统计报表

档案管理系统天然适合做数据统计展示，这也是评委最愿意看到的具体成果。可以在系统里增加一个统计面板，展示档案分类占比的饼图、借阅趋势的折线图、部门借阅排名的柱状图。图表用ECharts就能实现，后端统计SQL分别按分类、月份、部门分组汇总。

这里有个关键SQL技巧：月份分组在MySQL里直接按DATE_FORMAT(create_time, '%Y-%m')分组，返回的字段是格式化后的月份字符串和统计数据，前端直接就能作为图表x轴数据。统计接口的返回值设计成列表对象或Map直接返回，前端数据结构简单了，联调就快。

这个方向上还有一个实用扩展：把借阅超期档案拉成一张超期清单并加醒目标记，管理层的使用价值立刻显现。

9. 写在最后的实操心得

这套SpringBoot+Vue的档案管理系统，我前后经手过好几套不同来源的版本，心得就一条：源码不等于能力，跑通不等于掌握。你真正要做的，是把它的每一层剥开看一遍，弄清Controller到Service到Mapper的调用链，弄清前端路由到页面到接口的数据流，再顺手按照你自己的理解改两个小功能——比如加一个档案密级筛选，或者把档案列表的排序方式改一下。

改这些简单功能的过程中，你会遇到“为什么改了前端页面不生效”“为什么接口参数变了还是报错”这类问题，而这些问题才真正帮你入门了Java Web开发。项目本身是死的，但你在排查问题的过程中得到的经验，才是毕业设计给你留下的最实在的东西。最后再提醒一句，演示环境一定要提前准备两台电脑或者一主一备的环境配置，演示现场机器翻车是毕设翻车的第一大原因，这条比什么代码技巧都重要。