企业官网建设流程全解析

1. 项目概述与整体价值解析

1.1 这个选题为什么值得做

打开知乎或者毕设相关的论坛，“推荐一个简单好做的毕设题目”底下常年都会有社区管理类系统的影子。这题从表面看确实是“烂大街”了，但换个角度，正是因为烂大街，它的资料闭环最完整，踩坑记录最丰富，论文素材最充足，对普通学生来说反而是最稳妥的选择。

社区网格化管理平台，核心就是把传统社区管理搬到线上，按照“网格化”的思路，把一个街道或社区划分成若干个单元网格，每个网格配备网格员，负责采集人口信息、上报事件、处理投诉、发布通知等日常事务。落到技术层面，就是一套典型的前后端分离的管理信息系统，前端负责展示和交互，后端负责业务逻辑和数据存取，MySQL负责持久化。

这套技术选型——SpringBoot + Vue + MySQL——在当前的毕业设计生态里是绝对的“主流配置”，原因很直接：SpringBoot让后端开发不需要写繁琐的XML配置，内嵌Tomcat一键启动；Vue的组件化开发让前端维护起来不累，而且Vue2生态的资料至今仍然海量；MySQL免费、轻量、大学课程里基本都教过。三样东西任何一个计算机专业的学生都接触过，组合在一起，不会有“学不会”的硬门槛。

选题的价值还在于它好答辩。社区网格化是近几年城市治理里真实推进的方向，评委老师对这个业务背景都有认知，你能说出“网格员提交事件、社区管理员派单处置、系统自动归档”这一整套闭环逻辑，就已经比那些泛泛的“某某管理系统”高出一个段位。业务故事讲得通，技术实现讲得清，论文写得满，这三件事同时满足，毕设基本就稳了。

1.2 需要实现的模块边界

拿到这个题目先别急着写代码，先在纸上把模块边界画清楚。一个社区网格化管理平台，按业务角色拆，至少包含三类用户：系统管理员、社区管理员(或者说网格长)、网格员，偶尔还会有一个普通居民的角色用来提交诉求。不同角色干的活完全不同，这就是权限设计的依据。

从功能上看，下面这几个模块是标配，缺一个都容易在答辩时被追问“为什么没有”：

• 系统管理：用户管理、角色管理、菜单权限分配，这是所有管理系统的地基。
• 网格管理：维护网格信息，把网格和网格员关联起来，支持对网格的增删改查和状态启停。
• 人口管理：网格员维护网格内的常住人口和流动人口信息，支持按姓名、身份证号、居住状态检索。
• 事件管理：整个系统最核心的业务闭环，从事件上报、指派、处置、复核到归档的全流程跟踪。
• 通知公告：社区管理员发布公告，网格员和居民可以在线查看。
• 数据统计：按网格维度统计人口数量、事件数量、处置时效，常用柱状图、饼图展示。

事件管理一定要做闭环，这是区分“像样”和“凑合”的关键。

很多同学做这类系统，事件上报完了就完了，没有处置状态流转，评委一看就知道是CRUD拼凑。你在设计阶段就把事件状态机定义好——待指派、进行中、已处置、已归档——每个状态对应什么角色能操作，这既是技术亮点，又是论文里“业务流程设计”这一章的核心素材。

1.3 技术栈选择背后的逻辑

有些同学纠结要不要用更“新”的技术，比如Spring Cloud、Vue3、Redis之类的，我的建议是：别加。毕业设计的评分标准从来不是“用了多少新技术”，而是“是否完整、是否合理、能否自圆其说”。SpringBoot + Vue + MySQL这套组合，已经足够支撑你展示Controller层接口设计、Service层业务封装、Mapper层数据访问这样完整的分层架构，也足够你讲清楚JWT鉴权、RBAC权限控制、前后端分离联调这些核心知识点。

再说直白点，这套组合的资料密度是空前的。你遇到的任何报错，基本都能在网上搜到完全相同的场景和解决方案，而新技术栈的问题往往要翻英文文档甚至去GitHub提issue，毕业设计阶段的时间成本耗不起。

MySQL这里建议用5.7或者8.0，8.0在性能和数据完整性上更好，但要注意驱动版本匹配。数据库编码统一utf8mb4，别用utf8，不然用户输入个emoji表情直接报错。视图层面用MyBatis-Plus的Wrapper构造查询条件，不用手写太多SQL，同时保留XML自定义SQL的扩展能力，实际项目里这种组合最顺手。

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

