企业官网建设流程全解析

每年第三季度开始，高校科研处和教务处的人就会陷入同一种循环：在微信群里反复催老师交教研成果，收上来的Excel表格式五花八门，论文题目里带着斜杠就拆出好几列，教材ISBN号有的带横杠有的不带，再加上学院汇总的版本和科研处手里的版本怎么都对不上。这不是个例，是几乎所有高校管理里最消耗人力的环节之一。

我做过一套基于SpringBoot+Vue+MyBatis+MySQL的高校教师教研信息填报管理系统，覆盖教师在线填报论文、课题、教材、专利、获奖，到教研积分自动计算、教研室初审、科研处终审、批量导出汇总的全流程。这个项目也是Java课程设计和毕业设计里出现频率最高的题目类型之一。如果你正准备做类似的系统，或者想参考教研/科研管理类业务系统的完整落地方式，这篇文章可以帮你把关键设计提前想明白，少走几步弯路。

1. 教研填报场景的真实痛点与系统需求拆解

1.1 一张Excel表来回传的版本地狱

先说为什么需要一个专门的管理系统，而不是继续用在线文档或问卷工具。高校教研信息填报，表面看就是“收集成果数据”，实际上有四个在线文档解决不了的问题：多人同时编辑导致的数据互相覆盖、提交时间不可控导致逾期没人知道、审核过程毫无痕迹可查、最终统计时无法按学院/职称/年份灵活汇总。

我接手这个项目时，真实情况是：学校发一个《教研成果统计表》模板到各院系，院系教学秘书转发到群里，老师们下载后各自填写，再通过微信或邮件回传。两个老师同时填同一份表，后提交的覆盖先提交的；老师换了电脑导致格式错乱；科研处收表之后还要人工去重、人工核对、人工录入数据库，一波操作下来，两周能出初步汇总已算幸运。

所以这套系统的第一个设计目标，不是“把表格搬到网页上”，而是把“填报-审核-汇总”这件事重新做成一条可追溯、可控制、可自动统计的流水线。

1.2 系统角色与核心业务流程拆分

梳理高校教研信息填报的完整链路，核心角色有三类：教师、院系教学秘书（或教研室负责人）、科研处管理员。

业务流程也相对固定：

1. 教师登录系统，选择申报批次（如“2024年度教学改革与研究成果统计”），在线填报论文、科研项目、教材专著、专利软著、获奖荣誉等信息。
2. 教师可先存草稿，确认后再提交。
3. 院系教学秘书对本院教师提交的成果做初审，重点核对格式、成果归属、证明材料是否齐全。
4. 科研处管理员进行终审，审核通过的成果计分并进入汇总库，驳回的成果必须附带驳回原因，教师可修改后重新提交。
5. 汇总阶段按院系、职称、成果类型、时间范围多维度统计，支持导出Excel。

在业务实体上，至少需要覆盖：论文信息、科研项目、教材专著、专利软著、教研荣誉、教师工作量（课时/教研活动）。标题里说的是“教研信息填报”，所以我把前端页面按“成果类型”做成标签页切换，而不是把几十个字段堆在一个大表单里，这对用户体验的影响很直接。

1.3 区别于通用信息收集工具的关键设计

有人会问，用金数据、问卷星这类工具行不行？行，但只能解决“收集”，解决不了“审核和计分”。

教研填报系统和通用表单工具最大的差异在两点：一是审核状态机，二是积分规则。审核状态机要求每一条成果都有明确的生命周期：草稿-待审核-通过-驳回，驳回还要有理由和修改记录。积分规则则需要把不同成果换算成教研业绩分，比如一篇核心期刊论文记多少分、一个厅级课题记多少分，这些规则还随年度政策变化。

也就是说，这套系统本质上不是“表单系统”，而是一个轻量的“业务流系统”。这也决定了后端数据模型和技术实现的侧重点。

2. 技术选型逻辑：SpringBoot+Vue+MyBatis+MySQL这套组合为什么合适

