企业官网建设流程全解析

去年年底我帮一所高校的教研处做年度科研统计，亲眼看着几位老师抱着十几封Excel邮件来回核对："王老师，您这份表里的论文年份格式不对""李老师，您只交了纸质版，电子版缺课题目录那一页"。当时我就想，这个场景太典型了——高校教师教研信息填报这件事，居然还在用最原始的"发模板-收邮件-人工核对"流程。

所以当有人问"基于SpringBoot+Vue的高校教师教研信息填报系统到底怎么设计与实现"时，我特别理解他为什么需要一个完整源码做参考。这不是一个普通的CRUD练习，而是一个真正有业务深度的管理场景：不同角色的操作权限、表单字段的动态变化、审核流程的状态流转、统计报表的实时生成。无论是课程设计、毕业设计，还是作为自己入门JavaWeb的第一份完整项目，这套技术栈SpringBoot+MyBatis+MySQL+Vue都是最稳妥、也最常被问到的组合。下面我用实际做过的思路，把整个系统从需求拆分到部署上线捋一遍，希望能帮你少走弯路。

1. 从Excel漫天飞到在线填报：这类系统的真实需求在哪

做系统之前，最忌讳的就是直接建表写代码。你得先搞清楚，这个系统解决的是谁的什么问题。高校教研信息填报，表面上只是"填表"，实际上背后牵扯的是一整条业务链。

1.1 需求方与使用场景的真实痛点

高校里的教研信息填报，通常发生在每年固定的几个时间点——职称评审前、年终考核时、学科评估期间。教务部门或教研处下发通知，要求各学院教师填报论文、课题、教材、获奖、学术会议等教研成果。传统做法是：

1. 教研处用Excel制作统一模板，发到学院群。
2. 学院秘书转发给每位教师。
3. 教师填写后发回给秘书，秘书逐一检查格式和完整性。
4. 秘书汇总成一个大表，再上报教研处。
5. 教研处人工核对、去重、修正，最终形成全校统计报表。

这个流程的痛点非常明显：文件散落、版本混乱、格式不统一、审核无记录、统计靠手工。更麻烦的是，一个教师可能同时在几个课题里署名，同一年发表多篇论文，人工去重和归类非常耗费时间。系统要做的，不是简单把Excel搬到网页上，而是要让"填报—审核—统计—导出"这条链路在一个闭环里完成。

1.2 角色权限决定系统边界

这类系统的用户通常分三种：

• 普通教师：填报自己的教研成果，查看审核结果，修改被驳回的条目。
• 院系管理员（教研秘书）：审核本学院教师的填报内容，导出本学院统计表。
• 校级管理员（教研处）：查看全校数据，按学院、按年份、按成果类型做汇总统计，管理用户和基础字典数据。

角色权限设计是整个系统的地基。我的建议是：权限不写在业务代码里，而是用角色标识去控制路由、按钮和接口权限。后端用拦截器校验登录态和角色，前端用路由守卫控制页面跳转，按钮级权限可以用自定义指令处理。这样三层配合，才能做到页面看不到、接口调不了，而不是仅仅"前端隐藏一下"。

1.3 功能清单要具体到页面级别

基于这个需求，我的功能拆分大致如下：

• 登录与个人中心：账号密码登录、修改密码、查看个人基础信息。
• 教研成果填报：支持论文、课题、教材、获奖、专利、学术会议等多个成果类型，每个类型的字段不同（论文有期刊名、收录情况，课题有立项单位、经费，获奖有颁奖单位、奖项等级）。
• 审核管理：院系管理员对待审核条目进行通过或驳回，驳回时必须填写驳回理由。
• 统计查询：按年份、学院、成果类型、审核状态等维度组合查询，并支持导出Excel。
• 用户与基础数据管理：院系维护、教师账号维护、成果类型字典维护、年份学期维护。