2.1 用户角色权限体系怎么搭

权限模型直接决定这个系统的骨架质量。社区网格化管理平台涉及的岗位层级很清晰——系统管理员管全局配置，社区管理员管一个片区，网格员管自己负责的网格，所以用最经典的RBAC(基于角色的访问控制)模型就够了，不需要引入更复杂的ABAC或者数据权限框架。

RBAC的实现分三步：用户表存账号信息，角色表存角色定义，用户角色关联表把它们关联起来。菜单权限用另外一组表维护，角色菜单关联表控制每个角色登录后能看到哪些侧边栏菜单和操作按钮。实际开发中，后端接口再做一层拦截校验，前端根据登录用户返回的角色信息动态渲染路由和按钮，前后端双重控制，这是标准做法。

几点具体的做法：

• 密码不能明文存。用BCrypt加密，加盐处理，Spring Security里自带这个工具。
• 登录接口返回JWT令牌，前端把令牌存在localStorage里，每次请求在Header里带上，后端过滤器里解析校验。
• 超级管理员不要参与业务表关联，独立处理，避免误删关联数据。
• 分配网格员时要做双向校验——既要保证一个网格有一个负责人，也要保证同一个网格员没有被重复分配到多个网格。

2.2 数据库表设计的关键细节

表设计是论文里占比很重的一章，也是评委最容易翻的部分，所以E-R图一定要画、字段注释一定要写全。我梳理一下核心表的字段，你照着这个思路设计，基本不会漏：

画E-R图的时候，用户和网格、网格和人口、人口和事件、事件和日志之间都是“一对多”关系，这种关系的表述要跟表结构严格对应。数据库设计章节的得分点在于你敢于写出字段设计的理由，比如为什么person_info表要冗余grid_id而不是通过网格员反查——因为人口数据要按网格快速过滤，冗余一个外键字段能少一次联表查询。

2.3 业务状态流转怎么设计

事件处理是社区网格化管理的核心循环，它有天然的流程感，这个流程感就是论文业务设计的亮点。状态流转设计如下：

1. 网格员上报事件，状态变为待指派，记录上报人、上报时间和事件内容。
2. 社区管理员查看待指派列表，把事件指派给某个处置人员，状态变为进行中。
3. 处置人员接单处理，填写处置结果并佐证材料，状态变为待复核。
4. 社区管理员复核通过，事件归档；复核不通过则退回，状态重新变为进行中。

代码实现上用状态值字典表或者枚举类统一管理，每个状态变更都写入event_log表，记录操作人、操作时间、操作说明，这样将来答辩时可以拿出“审计追溯”这个点来应对评委提问。前端也有体现——事件详情页里展示一条清晰的处理进度时间线。

这个闭环设计还有一个实操层面的好处：它的接口之间天然存在状态约束，你在Service层写业务逻辑时需要对当前状态做前置判断，比如“待指派状态下不能被网格员直接归档”，这种约束条件写到代码里，论文里也能写成“业务边界校验”，属于技术含量不多但非常容易讲明白的加分项。

3. 前端Vue实现与界面联调细节

3.1 前端工程结构和路由策略

前端用Vue CLI搭建工程，目录结构建议这样组织：

• src/api：存放所有接口请求方法，按模块拆文件，比如grid.js、event.js、login.js。
• src/router：路由配置文件，使用动态路由方式，根据后端返回的菜单权限生成路由表。
• src/store：Vuex状态管理，存储用户信息、角色信息和菜单列表。
• src/components：公共组件抽取，比如文件上传、图片预览、分页组件。
• src/views：页面组件，按一级模块建目录，下面放列表页、表单页、详情页。

动态路由这块值得展开说。用户登录成功后，后端返回这个用户能访问的菜单列表，前端把字符串数组存到Vuex里，然后遍历注册路由。这样不同角色登录，左侧菜单完全不同，而且刷新页面后还要重新拉取一次菜单，避免权限丢失。路由守卫里判断token是否存在，不存在就redirect到login页面，这属于最基本的前端鉴权操作。

左边菜单建议用第三方组件生成，配合图标使用，菜单名称和后端返回的menu_name保持一致。页面顶部做一个面包屑导航，根据当前路由的matched数组自动生成，体验会好很多。