2.1 后端框架：SpringBoot为什么是中小系统里的安全牌

这套系统的技术栈是SpringBoot+Vue+MyBatis+MySQL，属于当前Java业务系统里非常主流的组合。后端选SpringBoot，理由很朴素：自动配置能力强、内置Tomcat、依赖管理省心，一个mvn spring-boot:run就能起服务，开发者可以把精力放在业务逻辑而不是环境配置上。

对于课程设计或毕业设计项目来说，SpringBoot还有一个隐形优势：面试官和评阅老师都认识它。你不需要花大量篇幅解释框架本身，重点展示业务建模能力就可以了。

实践里我会把工程按controller/service/mapper/entity分层，自定义统一返回体R （code、message、data），再加一个全局异常处理器，这样前后端联调时的沟通成本会低很多。这个分层看起来基础，但很多同学上来就把逻辑写在Controller里，后面改审核流程的时候会非常痛苦。

2.2 ORM选型：MyBatis与JPA、MyBatis-Plus的取舍

当前项目可以选三种ORM方案，区别我列个表：

这个项目用原生MyBatis，我的看法是：一方面是出于教学和源码可读性考虑，手写SQL更能理解数据是怎么查出来的；另一方面是教研统计天然要和大量聚合SQL打交道，GROUP BY院系、按成果类型分类汇总这类查询，在XML里写SQL比在代码里拼QueryDSL要直观得多。

热词里提到的“MyBatis缓存”和“MyBatis分页插件”，我在第5章会专门展开讲坑，这两块是实操里最容易翻车的地方。

2.3 前端框架：Vue的理由与版本选择细节

前端用Vue做前后端分离，核心原因是页面交互确实复杂。填报表单按成果类型动态切换、审核列表的筛选和状态标签、汇总统计图表的展示，如果用服务端模板渲染（Thymeleaf）来写，页面状态管理和局部刷新会非常别扭。

版本方面有个现实问题。很多存量源码项目是Vue 2 + Element UI，而2025年新写的项目用Vue 3 + Vite + Element Plus更合适。如果你拿到的源码是Vue 2的，不建议强行升级到Vue 3，因为Element UI和Element Plus的组件API有差异，迁移成本大于收益。我自己重做过一版Vue 3的，整体思路一样，只是组合式API写起来更顺手，路由守卫和Pinia状态管理也比Vue 2时代清晰。

开发环境上，Vue 3会要求Node.js 18+，npm install的依赖树较大，建议配好镜像源再装。调试时装上Vue Devtools浏览器插件，看组件状态和路由变化能省下很多时间。

3. 核心数据模型设计：教研成果怎么存才不折腾

3.1 整体表结构规划

教研填报系统的数据模型，我建议按“基础数据-成果数据-流程数据”三类去规划：

• 基础数据：sys_user（登录账号、角色、所属院系）、teacher_info（教师基本信息、职称、研究方向）、sys_dict（成果类型、评审结果这类字典项）。
• 成果数据：这是核心，做法上推荐分类型建表而不是一张大宽表。我实际用的表有：ach_paper（论文）、ach_project（项目）、ach_book（教材专著）、ach_patent（专利软著）、ach_honor（获奖荣誉）。各表共用的字段抽出来，比如申报批次、状态、积分、证明材料URL。
• 流程数据：review_record（审核记录，谁在什么时间审了什么，结果和意见是什么）。

分表的好处有两个：一是不同成果类型的字段差异很大，论文要期刊级别、第一作者、收录情况，项目要立项级别、经费、结项状态，塞在同一张表里会出现大量空列；二是按类型统计汇总时SQL更直观，不需要在一张大表里反复CASE WHEN。

3.2 关键字段设计细节

几个关键字段值得单独设计。

状态字段status是这条数据在业务流程中的位置。我用的是：0草稿、1待院系审核、2待科研处终审、3已通过、4已驳回。注意我这里把“待院系审核”和“待科研处终审”拆成了两个状态，虽然链路变长了，但比只存“0待审/1通过/2驳回”更清楚，教师端能直接看到当前卡在哪个环节。

