企业官网建设流程全解析

搞科研管理的朋友应该都有这种体会：项目申报靠纸质表、中期检查靠群聊催、成果统计靠Excel汇总、经费台账靠翻发票，一个月光整理材料就能耗掉小半时间。这两年我陆续帮几个高校和科研院所做过类似的内部管理系统，结论很一致——一套称手的科研管理系统，真正要解决的并不是“录入数据”这件事，而是把散落在邮件、微信、Excel、纸质文件里的信息流，统一收拢到一条可追踪、可统计、可回溯的线上通道里。

我这次整理的项目，正是基于SpringBoot + Vue + MyBatis + MySQL这套非常成熟的互联网后端组合实现的科研管理系统。它覆盖了项目管理、成果申报、经费管理、审核流程、用户权限、统计报表等核心场景，前后端完全分离，代码结构清晰，是拿来就能二次开发的节奏。对刚接触Java全栈开发的朋友来说，它也是一个能完整练手RBAC权限、动态路由、多表复杂查询、事务控制等技术点的实战项目。这文章我就按实际开发的先后顺序，把系统设计思路、数据库建模、后前端落地细节、部署避坑经验，一条一条掰开讲。

1. 系统设计与技术选型：为什么非这套组合不可

1.1 需求拆解：科研管理系统到底管什么

很多人在设计这类系统时容易陷入“功能越多越好”的误区。实际上以我接触过的真实需求来看，科研管理SaaS也好、校内自建也罢，最核心的其实就四件事：项目全生命周期管理、成果登记与认定、经费使用台账、审核流转与统计报表。

项目全生命周期，指的是从申报书提交、立项审批、中期检查到结题验收，每个环节都要有状态；成果登记包括了论文、专利、软著、获奖、标准等不同成果类型的录入与附件上传；经费管理则需要按项目挂账，记录每一笔支出与报销进度；审核流转则是管理员和评审专家对各类申请进行逐级审批，留下完整操作日志。

这四个需求放到技术层面，要求的是：用户体系要支持多角色（管理员、科研秘书、普通教师/研究生、评审专家）；业务状态要可配置可流转；统计报表要灵活（比如按学院、按年度、按成果类型交叉分组）；附件上传与在线预览要稳。这套需求画像，恰好是SpringBoot+Vue+MyBatis这套组合最擅长的战场。

1.2 前后端分离架构的技术权衡

选用前后端分离，不是跟风，而是这套系统的使用场景决定了它必须分离。科研管理系统的使用者往往是分散在多个办公室、多个课题组的老师，前端需要部署在学校信息中心的服务器上，后端接口又要能被多个端调用（比如后续加个小程序端或钉钉端），只有把API独立出来，才能真正做到一套后端服务多处消费。

SpringBoot在这套架构里承担的是后端底座，它的价值不需要我多吹：内嵌Tomcat让部署变成一句java -jar，自动配置机制减少大量XML配置，spring-boot-starter生态让整合MyBatis、Redis、MinIO这些组件都变成了“加依赖+写配置”的事。Vue负责前端交互层，响应式数据和组件化开发非常适合后台管理系统这类表单密集型、表格密集型的界面。

这里说一句掏心窝的话：如果你需要在这个项目里跑OA式的流程审批、复杂的汇总统计，那这套组合的性价比非常高；但如果你的需求是电商交易这类高并发场景，或者强实时协同交互场景，那技术选型就要重新评估了。选型这件事，永远是需求决定技术，不是技术决定需求。

1.3 ORM选型：MyBatis为什么比JPA更适合这类系统

我在不少技术群里见过“都2025年了还用MyBatis，不直接用MyBatis-Plus吗”的争论。这里我的观点比较务实：MyBatis作为底层ORM，依然是这个项目最稳的选择，MyBatis-Plus属于增强工具，能加也可以加，但如果你希望把SQL控制权完全抓在自己手里，原生MyBatis会更纯粹。

科研管理系统报表多，查询复杂，经常出现五表联查、行转列、按条件动态拼SQL的情况。MyBatis的价值在于SQL完全由自己编写，每一条慢查询都可以精准优化；而JPA/Hibernate虽然开发快，但遇到这种复杂统计场景，要么写JPQL，要么走原生SQL，反而绕了远路。说得直白点，MyBatis就像手动挡，虽然每一步操作要自己来，但在山路弯道上你更清楚车轮在哪。