3.2 核心功能页面的实现思路

从页面维度梳理，这里面最容易出彩的是三个页面：网格地图页面(如果做了可视化)、事件管理列表页、数据统计首页。

事件管理列表页要注意搜索条件的组合：按事件类型、事件状态、所属网格、时间范围筛选，这些条件通过query参数传递给后端的Page查询接口。表格里除了基础信息列，还要有操作列，比如“详情”“指派”“处置”“复核”这些按钮要根据当前用户角色和事件状态动态展示，这就是权限控制的落地。点击详情跳转到事件详情页，带id参数，详情页展示完整信息和处理时间线。

表单页方面，上传图片用本地上传到服务器指定目录，返回URL地址存到数据库。Vue端用Upload组件，注意上传接口需要携带token，后端要对此接口做白名单处理或者统一鉴权，前端代码里要设置headers参数。图片预览用组件自带功能就行。

数据统计首页用可视化图表库，柱状图展示每个网格的事件数量，饼图展示事件类型分布，折线图展示近七日的处置趋势。图表数据从后端聚合接口获取，接口返回格式固定为类目数组加数值数组，前端直接绑定。这块代码不复杂，但视觉效果很加分，答辩演示时评委第一眼看的就是首页。

3.3 前后端联调常见的坑

联调是毕业设计最容易深夜崩溃的阶段，我先把高频坑位列出来：

• 跨域问题：前端地址是localhost:8080，后端是localhost:9090，Ajax请求会直接跨域报错。常规做法是在后端加一个CorsFilter或者配置类，允许所有来源和所有方法，毕业设计阶段不需要把跨域白名单做太严格。
• 请求路径前缀不一致：后端RequestMapping写的是/api，前端axios实例baseURL没配上，导致404找不到接口，排查半天才发现路径对不上，这个问题用浏览器Network面板一眼就能看出来。
• 日期格式问题：后端LocalDateTime返回的格式是“2024-05-01T10:30:00”，前端组件显示不了这么原始的字符串。后端在application.yml里配置json格式化pattern，或者前端拿回来之后用dayjs转换，两种方案二选一，别都不处理。
• 长整型精度丢失：MyBatis-Plus默认主键是雪花算法生成的长整型，前端JavaScript处理不了那么大的数字，会导致ID末尾几位变成0。解决办法是在后端序列化配置里把Long类型转为String返回。
• token失效跳转：axios响应拦截器里统一判断HTTP状态码，如果返回401就清空本地登录信息，跳转登录页。

这些坑都不是什么高深问题，但你不提前知道，每个都能耗掉你半天时间。联调是个体力活，但前置知识到位了，整体节奏能快很多。

4. 后端SpringBoot业务实现与接口设计思路

4.1 项目结构到底怎么分

后端工程结构建议按功能模块划分，而不是整个业务堆在一起。一个比较舒服的结构是这样：

src/main/java/com/example/gridmanagement ├── config # 配置类，比如跨域配置、MyBatis-Plus分页配置 ├── controller # 接口入口层，只做参数接收和响应封装 ├── service # 业务逻辑层 │ └── impl # 实现类 ├── mapper # 数据访问层 ├── entity # 数据库实体类 ├── dto # 数据传输对象，用于接收前端入参 ├── vo # 视图对象，用于返回给前端 ├── common # 通用返回类、异常处理、常量定义 └── utils # 工具类，比如JWT工具

分这个层级不是形式主义，是为了论文里的架构图有东西可画。简单说就是三层架构加DTO/VO分离——传给数据库的实体和返回给页面的数据模型解耦，这样前端需要什么字段就返回什么字段，不用把整张表的字段全塞出去。你的代码里如果entity直接当VO用，虽然少写几个类，但答辩时被问到“如果表结构调整会不会影响前端返回结构”就会卡住。

4.2 Service层代码怎么写出业务味

Service层是代码的核心地带。举个例子，事件上报接口的ServiceImpl，你不能只是插入一条event记录，你要把整个链路走完：