每个字段的ORM设计：status用TINYINT，state字段给默认值0，配合MySQL的DEFAULT 0，避免插数据时少传字段导致NULL判断混乱。热词里提到的“MySQL设置默认值为0”就是这个场景。

成果主表上要加uni_biz_id，由前端生成UUID或后端按业务键生成，用途是防止重复提交。老师在网络卡顿的时候点两次提交按钮，第一次请求还没返回，第二次请求又到了，如果靠自增主键判断，就会插入两条重复成果。我在表上加了UNIQUE KEYuk_biz_id（uni_biz_id），重复提交被数据库直接拒绝，比锁或分布式锁方案简单可靠得多。

create_time和update_time都用DATETIME，update_time设置ON UPDATE CURRENT_TIMESTAMP，这样修改记录自动更新，审核历史排查时很有用。

3.3 一段可直接用的建表SQL示例

下面这段是paper表的精简版建表SQL，其他成果表按相同思路扩展：

CREATE TABLE `ach_paper` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键', `uni_biz_id` VARCHAR(64) NOT NULL COMMENT '业务唯一ID，防止重复提交', `teacher_id` BIGINT NOT NULL COMMENT '教师ID，关联teacher_info', `batch_id` BIGINT NOT NULL COMMENT '申报批次ID', `paper_title` VARCHAR(255) NOT NULL COMMENT '论文题目', `journal_name` VARCHAR(255) DEFAULT '' COMMENT '发表期刊', `journal_level` TINYINT DEFAULT 0 COMMENT '期刊级别：0未认定/1普刊/2核心/3SCI等', `author_order` VARCHAR(32) DEFAULT '' COMMENT '作者排序', `publish_date` DATE DEFAULT NULL COMMENT '发表日期', `proof_url` VARCHAR(255) DEFAULT '' COMMENT '证明材料URL', `score` DECIMAL(6,2) DEFAULT 0.00 COMMENT '教研积分', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0草稿 1待院系审核 2待科研处审核 3已通过 4已驳回', `reject_reason` VARCHAR(500) DEFAULT '' COMMENT '驳回原因', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_biz_id` (`uni_biz_id`), KEY `idx_teacher_status` (`teacher_id`, `status`), KEY `idx_batch` (`batch_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='论文成果表';

注意索引设计。idx_teacher_status是“教师看我的成果列表”的高频查询，idx_batch是“按申报批次汇总统计”的关键路径。这类业务查询条件很固定，两个联合索引就能覆盖绝大部分需求，不需要过度加索引。

4. 填报与审核主流程：状态机是这类系统的灵魂

4.1 后端状态流转的落地实现

审核流程在后端就是一个状态机。我写过的版本里，最关键的是“提交”和“审核”两个接口。

提交接口的主要逻辑是：校验当前状态必须是草稿或驳回状态，不允许覆盖“已通过”的数据；设置status=1，记录提交时间。这里要注意修改status时，SQL里的WHERE条件必须带上状态条件，而不是只按id更新：

@Update("UPDATE ach_paper SET status = #{targetStatus}, update_time = NOW() " + "WHERE id = #{id} AND teacher_id = #{teacherId} AND status = #{expectedStatus}") int updateStatus(@Param("id") Long id, @Param("teacherId") Long teacherId, @Param("expectedStatus") Integer expectedStatus, @Param("targetStatus") Integer targetStatus);

这样写的好处是并发场景下不会出现“教师A撤回的同时科研处正在通过”导致的状态错乱。数据库行锁本身就保证了同一条数据不会被两个事务同时更新成功，返回行数为0的时候再提示“数据状态已变化，请刷新页面”，这就是乐观锁的思路。热词里提到“MyBatis @Update 执行慢”，很多时候不是SQL本身慢，而是没走索引或者没加条件，全表扫描导致锁范围变大。