这些功能分别落在SpringBoot后端的不同模块和Vue前端的不同页面上。做的时候我建议按照"填报—审核—统计"这条主流程去安排优先级，先把主流程跑通，再补辅助功能。

2. 数据库表设计这么规划，后面开发才不会返工

很多人在这个项目上最失败的环节就是数据库设计——要么表建得太粗，所有成果类型塞一张表，字段冗余到没法看；要么建得太细，每类成果一张表，查询和扩展都痛苦。这块值得仔细说说。

2.1 基础表结构：用户、院系、角色

系统的基础数据是用户、院系、角色三张表。用户与院系是多对一关系，用户与角色是多对多关系。但考虑到一个教师通常只属于一个学院，我一般会把用户表直接冗余院系ID，省去中间表的无谓join。

角色表我倾向用固定值：ROLE_TEACHER（教师）、ROLE_COLLEGE_ADMIN（院系管理员）、ROLE_ADMIN（校级管理员），不把角色设计成可动态配置的完整RBAC。原因很简单：这是个内部管理工具，动态角色带来的灵活性，远抵不上它增加的实现复杂度。给毕设或内部系统用，固定角色更加清晰可控。

用户表的核心字段如下：

CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '主键', username VARCHAR(50) NOT NULL UNIQUE COMMENT '登录账号（工号）', password VARCHAR(100) NOT NULL COMMENT '密码（加密存储）', real_name VARCHAR(50) NOT NULL COMMENT '真实姓名', college_id BIGINT NOT NULL COMMENT '所属院系ID', role_code VARCHAR(30) NOT NULL COMMENT '角色编码', email VARCHAR(100) DEFAULT NULL, phone VARCHAR(20) DEFAULT NULL, title VARCHAR(50) DEFAULT NULL COMMENT '职称', status TINYINT DEFAULT 1 COMMENT '账号状态：1启用 0禁用', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_college (college_id), INDEX idx_role (role_code) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

这里有个非常容易踩的坑：role_code不要用数字，直接用字符串。原因很直白——数字通用性强，但在可读性和后续权限判断上，"ROLE_ADMIN"比1直观得多。而且判断时，硬编码字符串不会因为id变动而产生歧义。

2.2 成果数据怎么存：单表加类别标识，比拍脑袋拆表靠谱

论文、课题、教材、获奖、专利的字段差异确实存在，但如果每种类型拆一张表，之后要改字段或者新增类型，代码量会成倍增长。我的做法是：一张教研成果主表 + 一个JSON扩展字段。

让所有类型的公共字段都在主表：填报人、所属学院、成果类型、成果名称、发表/立项/颁奖日期、参与角色（第一作者/通讯作者/主持人/参与人）、审核状态、附件路径。不同类型特有的字段（比如论文的期刊名、影响因子、检索收录情况）统一放进一个extra_info的JSON列。

CREATE TABLE teaching_research_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL COMMENT '填报教师ID', college_id BIGINT NOT NULL COMMENT '所属院系ID', item_type VARCHAR(30) NOT NULL COMMENT '成果类型：paper/topic/book/award/patent', item_name VARCHAR(200) NOT NULL COMMENT '成果名称', role_type VARCHAR(30) DEFAULT NULL COMMENT '本人角色', complete_date DATE DEFAULT NULL COMMENT '发表/立项/获奖日期', extra_info JSON DEFAULT NULL COMMENT '类型特有字段，JSON格式', attach_path VARCHAR(255) DEFAULT NULL COMMENT '附件路径', status VARCHAR(20) DEFAULT 'DRAFT' COMMENT '状态：DRAFT/SUBMITTED/APPROVED/REJECTED', audit_comment VARCHAR(500) DEFAULT NULL COMMENT '审核意见', auditor_id BIGINT DEFAULT NULL COMMENT '审核人ID', audit_time DATETIME DEFAULT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_user (user_id), KEY idx_college (college_id), KEY idx_status (status), KEY idx_type (item_type) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='教研成果主表';

