企业官网建设流程全解析

最近帮一所高校把科研工作量管理系统完整落地了一遍，从需求梳理到前后端联调，再到部署给科研处用上，整个过程踩了不少坑，也攒了不少经验。这套系统的源码是标准的SpringBoot后端 + Vue前端 + MySQL数据库组合，拿过来就能直接跑，我会把从环境搭建到功能实现的完整链路都拆开讲清楚，包括每个模块为什么要这么设计、数据库表结构背后的业务逻辑、以及启动过程中最容易卡住的几个点。

先说清楚它到底是干什么的。科研工作量管理，说白了就是把老师的科研产出量化成可计算的分数。以前科研处每年底要人工收材料、对表格、算分数，一篇一篇核对论文级别、一个一个确认项目立项号，工作量巨大还容易出错。这套系统就是把这件事全部搬到线上：老师自己登录系统填报论文、项目、专利、获奖这些科研产出，系统按照事先设定好的计分规则自动换算工作量分，科研处再审核确认，年底直接按部门、按个人导出统计报表，效率完全不是一个量级。

它适合谁看？两类人。第一类是高校、医院、科研院所的科研管理相关人员和信息中心工程师，这类单位对科研工作量核算有真实刚需，系统可以直接内部部署使用；第二类是Java全栈开发者，尤其是大一统式的SSH时代转过来的、想看看现在SpringBoot + Vue到底怎么搭档做业务系统的朋友，这个项目就是一个非常典型的前后端分离工程范例。学生党拿去做课程设计、毕业设计的完整素材库，也完全合适。

1. 科研工作量管理系统的需求与整体设计思路

1.1 科研管理到底在管什么：核心痛点拆解

在动手写代码之前，最容易被初学者忽略的就是业务梳理。很多朋友拿到项目第一件事就冲去看代码，其实不对，应该先看业务结构。高校科研工作量管理，拢共管四类核心业务对象：科研项目、论文成果、知识产权、获奖与著作。这四类几乎是所有科研单位的通用口径。

科研项目要管立项信息、项目级别（国家级、省部级、市厅级、校级）、经费额度、项目负责人和参与人名单。这里有个隐藏难点：一个项目往往有多个参与人，每个参与人的排序不同，折算到工作量的系数也不同。论文要管标题、期刊等级（SCI一区二区、EI、中文核心、一般期刊）、第一作者和通讯作者。专利要管类型（发明专利、实用新型、外观设计）、授权状态。获奖更是五花八门，国家级、省级、校级、行业协会奖，全都要能自定义计分规则。

这是系统的业务地基。我见过一些做坏的项目，原因就是在这一层偷懒了，把项目成员做成了文本字段，存一个字符串，后面做统计工作量时才发现各种拆分不了。这套源码在设计时就避开了这个坑，每个科研产出对象对应一个独立的表，再通过关联表和教职工表建立多对多关系，这样才能支撑后续的复杂核算。数据模型如果没设计清楚，功能做得再花哨都是在盖危楼。

还有一个核心概念叫“工作量分”。每个科研单位都会有一份自己的奖励/计分实施细则，比如：“国家级纵向项目，主持人计120分/项，第二参与人计40分/项；SCI一区论文计30分/篇，二区计20分/篇。”系统要做的就是把这些细则数字化，变成可配置的规则数据，然后自动算分。不同单位的规则差异很大，所以系统设计成规则配置化的方式，而不是把分数写死在代码里——这是整个系统最体现业务思考的地方。

1.2 为什么偏偏选这套技术栈：选型拆解与对比

这套系统用的是SpringBoot + Vue + MySQL，这套组合今天几乎成了中小型管理系统的事实标准，不是没有原因的。

