1. 项目背景与功能定位1.1 为什么做“苏蔚家校互联管理系统”这个题目挂在毕业设计选题列表里的时候我第一反应是这又是一个“标准化”的管理系统无非是增删改查换了一层壳。但真正动手之后发现家校互联这个场景比想象中要复杂不少——它不是简单的信息发布平台而是涉及学生、家长、教师、班级管理四个核心维度交叉的业务系统。从业务链条来看学校端需要发布通知、布置作业、记录成绩、反馈考勤家长端需要实时接收这些信息同时还能查看孩子的成长轨迹教师端要能管理自己负责的班级给不同班级推送差异化内容。如果只做单表CRUD表面上看功能“齐全”但用起来会非常别扭——比如一个班主任带两个班发通知时得选两遍家长看到的信息还完全一样这在真实场景里是站不住脚的。我最终确定的方案是一个以班级为纽带、以用户角色为权限边界的三端系统。管理员维护基础数据教师按班操作家长按孩子维度查看每一条数据都有清晰的归属关系这样既符合学校管理的真实逻辑也方便在答辩时讲清楚“为什么这么设计”。1.2 角色权限设计的核心思路角色这块我卡了一段时间最初参考了不少同类系统的做法有的做成单表加角色字段有的做四张表分别管理。权衡之后我选择了单用户表加角色枚举的方式配Spring Security做接口级权限控制。系统管理员负责教师账号的开通、班级年级的维护、基础字典数据的配置。教师可管理自己关联的班级发布通知、布置作业、录入成绩、登记考勤并查看本班学生的基本信息。家长通过绑定的学生关联到班级查看通知、作业、成绩、考勤以及教师发布的本班专属内容。有人可能会问家长跟老师之间是否需要单独做“私信”功能我的建议是如果时间紧张可以先不做因为私信会引入聊天表、已读未读、会话列表等一大堆额外设计而毕业设计最怕的是功能铺太开、每个模块都浅尝辄止。把通知、作业、成绩、考勤这四个核心模块做深比十个模块都只做表面要稳妥得多。2. 技术选型与项目初始化2.1 技术栈选择的实际考量Spring Boot是这类系统的标准答案但版本选择上有个小讲究。我用的Spring Boot 2.7.x而不是3.x主要原因是大量毕业设计项目用的教程、开源代码都是基于2.x的遇到问题时搜索引擎能搜到的解决方案更多。毕竟做毕业设计不是搞技术前沿探索稳定、资料多、能和参考代码无缝对接才是关键。其余技术配套如下技术组件选型结果选择理由持久层框架MyBatis-Plus单表CRUD不用写SQL复杂查询支持自定义XML适合毕设节奏数据库MySQL 8.0免费稳定Linux服务器和本地Windows环境都很友好权限方案Spring Security JWT无状态认证前后端分离更容易处理前端框架Vue 2 Element UI组件成熟后台管理类页面开发效率极高构建工具Maven默认选择依赖管理清晰接口文档Knife4j自动生成API文档答辩演示时可以直接打开页面看接口2.2 项目结构的一点点心得很多人在项目初始化阶段喜欢按controller、service、mapper这种“三层结构”把包建好但如果把所有代码全堆进去后期维护很痛苦。我的习惯是按业务模块分包com.suwei ├── common // 统一返回结果、异常处理、工具类 ├── config // 安全配置、Knife4j配置、CORS配置 ├── controller // 接口层 ├── entity // 数据库实体 ├── mapper // 数据访问层 ├── service // 业务逻辑层 │ └── impl ├── dto // 接收参数的传输对象 ├── vo // 返回前端的视图对象 └── security // JWT过滤器、用户详情处理这个结构的好处是dto和vo单独拎出来之后controller里的方法签名非常干净不会出现“为了传三个字段直接把整个实体类传进去”的情况。答辩的时候老师问数据传输怎么设计你也能顺理成章讲出一套规范。2.3 依赖配置里的关键细节application.yml里最容易出错的是日期格式和时区。MySQL连接串里如果不加serverTimezone往往会报时区错误Jackson如果不配置日期格式前端拿到的时间戳会被序列化成一串数字还得再做一次转换。我直接在配置文件里定死spring: datasource: url: jdbc:mysql://localhost:3306/suwei_school?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8这段配置看起来不起眼但实际运行中绝大多数“时间不对、乱码、连不上库”的问题都跟它有关提前设置好能省掉后期大量排查时间。3. 数据库设计核心中的核心3.1 实体关系梳理数据库设计我推倒重来了两遍。第一遍按“用户、通知、作业、成绩、考勤”五个表去做结果发现班级和学生的关系没法闭环——比如老师发作业是发给班级的家长要看孩子的作业得先知道孩子属于哪个班但作业表里只存班级id的话家长就很难查。后来我理清了一个核心原则家长不直接关联班级而是通过学生间接关联。最终的核心表设计如下用户表sys_user存放所有登录账号区分角色类型学生表student维护学生基本信息关联班级id和监护人家长id班级表class_info班级名称、所属年级、班主任id通知表notice发布人id、班级id、标题、内容、附件路径、发布时间作业表homework班级id、科目、内容、截止时间、发布时间成绩表exam_score学生id、考试名称、科目、分数考勤表attendance学生id、日期、考勤状态教师班级关联表teacher_class教师id、班级id支持一个老师带多个班3.2 几张核心表的详细说明先看学生表这是整个系统的枢纽CREATE TABLE student ( id bigint NOT NULL AUTO_INCREMENT, name varchar(32) NOT NULL COMMENT 学生姓名, gender tinyint DEFAULT NULL COMMENT 性别, class_id bigint NOT NULL COMMENT 班级ID, parent_id bigint DEFAULT NULL COMMENT 关联的家长用户ID, student_no varchar(32) DEFAULT NULL COMMENT 学号, create_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT学生信息表;这条设计的核心在于parent_id。家庭端登录之后只要根据当前用户id反查student表就能找到孩子再顺着class_id进入班级上下文所有班级维度的数据通知、作业都能查到。不需要搞额外的关联中间表。通知表增加了publish_type字段分别是0-全校、1-班级、2-个人用type区分通知范围比单独建全校通知表更灵活CREATE TABLE notice ( id bigint NOT NULL AUTO_INCREMENT, title varchar(128) NOT NULL, content text, class_id bigint DEFAULT NULL COMMENT 班级ID为空表示全校, publisher_id bigint NOT NULL COMMENT 发布教师ID, publish_time datetime DEFAULT NULL, attachment varchar(255) DEFAULT NULL COMMENT 附件URL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT通知表;3.3 表关系与访问路径整个系统的数据流可以概括成一条线家长登录 - 通过parent_id查student - 拿到class_id - 按class_id查通知、作业、考勤。老师的路径类似老师登录 - 通过teacher_class查班级列表 - 按班级发布或查询内容。这条链路在设计阶段就想清楚后边写代码基本不会卡壳。我最开始做反了方向在通知表里存了parent_id来标识家长是否已读结果班级发一条通知要给全班每个家长插一条已读记录数据量瞬间膨胀而且改起来极麻烦。后来改成“前端根据通知的班级范围和当前家长的班级归属判断是否展示”逻辑简化了一大截。这个教训让我印象深刻能用查询解决的问题不要用冗余存储去解决。4. 后端核心功能实现解析4.1 登录认证与JWT处理登录这块我用了Spring Security框架加JWT的无状态方案。逻辑上前端把用户名密码传到后端后端校验成功后生成一个token返回之后的请求在请求头上带Authorization: Bearer token即可。具体实现时我自定义了一个JwtAuthenticationFilter继承OncePerRequestFilter每次请求先从Header里取token解析出用户id和角色再放入SecurityContextOverride protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String authHeader request.getHeader(Authorization); if (authHeader ! null authHeader.startsWith(Bearer )) { String token authHeader.substring(7); try { Claims claims JwtUtil.parseToken(token); String username claims.getSubject(); String role claims.get(role, String.class); // 构造认证信息放入SecurityContext UsernamePasswordAuthenticationToken authentication new UsernamePasswordAuthenticationToken(username, null, Collections.singletonList(new SimpleGrantedAuthority(role))); SecurityContextHolder.getContext().setAuthentication(authentication); } catch (Exception e) { // token无效时直接放行后续接口权限校验会拦截 } } chain.doFilter(request, response); }这里有个容易踩的坑token过期时间的设置。我设了两小时但家长端往往会在校期间一直挂着页面两小时一到所有请求都401体验很差。后来我在前端加了拦截器token过期时跳转到登录页并弹出提示“登录已过期请重新登录”配合后端刷新token的接口才算把体验理顺。4.2 班级-学生-家长的关联逻辑用户认证过后下一步就是构建当前登录人的“数据上下文”。我在UserContext工具类里封装了三个方法getCurrentUserId()、getCurrentUserRole()、getCurrentUserClassIds()。以家长端为例获取孩子班级列表的逻辑Override public ListLong getClassIdsByParent(Long parentId) { LambdaQueryWrapperStudent wrapper new LambdaQueryWrapper(); wrapper.eq(Student::getParentId, parentId); ListStudent students studentMapper.selectList(wrapper); return students.stream().map(Student::getClassId).distinct().collect(Collectors.toList()); }这段代码就是“家长关联班级”的核心。如果家长绑定了多个孩子在不同班级返回的就是多个班级id前端在“切换孩子”或者“聚合查看通知”时直接遍历即可。4.3 通知发布与撤回的业务细节通知模块看着简单实际写起来有不少细节。发布通知时前端会传班级id列表后端需要做容量判断——一次只能发到某个班级还是允许跨班级群发我的设计是允许选择多个班级服务端统一接收班级id数组PostMapping(/notice/publish) public Result publish(RequestBody NoticePublishDTO dto) { // dto.classIds 可能是一个列表 for (Long classId : dto.getClassIds()) { Notice notice new Notice(); BeanUtils.copyProperties(dto, notice); notice.setClassId(classId); notice.setPublisherId(UserContext.getCurrentUserId()); notice.setPublishTime(new Date()); noticeMapper.insert(notice); } return Result.success(); }这种批量插入的实现说不上高效但在这个数据量级下完全够用。真要优化的话可以攒成批量insert或者先生成一条主通知再建关联表。但毕业设计的核心是把流程跑通、逻辑自洽我不建议在这个层级做过度设计。撤回通知时需要注意权限控制只能撤回自己发的通知。很多同学习惯在前端隐藏按钮但接口层面不做校验这就留下了越权漏洞。我写了个判断Notice notice noticeMapper.selectById(id); if (!notice.getPublisherId().equals(UserContext.getCurrentUserId())) { return Result.fail(无权操作该通知); }这个小细节在答辩时如果老师问了你能答出来“防止水平越权”会是很加分的点。4.4 成绩与考勤模块的实现思路成绩模块我采用按学生逐条录入的方式而不是按班级批量录入因为批量录入的前端交互要复杂得多需要动态生成表格还要处理“每个学生的成绩校验”。而逐条录入配合一个简单的下拉选择考试名称后端一个saveOrUpdate就能搞定。考勤模块稍微特殊一些它天然有“日期 学生id 状态”三个维度。我提供了一个打卡式的接口教师选择班级和日期然后逐个标记学生出勤状态。查询端接口则支持按学生维度分组展示某月考勤汇总。这里我用了一个自定义SQLselect idselectAttendanceSummary resultTypecom.suwei.vo.AttendanceSummaryVO SELECT a.student_id AS studentId, s.name AS studentName, COUNT(CASE WHEN a.status 1 THEN 1 END) AS normalCount, COUNT(CASE WHEN a.status 2 THEN 1 END) AS lateCount, COUNT(CASE WHEN a.status 3 THEN 1 END) AS leaveCount FROM attendance a LEFT JOIN student s ON a.student_id s.id WHERE a.class_id #{classId} AND a.att_date BETWEEN #{startDate} AND #{endDate} GROUP BY a.student_id, s.name /selectMyBatis-Plus的单表查很方便但这种带分支统计的聚合查询写XML反而更直接。这个接口做出来之后教师端页面只要调用一次就能拿到整班考勤统计不需要前端做二次加工。5. 前端页面与交互实现5.1 页面结构整体规划前端我用的是Vue 2加Element UI经典的管理系统组合。页面拆成三大块登录页统一的账号密码登录登录后根据角色跳转不同首页管理端布局左侧菜单 右侧内容区按角色动态渲染菜单数据看板页登录后默认展示的汇总数据页管理端菜单分角色控制比如教师端显示“班级管理、通知管理、作业管理、成绩管理、考勤管理”家长端只显示“通知查看、作业查看、成绩查看、考勤查看”。这个动态菜单通过后端返回的menuList字段渲染不是在前端硬编码。5.2 前端路由与权限拦截路由权限这块我用了一个很常见的方案全局前置守卫。每次路由切换时判断本地是否存了token没有token强制跳转登录页有token但访问了非当前角色的路由则跳转到404。router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.path /login) { next(); return; } if (!token) { next(/login); return; } // 根据角色做路由级过滤 const role localStorage.getItem(role); if (to.meta.roles !to.meta.roles.includes(role)) { next(/404); return; } next(); });这个实现成本很低但对系统的完整感提升非常大。不然家长端能打开教师管理的页面虽然接口有权限拦截但404页面都懒得做的话答辩时说“做了权限控制”就有点心虚。5.3 数据展示上的几个细节家长端首页需要展示孩子的基本信息、最近三条通知、最近一次考试成绩和本月考勤情况。这个页面在实现上是个多接口聚合的“门户页”但为了减少请求次数我做了个聚合接口后端一次性返回GetMapping(/parent/dashboard) public Result getParentDashboard() { Long parentId UserContext.getCurrentUserId(); ListLong classIds classService.getClassIdsByParent(parentId); DashboardVO vo new DashboardVO(); vo.setStudentList(studentService.getStudentsByParent(parentId)); vo.setRecentNotices(noticeService.getRecentNoticesByClassIds(classIds, 3)); vo.setLatestExamScores(examScoreService.getLatestScoresByParent(parentId)); vo.setAttendanceSummary(attendanceService.getAttendanceSummaryByParent(parentId)); return Result.success(vo); }前端一次性拿到数据渲染成四个卡片区块体验比打开页面后连续发四五个请求好得多。这里我要提一句很多毕设的项目在数据展示上习惯“前端循环调接口”看起来代码简单但演示时如果网络慢一点页面上一个一个模块往外蹦观感很差。一口聚合返回是提升演示效果的低成本高收益手段值得花十分钟合并一下。6. 部署配置与常见问题排查6.1 本地运行与部署注意事项项目本地跑起来很简单后端idea里直接启动前端npm run dev。但有几个环境层面的事需要提前确认MySQL版本尽量用8.0驱动和方言配置都顺一些Node版本不要太高我用的Vue2项目在Node 18上跑会报OpenSSL错误后来改用Node 16才顺利启动Redis如果没有用到可以不加没必要为了“技术栈好看”硬塞一个组件进来真正要部署到服务器上演示时我建议用mvn package打jar包配合nohup java -jar suwei.jar启动前端构建后丢到Nginx的html目录里再配置一下反向代理server { listen 80; server_name localhost; location / { root /usr/share/nginx/html; index index.html; } location /api/ { proxy_pass http://localhost:8080/; proxy_set_header Host $host; } }6.2 常见问题速查与解决办法整理一下我在开发中真正踩过、也大概率会被其他同学踩到的坑问题现象根因解决办法前端请求接口报跨域前后端不同端口后端加CORS配置类或用Nginx反向代理同源token登录后刷新就失效JWT密钥每次重启随机生成在yml中配置固定jwt.secret日期显示成Array或时间戳序列化格式未指定配置jackson日期格式上传文件失败Nginx上传文件大小限制在nginx配置client_max_body_size数据库中文乱码表和连接串字符集不统一统一utf8mb4查询成绩时数据重复多表join没去重检查是否是多对多关系用distinct解决6.3 实际排查经验记录我记得最折腾的一次是“教师端发布通知后家长端看不到”。一开始怀疑是接口问题后来发现是班级范围匹配错了。教师发布时选择了班级id为5的班级但家长端根据学生关联到的class_id是6两边对不上。排查时我直接在数据库里查了notice表的class_id和student表的class_id发现是测试数据维护时学生被误派到了另一个班。这类问题有个共同特点业务逻辑没错数据错了。所以遇到“看不到数据”先别急着查代码先用SQL确认数据是不是符合预期SELECT class_id FROM student WHERE parent_id 1; SELECT class_id, title FROM notice WHERE publisher_id 1;把这两条查询结果一对比问题基本一目了然。以后遇到类似问题我都养成了“先查数据、再断逻辑、最后看代码”的排查顺序效率高出不少。6.4 答辩演示时的一些实操建议最后说点答辩演示的细节。很多同学演示系统时临时操作、手忙脚乱我建议提前准备好一套“演示剧本”按固定的数据走一遍先用管理员账号登录创建班级、创建教师账号切换到教师账号发布通知、布置作业、录入几条成绩切换到家长账号按班级查看到刚才发布的内容最后演示一个越权场景比如家长账号直接访问教师管理接口被后端拒绝并返回401展示权限控制的真实性这套流程走完基本覆盖了系统所有核心功能。同时把Knife4j接口文档页面提前打开万一某个页面操作出了小问题还能切到接口文档接口“手动补一刀”避免当场卡壳。我个人在实际操作中最深的体会是这类管理系统真正的难点不在单点技术而在数据关系的闭环设计。把“谁的数据、从哪来、到哪里去”这条链路想透后端写着顺前端展示也顺。如果你也在做类似的系统建议先在纸上把角色、数据、权限画清楚再动手写代码后面会发现踩坑的概率小很多。