再说说MyBatis的缓存机制。一级缓存是SqlSession级别的，默认开启，同一个SqlSession内重复查询不会走数据库；二级缓存是Mapper级别的，默认关闭，需要你在XML里显式配置。科研管理系统里有一个特别容易踩的坑：多表关联查询时开启二级缓存，一旦其中某张表的数据被更新，缓存不会自动失效，就会查到脏数据。所以我的建议是，这个项目里别开二级缓存，复杂查询加Redis做业务缓存，可控性高得多。

2. 核心模块拆解与数据库设计

2.1 用户-角色-权限的RBAC模型设计

这个系统的权限模型是我最花心思的地方，也是整个项目的地基。没有一套稳妥的角色权限设计，后续所有功能都是空中楼阁。

我采用的是经典的RBAC（基于角色的访问控制）五张核心表：用户表（sys_user）、角色表（sys_role）、菜单表（sys_menu）、用户角色关联表（sys_user_role）、角色菜单关联表（sys_role_menu）。菜单表里有一个很关键的字段是component，它对应前端Vue组件路径，这就是动态路由的数据来源——用户登录后后端返回其可见的菜单列表，前端根据列表动态挂载路由。

菜单表还包含了按钮权限，比如“新增”、“审核”、“导出”这些操作按钮，前端通过v-permission指令或自定义指令来控制显示。这在科研管理系统的审核流程中很实用：普通用户看不到“通过/驳回”按钮，只有具备审核角色的账号才能看到。

用户表设计中有一个值得注意的细节：不要只存明文密码，至少要用BCrypt加密（Spring Security自带的BCryptPasswordEncoder），密码字段长度建议设置64位，因为BCrypt加密后的字符串长度就有60位。另外要加上status字段，支持账号禁用/启用，这比直接删除用户更符合管理系统的操作习惯。

2.2 业务表设计：项目、成果、经费三驾马车

业务表的设计决定了系统能承载的业务深度。我用一个实际项目的表结构来说话。

项目表（project）核心字段大概是这些：

CREATE TABLE `project` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `project_code` varchar(64) NOT NULL COMMENT '项目编号', `project_name` varchar(200) NOT NULL COMMENT '项目名称', `project_type` varchar(32) DEFAULT NULL COMMENT '项目类型：国家级/省部级/校级', `leader_id` bigint(20) DEFAULT NULL COMMENT '项目负责人ID', `leader_name` varchar(50) DEFAULT NULL COMMENT '负责人姓名', `department` varchar(100) DEFAULT NULL COMMENT '承担部门', `total_funding` decimal(12,2) DEFAULT NULL COMMENT '总经费（万元）', `start_date` date DEFAULT NULL COMMENT '开始日期', `end_date` date DEFAULT NULL COMMENT '结束日期', `project_status` tinyint(1) DEFAULT '0' COMMENT '状态：0草稿 1申报中 2评审中 3已立项 4已结题 5被驳回', `apply_file_url` varchar(255) DEFAULT NULL COMMENT '申报书附件URL', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_leader_id` (`leader_id`), KEY `idx_department` (`department`), KEY `idx_status` (`project_status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='科研项目表';

成果表（achievement）和经费表（fund）的逻辑类似，但有几个差异点值得提。成果表要区分成果类型，比如论文类型要记录期刊级别（SCI/中文核心/普通期刊）、作者排序（第一作者/通讯作者）、影响因子；专利类型要记录专利号、授权日期。我的做法是用一个achievement_type字段做区分，不同类型补录的信息放进一个extra_json字段存JSON格式，这样不用反复改表结构。

经费表则要绑定project_code，每一笔记录都包含收支方向（收/支）、金额、经办人、经费类型。统计科研经费使用率的时候，核心就是一条SQL：

SELECT p.project_code, p.project_name, p.total_funding, IFNULL(SUM(CASE WHEN f.biz_type = 'EXPENSE' THEN f.amount ELSE 0 END), 0) AS used_amount FROM project p LEFT JOIN fund f ON f.project_code = p.project_code WHERE p.project_status = 3 GROUP BY p.project_code, p.project_name, p.total_funding;