@Transactional(rollbackFor = Exception.class) public void reportEvent(EventReportDTO dto) { // 生成事件编号，比如EV20240501001 String eventNo = "EV" + LocalDate.now().format(DateTimeFormatter.ofPattern("yyyyMMdd")) + String.format("%03d", generateSeq()); // 插入事件主表 EventInfo event = new EventInfo(); event.setEventNo(eventNo); event.setGridId(dto.getGridId()); event.setEventType(dto.getEventType()); event.setTitle(dto.getTitle()); event.setContent(dto.getContent()); event.setStatus(EVENT_STATUS_WAIT_ASSIGN); event.setReporterId(SecurityUtils.getCurrentUserId()); event.setCreateTime(LocalDateTime.now()); save(event); // 写入操作日志 EventLog log = new EventLog(); log.setEventId(event.getId()); log.setOperateType("report"); log.setOperatorId(event.getReporterId()); log.setRemark("网格员上报事件"); log.setCreateTime(LocalDateTime.now()); eventLogMapper.insert(log); // 如果网格关联了社区管理员，可以同步生成一条待办通知 // 这一步可以实现也可以不实现，属于可扩展点 }

这段代码的价值在于它串起了多条业务线的核心逻辑：状态设置、审计日志、外加一个可扩展点。事件编号生成规则、SecurityUtils获取当前登录人、事务注解控制，每一个点都是答辩时可以展开讲五分钟的话题。事件指派、处置、复核几个接口的逻辑模式都差不多，核心是变更状态前先查询原记录，校验当前状态是否允许该操作，再进行更新和日志写入。

接口返回体统一使用自定义Result类，比如Result.success(data)、Result.error(code, message)，这样前端分页和列表接口的返回结构保持一致，后续联调省心。异常处理用全局异常拦截器，捕获业务异常并返回友好提示，而不是让SpringBoot把500错误堆栈直接吐给前端。

4.3 权限方案这样实现最省事

做权限方案的时候不用把Spring Security全家桶都接进来，只需要引入Spring Security依赖里最常用的功能，或者直接用拦截器来做，在毕业设计里更可控。这里我给出一个实操路径：

1. 用户登录成功后，用JWT工具生成token，内部包含用户id和角色标识，设置过期时间，比如24小时。
2. 写一个HandlerInterceptor，在preHandle里从请求头获取token，解析并校验，失败则返回401。
3. 注册拦截器到WebMvcConfigurer，设置排除路径列表，比如“/api/login”、“/api/register”。
4. 接口粒度权限用自定义注解加上拦截器判断实现，比如在Controller方法上标注@RequirePermission("grid:view")，核心管理接口加上，列表查询接口不加，避免逻辑过于繁琐。

这样的方案比引入Spring Security简单很多，实现原理却一清二楚，论文的“技术选型”部分也有理由可写——拦截器更轻量，方便教学展示。

4.4 MyBatis-Plus使用心得

MyBatis-Plus是这类系统最顺手的ORM框架，开箱即用。分页查询时引入分页插件，然后：

Page<EventInfo> page = new Page<>(current, size); LambdaQueryWrapper<EventInfo> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(EventInfo::getGridId, dto.getGridId()) .like(StringUtils.hasText(dto.getTitle()), EventInfo::getTitle, dto.getTitle()) .eq(dto.getStatus() != null, EventInfo::getStatus, dto.getStatus());

LambdaQueryWrapper的查询下沉写法是MyBatis-Plus的精髓，它让条件拼接不再是字符串拼接的噩梦。统计报表的时候，直接写注解SQL或者XML：

SELECT grid_name, COUNT(*) AS event_count FROM event_info GROUP BY grid_id

这个统计查询非常直观，返回的Map列表在Service层转换成图表需要的VO结构返回前端。注意日期范围过滤时数据库字段和参数类型必须一致，别用字符串传日期范围，后期格式化会非常痛苦。

5. 数据库脚本与初始化数据准备

5.1 初始化数据为什么要认真

一个空荡荡的管理系统，登录进去除了侧边栏菜单什么都没有，在答辩演示时会让印象分大打折扣。事先填充好一套合理的模拟数据，演示的时候直接看到真实效果，观感完全不同。

初始化数据分两类：一类是系统必须的基础数据，比如菜单权限、角色定义、默认管理员账号；另一类是演示用的业务数据，比如几十条人口记录、十几条不同状态的事件、几个网格的配置。前者必须严格准确，后者要覆盖完整流程。

SQL脚本建议单独放在项目根目录的db文件夹下，分为schema.sql(建表)和data.sql(数据)，这样论文附录可以直接引用脚本片段，部署文档里也能让读者按顺序执行。注意MySQL的sql_mode在5.7和8.0下默认值不同，ONLY_FULL_GROUP_BY会让部分group by查询报错，把SQL执行不了的锅先排除掉。

5.2 常用的几类初始化脚本

管理员账号是必须的，密码用BCrypt加密后的密文写入数据库，并且把这段操作写在部署文档里，明确告诉部署者“不要再手动改表密码”。角色配置表里至少要加三个角色：ROLE_SYSTEM_ADMIN、ROLE_GRID_ADMIN、ROLE_GRID_WORKER，然后分配菜单权限。

网格数据初始化三四条就可以，覆盖“某街道第一网格”这类命名即可。人口信息造20条左右，分布在各个网格里，注意身份证号格式要规范，姓名尽量用常见姓氏，不要编造明显不存在的号码。事件数据造10到15条，状态覆盖待指派、进行中、已处置、已归档，时间分布在最近一个月内，这样统计接口返回的图表数据才丰富，页面展示的筛选条件才都有内容可筛。

5.3 数据库版本不一致的避坑

5.7和8.0的MySQL在驱动类名、SSL连接方式上有区别。我的建议是安装8.0，pom里引入mysql-connector-java(8.x版本后更名为com.mysql.cj.jdbc.Driver)，jdbcUrl上加serverTimezone=Asia/Shanghai，这样时区问题也会一并解决。

如果你在别人电脑上部署，对方的MySQL是5.7，那driver改成com.mysql.jdbc.Driver，然后用对应版本的连接器，这种情况常出现在机房演示的备用机上。提前在部署文档里把两个版本的差异写清楚，别到了现场才手忙脚乱。

6. 部署流程与现场演示准备

6.1 本地开发环境搭建步骤

本地安装的必备软件按顺序列举如下：JDK1.8、Maven3.6以上、Node.js 14以上(不要用太新的18，部分旧依赖会报OpenSSL错误)、MySQL5.7/8.0、Navicat或MySQL Workbench。

后端启动流程比较简单：导入数据库执行脚本，修改application.yml里的数据库账号密码，在项目根目录执行mvn spring-boot:run，看到Tomcat started on port 9090就表示成功了。前端通过npm install安装依赖，npm run serve启动，默认端口8080。前后端端口不同，跨域问题按前面说的方法处理就行。

6.2 服务器部署的完整链路

如果把项目部署到云服务器上做展示，流程会更完整。先买个基础配置的云主机，安装JDK和MySQL，把数据库脚本导进去，后端代码用Maven打成jar包，后台运行命令设为nohup java -jar xxx.jar > log.log 2>&1 &，前端代码执行npm run build生成dist文件，然后由Nginx托管静态文件，并配置反向代理：

server { listen 80; server_name your_ip_or_domain; location / { root /home/www/grid-admin; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:9090; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

这个配置解决两个问题：history模式路由刷新404要try_files回退到index.html；前端请求/api路径要将请求转发给后端9090端口。部署文档里把这段配置放进去，并把防火墙端口、MySQL远程访问权限等注意事项一并写上，整套文档就非常完整了。

6.3 答辩演示的演示路径建议

答辩演示不要从头到尾把所有页面点一遍，那叫功能展示，不叫演示。逻辑应该是讲故事：开场进入数据统计首页，让图表说话，快速展示网格人口结构、事件分布；然后顺着一条主线走，切换到网格员账号上报一个新事件，再切到社区管理员账号进行指派、复核，把整个流程走完；最后进入系统管理模块展示一下菜单权限分配和用户管理，收尾收在架构阐述上。

切换账号需要重新登录，演示前把所有角色的账号密码列在便签上，不然台上手抖打错密码直接冷场。数据库清掉测试垃圾数据，把演示数据做成容易理解的内容，时间充裕时可以准备一个录屏，防止现场网络故障或者服务器挂了。这类系统的演示通常十分钟内要搞定，节奏感比完整度重要。

7. 论文写作框架与文档要点

7.1 论文各章节怎么搭

毕业设计论文的套路相对固定，但每一章能写出的深度差别很大。参考结构如下：

第一章绪论写选题背景和意义，国内社区网格化管理现状的概括要跟上时代，不要写“国家飞速发展”这类空话；第二章相关技术介绍，SpringBoot、Vue、MySQL、JWT、MyBatis-Plus各占一页左右；第三章系统分析，重点画用例图、功能模块图、业务流程时序图；第四章系统设计，架构图、功能设计、数据库E-R图和表结构说明，这一章要写得极其细致，尤其把事件流转状态机的图放进来；第五章系统实现，按模块贴代码核心片段和界面截图；第六章系统测试，测试计划、测试用例表、结果分析和性能测试记录。

每章的图表要编号清晰，截图保存位置提前规划好，写论文那天不至于满盘找图。截图需要用真实运行效果，在需求分析和系统设计阶段就用取色规范来统一截图时浏览器窗口尺寸，让整篇论文看起来干净整齐。

7.2 论文中技术难点的表达技巧

“难点”不是说代码写得有多难，而是你如何把一个简单问题包装成“挑战与解决方案”。比如把“事件状态需要统一管理”写成“系统中事件状态散落多处且缺乏规范性约束，为解决该问题，独立设计状态常量类并进行前置校验”；把“前端每个页面重复处理token过期”写成“针对会话失效场景，基于Axios响应拦截器实现统一异常捕获与跳转，显著提升用户体验”。

这不是让你夸大其词，而是引导你站在“设计者”的角度去描述代码里已有的逻辑。你已经实现的功能就是论据，论文只是把这些论据组织得更体系化。答辩评委最反感的是论文和代码对不上，只要你把真实做了的事情写清楚，那就是安全分。

7.3 部署文档的写作要点

部署文档按时间线组织，从环境准备、后端启动、前端启动到数据库初始化，每一步写清“目标状态”——执行这个命令后应该看到什么。比如“若控制台出现Tomcat started on port 9090，说明后端启动成功”。格式上把需要修改的配置项用代码块单独标注，如username、password、端口号，好让部署者明确知道哪些是必须改的参数。

部署文档里应该加一个“常见问题”小节，把tomcat端口被占用、node版本不支持、数据库驱动时区错误、前端跨域报错这类高频问题收集进去。这份东西不仅给自己留下后路，也是“辅助文档”这一评分细项里的关键素材。

8. 常见问题排查与经验小结

8.1 高频坑位速查表

在编写和部署过程中，各类问题很常见，我按出现概率从高到低整理出一个速查表：

每条问题都对应一行“背下来就有用”的知识点。这类对面项目排查浪费的时间，远超过写自身代码的时间，提前把这些坑补上，能让整体进度快很多。

8.2 独家的几招锦上添花

第一，加一个“导出Excel”功能。利用Apache POI或者EasyExcel，把事件列表、人口列表导出成Excel文件。这个功能做起来不难，但论文测试表里多一条“兼容性测试”用例，演示时也多一个亮点。

第二，给系统加操作日志查询页面。前面已经做了event_log表，再加一个登录日志表，展示用户的登录时间、登录IP、操作系统。这类功能对评委的“系统管理完善度”观感提升非常明显。

第三，前端页面统一做响应式和刷新保留参数。比如筛选条件翻页后清空的问题，可以把查询参数同步到URL的query上，页面加载时从URL恢复，这个细节做到位，操作体验比一大半同学的系统都好。

第四，代码里把TODO标记清理干净，日志输出用log.info规范记录，不要把System.out.println留在线上。这些细节是答辩前最后一遍自测时重点过一遍的。

8.3 我个人的实操体会

从选题、框架搭到数据调试、论文成稿，整个周期里最花时间的往往不是写代码，而是把思路整理清楚。我的习惯是开工前先花一个晚上把模块清单、数据库字段、接口列表全部写在文档里，之后写代码就是按图索骥，反而省时间。很多同学直接开IDE写实体类，写到一半发现字段不够，又回去改表结构，来回折腾好几轮。

这套系统做完，你大概率对“一个完整的全栈项目长什么样”会有一个特别具体的体感——从数据库关系设计，到接口分层和权限控制，再到前端鉴权和部署，整个过程串起来之后，你会发现毕业设计真的不只是一个作业，它就是你第一份可以写进简历的实战作品。把部署文档打磨好，把自己做过的每个模块逻辑都能讲清楚，答辩台上比什么都管用。

如果后面还有时间，可以在这个系统上加一个消息推送模块，或者把前端升到Vue3和Element Plus，都是很自然的演进方向。但这些都属于锦上添花，先把当前这套完整跑通、跑顺，确保论文和代码严丝合缝，这才是当前优先级最高的事。