企业官网建设流程全解析

毕业设计做管理系统，十个选题人里有八个会撞上“XX管理系统/平台”。这几年陆续被不少师弟师妹问过SpringBoot+Vue全家桶的开发套路，暑期也带过一期基于经典前后端分离架构的模拟项目，正好前端用Vue做了实时看板，后端用SpringBoot接了数据服务，数据库落MySQL，整体就是一个完整可运行的“水产养殖系统平台”。这个选题很典型：行业背景清楚、技术栈主流、业务天然带数据可视化和告警的场景，无论从毕业设计的“工作量展示”还是答辩时的“功能完整度”来说，都很讨喜。

这篇文章我会直接把整套系统的拆解思路、数据库设计、前后端核心实现、部署流程和论文写作的碎片经验都整理出来，内容对所有正在做管理类毕设、想抄一份快速可用框架的人都会有帮助。你不一定真做水产养殖，但把这套骨架吃透，换一个业务领域，比如社区团购、校园报修、农场溯源，只是换表名和页面文案的事。

1. 整体设计与技术选型拆解

1.1 为什么是SpringBoot + Vue + MySQL这个组合

说到毕设技术栈，“SpringBoot + Vue + MySQL”几乎成了标准答案，这个组合确实不是最优的花哨选择，但它就是最不容易翻车的那一套。

后端用SpringBoot，核心理由是省事。内置Tomcat不用额外配置，起步依赖把大部分通用功能都准备好了，配合MyBatis-Plus操作数据库，单表CRUD基本上不用写SQL。对于毕业设计这种需要“快速出活”的场景，这套组合能把开发周期压缩到两周以内。相比早期的SSH、SSM框架，SpringBoot省掉了大量XML配置，对基础薄弱的同学友好得多。

前端选Vue，优势在于组件化和数据驱动。尤其是配合Element Plus组件库，表格、表单、弹窗、分页这些管理系统的常见元素都是现成的，加几行配置就能出一个像样的页面。水产养殖系统正好需要大量图表展示水质数据的变化趋势，Vue配上ECharts，数据可视化这块非常顺手，答辩时演示效果也足够“有内容”。

MySQL就是稳稳当当的数据库选择。开源、免费、资料多，Navicat或DataGrip连上去看表结构都很直观。毕设阶段不用考虑复杂的高并发分布式，单机MySQL完全够用，而且答辩老师对这个数据库也最熟悉，不会在技术选型上跟你较劲。

1.2 选题价值与需求拆解

水产养殖这个行业，数字化程度并不高，很多中小型养殖场还在靠老师傅的经验判断水质好坏。但养殖的收益恰恰高度依赖水质，比如溶解氧低了鱼会浮头、氨氮超标容易引起大面积死亡，这些都不适合靠人眼估摸。所以“水产养殖系统平台”这个题目天然自带需求合理性：让养殖户通过系统实时看水质数据，异常时主动告警，平时可以做投喂记录和疾病防治记录，数据还能汇总成报表反哺生产决策。

从毕业设计的角度拆解需求，系统可以划分成三大块：

• 基础管理：用户登录、角色权限、养殖户/员工信息管理。
• 核心业务：池塘档案管理、水质数据采集与展示、设备（增氧机、投喂机）运行监控、投喂记录管理。
• 数据增值：历史水质趋势分析、异常告警记录、生产数据报表。

这样的需求拆解有一个好处，答辩时每一张页面都能对应到一个“用户痛点”，不会出现那种“做了个管理系统但不知道解决什么问题”的尴尬。

1.3 整体架构与目录规划

系统采用前后端分离架构，后端只提供RESTful API，前端通过Axios异步调用接口渲染页面。数据流向是：MySQL存储原始数据，MyBatis-Plus负责ORM映射，SpringBoot提供业务接口，Vue负责展示和交互。

整个工程的规划大致是这样的：