这里有个MySQL排序和分组的细节：GROUP BY的字段不仅要包含SELECT中的非聚合字段，还要注意排序字段如果涉及索引的话尽量让排序列也在索引里，否则MySQL5.7以上虽然默认开启了ONLY_FULL_GROUP_BY，但性能依然可能出问题。后文我会专门整理这类SQL优化的经验。

2.3 审核轨迹与状态机设计

科研管理系统的审核流程比一般后台管理系统复杂，因为涉及多级审批。我的方案是两张表配合使用：业务表只存当前状态（project_status），另外单独建一张审核记录表（audit_record）存全部历史轨迹。

CREATE TABLE `audit_record` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `biz_type` varchar(32) NOT NULL COMMENT '业务类型：PROJECT/ACHIEVEMENT/FUND', `biz_id` bigint(20) NOT NULL COMMENT '业务主键ID', `audit_status` tinyint(1) DEFAULT NULL COMMENT '审核结果：1通过 2驳回', `audit_comment` varchar(500) DEFAULT NULL COMMENT '审核意见', `auditor_id` bigint(20) DEFAULT NULL COMMENT '审核人ID', `auditor_name` varchar(50) DEFAULT NULL COMMENT '审核人姓名', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_biz_type_biz_id` (`biz_type`, `biz_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='审核记录表';

状态流转上，我在枚举层做了约束。项目状态从草稿到申报中再到评审中，是一条单向链路，不允许随意跳转。在Service层里我会写一个状态校验逻辑，比如只有当前状态为“申报中”的项目，审核接口才允许被调用，否则直接抛出业务异常。这种防护必须做在后端而不是只靠前端隐藏按钮，因为接口是可以被直接请求的。

2.4 数据库索引与查询优化的底层逻辑

数据库设计这块，我多啰嗦几句，因为这是上线后最容易出问题的环节。科研管理系统到后期可能积累几万条项目记录、几十万条成果记录。如果没有合理的索引，一个关联查询慢个三五秒很正常，领导打开报表页面转圈圈，体验非常差。

我的索引设计原则其实很简单：高频查询条件建复合索引，排序字段尽量进索引，区分度低的字段不要单独建索引。

比如前面建的project表，idx_leader_id用来支撑“查某人名下的所有项目”，idx_department用来支撑“按学院汇总统计”，idx_status用来做待办列表筛选。如果某天你的查询条件变成了“某个学院某个状态下的项目”，那就要建一个(department, project_status)的复合索引，而不只是继续靠单列索引硬扛。

再说说MySQL排序的一个关键点：ORDER BY如果无法使用索引，就会产生文件排序（filesort）。文件排序在小数据量下没感觉，但到几十万行的时候就是灾难。解决办法是让排序字段出现在复合索引的最右端或者单独建索引。但也要注意，MySQL的索引优化器并不是把所有带索引的字段组合在一起都能生效，最左前缀原则必须懂，否则建了索引也是白搭。

3. 后端落地实录：SpringBoot+MyBatis的关键细节

3.1 项目结构与依赖配置

后端项目我习惯按controller/service/mapper/entity/dto分层，同时加一个common包存放统一返回结果、异常处理、工具类。这个结构看起来朴素，但胜在直观——新接手的人看一遍目录就能明白每个类的职责。

pom.xml的核心依赖只需要这几样：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.1</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>com.github.pagehelper</groupId> <artifactId>pagehelper-spring-boot-starter</artifactId> <version>1.4.6</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency>

这里必须专门提醒一下：新版SpringBoot（3.x以上）对应的MyBatis starter版本必须要换，而且SpringBoot3必须搭配JDK17+，很多人在这一步翻车。如果你只是想快速跑起来这套管理系统，我的建议是选稳而不是选新：JDK8 + SpringBoot 2.7.x + MyBatis starter 2.3.x这套组合，经过大量生产环境验证，坑最少。SpringBoot版本太高导致的各种配置方式变化，我后面单独列一节讲。

application.yml里几个容易踩坑的配置项我提前说：

spring: datasource: url: jdbc:mysql://localhost:3306/research_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.research.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