我曾经见过用C# WinForm 做的高校管理系统，界面老气、只能局域网跑，部署一次还要装.NET Framework，别提多痛苦了。SpringBoot带来的第一个红利就是内嵌Tomcat，一个java -jar命令服务就起来了，部署成本极低。第二个红利是starter机制，引入依赖就像逛超市拿货，用MyBatis就拽一个mybatis-spring-boot-starter，做接口就用spring-boot-starter-web，配置集中到application.yml，项目结构极其清爽。

前端Vue是我的心头好。这个项目前端用的是Vue 2.x + Element UI 的组合，虽然Vue 3和Composition API已经是主流，但Vue 2 + Element UI在管理系统领域的生态成熟度目前依然是最高的——组件多、文档全、示例海量，遇到问题一搜就有答案。而且这套系统面向的协作对象是高校信息中心的技术老师，他们对Vue 2的熟悉程度普遍更高，后续维护交接成本最低。前端和后端通过axios走JSON接口通信，前后端分离，后端只管出数据接口，前端专注页面交互和用户体验。

数据库选MySQL没什么悬念：免费、稳定、文档多、几乎所有人都会用。包括后面的部署环境，高校服务器基本都预装了MySQL，根本不需要额外采购或申请授权。MySQL 8.0自带的窗口函数、JSON类型等能力，对这个体量的系统绰绰有余。这套组合最大的优势不是某个单点技术强，而是整个生态的链路短、坑少、能跑起来的人多。

我有一个习惯性的对比逻辑：做管理系统，选技术栈的首要标准不是“新”，而是“稳”。团队里任何一个人去看教程都能上手，才是最好的选型。SpringBoot + Vue + MySQL，老少通吃，这就是它在这个领域不可撼动的地位。

2. 后端核心实现拆解：SpringBoot不是摆设

2.1 分层设计：从Controller到Mapper的路该怎么走

很多人看SpringBoot项目，一进来先晕目录结构。其实它的分层逻辑非常清晰，只要你理解了“请求是怎么一步步变成数据再返回的”这条主线，整个后端就都在脑子里了。

标准调用链是：浏览器发请求 → Controller接收参数 → Service处理业务逻辑 → Mapper访问数据库 → 结果逐层返回。整个项目把每一层都拆成独立的包，各司其职。

Controller层（controller包）只做三件事：接收参数、调用Service、返回结果。它不应该写任何业务逻辑，谁在Controller里写if else算工资，谁就是给自己埋雷。我见过一些新手项目，Controller里动不动两百行，数据校验、权限判断、业务计算全塞进去，后期改一个需求就要在Controller里打补丁，维护成本极高。

Service层（service包）是业务逻辑的核心地带。科研工作量计分规则的判定、项目参与人系数的折算、工作量明细的生成，全部在这一层完成。接口定义和实现类分离（service接口 + service.impl实现类），为的是后面做单元测试或者扩展时方便替换。这套系统在Service层体现得最明显的一个设计是：工作量核算逻辑被单独抽成了一个WorkloadCalculateService，不跟具体的Controller耦合。哪天规则变了，只需要改这一个类，不用动Controller和数据库层。

Mapper层（mapper包）在MyBatis体系里对应的是数据访问接口，配合mapper目录下的XML文件写SQL。这套系统大量使用了MyBatis-Plus，它对单表CRUD的支持非常到位，内置的BaseMapper接口帮你把增删改查都封装好了，你只需要写复杂的多表关联和统计SQL。这样省下来的时间不是一点半点。我第一次用MyBatis-Plus的时候是有点怀疑的，总觉得这种“万能接口”会不会出幺蛾子，用熟了才发现，对业务型管理系统来说，手写基础CRUD的时间绝对是纯浪费。

2.2 鉴权与权限控制：JWT+拦截器缺一不可

管理系统一定要有权限控制，不然任何人都能访问管理接口，系统就成摆设了。这套系统用的是JWT（JSON Web Token）配合Spring拦截器实现登录态管理，这也是目前前后端分离项目里最主流的方案。