aquaculture-system/ ├── backend/ # SpringBoot后端工程 │ ├── src/main/java │ │ ├── controller/ # 控制层，RESTful接口 │ │ ├── service/ # 业务逻辑层 │ │ ├── mapper/ # 数据访问层 │ │ ├── entity/ # 实体类 │ │ ├── config/ # 跨域、MyBatis-Plus等配置 │ │ └── common/ # 统一返回结果、异常处理 │ ├── src/main/resources/ │ │ ├── mapper/ # XML映射文件 │ │ └── application.yml # 配置文件 │ └── pom.xml ├── frontend/ # Vue前端工程 │ ├── src/ │ │ ├── api/ # 接口封装 │ │ ├── router/ # 路由配置 │ │ ├── store/ # 状态管理 │ │ ├── views/ # 页面组件 │ │ ├── components/ # 公共组件 │ │ └── utils/ # 工具函数 │ ├── package.json │ └── vite.config.js └── sql/ # 数据库初始化脚本

这种分层结构也是论文架构的天然骨架，画系统架构图的时候直接照着这个改就行。

2. 数据库设计与核心业务建模

2.1 功能模块与数据关系梳理

数据库设计是整个系统的地基，地基没打好，后面所有功能都会写得很别扭。水产养殖系统涉及的核心实体有：用户、角色、池塘、设备、水质监测记录、投喂记录、告警记录。

实体之间的关系并不复杂：

• 一个用户可以管理多个池塘（养殖户角色）。
• 一个池塘可以绑定多个设备（增氧机、投喂机、水质传感器）。
• 水质监测记录和告警记录都属于池塘的子数据。
• 投喂记录绑定池塘，并记录操作人。

搞清楚这些关系以后，表结构的设计就有方向了。设计原则是：业务数据表尽量冗余少量的统计字段（比如最新溶解氧值），但不要过度冗余，保持范式化，让数据维护起来不混乱。

2.2 核心表结构设计

我会把关键的表列出来，方便直接对照着建库。先看用户和池塘这两张基础表。

用户表相对常规，核心字段包括用户名、密码、真实姓名、手机号、角色类型（管理员/养殖户/员工）、创建时间。

池塘表则是整个系统的业务中心，建议包含这些字段：

CREATE TABLE pond ( id INT PRIMARY KEY AUTO_INCREMENT, pond_name VARCHAR(100) NOT NULL COMMENT '池塘名称', area DECIMAL(10,2) COMMENT '面积（亩）', depth DECIMAL(10,2) COMMENT '平均水深（米）', water_type VARCHAR(50) COMMENT '水体类型：淡水/海水', farmer_id INT COMMENT '负责养殖户ID', device_id INT COMMENT '绑定设备ID', longitude DECIMAL(10,6) COMMENT '经度', latitude DECIMAL(10,6) COMMENT '纬度', status TINYINT DEFAULT 1 COMMENT '状态：0停用，1启用', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) COMMENT '池塘信息表';

这里把经纬度字段加上，后续如果要做养殖区域地图展示就有数据支撑，论文里也能多写一个“基于位置的养殖资源分布”功能点。

水质监测记录表是系统的数据核心：

CREATE TABLE water_quality ( id BIGINT PRIMARY KEY AUTO_INCREMENT, pond_id INT NOT NULL COMMENT '池塘ID', temperature DECIMAL(4,2) COMMENT '水温（℃）', ph_value DECIMAL(3,2) COMMENT 'pH值', dissolved_oxygen DECIMAL(4,2) COMMENT '溶解氧（mg/L）', ammonia_nitrogen DECIMAL(4,3) COMMENT '氨氮浓度（mg/L）', turbidity DECIMAL(6,2) COMMENT '浊度（NTU）', sample_time DATETIME NOT NULL COMMENT '采集时间', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_pond_time (pond_id, sample_time) ) COMMENT '水质监测数据表';

需要说明的是，溶解氧、pH、温度这些字段都来自水质传感器设备，毕设阶段如果没有真实硬件，可以通过模拟数据接口按时间随机生成，前端图表展示效果完全一样。论文里可以说“预留物联网设备接入接口，当前采用模拟数据源验证系统功能”，这个表述在毕设场景是完全站得住脚的。

设备表和告警记录表也是水产养殖系统的特色表，设备记录增氧机和投喂机的基础信息及运行状态，告警表记录异常事件的时间、类型、具体参数和处理状态。告警类型可以设计成：低溶解氧告警、高氨氮告警、水温越界告警等。