allowPublicKeyRetrieval=true这个参数，MySQL8.0以上如果不加，经常报SSL连接错误或者Public Key Retrieval错误，不少新手在这里卡半天。serverTimezone一定要设置，否则日期字段查询和插入会有8小时的时差问题。map-underscore-to-camel-case改成true之后，数据库的create_time字段才能自动映射到实体类的createTime属性。

3.2 通用Mapper与PageHelper分页的整合

MyBatis项目里，每个实体都写一套重复的增删改查很浪费时间。我自己的做法是先用MyBatis Generator根据表结构生成基础代码（实体类、基础Mapper接口、基础XML文件），然后在Mapper层做一个泛型基类，把单表CRUD抽出来。

分页是这个系统绕不开的功能，列表页、审核页、报表页全都要分页。PageHelper是MyBatis生态里最成熟的分页插件，用法很简单：

PageHelper.startPage(pageNum, pageSize); List<ProjectVO> list = projectMapper.selectProjectPage(queryDTO); PageInfo<ProjectVO> pageInfo = new PageInfo<>(list);

但要特别注意，PageHelper.startPage()是静态方法，它只对下一条执行的MyBatis查询生效。如果在调用之前又执行了别的查询（比如先查了一次用户表），分页就会加到错误的SQL上。这种错误在日志里还不太好看出来，典型的排查方向是先自查代码调用顺序。

另外，分页插件对复杂查询（比如带聚合函数的报表统计SQL）有时候会生成错误的总数查询SQL。我的建议是：涉及GROUP BY或者SUM/COUNT的统计查询，不用PageHelper，手写一个count查询配合limit，既稳又可控。

3.3 动态SQL与事务控制

MyBatis动态SQL是这套系统查询灵活性的核心武器，尤其是科研项目列表那种筛选项特别多的场景：项目类型选不选？学院填不填？时间范围给不给？这些全得靠动态拼接。

一个典型的多条件查询XML片段：

