企业官网建设流程全解析

我拿到这个项目源码文件夹的时候，第一反应是整理它的核心脉络。标题已经把技术栈写得很清楚——SpringBoot2做后端服务、Vue3做前端页面、MyBatis-Plus操作数据库、MySQL8.0存数据，本质上是一套前后端分离的师生健康信息管理系统。这类项目在教育信息化场景里很常见，高校、中小学、培训机构都有需求，核心是把学生的健康档案、晨午检记录、疫苗接种信息、体检数据统一管理起来，替代过去的纸质表格和Excel台账。

我更想聊的是这套项目中真正值钱的东西：不是框架本身，而是围绕这个业务场景做的数据模型设计、权限体系、报表统计逻辑，以及在本地跑通整套系统时会踩的坑。这篇文章我会把项目从功能拆解到技术落地全过程讲透，也把SpringBoot2+Vue3+MyBatis-Plus+MySQL8.0这套组合里最容易出问题的地方拿出来单独说。不管你是刚接触Java Web的学生，还是准备做类似管理系统的开发者，照着这篇文章的思路去梳理一个前后端分离项目，会省掉大量摸索时间。

1. 系统定位与功能模块拆解

1.1 这类系统到底要解决什么问题

师生健康信息管理系统听起来是个挺笼统的名字，但落到业务上，其实是一套专门给学校卫生管理场景用的数据平台。过去学校收集学生健康信息，靠的是班主任发Excel表、校医手动汇总，数据一多就乱，查某个学生的历史记录要翻半天文件夹。这个项目本质上就是把这类工作流搬到线上，让健康数据的采集、存储、查询、统计都自动化。

按我接触过的同类项目来看，核心角色一般分四类：系统管理员负责账号和基础数据维护，班主任或辅导员录入本班学生的日常健康信息，校医查看全校数据并处理预警，学生本人可以登录查看自己的档案和上报身体状况。角色的差异决定了权限设计必须细致，不能出现学生能看到全校数据的低级错误。这类系统看起来管理端功能占大头，但用户端的上报入口和查询入口同样不能缺，否则就变成纯内部工具了。

1.2 核心业务模块与角色权限设计

拿这个项目的标准功能清单来拆，基本可以拆成六个模块：

• 用户管理：账号维护、角色分配、重置密码、登录日志。
• 学生档案管理：学生基础信息、班级归属、既往病史、过敏史、监护人联系方式。
• 健康记录管理：晨午检记录、因病缺勤登记、就诊记录、疫苗接种记录。
• 体检与体质数据：年度体检报告、身高体重视力等指标跟踪。
• 异常预警与统计报表：发热、传染病症状预警，各类健康数据统计图表。
• 系统配置：健康指标阈值、预警规则、数据字典。

权限设计上，我建议采用RBAC模型，也就是基于角色的访问控制。管理员属于超级角色，拥有所有权限；校医拥有健康档案和预警模块的读写权限；班主任拥有本班学生档案的读写权限；学生只有本人数据的查询和每日上报权限。这个模型在SpringBoot项目里实现成本很低，一张用户表、一张角色表、一张菜单权限表就能搞定，配合拦截器和注解就能完成接口层的权限校验。

1.3 一条核心业务流程的完整链路

我挑一条最典型的流程来说明系统如何运转，晨午检记录上报。班主任登录系统后进入本班学生列表，选择当天的日期，为每个学生填报体温和健康状况，系统自动比对后台配置的体温阈值，比如37.3摄氏度，一旦超过就自动打上预警标记并推送给校医角色。校医看到预警后可以进一步处理，登记是否就医、是否隔离观察。

这条链路包含了这个项目最核心的设计思路：数据采集在前端，规则判断在后端，异常通知靠角色权限。前端只需要负责表单填写和数据展示，所有的业务规则都收敛在后端接口层，这样后续新增规则时不需要改动前端页面。项目文档里如果对这块有截图，你会发现班主任端、校医端的学生数据列表虽然长得像，但可用操作完全不同，这就是权限控制落到页面按钮和接口两个层面的结果。