流程是这样的：用户登录时，后端用密码校验身份，通过后签发一个JWT令牌返回给前端。前端拿到令牌存在本地存储，之后每次请求在请求头里带上。后端用一个拦截器拦截所有受保护的接口请求，验证令牌的有效性。令牌有效就放行，顺便把当前登录用户的ID和角色塞到请求上下文里供后续使用；令牌无效就直接返回401未授权。

为什么用JWT而不用Session？因为前后端分离的项目，前端可能部署在A服务器，后端部署在B服务器，甚至以后要做集群扩容，Session在分布式场景下是非常麻烦的事情——你得引入Redis做会话共享。JWT是无状态的，令牌自带有效期和签名信息，后端不需要存储任何会话数据，天然适合分布式部署。这一点在高校场景也很实用：科研处有时候需要同时向不同校区提供访问，后端挂两台服务器做负载均衡，JWT方案直接省去了会话同步的破事。

权限控制上，系统内置了三种角色：管理员、科研处审核员、普通教师。不同角色能访问的路由和接口不一样，菜单也是按角色动态渲染的。这个实现方式并不复杂：后端接口在做权限校验时，取当前用户的角色，比对接口注解上要求的权限码。前端配合vue-router的守卫和动态路由，用户没权限的菜单直接不显示，体验上干净利落。

2.3 工作量自动核算：比你想象中更好实现的业务核心

工作量核算是整个系统的灵魂。很多开发者一听到“自动核算”就紧张，觉得这里面肯定要写复杂算法，其实做下来你会发现，它的核心逻辑就是一个规则映射表加一个累加计算过程。

现在系统实现的计算规则大概长这样：科研成果表里每一条记录都带类型字段，比如PAPER_TYPE=“SCI一区”。系统里预设了一张计分规则表，规则表里存着“成果类型 → 基础分值”的映射。核算的时候，Service层把该老师名下的所有科研产出都捞出来，逐条读取其类型字段，查询出对应的基础分值，再乘上参与者排名系数，累加得到总工作量分。

关键技术点在于如何定义多种计分维度而不把代码写死。我的做法是把规则表独立出来，包含rule_type（规则类型）、item_type（成果类型）、base_score（基础分值）、unit（计分单位）、is_active（是否启用）这些字段。以后科研处要调整计分细则，维护人员直接在管理端改数据库记录即可，完全不碰代码。这种“数据驱动业务“的设计思路，是所有管理系统的必修课。

工作量核算之后还要保证每条计算过程有迹可循，所以系统里还设计了一张工作量明细流水表，每一位老师的每一笔科研产出对应的单位分、排名系数、实际分，全部落成一条一条的明细记录。要做报表的时候直接按条件聚合，领导要查某一个分是怎么算出来的，科研处也能把明细甩出来，有理有据，透明可审计。这一点对科研处来说非常重要，因为工作量公示之后必然有人来质疑来核对，没有明细表撑腰，系统就等于没有公信力。

3. 前端实现要点：Vue+Element UI 的工程化实践

3.1 页面路由与状态管理：别在逻辑里把项目写死

前端这一侧的架构设计，决定的是用户实际用起来爽不爽。这个项目前端采用的工程化方案是：Vue CLI创建项目，配合vue-router做路由管理、vuex做全局状态管理、axios做HTTP请求，UI框架用Element UI。

路由设计上采用模块化思路，登录页、工作台、项目管理、论文管理、知识产权管理、工作量统计、系统管理各占一块。这里有一个特别值得说的设计：动态路由和权限菜单是挂钩的。普通教师登录后只能看到“我的科研产出”和“我的工作量”，科研处审核员能看到“成果审核待办”，管理员才能看到“用户管理”和“规则配置”。实现的底层逻辑是路由表分成了“公共路由”和“动态路由”，用户登录后，前端根据角色去filter出可见路由，再用router.addRoutes动态添加进去。

这样做的好处不仅是界面好看，更是安全性的第二道防线。用户虽然在浏览器里能猜到其他页面的地址，通过URL直接访问，但后端接口会返回403，前端也会在路由导航守卫里做拦截。前端能拦一层、后端又能拦一层，这种纵深防御的思路做管理系统是必须的。