用JSON扩展字段，既避免了一次性建几十个空字段的臃肿，也能应对论文要有期刊音、课题要有立项编号、获奖要有颁奖单位这些差异。MySQL从5.7起原生支持JSON列，配合JSON_EXTRACT也可以做条件查询。这样一张表，查询所有成果时只要WHERE user_id = ?，统计时只要GROUP BY item_type，比拆表简单得多。

2.3 审核流状态机：不要只用一个字段硬扛

成果数据提交后要经历审核。状态机我设计为：

• DRAFT：草稿，教师可改可删。
• SUBMITTED：已提交待审核，不可再修改。如果管理员退回，则回到DRAFT。
• APPROVED：审核通过，数据进入统计范围。
• REJECTED：审核驳回，教师可修改后重新提交。

这里我给每条成果额外加了audit_comment、auditor_id、audit_time三个字段，而不是单独建一张审核日志表。原因很简单——毕设和管理系统里，审核行为通常只有最后一次有展示价值，前面被退回的记录没有太多保留意义。如果你希望记录完整的审核流转历史，也可以建一张audit_log表，但至少要确保主表的当前状态和最后审核信息是准确的。

我建议在Service层做一个状态变更校验方法，防止前端绕过流程直接调接口。例如DRAFT状态的记录不允许直接调用审核通过的接口，只有SUBMITTED的条目允许审核。这个校验放在后端updateStatus方法里统一处理，而不是每个Controller分散判断。

3. SpringBoot+MyBatis后端落地的关键节点

后端是整个系统的大脑，也是技术含量最集中的一块。SpringBoot提供了良好的分层约定，MyBatis负责和MySQL打交道。这块我不打算重复官方文档，只讲在这个项目里真正会遇到的问题和对应的处理方式。

3.1 分层结构与统一返回体

项目包结构建议为：

com.example.education ├── controller ├── service │ └── impl ├── mapper ├── entity ├── dto ├── vo ├── config ├── common │ ├── result │ ├── exception │ └── utils └── interceptor

entity对应数据库表，dto用于接收前端参数（导入导出、分页等），vo用于向前端返回的组装对象。不要图省事全程使用Map传参，后面维护时你会痛苦万分。

统一返回体我习惯用这个简洁结构：

public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.code = 200; result.message = "操作成功"; result.data = data; return result; } public static <T> Result<T> error(Integer code, String message) { Result<T> result = new Result<>(); result.code = code; result.message = message; return result; } }

前端axios拦截器看到code != 200就直接弹错误提示，统一了异常展示逻辑。配合@RestControllerAdvice全局异常处理，再也不用每个接口都写try-catch。

3.2 拦截器实现登录校验与权限校验

登录校验我推荐用拦截器统一处理，判断request头里的Token是否存在且有效。权限校验可以在拦截器里根据@RequiresRole注解做，也可以直接在方法首行写if判断。毕设和实际项目中，我倾向简单粗暴——编写一个拦截工具类，在Controller每个敏感接口方法上标注角色码，用自定义注解加拦截器实现。

自定义注解：

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RequireRole { String[] value(); }

拦截器核心逻辑：

@Component public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; } HandlerMethod handlerMethod = (HandlerMethod) handler; RequireRole requireRole = handlerMethod.getMethodAnnotation(RequireRole.class); if (requireRole == null) { return true; } // 从请求头获取token，解析出当前用户和角色 String token = request.getHeader("Authorization"); LoginUser loginUser = JwtUtils.parseToken(token); if (loginUser == null) { response.setStatus(401); return false; } if (requireRole.value().length > 0 && !Arrays.asList(requireRole.value()).contains(loginUser.getRoleCode())) { response.setStatus(403); return false; } // 将用户信息塞进request，方便后续获取 request.setAttribute("loginUser", loginUser); return true; } }

这样@RequireRole("ROLE_ADMIN")就明确告诉维护者，这个接口只有管理员能调。比散落的if判断好维护得多。