2. 技术选型与整体架构说明

2.1 为什么是这个技术组合

SpringBoot2、Vue3、MyBatis-Plus、MySQL8.0这个组合，放到今天依然是Java Web项目里非常主流的一套方案。对于做学业项目或中小型管理系统的人来说，它最大的优势是社区资料多、上手成本低、踩坑基本都能搜到解决方案。我见过不少项目为了追赶技术热点上了SpringBoot3或JDK17，结果遇到某个依赖不兼容，排查半天。SpringBoot2基于JDK8开发，兼容性最好，大量生产环境的第三方库对它支持也最完善。对学习者和中小型项目来说，稳才是第一位的。

MyBatis-Plus的选择就更实际了。它本质上是MyBatis的增强工具，内置了通用的CRUD方法、条件构造器、分页插件、代码生成器，单表操作基本不用手写SQL。对这套师生健康管理系统来说，大部分数据操作都是单表查询加简单条件过滤，比如按班级查学生、按日期查记录，MyBatis-Plus能把这部分效率提得很高。加上它支持XML自定义SQL，遇到复杂查询也不会被卡住，算得上两全其美。

Vue3这边的理由也很直接。Vue2虽然存量项目多，但官方已经停止维护了。Vue3的组合式API让逻辑复用变得更干净，配合Vite开发时的热更新速度比Webpack快得多。像健康上报这种表单密集型的页面，用组合式API把逻辑按功能拆成一个个composable，代码组织起来会舒服很多。

2.2 前后端分离架构与标准目录结构

很多同学拿到项目源码后第一个困惑是：为什么没有JSP页面？这就要说到前后端分离了。SpringBoot后端只负责提供JSON接口，前端Vue3项目通过HTTP请求调用这些接口，两者通过约定好的接口文档协作。访问系统时，浏览器先加载Vue打包后的静态文件，再通过Ajax向后端拿数据，页面路由由前端框架控制。

后端标准的Maven工程目录结构大致是这样：

src/main/java ├── com.xxx.health │ ├── controller // 接口层 │ ├── service // 业务逻辑层 │ ├── mapper // 数据访问层 │ ├── entity // 数据库实体类 │ ├── dto // 传输对象 │ ├── config // 配置类 │ ├── common // 通用结果返回、异常处理 │ └── utils // 工具类 src/main/resources ├── mapper // MyBatis XML文件 ├── application.yml // 核心配置 └── sql // 初始化脚本

前端Vue3项目一般是独立的文件夹，比如frontend或web，内部结构遵循Vite+Vue3的约定，src/views放页面、src/components放组件、src/api放接口封装、src/router放路由配置。理解了这个标准结构，看任何同类项目都不会懵。

2.3 为什么不做成微服务

这个项目使用单体架构是合理的选择。师生健康信息管理系统的用户规模和应用场景决定了它不需要微服务的支持。从部署角度看，SpringBoot应用打成一个JAR包，前端构建后扔进Nginx或者直接打包成静态资源，一台服务器就能跑完整个系统，运维成本极低。学生作业、课程设计或者中小型学校内部部署，这种架构是最实用的方式。

微服务虽然听起来高端，但引入了服务注册、配置中心、分布式事务等一系列问题，对这个小规模系统来说是纯粹的过度设计。做技术选型一定是从业务需求出发，不是从技术热度出发。

3. 数据模型与核心库表设计

3.1 数据库设计的关键原则

系统就一个核心原则：表的拆分粒度要跟业务对象对齐，而不是跟页面结构对齐。很多人在设计数据库时习惯按页面来建表，页面上有几个输入框就建几个字段，最后导致一张表塞了几十列，或者一个字段在不同表中重复存储。

师生健康管理系统建议这样划分核心表：

• sys_user：系统用户表，包含账号、密码、姓名、角色类型、状态字段。
• student_info：学生档案表，包含学号、姓名、性别、班级、出生日期、既往病史、过敏史等。
• health_check：晨午检记录表，包含日期、体温、症状描述、检查结果。
• vaccine_record：疫苗接种记录表。
• physical_exam：体检记录表，存储每次体检的各项指标。
• warning_record：预警记录表，记录异常规则触发的信息。
• sys_dict：数据字典表，用于维护下拉选项，实现动态扩展。