驳回操作则强制要求填写驳回原因。我的做法是：驳回时reject_reason必填，status置为4，前端审核页面如果点击“驳回”但原因没填，按钮置灰。这在业务上很重要，老师看到驳回消息的第一反应是“为什么被打回来”，没有原因的驳回会大量增加咨询电话。

4.2 前端页面与Vue路由设计

前端页面围绕“填报、审核、统计”三个入口展开，Vue路由设计如下：

• /fill：教师填报页，左侧选择成果类型，右侧动态渲染对应表单。
• /my-list：教师“我的成果”列表，展示每条成果的状态标签，草稿可编辑，驳回可查看原因后修改重提。
• /review（院系/科研处）：审核列表，按状态和院系筛选，点击进入审核详情页。
• /report：统计汇总页，按院系、成果类型、时间范围生成汇总表。

路由守卫按角色控制，核心是通过后端返回的用户角色来判断访问权限：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); if (!token && to.path !== '/login') { next('/login'); return; } // 简单角色判断：teacher_info表中role字段，1管理员/2院系审核/3教师 const role = store.state.user.role; if (to.meta.roles && !to.meta.roles.includes(role)) { next('/403'); return; } next(); });

这个方案是纯前端的粗略控制，真正防越权要看后端接口的权限校验。热词里提到“Vue路由参数”，主要是编辑成果时从列表页跳转详情页，通过路由的query或params携带成果ID。我建议用params传主键ID，通过详情页重新拉取数据，避免刷新页面后参数丢失。

4.3 后端权限控制：一个全局过滤器解决XSS和认证

后端权限我用JWT+拦截器实现，同时用一个全局过滤器统一处理两件事：登录认证和输入安全。

具体的全局过滤器通常会这样做：