vuex在系统里的定位是跨页面状态缓存。比如当前登录用户的信息、全局的计分规则字典、下拉选项的枚举值，这些数据如果每个页面都去后端拉一遍，不仅是浪费资源，还会造成体验卡顿。我的处理方式是把它统一放到vuex里注册成module，应用启动时加载一次，后续页面直接从仓库里读。比如系统里所有下拉框要用的“成果类型”字典项，就是从store里直接取，改一条数据全站联动。

3.2 axios封装与接口调用的几个细节

axios是Vue里最常用的HTTP库，但这个项目里我把它做了一层封装，而不是直接裸用。很多人嫌麻烦直接在每个组件里import axios然后调用，结果当后端接口统一调整返回格式的时候，一堆组件里的代码全部要改，相当的酸爽。

这里封装的核心是一个http工具类和两个拦截器。请求拦截器负责从vuex里取token，往请求头的Authorization字段里塞，这样每个接口就都不用手动带token参数了。响应拦截器做两件事：第一，统一处理HTTP错误状态，比如401直接跳登录页并弹出token失效提醒；第二，解包后端统一返回的响应体data字段，让组件里的代码更干净。

还有几个开发细节值得展开说说。跨域问题是前端联调的必修课。本地开发时前端跑在8080端口，后端跑在8088端口，直接请求必然被浏览器的同源策略拦截。这个项目用Vue CLI的webpack-dev-server内置代理解决，在vue.config.js里配置devServer.proxy，把/api前缀的请求代理到后端的http://localhost:8088，前端的开发体验就完全像在跑同源请求一样。生产环境部署时，则是用Nginx配置反向代理来做同样的转发。

另一个细节是加载反馈。管理系统的操作基本上就是增删改查，请求有耗时，用户如果看不到loading状态就会觉得系统卡死或者误以为没点上去。Element UI的loading指令在这些场景用起来非常顺手，配合按钮的loading属性，操作体验会上一个档次。这是很多外包系统做得特别廉价的一个原因——接口数据之间的交互没有任何视觉反馈，用户自然评价不高。

4. MySQL数据库设计：所有功能的根基

4.1 核心表结构设计：业务关系一图理清

数据库是整个系统的地基，地基没打好，功能做得再多也是空中楼阁。这套系统的数据模型，主体可以概括成**“一个中心、三类成果、一套流水”**。

“一个中心”指的是教职工（教师）表，承载老师的基本信息——工号、姓名、所属部门、职称、入职年份等。它好比是坐标系的原点，所有科研产出都要挂到这个原点上来。“三类成果”就是前面说的科研项目表、论文成果表、知识产权/获奖表，各自记录成果的元信息。“一套流水”就是工作量明细表，把成果和分值的映射结果流水账保存下来。

以论文成果表为例，字段设计大概包括：论文标题、期刊名称、ISSN号、期刊级别（用枚举值/关联字典表）、发表年份、卷期页码、第一作者工号、通讯作者工号、是否通讯作者单位第一、收录情况等。特别注意一点：这个表只存“论文本身的信息”，不存“算分的系数”，也不存“分数结果”，因为这些都是运行时计算的，存进去反而会产生冗余和不一致。

项目成员关系上用了一张中间表（项目负责人和参与人），这是数据库设计的正规做法。我的建议是，永远不要在业务表里放一个“参与人列表”字段用逗号分隔字符串，这样设计后期做统计SQL时，你会被字符串切割气到怀疑人生。中间表其实非常简单，项目ID + 教职工ID + 排名序号，三列搞定，查询时一个JOIN全部解决。