投喂记录表相对简单，携带池塘ID、饲料类型、投喂量、操作人、投喂时间即可。这部分的业务逻辑可以扩展到“根据水温自动推荐投喂量”之类的亮点功能。

2.3 数据库设计时的经验心得

设计完这些表，做毕设常见的坑已经能预判到了。最典型的是不在时间字段上建索引，水质数据一旦按分钟级采集，一张表很快就是几万条记录，查询“某个池塘最近7天的水温趋势”时，没有索引会慢到能明显感知。所以我在建表的时候顺手把pond_id和sample_time建了联合索引，这个细节在论文的系统设计章节里也可以提一句，算是亮点。

另外，金额、面积等数值字段用DECIMAL而不是FLOAT，避免浮点数误差。所有表都带上create_time和update_time字段，后面做统计报表和问题排查都会用到。

3. 后端SpringBoot核心实现

3.1 工程骨架与依赖配置

后端工程直接用Spring Initializr生成即可，SpringBoot版本建议用2.7.x，稳定性最好，资料也最丰富。Java版本1.8或11都可以，考虑到服务器部署环境，1.8是最稳妥的选择，不需要非得追新。

pom.xml里的核心依赖记录一下，照着加就行：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency>

MyBatis-Plus对毕业设计来说几乎是“开挂”的存在。内置的BaseMapper提供了insert、deleteById、selectById、selectPage这些方法，连SQL都不用写。配合条件构造器QueryWrapper，能应付绝大多数查询场景。只有多表联合查询才需要写自定义XML，比如查“池塘+负责养殖户姓名+最新水质数据”这种聚合信息。

还有一点值得一提，MyBatis-Plus 3.5以上的版本自带分页插件，在配置类里注册一个MybatisPlusInterceptor就可以实现分页查询。毕业论文里写清楚“基于MyBatis-Plus内置分页插件实现高效分页”，听起来也很专业。

3.2 统一返回结果与异常处理

一个值得一开始就做好的细节是统一返回结果。不要每个接口都返回不同类型的Map或裸数据，定义一个通用返回类，所有接口统一返回约定好的结构，前后端联调时省掉大量沟通成本。

我习惯的返回结构是：

{ "code": 200, "message": "操作成功", "data": { } }

对应的通用类很简单，核心代码就几十行：

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

配合全局异常处理器，用@RestControllerAdvice捕获业务异常和系统异常，前端拿到的错误信息永远是统一的JSON，而不是一堆乱七八糟的堆栈文本。这个设计不要嫌麻烦，前期花五分钟做好，后面几十个接口都跟着受益。

3.3 登录鉴权与JWT方案

毕业设计级别的登录鉴权，不要上来就接SpringSecurity加OAuth2那一套，配置复杂、学习成本高，答辩老师也不一定认可“过度设计”。轻量级的JWT方案刚刚好：用户登录成功后，后端签发一个有效期为24小时的Token，前端把Token存到localStorage里，每次请求在请求头带上Authorization字段，后端通过拦截器解析Token并校验有效性。

核心实现分三步：

1. 登录接口：接收用户名密码，校验通过后生成Token返回。
2. 拦截器：实现HandlerInterceptor，在preHandle方法里解析Token，校验失败直接返回401。
3. 配置类：注册拦截器，并放行登录接口和静态资源路径。

Token生成的方法用jjwt库封装一下，核心代码：