1. 拦截所有/api/**请求，放行login接口。
2. 检查请求头里的Authorization，JWT失效或无token时返回401。
3. 对请求参数做统一清洗，防止XSS脚本注入。

热词里有一条“springboot项目全局过滤器处理上传pdf文件时xss攻击”，说的就是这类问题的真实场景。教研系统里老师要上传论文见刊页、立项文件等扫描件，文件名往往是“论文：基于某某的研究”，里面可能夹着特殊字符甚至脚本内容。

我在全局过滤器里除了限制扩展名白名单（pdf/jpg/png/zip），还会统一清洗文件名，把<script>、<img onerror>这类恶意内容在存储之前就替换掉：

String cleanFileName = fileName.replaceAll("<[^>]*>", "").replaceAll("[\"'<>]", ""); String randomName = UUID.randomUUID().toString().replaceAll("-", "") + "." + StringUtils.substringAfterLast(originalName, ".");

这样处理之后，就算原始文件名里有脚本，落盘的文件名也是UUID重命名后的安全文件名，既不暴露原始文件名信息，也消除了XSS触发路径。审核材料的预览页面再配合前端对文件名进行转义输出，双层保险。

这里我要特别强调一点：XSS过滤不是只在接口里针对某个字段做，而是要在全局过滤器层面统一做，否则你会漏掉很多入口。那些通过POST表单提交却能执行脚本的案例，本质上都是因为在某个角落漏了清洗。

5. 实操避坑：MyBatis分页、导入导出与文件安全的那些坑

5.1 PageHelper分页插件的正确用法与常见翻车点

教研成果列表、审核列表全部涉及分页，几乎所有人都会引PageHelper这个插件。它的用法确实简单：

PageHelper.startPage(pageNum, pageSize); List<PaperVO> list = paperMapper.selectPaperListWithTeacher(condition); PageInfo<PaperVO> pageInfo = new PageInfo<>(list);

问题往往出在“startPage之后必须紧跟第一条查询”这个规则上。如果你在startPage和真正要分页的查询之间又执行了别的SQL，分页插件就会分页到那条SQL上，查出来的数据是乱的。

我在这个项目里踩过最典型的坑是这样的：在service里先查了一遍字典配置，再查成果列表，结果分页一直作用在字典查询上。排了半天才意识到，PageHelper是基于ThreadLocal实现的，只要两次查询间隔里有其他SQL执行，分页上下文就污染了。

规避方案很简单：把分页查询独立到Mapper接口的第一条SQL位置，业务逻辑里需要先查的其他数据，放到分页查询之后再处理。另外，多表关联查询（teacher表join ach_paper）时PageHelper会自动把count语句套成select count(0)，但如果SQL里写了复杂的GROUP BY，count结果可能会不符合直觉，这种情况我一般会手写count查询。

5.2 MyBatis缓存：一级缓存与二级缓存引发的“幽灵数据”

MyBatis缓存是热词里出现频率很高的话题，因为这个项目踩过一次很隐蔽的坑。

MyBatis默认开启一级缓存（SqlSession级别），同一个SqlSession里执行两次相同SQL，第二次直接命中缓存。在Spring中，如果Service方法默认走同一个SqlSession，你在同一次请求里查同一个成果两次，第二次拿到的其实是缓存对象，不是数据库最新值。更隐蔽的是二级缓存（Mapper namespace级别），一旦开启，不同会话之间共享缓存数据。问题在于：教研成果表经常和审核记录表联查，如果审核表更新了但成果表缓存没失效，页面上的状态还是旧值。

我的做法是：项目里直接关闭二级缓存，所有查询走实时数据库。教研填报系统的数据量级在百万以内，单表查询都在毫秒级，完全不需要靠缓存来扛性能。开着二级缓存反而要时刻担心缓存一致性问题，属于典型的“为了优化而优化”。

类似的坑还有“MyBatis XML里的SQL写错导致查询结果和预期不一致”。我建议本地开发时开启控制台SQL打印：

mybatis: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

这样能直接看到MyBatis解析后的完整SQL和参数，找问题效率高很多。热词里的“mybatis xml高亮”就是建议在IDEA里装MyBatis插件，处理XML中SQL的动态标签时，高亮提示能让你一眼看出<if>条件有没有拼接错。

5.3 Excel导入导出的选型与实践

教研汇总阶段有一个刚性需求：按院系导出教师教研成果汇总表。很多老师习惯用Excel上报，系统也要支持按模板导入。

按经验推荐EasyExcel而不是直接裸写Apache POI，核心原因是内存占用差距。POI可以把Excel对象全部加载到内存，几万行数据导出时JVM内存很容易被打爆；EasyExcel基于SAX模式流式读写，内存占用小一个数量级。对于一个课设或毕设级别的系统，EasyExcel的注解导出方式也极大降低了实现成本：

@ExcelProperty("论文题目") private String paperTitle; @ExcelProperty(value = "状态", converter = StatusConverter.class) private Integer status;

我实际用的导出功能支持“按院系筛选→导出当前筛选条件下的全部成果”，代码里只需要一行easyExcel.write().sheet().doWrite(list)。

导入相对麻烦一点，但也建议用EasyExcel配合校验模型。实操里最恼火的不是解析Excel，而是“模板乱填”。我在导入前先做数据合法性校验：论文题目不能为空、期刊名不能超过255字符、日期格式必须是yyyy-MM-dd，错误单元格收集后生成错误提示文件返回给用户。这个“导入+校验+错误反馈”的闭环比简单导入要复杂，但用起来完全是两种体验。

5.4 一个真实的文件上传+XSS污染问题

前面提的全局过滤器，在这个项目里跟PDF上传产生一次直接冲突。当时是科研处反馈，老师上传的PDF文件名里带了书名号和百分比符号，结果前端列表页渲染文件名时偶尔会把个别HTML标签吃掉。

排查链路是这样的：上传接口返回的文件访问路径包含了原始文件名，后端列表接口又把文件名拼到JSON里返回，前端用模板字符串渲染到页面。如果文件名里恰好包含<script>这类字符，浏览器就会把它当HTML解析。单看问题很小，但安全问题不能这样侥幸。

最终方案就是上文说的三步：全局过滤器清洗文件名+落盘时用UUID重命名+前端统一用textContent/插值转义而不是dangerouslySetInnerHTML。做完整套之后，这类问题彻底绝迹。如果你也在做带文件上传的系统，建议直接照这个组合抄。

6. 部署上线要点：从打包到真正能用的几个建议

6.1 前后端分离的部署方式与跨域处理

项目开发和部署环境要分开配置。开发阶段前端通过Vite的proxy代理把/api请求转发到后端，后端Config里配置跨域规则允许本地开发域名访问。

生产环境推荐用Nginx统一部署：前端打包出的dist目录交给Nginx托管，后端以jar包方式运行在8080端口，Nginx把/api路径反向代理到后端服务。这样前端和后端之间不直接跨域，浏览器看起来是同一个源。

server { listen 80; server_name your.domain.com; location / { root /var/www/research-system/dist; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; client_max_body_size 50m; } }

client_max_body_size设到50m是因为老师上传的PDF扫描件动辄几十兆，Nginx默认1m限制会让大文件上传直接报413。这个参数几乎每个第一次部署文件上传类项目的人都会漏。

SpringBoot的打包直接mvn clean package生成可执行jar，启动命令建议写成带JVM参数的形式：

java -Xms512m -Xmx1024m -jar research-system.jar --spring.profiles.active=prod

生产环境的数据库连接、Redis配置等通过application-prod.yml隔离，避免把开发环境配置带到生产。

6.2 MySQL配置、索引与常见的SQL慢问题

MySQL这层要做的事不多但很关键。字符集统一utf8mb4，排序规则utf8mb4_general_ci，避免中文和emoji字符乱码。数据库连接串里加上useUnicode=true&characterEncoding=utf8，否则Java传中文到MySQL可能因为编码问题变成乱码。

慢SQL是审核高峰期最容易出现的问题。我的经验是三类场景：按status查询未加索引导致全表扫描；按时间范围筛选时DATE函数包住字段导致索引失效；分页深翻页时limit 100000,20这种写法越翻越慢。前两类通过补联合索引解决，第三类建议用游标分页或延迟关联来优化，比如先只查主键列表，再JOIN回完整数据。

热词里的“MySQL update语法”在多表状态更新时值得重视。比如审核通过时除了更新成果状态，还要同时更新教师积分汇总，这两步要放到同一事务里：

@Transactional public void approve(Long paperId, Long reviewerId) { achPaperMapper.updateStatus(paperId, 3, reviewerId); teacherScoreMapper.addScore(paper.getTeacherId(), paper.getScore()); }

没有事务保护的话，成果通过但积分没加，或者积分加了但成果状态没变，查问题时都会很抓狂。

6.3 “填报批次”这个设计，一开始就要做

最后说一个我重新做一遍会从一开始就加入的设计：填报批次表。

第一次做的时候我没建批次表，所有成果数据直接挂在学年字段上。第二年数据一多，问题就来了：老师去年的草稿和今年的混在一起，审核列表里没法按年度一键切换，统计汇总要写一堆带时间的条件。

后来我加了sys_batch表，包含批次名称、开始时间、结束时间、是否启用等字段。每次系统开放填报前，管理员创建一个新批次，教师端填报页默认显示当前启用批次，历史批次的数据只读。成果表里增加batch_id关联后，所有按年度的统计都变成按批次统计，逻辑瞬间干净了。

这个设计对毕业设计来说也是个加分项，答辩时老师如果问“跨年度数据怎么处理”，这个答案比你想临时加一个年份字段要成熟得多。

如果你准备拿这份源码二次开发，我的建议是优先把“批次管理”和“多级审核”这两个核心模块跑通，再考虑界面美化。业务流系统只要状态流转正确、数据不丢不重，就已经解决了学校里最痛的问题。至于统计图表、消息提醒、移动端适配，都是第一批上线稳定之后再加的功能。别一上来就铺开做，先把主链路走通，后面真的会省心很多。