工作量明细表的核心字段包括：成果类型、成果ID（关联到具体论文表/项目表的主键）、成果名称快照、计分规则ID、基础分值、排名系数、实际得分、核算年份、操作用户和操作时间。快照字段是点睛之笔，因为计分规则未来可能调整，如果不做快照，历史数据用新规则重新算一遍，账就算不对了。加上快照，历史单据就固定在当时的口径上，这个设计在财务和绩效类系统中极其重要。

4.2 数据库连接与初始化：跑通前的最后一公里

数据库侧最容易被新手绊倒的地方，是版本和连接配置。这套系统推荐使用MySQL 8.0以上版本，因为8.0的默认字符集已经是utf8mb4，对中文和emoji有良好支持。如果你还在用MySQL 5.7，也不是不行，但建库时务必手动指定utf8mb4，否则后面插入中文数据会碰到乱码和字符长度问题的概率大增。

建库语句通常是这么一句：

CREATE DATABASE research_workload DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

然后把项目里附带的research_workload.sql导入进来。导入方式有两种：命令行source，或者用图形工具Navicat/DataGrip直接运行SQL文件。初始化完成后，你会发现系统里已经有一套基础数据，包括默认管理员账号和演示用的教职工数据，这对手跑的阶段很友好。

后端连接数据库的配置集中在application.yml：

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

这段配置里藏着几个过往踩坑的教训。时区参数serverTimezone=Asia/Shanghai必须加，否则MySQL 8.0会报时区相关的连接错误，因为数据库默认的时区处理方式和驱动预期不一致。useSSL=false这个参数，直接原因就是本地开发环境不需要SSL加密，加了反而可能引入证书校验的麻烦，报一堆ssl连接错误。driver-class-name是8.0的全限定类名，5.7时代的老司机类名com.mysql.jdbc.Driver在这个版本里已经废弃了。

注意：如果你用的是MySQL 8.0，而网上下载的教程还在教你写旧的驱动类名或者不写时区参数，大概率连接会报错。认准上面的配置句式，直接抄就行。

数据库连接池这个项目用的是HikariCP，SpringBoot 2.x之后的默认连接池，性能是目前所有连接池里公认最强的一档。它的大多数配置项都保持默认即可，需要留意的是max-pool-size，如果后端的并发访问量较大，可以根据服务器内存适当调大，比如30。频繁创建连接的开销非常大，连接池的本质就是把这个开销摊薄，池子大小设置不当会导致并发高峰期接口变慢。

5. 从0到1：本地环境搭建与项目启动全流程

5.1 环境准备清单：照着装就行

拿到源码之后，建议先对照环境清单把开发环境装齐，这一步能避开后面至少80%的问题。整套环境包含四件套：JDK、MySQL、Maven、Node.js。

JDK建议装8版本（即1.8），这套系统用的是SpringBoot 2.7.x，JDK 8完美兼容且运行最稳。装JDK 17也能跑，但SpringBoot 2.x对JDK 17的兼容性不如OpenJDK 8成熟，没特殊理由别追求新版本。装完记得配JAVA_HOME环境变量，然后命令行执行java -version确认。

Maven用3.6.x到3.8.x都行。它的核心作用是帮你把SpringBoot那一堆依赖全部拉取到本地。装完之后需要配置阿里云镜像仓库，原因你懂的，Maven中央仓库在国内的下载速度会让人等到怀疑人生。在maven的conf/settings.xml里加一段mirror配置，把中央仓库镜像到阿里云，依赖下载的速度立竿见影。

Node.js装14.x或16.x长期维护版本都可。Vue CLI 4.x对Node的版本要求不高，但Node版本太高的话，遇到node-sass这类老依赖会编译报错。装完之后把npm的registry也切到淘宝镜像，npm install的速度会大幅提升：

npm config set registry https://registry.npmmirror.com

数据库这块按4.2节说的装MySQL 8.0，图形管理工具装Navicat或者免费开源的表结构管理工具DBeaver都行。DBeaver我最近用得比较多，纯Java写的软件，对MySQL的支持非常到位。

5.2 后端启动三步走：拿下来就能跑