public String generateToken(User user) { return Jwts.builder() .setSubject(user.getUsername()) .claim("userId", user.getId()) .claim("role", user.getRole()) .setExpiration(new Date(System.currentTimeMillis() + 86400000)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }

有个细节值得注意：Token过期时间的单位是毫秒，86400000正好是24小时。如果学生答辩现场临时想演示“已过期”的交互效果，把有效期改成60000（1分钟）重新登录一次就行，不用改代码。

拦截器里再配合ThreadLocal存储当前登录用户信息，后续业务代码里直接通过UserContext.getUserId()拿当前操作人ID。这个小工具在论文里可以写成“基于ThreadLocal的用户上下文管理”，也算一个技术点。

3.4 核心业务接口实现

后端接口覆盖了系统需求分析阶段的每一个功能点。水质数据接口是最核心的：

• 分页查询某个池塘的水质历史数据。
• 查询最近24小时/7天/30天的平均水温、pH、溶解氧等趋势数据。
• 查询最新一条水质数据（用于首页实时展示）。

趋势数据接口是个典型的“统计报表”场景，SQL层面可以用日期函数做分组。比如按天统计近7天的平均溶解氧，SQL大致是：

SELECT DATE_FORMAT(sample_time, '%Y-%m-%d') AS day, AVG(dissolved_oxygen) AS avg_do FROM water_quality WHERE pond_id = #{pondId} AND sample_time >= DATE_SUB(NOW(), INTERVAL 7 DAY) GROUP BY day ORDER BY day;

这段SQL不需要写得太复杂，MyBatis-Plus的QueryWrapper也能实现类似效果，但直接写XML的清晰度更高。查询结果封装成一个Map或者专门的统计VO返回给前端。

告警逻辑也比较有意思：在写入水质数据的时候同步做阈值判断，比如溶解氧低于3.0mg/L或者pH超出6.5到8.5的范围就生成一条告警记录。这个逻辑不复杂，但它是整个系统中最能讲出“智能化”味道的功能，论文的创新点可以往这个方向靠。

4. 前端Vue工程落地

4.1 工程初始化与目录划分

前端工程用Vite创建Vue3项目，跑一条命令就行：

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

模板创建完成后，安装必要依赖：

npm install element-plus @element-plus/icons-vue axios vue-router pinia echarts

Element Plus是UI组件库，负责表格、表单、弹窗、消息提示这些基础交互组件。Pinia做状态管理，主要存用户信息和登录状态。ECharts负责图表渲染，是数据可视化展示的主力。

目录结构建议保持清晰，每个模块的页面放在views下的独立文件夹里，公共组件抽到components里，API请求统一放到api目录下。个人经验：不要在页面组件里直接写Axios请求，所有接口先封装到api文件里再在页面中调用，这样接口地址改动时只需要改一处。

4.2 路由与登录拦截

路由配置用Vue Router，关键点在于全局前置守卫。未登录用户访问任何页面时，直接重定向到登录页；已登录用户访问登录页时，重定向到首页。代码如下：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path !== '/login' && !token) { next('/login') } else if (to.path === '/login' && token) { next('/') } else { next() } })

这个逻辑虽然简单，但非常实用。毕业论文里也可以把这个功能描述为“基于路由守卫的前端访问权限控制”。

Axios请求封装的要点是请求拦截器统一添加Token头，响应拦截器统一处理业务错误码。这里踩过一个很常见的坑：如果后端返回的code是200表示成功，但HTTP状态码是500，响应拦截器直接进入reject分支，此时前端要用response.data.code而不是error.response来处理业务提示，否则“系统错误”的弹窗会盖掉后端返回的真实业务信息。

4.3 数据看板与图表实现

首页数据看板是这套系统的门面，也是答辩演示时最抓眼球的页面。设计思路是：顶部放统计卡片，展示池塘总数、设备总数、今日告警数、今日投喂次数；中部放ECharts图表，展示近7天水质趋势折线图和水温分布柱状图；底部放最新告警列表。

ECharts接入Vue3的方式很多，最简单的是用echarts库直接初始化：

import * as echarts from 'echarts' const chartDom = ref(null) let chartInstance = null onMounted(() => { chartInstance = echarts.init(chartDom.value) fetchWaterQualityTrend() }) function renderChart(data) { chartInstance.setOption({ tooltip: { trigger: 'axis' }, legend: { data: ['溶解氧', '水温', 'pH'] }, xAxis: { type: 'category', data: data.dates }, yAxis: [{ type: 'value' }], series: [ { name: '溶解氧', type: 'line', data: data.oxygen }, { name: '水温', type: 'line', data: data.temperature }, { name: 'pH', type: 'line', data: data.ph } ] }) }

一个很容易被忽略的细节是：图表容器必须有明确的宽度和高度，否则ECharts初始化后显示不出来。我发现很多同学的图表演示空白，原因都是父容器高度为0。

