1. 教务平台在解决什么事九大关键词背后的真实业务教务系统这个题目基本是每年课设、毕设里出现频率最高的那一档。不是因为它简单恰恰相反——学生信息、学籍管理、课程安排、选课系统、成绩查询、考试安排、教学管理一套下来七八个关联模块数据库关系多、角色权限杂、业务规则绕能把一个完整闭环做通顺就足够证明你从需求到设计再到落地是过关的。再加上项目里出现的“JavaSSMDjango”这套混合技术栈它更像“一个工程里同时跑两套后端”的实战形态比纯单体CRUD有东西可讲。这篇文章主要写给两类人。一是准备拿教务信息平台练手的同学想搞清楚模块边界、表怎么建、双端怎么跑通二是项目已经做了一半、正在纠结答辩怎么讲的选手。我会把模块拆分、数据库设计、双端启动流程、调试里最常翻车的几个点以及文档和答辩怎么搭故事线一次性梳理清楚。1.1 三条角色主线决定模块边界教务平台看起来模块多其实顺着角色拆分就清楚了。系统里永远是三类人学生、教师、管理员。权限和功能都围绕这三条主线展开。学生端要的是选课、查看课表课程安排、成绩查询、考试安排再加一个自己的学籍信息核对。教师端要的是课程安排与教学任务、成绩录入、选课名单导出。管理端要的是学生信息、学籍管理、课程与教师资源维护、排课参数、数据统计。模块主要角色核心动作学生信息管理员录入、维护、查询学生档案学籍管理管理员、学生学籍状态变更、信息核对课程安排管理员、教师排课、冲突检测、查看课表选课系统学生、管理员选课、退课、名额控制成绩查询教师、学生成绩录入、加权计算、导出教学管理管理员、教师教学任务分配、进度管理考试安排管理员、学生考表生成、教室分配拿到需求先干这件事把每个功能标到对应角色上去。角色一旦明确了控制层和页面路由就好写很多数据库也顺势分成“学生相关表”“教师相关表”“系统配置表”三块。1.2 从关键词看透要做的核心功能标题里的九个关键词每个都不是表面意思背后有明确的业务含义。教务管理不是单一功能它是管理端一堆操作的集合资源维护、规则配置、数据统计本质是零散管理动作的统称。学生信息和学籍管理要区分开学生信息是基础档案包括姓名、学号、学院、班级、入学年份学籍管理是状态流转入学、休学、复学、退学、毕业每个状态变更都要留痕。课程安排和教学管理也不是一回事。课程安排管的是“课在什么时候上、在哪上”核心是教室资源和时间资源的排布教学管理管的是“谁上、上哪些班”核心是教师的教学任务分配。成绩查询容易想简单以为就是列表加搜索。实际上成绩模块要处理平时成绩和期末成绩按比例加权、补考重修标记、成绩导入导出还有教师录入后的二次审核。考试安排则是把课程、时间、教室、监考老师做组合约束不能同一个教室同时排两场考试同一个老师也不能同一时段出现在两个考场。选课系统是最能体现项目含金量的地方。学生选课后要反写课程安排里的已选人数名额满了不能继续选同一门课不能重复选选课时间窗口要生效。这一块涉及并发控制后面我会专门展开。2. SSM和Django为什么能凑在一起混合架构的选型逻辑与通信设计2.1 这不是微服务是两个进程各管一段先说个答辩被问懵概率最高的题项目里既有SSM又有Django到底是谁干谁的活按这类项目常见的分工SSMSpring SpringMVC MyBatis负责主业务也就是登录鉴权、学生档案、课程、选课、成绩、排课这些强事务操作事务边界和并发控制都在这一侧。Django那边通常承担三类事数据统计与可视化按学院、按课程统计选课人数、成绩分布。Django写聚合查询快自带的 admin 后台也能少写不少管理页面。批量导入导出用 pandas 或 openpyxl 处理 Excel比 Java 的 POI 方案短平快。辅助脚本与测试数据生成模拟成绩、批量创建账号、清理脏数据。这不是微服务架构更准确说是“同一批数据上的双后端分工”。主业务保持在一个事务管理器里保证关键流程不跨库辅助功能走独立服务互不干扰。答辩时用这个逻辑去解释“为什么要用两套技术栈”比含糊说“老师要求用”要站得住得多。2.2 跨栈通信的三种写法两套后端之间不直接共享内存必须走HTTP接口。最常见的方案有三种。一种是 SSM 主动调用 Django 的接口把统计结果拿到 Java 页面展示。用 HttpClient 就能实现String url http://localhost:8081/api/stats/score-distribution?term2024-2025-1; CloseableHttpClient client HttpClients.createDefault(); HttpGet get new HttpGet(url); CloseableHttpResponse resp client.execute(get); String json EntityUtils.toString(resp.getEntity(), UTF-8); // 解析 json组装成页面需要的数据另一种是 Django 主动调 SSM 的接口拿选课名单做二次分析或者生成导出文件。Python 端用 requests 即可import requests resp requests.get( http://localhost:8090/api/course/selected, params{course_id: 101}, timeout3 ) data resp.json()第三种是浏览器统一入口。用反向代理把页面请求分流/admin 走 Django/api 走 SSM。如果只是本地跑课程设计前端直接请求两个端口也能通但记得处理跨域这个坑我放到第五章讲。2.3 数据一致性怎么兜底两套后端连同一个 MySQL 库时最重要的原则是划清楚“谁的表”。每张表只有一个主要写入方学生、课程、成绩相关主表由 SSM 维护Django 只负责统计查询和中间结果表最多写入自己的日志、导出任务表。千万别两边都写同一张业务表改一处漏一处线上排查成本很高。时间字段也要统一。Java 和 Python 对时间的处理风格不同Java 的 LocalDateTime 和 Python 的 datetime 在序列化时格式可能不一致。建议库表统一用 datetime接口传输统一用字符串“yyyy-MM-dd HH:mm:ss”Java 和 Django 都按这个格式解析避免跨天数据对不上。时区问题也是同理后面排错章节会详细说。3. 数据库设计是重头戏核心表结构与业务规则落库3.1 九张核心表的最小集合按标题里的功能项表最少可以缩到这些表用途关键字段student学生档案student_nonamecollege_idclass_namestatusteacher教师档案teacher_nonametitlecollege_idcourse课程信息course_codecourse_namecredithourscourse_arrangement排课记录termcourse_idteacher_idweek_daysection_listclassroommax_countselected_countcourse_selection选课记录student_idcourse_idselect_timestatusscore成绩记录student_idcourse_idregular_scoreexam_scorefinal_scoretermexam_arrangement考试安排course_arrangement_idexam_timelocationinvigilatorcollege学院/系部nameuser登录账号usernamepasswordroleref_id这里有个关键设计user 表用 ref_id 关联 student 或 teacher而不是给每个角色各建一套账号表。登录时按 role 去查对应档案权限判断只认 role不要靠前端按钮隐藏来兜底安全。服务端接口必须做角色校验不然会被人绕过页面直接调接口拿数据。course_arrangement 里的 section_list 是节次组合比如第 1-2 节存成“1,2”第 3-4 节存成“3,4”。用逗号分隔的字符串虽然不满足最严格的第一范式但在这个场景下查询和展示都很方便属于合理的工程取舍。3.2 业务规则怎么变成表和 SQL选课防重复靠的是 course_selection 上的联合唯一约束ALTER TABLE course_selection ADD UNIQUE KEY uk_student_course (student_id, course_id);选课防超员给 course_arrangement 加 selected_count选课前做条件更新而不是先查再改。排课冲突检测用一条 SQL 查同一周几、同一节次区间下教室或者教师是否被占用SELECT COUNT(*) FROM course_arrangement WHERE term #{term} AND week_day #{weekDay} AND classroom #{classroom} AND FIND_IN_SET(#{section}, section_list) 0;成绩加权计算平时成绩和期末成绩分字段存final_score 在录入时按比例算好入库同时保留原始分数方便复核。比如平时占 40%、期末占 60%就是 regular_score * 0.4 exam_score * 0.6这个规则建议放到服务端统一算不要在页面写死。3.3 表设计里最容易翻车的三个习惯第一把成绩直接挂到学生表上。一个学生一学期十几门课这样做字段根本没法设计拆出 score 表是唯一的正解。第二喜欢用课程名称、学生姓名做关联字段。名称随时可能改数据一改全链路崩必须用 id 关联名称只作为展示字段。第三不建索引不建唯一约束。选课表刚跑起来没感觉数据到几千条之后重复选课和联表查询的问题会一起冒出来。索引不用一次建满但 (student_id, course_id)、(course_id) 这些高频查询路径从一开始就要考虑。外键要不要加我的建议是表关系在逻辑上清晰即可写 SQL 时手动保证数据完整性外键在课设项目里加了反而容易成为迁移和测试数据的障碍。4. 从环境搭建到双端启动完整复现一套可运行项目4.1 环境依赖清单动手前先把环境对齐不然容易“启动即报错”。SSM 端需要 JDK 8 或 11、Maven 3.6、Tomcat 8.5 或 9、MySQL 5.7 或 8.0。Django 端需要 Python 3.8、Django 2.x 或 3.x。版本匹配要格外注意老项目用 JDK8 配 Tomcat8 最稳JDK11 上跑老版本 Spring 有可能遇到模块化相关的兼容问题Django 2.x 建议配 Python 3.6 到 3.9Django 3.x 配 Python 3.8 以上。拿到源码先看 pom.xml 和 requirements.txt按里面的版本号来不要自作主张升大版本。4.2 先把 SSM 主服务跑起来完整流程分四步。第一步把源码导入 IDE等待 Maven 把依赖拉完这一步如果网速慢要有点耐心。第二步修改 main/resources 目录下的数据库配置文件把 MySQL 地址、端口、账号、密码改成自己的。第三步用项目里的 SQL 脚本建库如果没有完整脚本至少把表结构和初始管理员账号造好。第四步在 Tomcat 里部署 war 包或者配置 exploded artifact启动后访问登录页。验证方式很简单admin 能登录进去学生列表、课程列表有数据说明 SSM 端通了。提示如果启动报数据库驱动相关的错误98% 是 MySQL 8 的驱动名写成了 com.mysql.jdbc.Driver。MySQL 8 必须用 com.mysql.cj.jdbc.Driver并且连接串里带上 serverTimezoneAsia/Shanghai不然会报时区错误。4.3 再把 Django 端跑起来Django 端启动也不复杂。先建虚拟环境并安装依赖python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate pip install -r requirements.txt然后修改 settings.py 里的数据库配置让它指向同一个 MySQL 库。执行 python manage.py migrate 应用数据表迁移再执行 python manage.py createsuperuser 创建后台管理员账号。最后运行python manage.py runserver 0.0.0.0:8081浏览器访问 /admin输入刚创建的账号能进后台Django 端就算跑通了。如果 migrate 之后库里没出表先检查 INSTALLED_APPS 里有没有注册对应的 app这步最容易漏。4.4 双端联调自检清单双端都启动后按这份清单过一遍浏览器从 8081 端口访问页面请求 8090 端口的 SSM 接口时是否提示跨域错误。登录接口返回的是 session 还是 tokenDjango 端拿到后如何透传给 SSM两端要约定好。Windows 下 MySQL 表名不区分大小写Linux 下区分跨平台部署时 SQL 里的表名大小写要统一。双端共用库时确认没有两个服务同时写同一张业务表。联调阶段的报错八成出在端口、跨域、字符集这三件事上先把清单过完再深入代码定位。5. 调试翻车实录跨域、MyBatis映射、选课并发与数据一致性5.1 页面打不开接口跨域问题症状很典型浏览器控制台报 blocked by CORS policy页面数据加载不出来。原因就是前端页面在 Django 端请求目标在 SSM 端端口不同触发浏览器的同源策略。解决方案是在 SSM 端加一个全局跨域过滤器Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedHeader(*); config.addAllowedMethod(*); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); }Django 端如果也要被别的来源调用用 django-cors-headers 中间件配置好允许来源即可。本地开发用通配符没问题部署到公网环境后要收敛成具体的域名列表不然等于向所有来源开放了接口。5.2 Invalid bound statementMyBatis 映射没接上症状是调用 Mapper 方法时报 Invalid bound statement (not found)翻译过来就是 MyBatis 没找到对应的 SQL 语句。根因通常是 mapper XML 没有被 Spring 扫描到或者 namespace 和接口全限定名对不上。排查顺序按三步走先看 Spring 配置文件里 mapper-locations 扫的是哪个目录再看 XML 文件是否真的落在该目录下最后核对 namespace 是否等于接口的全限定名。XML 里每个语句的 id 必须和接口方法名一致resultType 要写实体类的全限定名少写一个都会在运行期才报错。一个典型的正确写法mapper namespacecom.example.mapper.StudentMapper select idselectStudentList resultTypecom.example.entity.Student SELECT * FROM student /select /mapperSPring 配置文件里对应加上property namemapperLocations valueclasspath:mapper/*.xml/这类问题定位不难但很容易浪费半小时因为报错发生在调用时而不是启动时。5.3 选课并发超选的名额怎么防选课系统是最容易出现业务逻辑漏洞的地方。错误写法是先查当前已选人数判断小于 max_count 再插入。高并发下两个请求都读到 99同时执行插入名额就超了。正确做法是条件更新加唯一约束双保险UPDATE course_arrangement SET selected_count selected_count 1 WHERE id #{id} AND selected_count max_count;受影响行数为 0说明名额已满。同时靠 course_selection 上的 (student_id, course_id) 唯一约束兜底插入时捕获重复键异常给前端返回“你已经选过这门课了”。这套组合能同时防超选和防重复也是答辩时最值得讲的业务亮点。5.4 双端数据对不上字符集与时区症状是 Django 端导出的名单中文乱码或者 SSM 写入的时间在 Django 页面显示少了 8 小时。这两个问题都是配置级的却很难排查。数据库连接串统一加上 characterEncodingutf8建库时用 utf8mb4 字符集。Django 的 settings.py 里 LANGUAGE_CODE 设为 zh-hansTIME_ZONE 设为 Asia/ShanghaiUSE_TZ 按项目实际情况统一开或关。时区问题会让“今天选的课”在统计里变成昨天跨天之后对不上账。注意我建议所有双端项目接入后第一件事就是检查连接串字符集和时区而不是先去跑通业务。这两个配置看着小引发的数据问题却最难追溯数据一旦写脏后面全是连锁反应。6. 文档与答辩把项目讲成“你的作品”的实践经验6.1 论文/LW 的主线怎么搭这类项目包里的 LW一般指论文或者设计文档。一篇合格的毕设文档主线只有一条从需求到设计到实现到测试。章节骨架建议是——绪论、可行性分析、需求分析、系统设计、数据库设计、详细设计与实现、系统测试、总结。写的时候注意三点。需求分析不要抄概念直接列功能用例最好对应到表格里的每个模块数据库设计放 ER 图和主要表结构重点讲清楚 student、course_arrangement、score 这三张核心表的关联实现章节不贴大段源码贴核心方法并说明思路配完整截图。截图要截全别截一半答辩老师基本靠截图来快速判断功能是否存在。6.2 答辩高频提问清单为什么选 SSMDjango 这套混合架构回答重心放在分工主业务用 SSM 保证事务一致性Django 在统计、导入导出和后台管理上开发效率高。课程冲突怎么检测答按学期、周几、节次查教室和教师的占用情况插入前做时间冲突校验。选课人数会不会超答条件更新 selected_count 加唯一约束双保险并发场景下也不会超选。权限怎么控制答登录后按角色持有不同权限服务端通过拦截器做接口级权限校验不能只靠前端隐藏按钮。项目里最大的坑是什么这种问题千万别答“没坑”挑一两个真实问题讲比如跨域、并发重点说怎么定位、怎么解决。6.3 演示准备的细节演示数据要少而精。两三页的分页数据比一百条更有看头核心操作反复练熟给一个学生开班建课去选课窗口完成选课成绩录入后看统计图表。准备一个“错误演示”会更加分比如选课人数已满时弹出的提示比一路顺畅更能体现你理解业务。演示前把 MySQL、Tomcat、Django 全部启动好浏览器标签页提前打开数据库备份一份。现场卡在启动环节比任何答辩问题都尴尬这种低级错误千万别犯。另外提前想好“如果网络环境变了怎么办”本地演示就用 localhost不依赖外部网络是最稳的。最后聊点个人体会。这种教务信息平台项目代码量其实不算大真正的门槛在业务规则能不能闭环。同样的功能有的人做出来是 CRUD 工程有的人做出来是“能回答为什么”的系统差距就在表设计、并发控制和权限边界这些细节上。只要你能把“用户从登录到选课再到查成绩”这条链路从头到尾讲清楚答辩基本就稳了。这也是我一直建议多做图表、少死磕代码的原因——理清业务关系代码只是翻译的过程。项目跑不通的时候先查配置再看代码往往能省下大量时间。