后端工程用IDEA打开，等Maven把依赖下载完，然后按三步走启动。第一步，改配置。打开src/main/resources/application.yml，把数据库的username和password改成你本机的实际值。别的配置项一般不用动，因为项目里默认的端口、参数都已经为你调好了。

第二步，确保本地MySQL服务已经在运行，同时数据库已经按4.2节建好并导入完成。可以用一个最简单的命令验证：在命令行输入mysql -u root -p，能进入mysql命令行就说明服务正常。

第三步，找到主启动类，也就是类名带@SpringBootApplication注解的那个文件，点击运行。也可以在项目根目录执行：

mvn spring-boot:run

等待控制台输出一行 SpringBoot启动成功的日志，就大功告成了。后端默认在8088端口提供服务，浏览器访问http://localhost:8088可以看到一个项目信息页，或者直接去访问API接口测试。

我建议第一次启动的时候，顺手验证一下登录接口是否通。用Postman/Apifox这类工具发一个POST请求，地址是http://localhost:8088/api/auth/login，请求体带默认账号密码（项目里提供了admin/admin123之类的默认账号），如果你能收到一个包含token的JSON响应，那说明后端跟数据库的连接和鉴权链路全部畅通了。

5.3 前端启动与联调：两个终端搞定

前端工程是一个独立的Vue CLI项目目录，打开方式很简单，进入前端目录后执行依赖安装：

npm install

依赖装好之后，执行：

npm run serve

Vue CLI会默认在8080端口启动开发服务器。浏览器访问http://localhost:8080，你会看到系统登录页。用默认账号登录进去，就能开始体验完整功能了。

这里要特别说明一下vue.config.js里的代理配置，前端开发服务器能访问后端接口就是靠它：

devServer: { port: 8080, proxy: { '/api': { target: 'http://localhost:8088', changeOrigin: true } } }

它的工作原理是：浏览器请求http://localhost:8080/api/login，开发服务器拦截下来后，把请求转发到http://localhost:8088/api/login，再把后端的响应原封不动地返回给浏览器。前端的代码里不需要写任何绝对地址，全用相对路径/api开头，就能在开发阶段和部署阶段无缝切换。

注意：如果你同时开了多个Vue项目，8080端口可能被占，前端会提示你选择是否换一个端口。也可以手动改端口配置。开发阶段前端端口和后端端口不要相同，否则代理会指向自己。

个人体会，第一次把前后端都启动起来、成功从页面里看到数据联动的那一刻，这套体系就算彻底跑通了。往前迈一步，后面所有的功能调试、业务测试都有了下手的地方。

6. 常见问题与避坑指南（实测整理）

6.1 启动期高频故障排查表

这一节把我实际跑这个项目过程中遇见过的高频问题整理成速查表，直接对着查，能省大半天时间。

还有一个非常容易栽的坑是数据库版本不兼容。如果你用的是MySQL 5.7，而导入的SQL文件里出现了8.0才支持的特性（比如某些默认值表达式），导入过程就会报错。这条没写在表里但特别重要：拿到SQL文件后先看第一行和最后几行是什么，再确认字段类型，不要上来就source执行。

6.2 开发期最容易踩的5个坑

运行起来之后，实际业务开发中还会有一些隐蔽的坑。我把我自己体验最深的五个列出来，基本都是教科书里不会专门讲的。

第一个坑是跨域问题在开发环境没了，但生产环境又冒出来。开发环境有webpack代理兜底，大家往往忽略了跨域配置。部署到服务器时前端用Nginx托管、后端是独立端口，如果不配Nginx反向代理，生产环境就会各种接口请求失败。我的建议是生产环境一定用Nginx把前端页面和后端API统一到同一个域名（或同一端口下按路径分流），比如/api/开头的请求直接proxy_pass到后端服务，从这个根上消除跨域。