3.2 几张核心表的字段拆解思路

学生档案表是整个系统的数据底座，字段设计要兼顾完整性和可扩展性。除了姓名、学号、性别这些基础字段，过敏史和既往病史应该用文本类型存储，同时建议预留一个ext_infoJSON字段，后续在业务中遇到字段变化时不需要直接改表结构。

晨午检记录表是最高频写入的表，每天每个学生都可能产生一条甚至多条记录。这张表建议加联合索引，按student_id和check_date建索引，查询某个学生某段时间的记录时走索引能快很多。字段上建议区分体温值、症状描述、检查状态，检查状态用来表示正常、异常、待复查。

预警记录表的设计逻辑要稍微多想一步。它不只是存一条预警消息，还要存触发规则、处理状态和处理人ID，方便后续追溯。我是建议预警表里冗余一份学生姓名和班级名称，查询时减少一次联表，虽然违反了一点范式，但查询体验好很多。

3.3 数据安全与隐私保护设计

师生健康信息属于个人敏感信息，数据安全不能忽视。密码必须使用BCrypt加密存储，不能是明文或简单MD5。健康记录相关的接口要做权限校验，防止越权访问，这里就需要配合SpringBoot的拦截器或AOP实现。数据库连接账号建议单独创建，不要用root账号连业务库。前端展示敏感数据时做好脱敏，比如手机号中间四位打码。这些细节在文档里可能只是一句话带过，但实际做项目时，这些决定都比较关键。

4. 后端核心实现与MyBatis-Plus落地

4.1 后端项目搭建与统一返回结构

后端工程推荐直接使用Spring Initializr创建，选择Spring Web、MySQL Driver、Lombok依赖，然后在pom.xml中手动加入MyBatis-Plus的starter。MyBatis-Plus的SpringBoot2版本的starter坐标和SpringBoot3不同，用3.5.x版本的mybatis-plus-boot-starter时，它内部的传递依赖对SpringBoot2的兼容性最好。

接口层的返回值一定要设计成统一结构，我推荐一个基础的Result<T>类：

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.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; } }

这样前端收到的JSON结构就是固定的{code, message, data}三段式，无论是axios还是fetch，拦截器都只处理这一个结构，写前端业务代码时会非常省事。

4.2 MyBatis-Plus的使用要点与XML配置

MyBatis-Plus最大的价值是CRUD方法可以少写SQL。比如学生档案的Mapper接口，直接继承BaseMapper<Student>，就有了selectList、selectById、insert、updateById、deleteById这些方法。查询学生列表时用LambdaQueryWrapper，代码几乎是直译成SQL：

public List<Student> getStudentsByClassId(Long classId, String keyword) { LambdaQueryWrapper<Student> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Student::getClassId, classId); if (StringUtils.hasText(keyword)) { wrapper.like(Student::getName, keyword); } wrapper.orderByAsc(Student::getStudentNo); return studentMapper.selectList(wrapper); }

分页查询配合分页插件使用，在配置类中注册MybatisPlusInterceptor并添加PaginationInnerInterceptor，之后调用selectPage方法就会自动生成LIMIT语句。需要注意数据库类型要设置成MySQL，否则分页SQL的方言可能不兼容。

XML文件的位置配置是很多人卡住的地方。SpringBoot项目里XML文件一般放在src/main/resources/mapper目录下，同时需要在application.yml中配置路径：

mybatis-plus: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.xxx.health.entity

如果你的XML文件和Mapper接口放在同一个包目录下，还需要修改pom.xml中的资源目录配置，并且在application.yml加上对应的扫描路径。这个配置我第一次做时也调试了半天，所以特别提醒一下。

4.3 健康报表的复杂SQL实现

健康信息管理系统不可能全是单表操作，报表模块一定会有联表查询。比如统计一个班级某月发热人数、查询某学生的完整健康档案，这些都需要自己写XML SQL。