另一个值得做的交互是“联动筛选”：用户选择不同池塘时，图表数据跟着变化。这个功能在答辩时很容易被问到，“我这个系统支持按池塘维度查看水质趋势”，回答起来既有信心又能展示系统业务的完整闭环。

4.4 表单设计与校验细节

表单页面主要是池塘管理、设备管理、投喂记录录入。Element Plus的表单校验功能已经很好用了，但要想“有亮点”，可以在投喂记录表单里做一个联动：选择池塘后自动带出该池塘的面积和当前水温，然后根据预设的投喂策略计算“建议投喂量”，用户确认后提交。

这一点工作量不大，但和纯数据库CRUD的系统拉开了差距，业务上更“懂行”。论文里可以写“结合养殖对象和温度条件实现智能投喂建议，降低人工决策成本”，听起来像是一个值得肯定的系统优化点。

前端还有一个细节：删除操作都要加ElMessageBox.confirm二次确认，防止误操作。这种细节在论文的“系统界面设计”章节中用截图展示，是很加分的。

5. 数据库脚本与部署上线全流程

5.1 环境准备清单

部署文档最重要的就是环境依赖清单，我整理了一份，照着准备就行：

• JDK 1.8及以上
• Maven 3.6+（打包后端用）
• Node.js 16+（构建前端用）
• MySQL 5.7或8.0
• Nginx 1.20+（托管前端静态文件+反向代理）

5.2 后端打包与启动

后端打包前要检查application.yml里的数据库连接配置，尤其是账号密码和数据库名。之后在backend目录执行：

mvn clean package -DskipTests

执行完成后，target目录下会生成一个名为aquaculture-0.0.1-SNAPSHOT.jar的文件。将这个jar包上传到服务器，用以下命令启动：

java -jar aquaculture-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod

最好使用systemd或者nohup方式，保证终端断开后服务不终止。最简单的nohup命令：

nohup java -jar aquaculture-0.0.1-SNAPSHOT.jar > app.log 2>&1 &

启动时注意8080端口占用问题，最常见的错误就是端口被占用导致启动失败。可以用netstat -tlnp | grep 8080排查，把占用进程kill掉再来。

5.3 前端构建与Nginx托管

前端在frontend目录执行：

npm run build

构建成功后生成dist目录，把dist目录里的文件上传到服务器Nginx的html目录下。然后再给后端接口配一个反向代理，避免浏览器出现跨域问题。Nginx配置可以这样写：