<select id="selectProjectPage" resultType="com.example.research.entity.dto.ProjectVO"> SELECT p.*, u.nick_name AS leaderName FROM project p LEFT JOIN sys_user u ON p.leader_id = u.id <where> <if test="projectName != null and projectName != ''"> AND p.project_name LIKE CONCAT('%', #{projectName}, '%') </if> <if test="department != null and department != ''"> AND p.department = #{department} </if> <if test="projectType != null and projectType != ''"> AND p.project_type = #{projectType} </if> <if test="status != null"> AND p.project_status = #{status} </if> <if test="startDate != null"> AND p.start_date &gt;= #{startDate} </if> </where> ORDER BY p.create_time DESC </select>

<where>标签会自动处理掉第一个条件的AND关键字，这个机制要理解，不然手写WHERE 1=1既丑陋又容易出错。

事务控制方面，科研管理系统里最典型的事务场景是一次操作涉及多张表的变更。比如项目立项通过时，不仅要改project表的状态，还要在audit_record表里插入审核记录，同时可能还要在fund表里初始化一条经费记录。这三个操作必须保证原子性。

SpringBoot的声明式事务用@Transactional注解就能搞定，但有几个细节需要注意：

• @Transactional加在类上，则该类所有public方法都开启事务；加在方法上则只对单方法生效，方法上的配置会覆盖类上的配置。
• 默认情况下，事务只在抛出RuntimeException（运行时异常）时回滚，如果方法里catch住了异常却没重新抛出，事务是不会回滚的。
• 研究过程中发现的大问题：@Transactional只对通过Spring代理调用的方法生效，同类内部this.method()调用是绕过代理的，事务不生效。这是个非常经典的坑。

3.4 附件上传与在线预览方案

科研管理系统离不开附件场景：项目申报书PDF、论文原文、专利证书扫描件、结题报告。这些大文件肯定不能塞进MySQL，也没必要直接放在应用服务器本地。

我在这套项目里把附件存储抽象成了MinIO对象存储。MinIO是目前把文件存储落地到自建系统里非常顺手的方案——它兼容S3接口，支持私有bucket和预签名URL，还不需要像FastDFS那样单独搭建复杂的集群。把它集成进SpringBoot只需要三步：加依赖、配置endpoint和密钥、注入MinioClient。

<dependency> <groupId>io.minio</groupId> <artifactId>minio</artifactId> <version>8.4.6</version> </dependency>

minio: endpoint: http://192.168.1.100:9000 access-key: minioadmin secret-key: minioadmin bucket-name: research-files

上传接口的核心逻辑是：接收MultipartFile -> 校验文件类型和大小 -> 生成不重复的文件名（我习惯用日期+UUID）-> 调用MinIO putObject -> 把返回的文件路径存入业务表字段。下载/预览时，通过预签名URL给前端返回带有效期的访问链接，不需要把bucket设成公共可读，安全性更好。

另外如果系统里需要在线播放项目答辩视频，MinIO存储的mp4或m3u8切片都可以通过预签名URL直接播放。m3u8的HLS流媒体协议在浏览器里不能直接用原生video标签播放，需要配合hls.js或者video.js处理，这个细节前端部分我会再说。

4. 前端落地实录：Vue项目的工程化组织

4.1 Vue项目的初始化与目录结构

前端我用的Vue CLI创建的工程（Webpack构建），如果你喜欢Vite那套更快的启动体验也可以，核心代码不变。目录结构是后台管理系统社区里非常成熟的一种组织方式：

src/ ├── api/ # 接口定义，按模块拆分 ├── assets/ # 静态资源 ├── components/ # 公共组件 ├── router/ # 路由配置 ├── store/ # Vuex状态管理 ├── utils/ # 工具类（request封装、token存储等） ├── views/ # 页面组件，按模块分目录 ├── App.vue └── main.js

唯一要强调的是，api/目录下每个文件对应后端一个模块的接口，比如project.js里集中放项目管理相关的所有请求：

import request from '@/utils/request' export function getProjectPage(data) { return request({ url: '/api/project/page', method: 'post', data }) } export function auditProject(data) { return request({ url: '/api/project/audit', method: 'post', data }) }

这样做的目的是接口管理集中化，后端改了URL或参数，前端只需要动一个文件，不用跑到每个页面里去翻。

4.2 动态路由在权限系统中的应用

前面我在权限设计时说过，菜单表是动态路由的前端数据源。这里把流程走一遍：

1. 用户登录，后端校验账号密码，签发JWT令牌。
2. 前端拿到token之后，立即调用/api/user/info接口，拿到当前用户的基本信息、角色列表、菜单权限列表。
3. 前端对菜单列表做递归处理，生成Vue Router可以识别的路由记录。
4. 使用router.addRoute()动态注册这些路由。

动态路由最常见的坑是：刷新页面后路由丢失。因为刷新后Vue实例重建，内存里的动态路由全没了，而用户信息是异步加载的。解决思路在路由守卫里判断：如果当前路由记录为404（说明动态路由还没挂载），就先调用用户信息接口重新拉取菜单并注册路由，然后next({...to, replace: true})重新导航。

这套机制配合按钮级权限，能在用户在界面上真正做到“看不到就是没有”。

4.3 axios请求封装与统一异常处理

axios封装是整个前端工程的地基，我所有项目的request工具类基本都是一个模板：

import axios from 'axios' import { Message } from 'element-ui' import router from '@/router' import { getToken, removeToken } from '@/utils/auth' const service = axios.create({ baseURL: process.env.VUE_APP_BASE_API, timeout: 15000 }) service.interceptors.request.use( config => { if (getToken()) { config.headers['Authorization'] = 'Bearer ' + getToken() } return config }, error => Promise.reject(error) ) service.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { Message({ message: res.message || '请求错误', type: 'error' }) return Promise.reject(new Error(res.message)) } return res }, error => { if (error.response && error.response.status === 401) { removeToken() router.push('/login') } Message({ message: error.message, type: 'error' }) return Promise.reject(error) } ) export default service

这里有几个细节值得展开。第一是前后端的统一返回结构必须要约定清楚，我用的格式是{ code, message, data }，code为200代表成功；第二是401状态码统一跳登录页并清除本地token，避免用户停留在失效页面以为自己还能操作；第三是文件下载的接口要设置responseType: 'blob'，并且在拦截器里单独区分，否则下载下来的文件是一堆JSON字符串。