第二个坑是修改了数据库表结构但MyBatis-Plus没生效。MyBatis-Plus会自动映射实体类，如果你改了表字段但没同步实体类，查询结果就会缺字段，代码还不报错，特别隐蔽。改成表结构之后，务必检查对应的实体类和Mapper XML，保持三者字段一致。

第三个坑是JWT密钥硬编码在代码里。这是安全问题，当前源码里为了跑通方便放了一个默认密钥，生产部署的时候一定要改成自己的随机字符串，否则别人拿到源码就能伪造合法的token。

第四个坑是工作量核算的浮点精度问题。排名系数经常是三分之一、五分之一这种除不尽的数，如果直接用float类型存储，加出来的总分会出现0.0000001这种脏数据。数据库里分数和系数字段务必用decimal类型，Java对应使用BigDecimal。

第五个坑是时间字段的时区混乱。MySQL里存的时间是带时区的，Java侧如果不加统一时区处理，可能会出现数据库里存的是八点，导出报表却显示零点的情况。解决方式是在数据库连接的url指定serverTimezone，同时配置Jackson的时间格式化统一为yyyy-MM-dd HH:mm:ss。

7. 生产部署的几条个人经验

最后顺带聊一下部署，因为这大概是大家把项目跑通之后紧接着就会问的：怎么放到学校/单位服务器上去用。

后端直接打成可执行jar包就行，命令是mvn clean package，产出物在target目录下。把jar包放到服务器上，用一条命令就能启动：

nohup java -jar research-workload.jar --spring.profiles.active=prod > app.log 2>&1 &

这里--spring.profiles.active=prod的意思是切换到生产环境的配置，前提是你准备了application-prod.yml。生产配置里数据库连接改成内网地址，密码改成强口令，日志级别调成INFO。

前端打包就简单了：

npm run build

产出dist目录，里面是纯静态文件，扔到Nginx的html目录下就行。Nginx里配置上对后端接口的反向代理，一个最小可用的配置大概是：

server { listen 80; server_name your_domain; root /var/www/research-workload; index index.html; location /api/ { proxy_pass http://127.0.0.1:8088; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location / { try_files $uri $uri/ /index.html; } }

location /里的try_files配置是为了让Vue路由history模式能正确回退到index.html，刷新页面不404。这个坑特别经典，第一次部署Vue项目的人十有八九栽在这。

我在实际部署中还强烈建议加一个服务守护机制，比如systemd服务或者用docker compose管理容器。高校的服务器重启是家常便饭（机房维护、断电），没有守护机制的话，服务器一重启springboot就变成没有感情的墓碑，还得手动进服务器重新敲启动命令。配个systemd unit文件，设置Restart=always，二十分钟就能搞定，后期省心一大截。

8. 写在最后的几句体己话

这套系统源码的价值，不在于代码量有多大，而在于它把一个真实的业务场景完整地落成了工程。我见过太多学生项目或者外包项目，功能也能跑，但数据库字段设计得随心所欲、鉴权形同虚设、前端接口调用全是硬编码，根本经不起真实环境的使用。这套源码至少在“像正经工程”这件事上，没有掉链子。

我个人在实际操作中最有感触的一点是：管理系统的难点从来不是某个技术点，而是如何把业务规则梳理清楚，再把它翻译成数据模型和代码逻辑。工作量核算规则、成员排名系数、成果审核流程，这些才是系统真正的灵魂。技术选型上SpringBoot + Vue + MySQL的组合也许不酷，但它是当前业务型系统里容错率最高的搭配，普通Java开发、甚至学院派的老师都能快速接手。

最后再分享一个小技巧：你在跑通这个系统之后，完全可以把它作为二次开发的基座。比如把Excel导入导出改成对接学校统一身份认证，把报表模块接入大屏可视化系统，或者把计分细则做成管理端可视化的规则配置界面。这套系统的架构骨架足够干净，面对这些扩展点，你不需要伤筋动骨，顺着代码里的模块边界去扩展就行。这也是它的真正潜力所在。