MyBatis-Plus的XML写法兼容MyBatis的标签体系，<where>、<if>、<foreach>这些动态SQL标签非常实用。比如按条件动态查询健康预警记录：

<select id="selectWarningList" resultType="com.xxx.health.entity.WarningRecord"> SELECT w.*, s.name AS student_name, s.class_id FROM warning_record w LEFT JOIN student_info s ON w.student_id = s.id <where> <if test="studentName != null and studentName != ''"> AND s.name LIKE CONCAT('%', #{studentName}, '%') </if> <if test="classId != null"> AND s.class_id = #{classId} </if> <if test="startDate != null and endDate != null"> AND w.warning_date BETWEEN #{startDate} AND #{endDate} </if> </where> ORDER BY w.warning_date DESC </select>

动态SQL的<if>条件的判断逻辑值得注意，每个参数都要单独判断空值情况，否则SQL拼接容易出错。代码生成器可以自动生成Entity、Mapper、Service的代码，使用MyBatis-Plus的AutoGenerator工具，能省不少手写代码的时间，但生成后建议检查一下生成的字段类型是否正确映射。

5. Vue3前端工程搭建与应用模式

5.1 使用Vite创建项目与工程结构

前端工程推荐使用Vite创建，命令很简单：

npm create vite@latest frontend -- --template vue

相比Vue CLI基于Webpack的方案，Vite基于ESBuild做依赖预构建，开发服务器启动速度快很多，热更新也是毫秒级的。Vue3的工程结构比Vue2清晰不少，src/views放路由页面，src/components放通用组件，src/api放接口请求封装，src/router放路由配置。如果项目用的状态管理是Pinia，那src/stores就放状态模块。

项目里如果用了JSX，需要在vite.config.js里配置插件支持。多数情况下写模板语法就够了，JSX不是必选项，用组合式API已经能把逻辑组织得很好。

5.2 axios封装与登录状态管理

Vue3项目里连接后端，核心就是axios的封装。不要在每个页面直接写axios.get(url)，而是做一个统一的请求模块，把基础URL、请求拦截器、响应拦截器都放进去：

import axios from 'axios' import { ElMessage } from 'element-plus' import router from '@/router' const service = axios.create({ baseURL: '/api', timeout: 10000 }) service.interceptors.request.use( config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config }, error => { return Promise.reject(error) } ) service.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message || '请求失败') if (res.code === 401) { router.push('/login') } return Promise.reject(new Error(res.message)) } return res.data }, error => { ElMessage.error(error.message || '网络异常') return Promise.reject(error) } ) export default service

这段代码里把token注入到请求头、统一错误提示、401跳登录页这三件事都做了，后续每个API文件只需要关心业务数据。登录状态这里推荐用localStorage存token加Pinia存用户信息，刷新页面时从localStorage恢复，保证重新加载后不用重新登录。

5.3 动态路由与菜单权限控制

后台管理系统几乎都有动态菜单的需求，不同角色登录后看到的菜单不同。这个是前端权限控制的核心逻辑。

实现思路是：用户登录后，后端返回该用户有权限访问的路由列表数据，前端用router.addRoute动态注册路由，同时遍历生成侧边栏菜单。路由表里给每个路由配置meta: { title, icon, roles }，渲染菜单时根据当前用户角色过滤。

const permission = { state: { routes: [] }, generateRoutes(roles) { return new Promise(resolve => { const accessedRoutes = filterAsyncRoutes(asyncRoutes, roles) this.state.routes = accessedRoutes resolve(accessedRoutes) }) } }

需要注意，刷新页面时动态注册的路由会丢失。解决办法是在路由守卫里判断store中是否已有routes，如果没有就重新调用生成路由的方法。这个坑在Vue3后台管理系统里几乎必踩。

5.4 前后端联调的代理配置

Vue3项目本地开发时，前端跑在5173端口，后端跑在8080端口，直接请求会有跨域问题。在vite.config.js中配置代理：

export default defineConfig({ server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, rewrite: (path) => path.replace(/^\/api/, '') } } } })