4.4 通用组件：上传、表格、审批流的复用化

后台管理系统70%的页面都是“表格+搜索表单+弹窗表单”的组合。如果每个页面都写一遍完整代码，以后改公共样式能让人崩溃。我抽了几个高频组件：

• 搜索表单组件：根据配置数组自动渲染查询条件。
• 分页表格组件：内置el-table + el-pagination，监听页码变化，自动请求数据。
• 文件上传组件：封装el-upload，对接MinIO后端接口，返回文件URL并回填表单。
• 审核弹窗组件：根据业务状态显示“通过/驳回”按钮，提交审核意见。

组件化的核心思路是配置驱动而不是重复编码。比如审核弹窗组件接收一个auditConfig对象，里面包含业务类型、当前状态、审核人字段，组件内部根据配置决定按钮如何渲染、提交到哪个接口。这样做之后，新增一个审核业务场景，前端只需要新增页面级别的组装逻辑，公共交互全部复用。

在线播放项目答辩视频的场景，我在组件里用的是hls.js来处理m3u8格式。大致逻辑是：拿到MinIO预签名URL后，判断文件是否为m3u8结尾，是的话动态加载hls.js库并调用Hls.isSupported(),再把视频流attach到video元素上。这样科研管理系统里除了文档预览，也能支持答辩录像的回放查看。

5. 环境搭建与部署避坑

5.1 开发环境版本搭配清单

这套系统开发环境的版本搭配，我强烈建议直接抄下面这份清单，都是我反复验证过的稳定组合：

注意Node.js版本这个坑。新版Node（18+）在部分Vue CLI4项目里编译时会遇到OpenSSL相关的报错，错误信息类似error:0308010C:digital envelope routines::unsupported。网上能找到的解法是在package.json里加"dev": "NODE_OPTIONS=--openssl-legacy-provider vue-cli-service serve"，但这只是绕过，治本方案是固定Node版本。

5.2 MySQL安装与初始化注意事项

MySQL的安装网上教程一搜一大把，我这里只讲容易翻车的几个点。

Windows下安装MySQL8.0的典型流程是：下载zip包或msi安装包，配置my.ini文件，用管理员权限打开命令行执行mysqld --initialize-insecure，然后mysqld -install注册服务，最后net start mysql启动服务。初始化后默认root没有密码，直接mysql -u root -p回车就能进，进去第一件事是执行：

ALTER USER 'root'@'localhost' IDENTIFIED BY '你的密码';

Linux下用rpm方式安装要记住：MySQL8的rpm包会把数据目录放在/var/lib/mysql，首次启动前务必看/var/log/mysqld.log里的临时密码，再用mysql -u root -p临时密码登录修改。

初始化数据库时，字符集一定要用utf8mb4，因为科研管理系统里会有中文、英文、还有可能出现的数学符号甚至Emoji（有些备注里会粘贴特殊符号），utf8mb4才能真正兼容。

5.3 前后端部署的两种方案

这套系统的部署方案我试过两种，各有适用场景，这里都写出来供参考。

第一种是前后端分开部署：后端SpringBoot打成jar包运行在8080端口，前端Vue打包后扔到Nginx的静态目录，Nginx监听80/443端口，通过/api/前缀把接口反向代理到后端。

server { listen 80; server_name yourdomain.com; location / { root /usr/share/nginx/html; index index.html; 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; } }

第二种是Vue打包直接放进SpringBoot：把npm run build产出的dist目录内容复制到src/main/resources/static/下，改一下后端（不让拦截器拦截静态资源），打包成一个jar对外提供服务。这种方式适合小规模内部系统简化部署，但有几个坑：如果前端用了history路由模式，刷新页面会404，需要在SpringBoot里做一个转发控制器，把所有非/api请求转发到index.html。

我自己的倾向是：有Nginx条件就用第一种，没有就第二种。但无论哪种，跨域问题都要处理好。如果走Nginx代理，同源下基本不会跨域；如果前后端分离开发，则建议在Vue的vue.config.js里配devServer proxy，而不是在后端配CORS，因为上线时的Nginx代理往往比CORS更干净。

5.4 跨域与SSL连接问题排查