server { listen 80; server_name your-domain.com; # 前端静态资源 root /var/www/aquaculture; index index.html; # 解决history模式路由刷新404问题 location / { 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; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

需要提一下“history模式路由刷新404”这个问题的产生背景：Vue Router如果用history模式，前端路由切换是JS控制的，刷新页面时Nginx会按真实文件路径去找，找不到就会404。try_files这段配置把所有路径都回退到index.html，由前端路由接管。这个坑在部署文档里写清楚，毕业生部署时能少走很多弯路。

反过来，如果你不想折腾Nginx的回退配置，也可以直接用hash模式，URL会多一个#号，观感差一点，但部署绝对不会出问题。

6. 论文写作思路与研究价值提升

6.1 论文目录结构与写作顺序

系统做完之后，论文写作是最容易卡壳的环节。我建议的顺序不是从第一章摘要开始写，而是先写系统设计部分，因为有真实的代码和表结构可以参照，下笔很快。然后再回头补选题背景和需求分析，最后写测试和总结。

常规目录结构大概是：

• 第一章 绪论（研究背景、国内外现状、研究内容）
• 第二章 相关技术介绍（SpringBoot、Vue、MySQL、ECharts）
• 第三章 需求分析（可行性分析、功能需求、用例分析）
• 第四章 系统设计（总体架构、功能模块设计、数据库设计）
• 第五章 系统实现（分别描述后端接口实现、前端页面实现、核心业务逻辑）
• 第六章 系统测试（测试环境、功能测试用例、结果分析）
• 第七章 总结与展望

6.2 画图与创新点的细节

论文图片是毕设评审的重要环节。至少要把系统架构图、功能模块图、数据库ER图、核心业务流程图这四张图做好。

画图工具有很多选择，ProcessOn和draw.io都可以，关键是布局要留白、线条要对齐、层级要清晰。我见过不少论文里的架构图堆满了密密麻麻的文本框，看起来像一张电路图，反而很难在一分钟里讲清楚系统结构。架构图从上到下应该是：表现层（前端页面）、服务层（SpringBoot接口）、数据层（MySQL），这种三层结构画出来，答辩评委一眼就能看出你理解系统架构。

创新点的设计要有迹可循。对于水产养殖系统，不做物联网硬件也可以从以下方向找特点：

• 数据可视化分析：引入ECharts实现多维水质趋势分析。
• 告警机制：基于阈值规则的自动异常预警。
• 权限细分：面向管理员、养殖户等不同角色提供差异化视图。
• 智能投喂建议：根据水温与养殖周期推荐投喂量。

这几点在论文里都可以展开成一节来写，答辩时也能讲清楚。

6.3 测试章节的实操建议

很多毕业生的测试章节就是把前端页面截几张图，然后在每个功能后面写“测试通过”，这样的论文很容易被挑毛病。我建议按规范写功能测试用例表，每张表包含：用例编号、功能名称、操作步骤、预期结果、实际结果、是否通过六列。这个格式有据可依，又不需要真的去学自动化测试框架。

7. 常见问题与排查技巧实录

7.1 高频问题速查表

整理一份部署开发过程中最常见的问题清单，遇到直接照着排查：

这几种都是线上真实案例，哪一个都能省下半小时起步的排查时间。

7.2 排查过程详录

挑两个典型问题详细说。

第一个是后端返回了数据，前端却显示undefined。这种情况绝大多数是因为Java后端实体类的字段命名是驼峰式（比如dissolvedOxygen），而数据库字段是下划线式（dissolved_oxygen）。MyBatis-Plus默认开启了驼峰映射，这一层没问题，但如果使用了自定义SQL返回的Map，Map的key可能不是驼峰格式，前端拿到dissolved_oxygen这个key去取数据，自然取不到。解决办法是在XML中给查询列的别名，或者在返回的VO中用@JsonProperty注解指定JSON字段名。

第二个是Nginx部署后访问接口超时，后端日志也没有任何打印。当时排查发现是Nginx没有配置proxy_read_timeout，默认60秒超时，某些报表接口要跑好几秒应该不至于，但实际上问题出在proxy的请求转发到了错误端口，接口实际没打过去。所以部署后第一件事，先用curl测一下后端接口本身是否通，再测Nginx代理后的地址，分段定位问题。

7.3 避坑经验

关于数据库连接池，SpringBoot默认使用HikariCP，性能本身很好，但要注意连接超时和空闲回收时间的配置。有些服务器上MySQL默认的wait_timeout是8小时，而Hikari的maxLifetime默认是30分钟，两者配合其实问题不大。反倒是如果你同时开了多个项目共用一个MySQL实例，数据库连接数上限容易被打满，需要考虑调大MySQL的max_connections。

再有一个部署细节：jar包上传到服务器之后，时间久了容易遇到时区问题，数据库里的日期比本地时间晚8小时。最好的解决办法是在MySQL连接URL里加上serverTimezone=Asia/Shanghai，并在服务器上确认运行date命令显示的是中国时区。这个细节在论文的部署文档里写一下，能体现考虑的周全性。

最后做这套系统时，我自己带项目过程中最深的体会是：毕业设计考察的往往不是“你用了多牛的框架”，而是“这个系统的需求和实现是否闭环、文档能否把方案说清楚”。SpringBoot+Vue+MySQL这套组合本身不难，真正拉开差距的是细节，比如数据库索引有没有建、异常有没有统一处理、Token过期了什么表现、部署文档照着能不能跑起来。把这些细节处理好，答辩就是走过场。

最后再分享一个小技巧，给所有准备把毕设进一步扩展的同学：这套系统往后再加一个数据上报接口，用模拟传感器的方式按固定时间间隔写入水质数据，视觉效果就是系统在“实时更新”，展示的完整度和技术调性直接上升一个档位。做管理类毕设的同学，把这个思路记下来，你的演示环节会顺畅很多。