3.3 MyBatis的动态SQL和批量操作

MyBatis在这个项目里最核心的价值是动态SQL。查询条件不确定时，用<if>标签灵活拼接，比纯注解拼接字符串干净得多。多成果类型查询时尤其需要：

<select id="selectItemList" resultType="com.example.education.vo.TeachingResearchVO"> SELECT * FROM teaching_research_item <where> <if test="userId != null"> AND user_id = #{userId} </if> <if test="collegeId != null"> AND college_id = #{collegeId} </if> <if test="itemType != null and itemType != ''"> AND item_type = #{itemType} </if> <if test="status != null and status != ''"> AND status = #{status} </if> <if test="year != null"> AND YEAR(complete_date) = #{year} </if> </where> ORDER BY create_time DESC </select>

这个查询几乎覆盖了系统里90%的列表查询场景。很多人在这一块犯的错误是在Mapper接口里写一长串@Select注解，字符串拼接特别容易出错，而且无法复用。我的建议是复杂条件一律用XML文件写。

批量操作也有一个典型场景：管理员一次性导出某学院某年的所有成果，或者教师批量导入论文。批量插入用<foreach>标签拼接values，小数据量下性能足够：

<insert id="batchInsert"> INSERT INTO teaching_research_item (user_id, college_id, item_type, item_name, role_type, complete_date, extra_info, status, create_time) VALUES <foreach collection="list" item="item" separator=","> (#{item.userId}, #{item.collegeId}, #{item.itemType}, #{item.itemName}, #{item.roleType}, #{item.completeDate}, #{item.extraInfo}, #{item.status}, NOW()) </foreach> </insert>

3.4 密码存储与登录流程

密码不能明文存储，这一点现在连毕设答辩老师都会当场抽查。我建议用BCryptPasswordEncoder，它是Spring Security自带的加密器，不需要引入完整的Spring Security全家桶，直接new BCryptPasswordEncoder()就能用。注册或添加用户时加密存储：

String encodedPassword = new BCryptPasswordEncoder().encode(rawPassword);

登录时用matches校验：

boolean matches = new BCryptPasswordEncoder().matches(rawPassword, storedPassword);

这样做的好处是每次加密的盐值都不同，即使两个用户密码相同密文也不同，安全性有明显提升。登录成功后我用JWT生成token，把userId、roleCode、collegeId写进token里，设置4小时过期时间。无状态鉴权的好处是后续如果拆微服务或做移动端，可以直接复用。

3.5 文件上传的细节：附件是教研成果的重要组成部分

教研成果往往需要上传佐证材料，比如论文扫描件、获奖证书照片。SpringBoot文件上传用MultipartFile接收，存储路径建议配置到application.yml的外部路径，不要放在项目打包目录里，否则打成jar后没法持久化。

file: upload-path: /data/education/upload/ access-path: /upload/**

通过WebMvcConfigurer将本地上传目录映射为HTTP访问路径，这样前端可以直接用URL访问附件：

registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadPath);

这个设计在本地开发时也方便，只要指定绝对路径即可。需注意文件名一定要重命名，用UUID + 原始扩展名，避免中文名乱码和重名覆盖。

3.6 Service层事务控制：审核提交这个操作必须加事务

审核操作有典型的多步写操作：更新成果状态、写入审核人、写入审核时间。这三步任何一步失败都会导致状态不一致，所以要用@Transactional保证原子性。

@Transactional(rollbackFor = Exception.class) public void audit(Long itemId, String status, String comment, Long auditorId) { TeachingResearchItem item = itemMapper.selectById(itemId); if (item == null) { throw new BusinessException("该成果不存在"); } if (!"SUBMITTED".equals(item.getStatus())) { throw new BusinessException("只有已提交的成果才能审核"); } int updated = itemMapper.updateAuditInfo(itemId, status, comment, auditorId); if (updated != 1) { throw new BusinessException("审核失败，请重试"); } }

注意rollbackFor = Exception.class必须显式声明，因为Spring默认只回滚RuntimeException，如果你在Service里抛的是自定义的BusinessException且继承自Exception，不加这个参数会导致事务不回滚。这个坑我在实际项目中踩过一次，数据直接错乱了。

4. Vue前端把填报、审核、统计三个页面做扎实

前端我用的是Vue 2 + Element UI的组合，这个搭配在当前环境里生态最成熟，文档齐全，遇到问题搜索答案也容易。Vue 3虽然势头好，但做管理系统这种中后台项目，Vue 2 + Element UI的稳定性和项目兼容性仍然非常能打。

4.1 项目初始化和Axios封装

用vue create初始化项目后，第一件事是封装axios请求。如果不封装，每个页面都写this.$http.post(...)然后各自处理错误，代码冗余且混乱。我常用的封装：

import axios from 'axios' import { Message } from 'element-ui' import router from '@/router' const service = axios.create({ baseURL: '/api', timeout: 10000 }) // 请求拦截器：自动携带token service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = token } return config }, error => Promise.reject(error)) // 响应拦截器：统一处理返回码 service.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.data }, error => { if (error.response && error.response.status === 401) { Message.error('登录已过期，请重新登录') localStorage.removeItem('token') router.push('/login') } else if (error.response && error.response.status === 403) { Message.error('没有权限执行此操作') } else { Message.error('网络请求异常') } return Promise.reject(error) }) export default service

关键是统一处理401和403。管理员登录后打开页面，token过期时再点操作按钮，如果每个页面都自己调登录跳转，代码会非常分散。集中在拦截器里处理，后端返回401就自动踢回登录页，体验会干净不少。

4.2 路由守卫控制页面访问

Vue Router的beforeEach里，根据localStorage存的roleCode判断当前用户是否能进入对应页面。

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path === '/login') { next() return } if (!token) { next('/login') return } const roleCode = localStorage.getItem('roleCode') if (to.meta.roles && to.meta.roles.indexOf(roleCode) === -1) { next('/403') return } next() })

这里需要说明一点：前端路由守卫只解决"页面看不到"的问题，真正防止越权还得靠后端接口的@RequireRole校验。前端只是体验优化，后端才是安全防线。这个思路在答辩时也值得明确说出来，能体现你对安全的完整理解。

4.3 核心填报表单：用动态表单处理不同类型成果

填报页面是教师用得最多的页面，也是前端实现最值得花心思的地方。我采用的方法是：先选成果类型，再根据类型动态渲染不同的表单字段。Element UI的el-form配合v-if控制不同字段，在data里维护一个字段配置对象，比如论文多一个"收录情况"下拉框，课题多一个"经费金额"数字输入框，教材多一个"出版社"输入框。

<el-form :model="form" :rules="rules" ref="formRef" label-width="100px"> <el-form-item label="成果类型" prop="itemType"> <el-select v-model="form.itemType" @change="onTypeChange"> <el-option label="论文" value="paper"></el-option> <el-option label="课题" value="topic"></el-option> <el-option label="教材" value="book"></el-option> <el-option label="获奖" value="award"></el-option> <el-option label="专利" value="patent"></el-option> </el-select> </el-form-item> <el-form-item label="成果名称" prop="itemName"> <el-input v-model="form.itemName" placeholder="请输入成果名称"></el-input> </el-form-item> <template v-if="form.itemType === 'paper'"> <el-form-item label="期刊名称"> <el-input v-model="form.extraInfo.journalName"></el-input> </el-form-item> <el-form-item label="收录情况"> <el-select v-model="form.extraInfo.includedIn"> <el-option label="SCI" value="SCI"></el-option> <el-option label="EI" value="EI"></el-option> <el-option label="CSSCI" value="CSSCI"></el-option> <el-option label="北大核心" value="PKU"></el-option> <el-option label="普通期刊" value="GENERAL"></el-option> </el-select> </el-form-item> </template> </el-form>

提交时把extraInfo序列化成JSON字符串存入后端。这样前端也保持了和后端一致的"通用字段+扩展字段"思路，类型再多也不会把页面写死。

4.4 审核页面的关键体验：驳回原因和状态高亮

审核页面是院系管理员每天盯着的页面。表格用el-table列出所有SUBMITTED状态的成果，每行显示教师、类型、名称、日期。操作列放两个按钮：通过、驳回。驳回时用el-message-box.prompt弹出对话框强制填写理由，理由最终会存储到audit_comment字段，教师端可以在成果详情里看到被驳回的原因。

状态用el-tag展示，不同状态配不同颜色：草稿灰色、待审核蓝色、已通过绿色、已驳回红色。用户一眼就能看清当前数据处于什么环节，这是面向管理层做设计时最基本的可用性要求。

4.5 统计页面的实现：组合条件和可视化展示

统计查询页我用el-form作为筛选条件区（年份、学院、成果类型、状态），查询结果用el-table展示。为了直观展示全院各类型的成果数，我会引入echarts画一个简单的柱状图或饼图。

Echarts的使用在Vue2里很简单：

import * as echarts from 'echarts' mounted() { this.chart = echarts.init(this.$refs.chartRef) } loadChart(data) { this.chart.setOption({ tooltip: {}, xAxis: { data: data.categories }, yAxis: {}, series: [{ type: 'bar', data: data.counts }] }) }

注意图表容器需要设置明确的宽高（比如height: 400px），否则会渲染不出来。另外页面离开时记得this.chart.dispose()，避免内存泄漏。

4.6 一个前端冷知识：Vue里播放排查问题

这个项目的附件通常是PDF或图片，不太涉及视频。但我在搜相关技术时看到有人在Vue项目里处理m3u8视频流播放，也顺便提醒一句——如果你后续想扩展这种直播或视频点播，记得video.js或plyr这类库在Vue2里的集成方式，以及跨域问题的处理。这和教研申报系统本身无关，但作为Vue技术栈的扩展知识点，提前了解没有坏处。项目保持聚焦，先把表单和列表做好。

5. 联调部署中的实际坑位与调试方法

再好的代码，联调和部署阶段也会遇到各种莫名其妙的问题。这一章我专门记录一下这个项目里常见的问题和排查思路，都是我实际踩过或帮别人排过的。

5.1 跨域问题：别再重定向到CORS Config了

本地开发时，前端跑在localhost:8080，后端跑在localhost:9090，两个端口不同必然产生跨域。最简单的解决方式是写一个CorsConfig：

@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); } }

但注意，allowCredentials(true)时allowedOrigins("*")会失效，必须用allowedOriginPatterns("*")。这个细节很容易被忽略，导致前端请求被浏览器拦截。生产环境如果用Nginx同域部署，就不存在跨域问题了。

5.2 SpringBoot版本过高引发的配置问题

现在新建SpringBoot项目默认可能是3.x版本，如果你还照着网上大量2.x的教程复制配置，会踩不少坑。最大区别是javax改成了jakarta命名空间：

// SpringBoot 2.x import javax.servlet.http.HttpServletRequest; // SpringBoot 3.x import jakarta.servlet.http.HttpServletRequest;

还有MyBatis-Spring-Boot-Starter的版本也要跟着调整。我的建议是，如果你做这个项目是为了参考网上成熟的教程和源码，稳妥起见用SpringBoot 2.7.x，这是2.x的最后一个维护版本，兼容性和资料丰富度都很好。不需要追求最新，够用且稳定才最重要。

5.3 MySQL 8.x的连接配置变化

MySQL 8和MySQL 5.7在连接配置上有明显差异。老教程里的com.mysql.jdbc.Driver已经废弃，必须用com.mysql.cj.jdbc.Driver。同时8.0的默认时区是UTC，驱动连接时不加时区参数会报错。

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

allowPublicKeyRetrieval=true这个参数，MySQL 8.0使用caching_sha2_password认证时，某些连接工具会报"Public Key Retrieval is not allowed"，加上它是最省事的解法。另外创建数据库时记得用utf8mb4字符集，utf8在MySQL里是阉割版，不支持直接存储emoji。

5.4 前端build后部署到Nginx的路径问题

开发调试完，前端要npm run build生成静态文件。把dist目录放到Nginx下，后端jar包独立运行，Nginx做反向代理：

server { listen 80; server_name your-domain.com; root /data/education/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:9090/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /upload/ { proxy_pass http://127.0.0.1:9090/upload/; } }

这里有个常见的坑：前端axios的baseURL配置为/api，但后端Controller的@RequestMapping没有/api前缀。那么在Nginx里proxy_pass http://127.0.0.1:9090/;这个末尾的斜杠会把/api前缀去掉，转发到后端的是去掉/api后的路径。

另一种做法是后端Controller统一加/api前缀（比如类上写@RequestMapping("/api/research")），Nginx直接proxy_pass http://127.0.0.1:9090;不带末尾斜杠，保持路径原样转发。

我在实际项目中更推荐后一种——后端统一/api前缀，前端和Nginx的配置都简单统一，后期拆分服务也方便。如果使用前一种，你要确保自己完全理解Nginx的代理语义，否则经常会遇到404。

5.5 数据库初始化脚本：确保演示数据齐全

给用户提供完整源码时，一定要带上初始化SQL脚本。脚本里除了建表语句，别忘了预置基础数据：

• 超级管理员账号（admin/admin123，密码是加密后的）
• 几个测试院系和测试教师账号
• 若干条不同状态、不同年份、不同类型的教研成果
• 字典数据（成果类型、职称等）

这样部署完直接就能登录看效果，不用自己造数据。很多人拿到源码后第一件事就是跑起来看看，如果登录后一张空列表，他会觉得系统没做完整，或者到处找bug。演示数据是这个项目的"门面"，花半小时认真造一批有代表性的数据，非常值得。

6. 给这个项目做扩展时，我建议你这样下手

系统主体跑通之后，往往还有其他需求冒出来。我根据自己的经验，列出几个高性价比的扩展方向，以及各自的实现思路。

6.1 使用EasyExcel实现批量导入导出

统计导出Excel是一个刚需功能。我用过Apache POI直接写，太繁琐了，尤其是多sheet的复杂报表，代码量巨大。后来换成了阿里巴巴的EasyExcel，API简洁，内存占用低，不二之选。

导出代码示例：

public void export(List<TeachingResearchItem> list, HttpServletResponse response) throws IOException { String fileName = URLEncoder.encode("教研成果统计", "UTF-8"); response.setContentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"); response.setCharacterEncoding("utf-8"); response.setHeader("Content-Disposition", "attachment;filename=" + fileName + ".xlsx"); EasyExcel.write(response.getOutputStream(), TeachingResearchExcelDTO.class) .sheet("教研成果") .doWrite(list); }

注意TeachingResearchExcelDTO要加@ExcelProperty注解，字段顺序就是导出Excel的列顺序。导出时建议直接用DTO而不是实体类，因为数据库字段名和下发表头不一致，用Entity会导致列名变成英文，阅读性差。

批量导入同理，用EasyExcel.read()监听器逐行读取并校验。这块有个小坑：导入的日期字段是Excel序列数格式，需要单独转换，我一般会统一按"yyyy-MM-dd"字符串处理，避免时区和小数点坑。

6.2 填报截止时间控制：用定时任务或状态判断

有些老师喜欢拖到最后一刻才提交，学院管理员希望系统能自动关闭填报入口。最简单的实现不是用定时任务，而是在提交接口里判断当前时间和配置的截止时间：

if (LocalDate.now().isAfter(config.getDeadline())) { throw new BusinessException("填报已截止，请联系管理员"); }

这样只需要在数据库存一个system_config字典表，管理员可在后台修改截止日期。不用引入Quartz或Spring Task，逻辑清晰，还更容易测试。

6.3 MyBatis缓存的使用边界

网上好多帖子里把MyBatis二级缓存吹得很玄乎，但在这种教研填报系统里，我建议默认不要开二级缓存。因为这个系统的数据实时性要求很高：教师提交成果后，管理员要立刻在待审核列表看到；审核通过后，统计页面要立刻更新。二级缓存默认是跨Mapper共享的，一旦处理不好，可能会出现"数据库里状态变了，查询还是旧数据"的情况，非常难排查。

把SQL优化做好、配合MySQL索引，比上缓存更可靠。如果确实有高频查询（比如字典数据），用本地HashMap或Caffeine做简单的进程内缓存就够了，不需要动MyBatis的缓存配置。

6.4 Workbench备份与数据迁移

数据库管理工具，MySQL官方自带的Workbench就够用，完全不必要追求复杂的Navicat。Workbench的Server菜单里有Data Export和Data Import，导出SQL文件时记得勾选Include Create Schema，否则新建库后直接导入会提示找不到库。另外，如果导出的SQL文件在Windows下打开中文正常、到Linux下导入后乱码，重点检查文件编码是不是UTF-8，MySqL客户端连接时再加上--default-character-set=utf8mb4参数，基本能解决。

6.5 遇到的拦路虎：面试官问"你这个系统哪里最难"

这个项目做完后大概率要拿去答辩或面试，以下几个问题几乎必问，我提前练好答案：

1. "为什么选SpringBoot+Vue这套技术栈？"回答思路：SpringBoot简化了Spring的配置，内嵌Tomcat一键启动；Vue目前主流的渐进式框架，组件化开发和生态成熟；MyBatis能灵活控制SQL，适合查询条件复杂的报表场景；MySQL轻量免费，对中小规模项目完全够用。

2. "表结构是怎么设计的？为什么成果用JSON扩展字段？"回答思路：不同类型成果字段差异大，全字段冗余会导致大量空列，维护困难；拆多张表又导致查询统计时需要union多个表。JSON字段兼顾两者，既能存差异化信息，又保持单表查询的简单。

3. "权限和安全性怎么保证？"回答思路：后端用拦截器加自定义注解校验角色，前端口令守卫控制页面，密码BCrypt加密，Token无状态认证，文件上传路径做了外部化和限制。

4. "如果并发量大怎么办？"回答思路：系统按学院横向拓展很困难，但这类内部管理系统的并发量通常很小，瓶颈主要在数据库。合理建索引、使用分页查询已经是主要手段。如果真有高并发诉求，考虑Redis缓存热点数据、Nginx负载均衡多实例部署，但现阶段不需要过度设计。

每个答案控制在1分钟以内，既展现技术深度，也体现架构思维。这套组合拳打下来，答辩或初级开发面试都会稳很多。

写在最后

前后端分离的项目，最怕的就是"骨架搭好了，细节全塌了"。这个高校教师教研信息填报系统，抛开技术栈的光环，本质上是一个业务闭环完整、角色权限清晰、数据模型可扩展的中台系统。它的价值不在于用了多么高深的技术，而在于完整地串起了"需求分析—表设计—后端接口—前端页面—部署上线"的全过程。如果你照着这个思路走一遍，收获的绝对不只是一份源码，而是面对任意管理系统都能快速上手的底气。

最后再说一个实操小技巧：开发时，后端写好一个接口，我习惯先不用前端页面调，而是直接打开Swagger地址测一遍，确认返回数据结构没问题再写页面。很多前后端联调扯皮的问题，都源于后端返回的结构和前端预期不一致。SpringBoot整合springfox或springdoc非常快，省下的调试时间绝对远超搭建时间。这个习惯，我从做这个项目开始一直用到现在，很值得养成。