跨域问题的表现是前端浏览器控制台报Access-Control-Allow-Origin相关错误，后端日志里其实能看到请求已经进来。如果你决定在后端配CORS，加一个配置类就行：

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedHeader("*"); config.addAllowedMethod("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

我实际工作中遇到最多的部署问题是：后端跑得好好的，前端一请求就报504或连接被拒。排查思路按顺序来：先确认后端端口有没有被防火墙拦截；再确认数据库连接池有没有因为并发把连接数用完；最后确认MySQL的mysql-connector-j依赖版本和MySQL服务器版本是否匹配。MySQL8要用com.mysql.cj.jdbc.Driver驱动类，如果在SpringBoot2.7里还去配com.mysql.jdbc.Driver，连接初始化就直接报错。

6. 常见问题速查表与实战心得

6.1 高频问题与解决方案速查表

我把这套科研管理系统从开发到上线全过程中遇到的典型问题整理成了速查表，按出现频率排了序：

6.2 我在这个项目里踩过的三个典型坑

第一个坑在初始化阶段。当时我图省事直接用了最新版SpringBoot3.2，结果发现之前习惯用的很多starter都不兼容，MyBatis的配置方式改了不少地方，连JDK也得升到17。折腾半天之后我把SpringBoot版本回退到2.7.x，这才顺畅地把项目基础框架搭起来。我的心得是：接手已有项目或者新起一套以业务为主的管理系统时，技术栈版本宁稳勿新。新版框架带来的新特性对这套管理系统来说，远没有稳定可靠的值钱。

第二个坑来自动态路由。第一次做这套系统的时候，我把路由注册放在了登录页跳转之后立刻执行，结果用户登录后点菜单一切正常，但一按F5刷新就跳到404。排查了很久才发现是刷新后路由表被清空，而用户信息还没加载回来。后来我在路由守卫里加了“动态路由已注册”的判断，再用重新导航的方式解决。这个坑提醒我一个重要原则：前端的权限控制必须考虑刷新、直接输URL、浏览器后退这几种场景，不能只盯着正常点击流程。

第三个坑在数据库连接参数上。MySQL8.0在密码认证插件升级之后，我第一次连接时报了Public Key Retrieval is not allowed，看了半天官网文档才明白需要在连接串里加allowPublicKeyRetrieval=true。类似的还有SSL连接错误e0434352，本质是MySQL8默认开启SSL校验，而本地又没有配置证书。我的处理是完全关闭SSL（useSSL=false）——内网环境下SSl的意义本来就不大，反而徒增配置成本。

6.3 这套系统还能怎么扩展

最后说点这项目后续可以走的方向，给有二期规划的朋友参考。

第一是报表中心增强。目前我用的是SQL直接统计，如果想给领导一个可视化驾驶舱，可以引入ECharts在Vue前端做图表展示，比如各学院立项数量对比、经费使用率趋势、成果类型分布饼图。后端只需要把统计SQL的结果返回成图表组件能直接消费的数据结构。

第二是做消息通知与待办提醒。审核类操作的体验很依赖通知触达。给被审核人发系统站内信是基本操作，如果还想增强，可以接入邮件或企业微信通知，SpringBoot里用JavaMailSender发邮件其实不难。

第三是定时任务生成统计报表。SpringBoot自带@Scheduled注解就能支持，每天早上生成前一天的项目申报量、成果录入量、经费支出汇总，按部门维度塞进一张报表表里。领导打开系统看到的是预生成的报表，而不是等SQL现场跑几秒，体验差很多。

第四是导出Excel能力。用EasyExcel或Apache POI把列表数据和统计报表导成Excel，这在科研管理系统里几乎是刚需。做法是后端生成文件并上传MinIO，返回下载链接给前端，这样不会因为数据量大导致接口超时。

我个人的总体体会是，这套基于SpringBoot+Vue的科研管理系统，从头到尾完整走一遍，真正值钱的地方不在某个单一技术点，而在系统设计的完整度——数据库怎么建模才能支撑复杂查询，权限模型怎么设计才能覆盖多种角色，前后端怎么配合才能兼顾开发效率和上线后的可维护性。把这些想清楚、实现出来，你收获的不只是一个能跑的系统源码，更是一整套后台管理类项目的通关经验。