这样前端请求/api/user/list会被代理到http://localhost:8080/user/list，浏览器的跨域限制就从源头上绕开了。生产环境则通过Nginx做反向代理，把后端服务代理到同一域名的/api路径下。

6. 本地部署、常见问题与优化建议

6.1 本地环境准备与启动顺序

跑这个项目前需要准备的环境如下：

• JDK 8及以上版本，建议使用JDK8或JDK11，版本别太激进。
• Maven 3.6以上版本，用于编译打包后端。
• Node.js 16以上版本，用于构建前端Vue3项目。
• MySQL 8.0数据库，本地安装或Docker安装均可。

MySQL8.0的安装有几种方式，简单的是直接下载安装包一步到底，进阶一点用Docker起容器。Docker方式特别适合不想污染本机环境的人：

docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=123456 \ -e MYSQL_DATABASE=health_db \ mysql:8.0

启动顺序建议先启动MySQL，确认数据库能连上再启动后端SpringBoot，最后启动前端Vue3开发服务器。项目初始化时会自动执行sql目录下的建表脚本，或者由你手动导入health_db.sql文件。

后端启动前要确保application.yml里的数据库连接信息正确，尤其注意用户名、密码、数据库名要和实际环境一致。前端启动前先执行npm install安装依赖，再执行npm run dev启动开发服务器。

6.2 本地部署时常遇到的几个问题

MySQL8.0的驱动和时区问题是最常见的。MySQL8.0的驱动类名改成了com.mysql.cj.jdbc.Driver，老项目里如果还写com.mysql.jdbc.Driver会直接报错。URL配置时建议加上时区参数，否则会有8小时时差问题：

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

如果不用serverTimezone参数，连接时大概率会报The server time zone value is unrecognized。这些都是新手很容易白白浪费时间的地方。

端口占用问题也很常见。SpringBoot默认跑在8080，Vite开发服务器默认跑在5173。如果本机端口被占用，后端可以在配置里修改server.port，前端可以在vite.config.js里修改server.port。

前后端跨域问题在本地开发时，只要正确配置了Vite代理就不会遇到；如果没配代理，就会看到浏览器报CORS error。最快的验证方式是直接访问http://localhost:8080的一个接口，如果能通就说明后端正常，然后再排查前端代理配置。

6.3 系统上线前的功能自检清单

正式部署给用户使用前，要按下面的思路做一遍全面自检：

• 不同角色登录后看到的菜单和可执行操作是否符合预期。
• 越权访问测试，比如学生账号直接访问其他学生详情的接口，是否被拦截。
• 数据校验测试，空值、超长字符串、非法日期是否能被后端正确拦截。
• 导出功能测试，Excel导出文件能否正常打开且数据准确。
• 兼容性测试，重点检查Chromium系和部分国产浏览器的兼容性。

我在实际测试中发现，Vue3项目在一些老的WebView内核里会有白屏问题，解决办法是在index.html中加入Polyfill或者提示用户升级浏览器。这个坑对学校环境下配置较老的电脑特别有价值。

6.4 后续可以怎么扩展

这类系统上线后，扩展方向是很明确的。健康数据是时间序列数据，可以增加趋势分析，比如绘制学生视力变化曲线。定时任务方面，可以集成Spring的@Scheduled，每天定时提醒班主任完成晨检上报。消息通知方面，可以接入邮件或企业微信机器人，预警信息直接推到负责人手机。

从架构角度看，如果学校有多个校区，可以考虑数据按校区隔离，再加载一层数据权限过滤。如果数据量上来，体检记录这类历史数据可以归档到单独的库表，保证主表查询速度。

根据我的个人经验，这类系统的核心开发量不在CRUD，而在于业务流程细节和权限控制。业务规则才是这个系统真正有价值的部分。把表结构设计合理、权限模型理清楚、前端组件抽象到位，后续加任何功能都会变得很顺手。这套项目源码配合文档，其实非常适合作为前后端分离架构的学习模板，吃透它，你再去写其他管理系统就能举一反三了。