简介这是一份基于JAVA的教学进度在线管理系统/教学大纲在线管理系统的毕业设计级完整项目包含源代码、数据库及配套文档适合高校计算机相关专业学生、Java初学者用于毕业设计、课程设计或项目实践参考。压缩包共760个文件容量约42.73MB涵盖Java源码、JSP页面、HTML/CSS/JS前端资源、SQL数据库脚本、jar依赖包以及docx/pdf/xls等多类型文档目录结构清晰便于按模块检索。目前已有313人学习下载。资源内不仅有可直接运行的代码还包含从需求分析、概要设计、详细设计到项目总结的全套文档能够帮助读者系统理解在线管理系统的完整开发流程同时覆盖教学进度管理、教学大纲管理等典型功能模块对掌握Java Web项目开发具有相当参考价值且文档与代码配套便于在实践中边读边验证。1. 这个JAVA教学进度在线管理系统解决的是“进度失控”而不是“排课”“教学进度在线管理系统”这个名字听起来像大学课设仓库里又一个增删改查。但真去教研室待过两周就明白进度管理从来不是排课——大纲是PDF、进度是Excel、老师月底填一次交给主任时两份表对不上是常态。这套基于JAVA的系统核心价值是把教学大纲拆成细目、把细目折成周计划、把实际进度填回去算偏差让“讲到哪了”从人脑记忆变成一条随时可查的预警记录。项目自带的源代码、数据库和需求分析、概要设计、详细设计及项目总结文档说白了就是一套能直接跑的完整模板。适合三类人照着做做毕业设计或课程设计的在校生、接管理系统外包的开发者、想低成本给教研室做内部工具的运维。2. 从需求分析抽业务闭环三个角色、一条主线、五张核心表把这套系统的需求分析文档摊开前几十页的用例图、活动图和原型图本质上只回答三个问题谁来用、走什么流程、数据怎么存。这三个答案立住了剩下的大多数页面都是注释。2.1 角色边界管理员、教师、教研室主任各管一段这类系统最常见的角色划分是三个不多不少。管理员管基础数据教师管大纲和进度教研室主任看结果。管理员负责课程、账号和大纲的发布/归档操作不碰教学业务这是避免权限纠缠的常见做法。教师承担两类核心工作维护自己任教课程的教学大纲细目以及按周填报实际讲授内容。教研室主任不直接改数据但拥有大纲审核和进度报表查看权限。权限实现不需要一上来就上Spring Security。这套体量下一个拦截器拿到登录用户的role字段做判断就够了密码字段单独处理角色字段用ADMIN/TEACHER/DEAN三个枚举值存。等系统真需要细粒度权限时再迁移初期把角色边界写在需求分析文档里比写在代码里更值钱。2.2 核心业务闭环大纲制定、周计划、进度填报、偏差预警整个系统的业务主线是一条四个环节的闭环。第一环是大纲制定管理员建课程教师为课程创建大纲版本并把大纲拆成细目每个细目包含章节号、章节名、计划学时、起始周和结束周。第二环是周计划生成根据细目的start_week和end_week把每章学时摊到对应周次生成一张“第N周应该讲什么”的计划表。第三环是进度填报教师每周填写实际讲授内容、实际学时数据落到进度记录表。第四环是偏差预警系统对比计划学时和实际学时的累计比例偏差低于阈值时提醒教研室主任。第一环和第四环是这套系统和普通Excel台账的本质区别。没有周计划生成系统只是把Excel搬到网页上有了偏差预警它才配叫“管理”系统。需求分析文档里最该画清楚的也是这个闭环而不是登录注册那套通用流程。2.3 数据库模型五张核心表如何串起大纲与进度数据库设计直接决定这套系统能活多久。最小可用模型是五张表它们的职责分配如下表名职责关键字段sys_user系统用户username、password、rolecourse课程基础信息course_code、total_hours、creditsyllabus教学大纲主表course_id、version、statussyllabus_item大纲细目chapter_no、planned_hours、start_week、end_weekteaching_progress教学进度填报week_no、actual_content、actual_hours核心建表语句如下字段类型和约束直接按这套写后面踩坑最少。-- 用户表三种角色用 role 字段区分 CREATE TABLE sys_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, real_name VARCHAR(50), role VARCHAR(20) NOT NULL COMMENT ADMIN/TEACHER/DEAN, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 课程表一门课程只有一条基础信息 CREATE TABLE course ( id INT PRIMARY KEY AUTO_INCREMENT, course_name VARCHAR(100) NOT NULL, course_code VARCHAR(30) NOT NULL UNIQUE, total_hours INT NOT NULL, credit DECIMAL(3,1) NOT NULL, dept_name VARCHAR(50), status TINYINT DEFAULT 1 COMMENT 1启用 0停用 ); -- 教学大纲主表同一门课允许多个版本并存 CREATE TABLE syllabus ( id INT PRIMARY KEY AUTO_INCREMENT, course_id INT NOT NULL, version VARCHAR(20) NOT NULL COMMENT 如2025春-01, total_hours INT NOT NULL, status TINYINT DEFAULT 0 COMMENT 0草稿 1已生效 2已废弃, publish_date DATE, FOREIGN KEY (course_id) REFERENCES course(id) ); -- 大纲细目表每一条就是一个教学单元 CREATE TABLE syllabus_item ( id INT PRIMARY KEY AUTO_INCREMENT, syllabus_id INT NOT NULL, chapter_no VARCHAR(20) NOT NULL, chapter_name VARCHAR(100) NOT NULL, content_desc VARCHAR(500), planned_hours INT NOT NULL, start_week INT, end_week INT, FOREIGN KEY (syllabus_id) REFERENCES syllabus(id) ); -- 教学进度记录表老师每次填报一条 CREATE TABLE teaching_progress ( id INT PRIMARY KEY AUTO_INCREMENT, course_id INT NOT NULL, syllabus_id INT NOT NULL, teacher_id INT NOT NULL, week_no INT NOT NULL, actual_content VARCHAR(500), actual_hours INT NOT NULL, fill_date DATE NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (course_id) REFERENCES course(id), FOREIGN KEY (syllabus_id) REFERENCES syllabus(id), FOREIGN KEY (teacher_id) REFERENCES sys_user(id) );这里有几个设计细节值得说。syllabus主表单独带version字段是为了大纲改版时能同时存在“旧版已归档”和“新版草稿”两条记录进度记录绑定的是syllabus_id而不是syllabus_item_id这样旧数据不会因为细目调整而串味。syllabus_item里的start_week和end_week很关键它是后面生成周计划、计算计划进度的依据缺了这两个字段偏差计算就无从谈起。teaching_progress里冗余了course_id虽然能从syllabus_id反查但进度报表最频繁的查询就是按课程、按周次汇总冗余字段能少一次join。planned_hours用INT不用DECIMAL因为排课学时的最小单位是1节课用到0.5学时的情况在高校大纲里几乎不存在用INT反而避免浮点精度问题。password字段预留100长度因为登录校验从MD5换成BCrypt时密文长度会从32变到60字段不够就得改表。外键在MySQL里建不建都行实际开发我一般保留物理外键约束但初始化测试数据时会把外键检查临时关掉否则按顺序插入数据很痛苦。3. 用Spring Boot MyBatis跑通进度填报核心代码与关键配置技术栈选型上这类管理系统最常见的组合是把需求分析里的流程翻译成Spring Boot MyBatis MySQL。Spring Boot把Web层、事务、Jackson序列化都集成好了MyBatis让SQL保持可控不引入JPA那套实体关系映射的复杂度。3.1 项目骨架pom.xml依赖与版本匹配依赖清单并不长但版本是个容易翻车的点。以Spring Boot 2.7.x为例MyBatis官方starter要用2.3.x不要随手拖一个3.x版本否则启动时直接报找不到自动配置类。MySQL驱动用Boot默认管理的mysql-connector-j版本跟Boot走不用手写。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.2/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies版本匹配这事没什么玄学就一条规则Spring Boot 2.7配MyBatis starter 2.3.xSpring Boot 3.x配MyBatis starter 3.x。如果项目是从老代码里扒的骨架先看Boot版本再定starter版本比报错后再查更快。Lombok属于可选依赖团队不习惯就删掉手写getter/setter也不影响什么。3.2 核心Service填报、累计、偏差计算的实现进度偏差是整个系统最核心的计算逻辑。口径要统一我一般这么定义计划进度等于截至当前周累计计划学时除以大纲总学时实际进度等于累计实际填报学时除以大纲总学时偏差等于实际进度减计划进度。偏差为负表示落后。下面的ProgressService把偏差计算封装成一个方法传入课程ID和当前周次返回计划比例、实际比例和差值。Service public class ProgressService { private final SyllabusMapper syllabusMapper; private final SyllabusItemMapper itemMapper; private final TeachingProgressMapper progressMapper; // 构造器注入避免 Autowired 字段注入带来的循环依赖隐患 public ProgressService(SyllabusMapper syllabusMapper, SyllabusItemMapper itemMapper, TeachingProgressMapper progressMapper) { this.syllabusMapper syllabusMapper; this.itemMapper itemMapper; this.progressMapper progressMapper; } /** * 计算某门课截至指定周次的进度偏差 * 偏差 实际累计学时/大纲总学时 - 计划累计学时/大纲总学时 */ public ProgressDeviation calculateDeviation(Integer courseId, Integer weekNo) { // 1. 取当前生效中的大纲版本 Syllabus syllabus syllabusMapper.findEffectiveByCourseId(courseId); if (syllabus null) { throw new BusinessException(该课程没有生效中的教学大纲); } // 2. 取出该大纲下的所有细目累加得到总学时 ListSyllabusItem items itemMapper.findBySyllabusId(syllabus.getId()); int totalHours items.stream() .mapToInt(SyllabusItem::getPlannedHours) .sum(); // 3. 计划学时只统计起始周小于等于当前周的细目 int plannedHours items.stream() .filter(item - item.getStartWeek() weekNo) .mapToInt(SyllabusItem::getPlannedHours) .sum(); // 4. 实际学时查询截至当前周的累计填报学时 Integer actualHours progressMapper.sumActualHours(courseId, weekNo); int actual actualHours null ? 0 : actualHours; // 5. 换算成比例注意总学时为0的边界 double plannedRatio totalHours 0 ? 0.0 : (double) plannedHours / totalHours; double actualRatio totalHours 0 ? 0.0 : (double) actual / totalHours; return new ProgressDeviation(plannedRatio, actualRatio, actualRatio - plannedRatio); } }这里两个细节要注意。第4步的sumActualHours在Mapper里要写成累计查询SQL大致是SELECT COALESCE(SUM(actual_hours), 0) FROM teaching_progress WHERE course_id #{courseId} AND week_no #{weekNo}只统计当前周之前的填报记录不是只取本周数据。第5步里大纲总学时为0的概率极低但方法一旦被异常数据触发就是除零异常所以防御性判断不能省。进度填报的Service更简单本质就是一次INSERT加一次事务控制。教师在页面上选择课程、周次填写实际内容和学时后端校验同一课程同一周次是否已填报过避免重复提交。常见的做法是在teaching_progress表上加一个UNIQUE KEY uk_course_week (course_id, week_no)数据库层兜底比应用层判断可靠得多。3.3 application.yml四个必调的MyBatis与数据源参数配置文件是这套系统里除了pom之外第二处容易翻车的地方。以MySQL 8.0为例驱动类名、时区、公钥获取、驼峰映射四个参数必须显式写清楚缺一个都可能在启动或第一次查询时爆出莫名其妙的问题。spring: datasource: url: jdbc:mysql://localhost:3306/edu_progress?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true jdbc-type-for-null: NULL log-impl: org.apache.ibatis.logging.stdout.StdOutImpl server: port: 8080逐个说明这四个参数的意义。serverTimezoneAsia/Shanghai在MySQL 8.0下不写必报时区错误allowPublicKeyRetrievaltrue解决MySQL 8默认caching_sha2_password认证下首次连接的公钥获取问题useSSLfalse省去SSL握手开销本地开发调试很有必要。map-underscore-to-camel-case是MyBatis的驼峰映射开关开启后数据库的teacher_id自动映射到Java属性的teacherId省掉一堆Results注解。jdbc-type-for-null设成NULL避免插入空字段时MyBatis报JDBC类型异常。log-impl输出SQL到控制台调试阶段必须开上线前再关。提示如果开发机装的是MySQL 5.7driver-class-name要写com.mysql.jdbc.Driver连接串里也可以去掉allowPublicKeyRetrieval保留其他三个参数不影响运行。4. 数据库脚本与初始化数据让系统第一次启动就有东西可看拿到源代码和数据库文件之后最尴尬的事是启动项目发现库里是空的。所以数据库脚本必须包含两样东西完整的表结构脚本以及一套能演示业务闭环的初始化数据。这套脚本写好了系统第一次启动就能看到课程、大纲、细目、进度记录和偏差报表。4.1 补充索引与week_plan辅助表第2章五张核心表只解决“能存”还需要补索引和辅助表解决“查得快”和“周计划可对比”。进度表最频繁的查询是“某课程某周次的记录汇总”和“某教师的填报历史”这两个查询条件必须建索引。大纲细目按syllabus_id查询是常态也要索引。同时新建一张week_plan周计划表把大纲细目折算成按周次排列的计划基线。CREATE DATABASE IF NOT EXISTS edu_progress DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE edu_progress; -- 进度表高频查询索引 ALTER TABLE teaching_progress ADD INDEX idx_progress_course_week (course_id, week_no); ALTER TABLE teaching_progress ADD INDEX idx_progress_teacher (teacher_id); ALTER TABLE syllabus_item ADD INDEX idx_item_syllabus (syllabus_id); -- 周计划表按大纲周次唯一避免重复生成 CREATE TABLE week_plan ( id INT PRIMARY KEY AUTO_INCREMENT, syllabus_id INT NOT NULL, week_no INT NOT NULL, plan_content VARCHAR(500) COMMENT 本周应讲授内容摘要, plan_hours INT NOT NULL COMMENT 本周计划学时, UNIQUE KEY uk_syllabus_week (syllabus_id, week_no), KEY idx_plan_week (week_no) );索引不是越多越好。teaching_progress的联合索引(course_id, week_no)覆盖了偏差查询和防重复校验两个场景单查week_no的场景交给它也能走索引前缀规则所以不需要再单独建week_no索引。week_plan的UNIQUE KEY用(syllabus_id, week_no)因为同一份大纲下每周只能有一条计划这个约束同时防止生成脚本重复执行时产生脏数据。4.2 初始化数据账号、课程、大纲细目与样例进度初始化数据的核心目标是让系统能跑通完整演示。账号准备三个角色各一个课程准备一门大纲准备一个生效版本细目覆盖16周的教学安排进度记录准备三条其中故意留一条偏差记录这样打开报表就能看到预警效果。密码统一用123456的MD5值。-- 账号初始化密码均为 123456 的 MD5生产环境务必换 BCrypt INSERT INTO sys_user (username, password, real_name, role) VALUES (admin, e10adc3949ba59abbe56e057f20f883e, 系统管理员, ADMIN), (teacher01, e10adc3949ba59abbe56e057f20f883e, 张老师, TEACHER), (dean01, e10adc3949ba59abbe56e057f20f883e, 李主任, DEAN); INSERT INTO course (course_name, course_code, total_hours, credit, dept_name) VALUES (数据结构, CS201, 64, 4.0, 计算机系); INSERT INTO syllabus (course_id, version, total_hours, status, publish_date) VALUES (1, 2025春-01, 64, 1, 2025-02-20); -- 大纲细目8个章节总学时必须和 syllabus.total_hours 一致 INSERT INTO syllabus_item (syllabus_id, chapter_no, chapter_name, content_desc, planned_hours, start_week, end_week) VALUES (1, 01, 绪论, 算法复杂度、数据结构概念, 4, 1, 1), (1, 02, 线性表, 顺序表与链表, 8, 2, 3), (1, 03, 栈和队列, 栈、队列、表达式求值, 8, 4, 5), (1, 04, 树, 二叉树、遍历、线索树, 12, 6, 8), (1, 05, 图, 图的存储、遍历、最小生成树, 12, 9, 11), (1, 06, 查找, 顺序查找、二分查找、哈希, 8, 12, 13), (1, 07, 排序, 插入、交换、选择排序, 8, 14, 15), (1, 08, 复习, 总复习与习题, 4, 16, 16); -- 进度样例前两周正常第三周少填1学时用于触发偏差预警 INSERT INTO teaching_progress (course_id, syllabus_id, teacher_id, week_no, actual_content, actual_hours, fill_date) VALUES (1, 1, 2, 1, 讲了绪论重点讲时间复杂度, 4, 2025-02-28), (1, 1, 2, 2, 线性表顺序存储数组扩容, 4, 2025-03-07), (1, 1, 2, 3, 链表操作拖了一节课, 3, 2025-03-14);这段脚本里最容易被忽略的约束是syllabus主表的total_hours必须等于syllabus_item里sum(planned_hours)。我见过好几次初始化后偏差报表一片飘红最后发现是大纲总学时64、细目累加60两个数不一致导致计算比例全线失真。画个简单校验SELECT SUM(planned_hours) FROM syllabus_item WHERE syllabus_id 1;结果不是64就回去改数据。注意进度表的第三条记录故意让实际学时为3而按计划第3周属于“线性表”章节的第2周累计计划学时是12累计实际是11偏差为负报表页就能直接看到预警效果。这套数据是照着“演示需要”设计的不是随手造几条。4.3 配套文档各写什么四份文档怎么分工标题里提到的需求分析、概要设计、详细设计、项目总结四份文档很多人只是为凑数写的其实它们各有明确读者。需求分析给指导老师或甲方看核心是用例、业务流程和数据字典概要设计给开发组内评审看核心是模块划分、接口列表和数据库ER图详细设计给编码人员看核心是类图、时序图和核心方法伪代码项目总结给答辩或验收看核心是方案对比、测试结果和问题复盘。文档读者核心内容篇幅参考需求分析老师/甲方用例图、业务流程图、数据字典、非功能需求30-50页概要设计开发组模块划分、接口列表、数据库ER图、部署视图20-30页详细设计编码人员类图、时序图、核心方法伪代码、异常约定30-50页项目总结答辩/验收方案对比、测试报告、问题复盘、后续计划10-20页我的习惯是先把需求分析里的数据字典写到和建表SQL逐字一致再动手建表。表结构改了第一件事改数据字典。这套系统里“偏差计算公式”这种关键口径必须同时出现在需求分析和代码注释里否则答辩时被问到“为什么第三周偏差是负数”答不上来就尴尬了。如果时间紧需求分析不能省详细设计可以退化成核心方法上的注释但数据字典必须完整。5. 常见坑与排查教学进度系统最容易翻车的五个场景5.1 查询结果全是null驼峰映射没开现象接口跑通了但返回的JSON里teacherId、createTime这类多词字段全是null单字段的id、username却正常。翻车点很隐蔽因为SQL没问题、数据没问题就是映射不上。原因数据库字段是snake_caseteacher_idJava属性是camelCaseteacherIdMyBatis默认不自动映射。代码里没写Results注解也没开全局驼峰开关。解决在application.yml里加一行map-underscore-to-camel-case: true就好了。这个配置对XML和注解SQL都生效加了之后重启所有字段一次性恢复。排查时先看控制台SQL输出确认SQL查出来的列名再对照Java属性名两者不一致基本就是映射问题。5.2 MySQL 8.0连不上不是端口被封是连接串参数缺失现象项目启动报Communications link failure或者报Public Key Retrieval is not allowed。有同事会怀疑端口没放行、防火墙拦截折腾半天。原因MySQL 8.0默认认证插件是caching_sha2_passwordJDBC驱动首次连接需要向服务器请求公钥连接串里没有allowPublicKeyRetrievaltrue就拒绝另外serverTimezone不写的话驱动和服务器时区不一致直接抛异常。解决连接串补齐四个参数serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue驱动类名确认是com.mysql.cj.jdbc.Driver。注意MySQL 5.7和8.0的驱动类名不一样老代码里抄来的com.mysql.jdbc.Driver在8.0下也能跑但会有警告最好改成cj版本。5.3 大纲改版后历史进度对不上现象第一学期的大纲里“树”在第6-8周第二学期改成第5-7周。改完细目之后历史进度记录里原本属于“树”章节的填报记录章节名全变了报表数据直接乱掉。原因teaching_progress只关联了syllabus_item_id而syllabus_item是原地修改的。进度记录跟着指向了被改过的新内容历史快照丢了。解决这是典型的“改数据而不是加版本”问题。大纲改版应该新建一条syllabus记录status置为草稿审核后发布旧的置为已归档。进度表里冗余保存actual_content文本快照即使章节名后来变了历史记录里仍然保留当时的填写内容。永远不要UPDATE已经生效的大纲细目。5.4 偏差口径不统一三个人算出三个偏差现象同一门课老师说自己没落后教研室主任说落后了开发人员说数据没问题。最后发现三个人用的口径不一样一个按章节算一个按周次算一个按学时算。原因需求分析文档里只写了“统计教学进度偏差”没定义公式。代码实现时不同人按自己理解写报表展示层又没标注口径。解决把公式钉死在文档和代码里。建议统一为偏差 累计实际学时/大纲总学时 - 累计计划学时/大纲总学时。累计计划学时按“起始周 当前周”的细目学时求和这个方法在第3章已经给出实现。遇到这种问题先改需求分析文档里的定义再改代码最后在报表页面上把公式展示出来三方对不上时不用扯皮。5.5 周计划重复生成导致数据翻倍现象week_plan表里同一syllabus_idweek_no出现两条记录进度对比时数据翻倍偏差报表乱成一团。原因生成周计划的方法没有做幂等处理页面重复点击提交或者定时任务和手动触发同时跑了一次。解决两种手段叠用。数据库层靠week_plan表上的UNIQUE KEY (syllabus_id, week_no)兜底重复插入直接报错应用层在生成方法前先执行一次DELETE FROM week_plan WHERE syllabus_id ?再批量插入新数据。删除后插入放在一个事务里避免删了没插进去的中间状态。6. 把大纲细目折成周计划自动生成week_plan并验证进度的三个校验6.1 生成算法把章节学时按周次摊开第2章设计的syllabus_item带start_week和end_week现在把它变成按周分配的week_plan。算法的核心是均摊章节跨几周计划学时就分摊到这几周里余数补到最后一周。这样“第8周应该讲到树”就能从数据里直接算出来而不是靠人肉翻大纲。public void generateWeekPlan(Integer syllabusId) { ListSyllabusItem items itemMapper.findBySyllabusId(syllabusId); MapInteger, Integer weekHours new HashMap(); MapInteger, String weekContent new TreeMap(); for (SyllabusItem item : items) { int start item.getStartWeek(); int end item.getEndWeek(); int span end - start 1; int base item.getPlannedHours() / span; int remainder item.getPlannedHours() % span; for (int week start; week end; week) { int hours base (week - start remainder ? 1 : 0); weekHours.merge(week, hours, Integer::sum); // 每周只记录第一个新章节名避免周计划内容过长 weekContent.computeIfAbsent(week, k - item.getChapterName()); } } weekPlanMapper.deleteBySyllabusId(syllabusId); weekPlanMapper.batchInsert(syllabusId, weekHours, weekContent); }这段代码有两个细节值得说。remainder的分配方式是“前几周各多1学时”这样最后一周的学时不会突然变大更贴近老师实际排课节奏。weekContent用computeIfAbsent只记录每周第一个出现的章节名因为一周可能跨两个章节比如第3周既结束线性表又开始栈只展示一个名字避免界面拥挤。batchInsert方法里用批量插入一次性写入16条而不是循环单条插入。6.2 三个校验防止周计划数据自欺欺人生成了week_plan不代表它是对的。上线前花五分钟做三个校验能过滤掉九成数据问题。第一总和校验。SELECT SUM(plan_hours) FROM week_plan WHERE syllabus_id 1;结果必须等于大纲总学时64。不等说明生成时漏了章节或者学时分配算错。第二单周学时上限校验。SELECT MAX(plan_hours) FROM week_plan WHERE syllabus_id 1;超过6就要警惕。高校按每周6学时排课超过说明跨周跨度算错或者均摊逻辑有bug。第三进度对比校验这是最有价值的一个直接把进度记录和周计划拉到一张表里看差距SELECT p.week_no, w.plan_content AS 应讲内容, GROUP_CONCAT(p.actual_content) AS 已讲内容, SUM(p.actual_hours) AS 实际学时 FROM teaching_progress p LEFT JOIN week_plan w ON w.syllabus_id p.syllabus_id AND w.week_no p.week_no WHERE p.syllabus_id 1 GROUP BY p.week_no, w.plan_content ORDER BY p.week_no;这个SQL跑出来的结果比任何报表都直观。哪一周应讲内容在第6周而实际还停在第4周一眼就能看出来。这个示例数据里第3周实际学时3对应的week_plan计划学时4差值-1预警线设成-10%的话刚好能触发。我做这类管理系统养成的习惯是先生成周计划再做三个校验全部通过才开始写报表页面。数据基线一旦错了后面所有功能都是建立在错误地基上的。现在回头看这类系统真正考验人的不是增删改查而是“口径一致”四个字——偏差公式、版本策略、周计划生成这三处只要有一处含糊最终都会变成报表数据对不上的血泪经验。希望这套从业务闭环到周计划校验的拆解能帮你在做教学进度管理时少走一段弯路。本文还有配套的精品资源点击获取 
长河君 · 2026/10/31 6:00:36 · 阅读 1.2k Java教学进度在线管理系统：从需求分析到周计划偏差预警实现
简介这是一份基于JAVA的教学进度在线管理系统/教学大纲在线管理系统的毕业设计级完整项目包含源代码、数据库及配套文档适合高校计算机相关专业学生、Java初学者用于毕业设计、课程设计或项目实践参考。压缩包共760个文件容量约42.73MB涵盖Java源码、JSP页面、HTML/CSS/JS前端资源、SQL数据库脚本、jar依赖包以及docx/pdf/xls等多类型文档目录结构清晰便于按模块检索。目前已有313人学习下载。资源内不仅有可直接运行的代码还包含从需求分析、概要设计、详细设计到项目总结的全套文档能够帮助读者系统理解在线管理系统的完整开发流程同时覆盖教学进度管理、教学大纲管理等典型功能模块对掌握Java Web项目开发具有相当参考价值且文档与代码配套便于在实践中边读边验证。1. 这个JAVA教学进度在线管理系统解决的是“进度失控”而不是“排课”“教学进度在线管理系统”这个名字听起来像大学课设仓库里又一个增删改查。但真去教研室待过两周就明白进度管理从来不是排课——大纲是PDF、进度是Excel、老师月底填一次交给主任时两份表对不上是常态。这套基于JAVA的系统核心价值是把教学大纲拆成细目、把细目折成周计划、把实际进度填回去算偏差让“讲到哪了”从人脑记忆变成一条随时可查的预警记录。项目自带的源代码、数据库和需求分析、概要设计、详细设计及项目总结文档说白了就是一套能直接跑的完整模板。适合三类人照着做做毕业设计或课程设计的在校生、接管理系统外包的开发者、想低成本给教研室做内部工具的运维。2. 从需求分析抽业务闭环三个角色、一条主线、五张核心表把这套系统的需求分析文档摊开前几十页的用例图、活动图和原型图本质上只回答三个问题谁来用、走什么流程、数据怎么存。这三个答案立住了剩下的大多数页面都是注释。2.1 角色边界管理员、教师、教研室主任各管一段这类系统最常见的角色划分是三个不多不少。管理员管基础数据教师管大纲和进度教研室主任看结果。管理员负责课程、账号和大纲的发布/归档操作不碰教学业务这是避免权限纠缠的常见做法。教师承担两类核心工作维护自己任教课程的教学大纲细目以及按周填报实际讲授内容。教研室主任不直接改数据但拥有大纲审核和进度报表查看权限。权限实现不需要一上来就上Spring Security。这套体量下一个拦截器拿到登录用户的role字段做判断就够了密码字段单独处理角色字段用ADMIN/TEACHER/DEAN三个枚举值存。等系统真需要细粒度权限时再迁移初期把角色边界写在需求分析文档里比写在代码里更值钱。2.2 核心业务闭环大纲制定、周计划、进度填报、偏差预警整个系统的业务主线是一条四个环节的闭环。第一环是大纲制定管理员建课程教师为课程创建大纲版本并把大纲拆成细目每个细目包含章节号、章节名、计划学时、起始周和结束周。第二环是周计划生成根据细目的start_week和end_week把每章学时摊到对应周次生成一张“第N周应该讲什么”的计划表。第三环是进度填报教师每周填写实际讲授内容、实际学时数据落到进度记录表。第四环是偏差预警系统对比计划学时和实际学时的累计比例偏差低于阈值时提醒教研室主任。第一环和第四环是这套系统和普通Excel台账的本质区别。没有周计划生成系统只是把Excel搬到网页上有了偏差预警它才配叫“管理”系统。需求分析文档里最该画清楚的也是这个闭环而不是登录注册那套通用流程。2.3 数据库模型五张核心表如何串起大纲与进度数据库设计直接决定这套系统能活多久。最小可用模型是五张表它们的职责分配如下表名职责关键字段sys_user系统用户username、password、rolecourse课程基础信息course_code、total_hours、creditsyllabus教学大纲主表course_id、version、statussyllabus_item大纲细目chapter_no、planned_hours、start_week、end_weekteaching_progress教学进度填报week_no、actual_content、actual_hours核心建表语句如下字段类型和约束直接按这套写后面踩坑最少。-- 用户表三种角色用 role 字段区分 CREATE TABLE sys_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, real_name VARCHAR(50), role VARCHAR(20) NOT NULL COMMENT ADMIN/TEACHER/DEAN, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 课程表一门课程只有一条基础信息 CREATE TABLE course ( id INT PRIMARY KEY AUTO_INCREMENT, course_name VARCHAR(100) NOT NULL, course_code VARCHAR(30) NOT NULL UNIQUE, total_hours INT NOT NULL, credit DECIMAL(3,1) NOT NULL, dept_name VARCHAR(50), status TINYINT DEFAULT 1 COMMENT 1启用 0停用 ); -- 教学大纲主表同一门课允许多个版本并存 CREATE TABLE syllabus ( id INT PRIMARY KEY AUTO_INCREMENT, course_id INT NOT NULL, version VARCHAR(20) NOT NULL COMMENT 如2025春-01, total_hours INT NOT NULL, status TINYINT DEFAULT 0 COMMENT 0草稿 1已生效 2已废弃, publish_date DATE, FOREIGN KEY (course_id) REFERENCES course(id) ); -- 大纲细目表每一条就是一个教学单元 CREATE TABLE syllabus_item ( id INT PRIMARY KEY AUTO_INCREMENT, syllabus_id INT NOT NULL, chapter_no VARCHAR(20) NOT NULL, chapter_name VARCHAR(100) NOT NULL, content_desc VARCHAR(500), planned_hours INT NOT NULL, start_week INT, end_week INT, FOREIGN KEY (syllabus_id) REFERENCES syllabus(id) ); -- 教学进度记录表老师每次填报一条 CREATE TABLE teaching_progress ( id INT PRIMARY KEY AUTO_INCREMENT, course_id INT NOT NULL, syllabus_id INT NOT NULL, teacher_id INT NOT NULL, week_no INT NOT NULL, actual_content VARCHAR(500), actual_hours INT NOT NULL, fill_date DATE NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (course_id) REFERENCES course(id), FOREIGN KEY (syllabus_id) REFERENCES syllabus(id), FOREIGN KEY (teacher_id) REFERENCES sys_user(id) );这里有几个设计细节值得说。syllabus主表单独带version字段是为了大纲改版时能同时存在“旧版已归档”和“新版草稿”两条记录进度记录绑定的是syllabus_id而不是syllabus_item_id这样旧数据不会因为细目调整而串味。syllabus_item里的start_week和end_week很关键它是后面生成周计划、计算计划进度的依据缺了这两个字段偏差计算就无从谈起。teaching_progress里冗余了course_id虽然能从syllabus_id反查但进度报表最频繁的查询就是按课程、按周次汇总冗余字段能少一次join。planned_hours用INT不用DECIMAL因为排课学时的最小单位是1节课用到0.5学时的情况在高校大纲里几乎不存在用INT反而避免浮点精度问题。password字段预留100长度因为登录校验从MD5换成BCrypt时密文长度会从32变到60字段不够就得改表。外键在MySQL里建不建都行实际开发我一般保留物理外键约束但初始化测试数据时会把外键检查临时关掉否则按顺序插入数据很痛苦。3. 用Spring Boot MyBatis跑通进度填报核心代码与关键配置技术栈选型上这类管理系统最常见的组合是把需求分析里的流程翻译成Spring Boot MyBatis MySQL。Spring Boot把Web层、事务、Jackson序列化都集成好了MyBatis让SQL保持可控不引入JPA那套实体关系映射的复杂度。3.1 项目骨架pom.xml依赖与版本匹配依赖清单并不长但版本是个容易翻车的点。以Spring Boot 2.7.x为例MyBatis官方starter要用2.3.x不要随手拖一个3.x版本否则启动时直接报找不到自动配置类。MySQL驱动用Boot默认管理的mysql-connector-j版本跟Boot走不用手写。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.2/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies版本匹配这事没什么玄学就一条规则Spring Boot 2.7配MyBatis starter 2.3.xSpring Boot 3.x配MyBatis starter 3.x。如果项目是从老代码里扒的骨架先看Boot版本再定starter版本比报错后再查更快。Lombok属于可选依赖团队不习惯就删掉手写getter/setter也不影响什么。3.2 核心Service填报、累计、偏差计算的实现进度偏差是整个系统最核心的计算逻辑。口径要统一我一般这么定义计划进度等于截至当前周累计计划学时除以大纲总学时实际进度等于累计实际填报学时除以大纲总学时偏差等于实际进度减计划进度。偏差为负表示落后。下面的ProgressService把偏差计算封装成一个方法传入课程ID和当前周次返回计划比例、实际比例和差值。Service public class ProgressService { private final SyllabusMapper syllabusMapper; private final SyllabusItemMapper itemMapper; private final TeachingProgressMapper progressMapper; // 构造器注入避免 Autowired 字段注入带来的循环依赖隐患 public ProgressService(SyllabusMapper syllabusMapper, SyllabusItemMapper itemMapper, TeachingProgressMapper progressMapper) { this.syllabusMapper syllabusMapper; this.itemMapper itemMapper; this.progressMapper progressMapper; } /** * 计算某门课截至指定周次的进度偏差 * 偏差 实际累计学时/大纲总学时 - 计划累计学时/大纲总学时 */ public ProgressDeviation calculateDeviation(Integer courseId, Integer weekNo) { // 1. 取当前生效中的大纲版本 Syllabus syllabus syllabusMapper.findEffectiveByCourseId(courseId); if (syllabus null) { throw new BusinessException(该课程没有生效中的教学大纲); } // 2. 取出该大纲下的所有细目累加得到总学时 ListSyllabusItem items itemMapper.findBySyllabusId(syllabus.getId()); int totalHours items.stream() .mapToInt(SyllabusItem::getPlannedHours) .sum(); // 3. 计划学时只统计起始周小于等于当前周的细目 int plannedHours items.stream() .filter(item - item.getStartWeek() weekNo) .mapToInt(SyllabusItem::getPlannedHours) .sum(); // 4. 实际学时查询截至当前周的累计填报学时 Integer actualHours progressMapper.sumActualHours(courseId, weekNo); int actual actualHours null ? 0 : actualHours; // 5. 换算成比例注意总学时为0的边界 double plannedRatio totalHours 0 ? 0.0 : (double) plannedHours / totalHours; double actualRatio totalHours 0 ? 0.0 : (double) actual / totalHours; return new ProgressDeviation(plannedRatio, actualRatio, actualRatio - plannedRatio); } }这里两个细节要注意。第4步的sumActualHours在Mapper里要写成累计查询SQL大致是SELECT COALESCE(SUM(actual_hours), 0) FROM teaching_progress WHERE course_id #{courseId} AND week_no #{weekNo}只统计当前周之前的填报记录不是只取本周数据。第5步里大纲总学时为0的概率极低但方法一旦被异常数据触发就是除零异常所以防御性判断不能省。进度填报的Service更简单本质就是一次INSERT加一次事务控制。教师在页面上选择课程、周次填写实际内容和学时后端校验同一课程同一周次是否已填报过避免重复提交。常见的做法是在teaching_progress表上加一个UNIQUE KEY uk_course_week (course_id, week_no)数据库层兜底比应用层判断可靠得多。3.3 application.yml四个必调的MyBatis与数据源参数配置文件是这套系统里除了pom之外第二处容易翻车的地方。以MySQL 8.0为例驱动类名、时区、公钥获取、驼峰映射四个参数必须显式写清楚缺一个都可能在启动或第一次查询时爆出莫名其妙的问题。spring: datasource: url: jdbc:mysql://localhost:3306/edu_progress?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true jdbc-type-for-null: NULL log-impl: org.apache.ibatis.logging.stdout.StdOutImpl server: port: 8080逐个说明这四个参数的意义。serverTimezoneAsia/Shanghai在MySQL 8.0下不写必报时区错误allowPublicKeyRetrievaltrue解决MySQL 8默认caching_sha2_password认证下首次连接的公钥获取问题useSSLfalse省去SSL握手开销本地开发调试很有必要。map-underscore-to-camel-case是MyBatis的驼峰映射开关开启后数据库的teacher_id自动映射到Java属性的teacherId省掉一堆Results注解。jdbc-type-for-null设成NULL避免插入空字段时MyBatis报JDBC类型异常。log-impl输出SQL到控制台调试阶段必须开上线前再关。提示如果开发机装的是MySQL 5.7driver-class-name要写com.mysql.jdbc.Driver连接串里也可以去掉allowPublicKeyRetrieval保留其他三个参数不影响运行。4. 数据库脚本与初始化数据让系统第一次启动就有东西可看拿到源代码和数据库文件之后最尴尬的事是启动项目发现库里是空的。所以数据库脚本必须包含两样东西完整的表结构脚本以及一套能演示业务闭环的初始化数据。这套脚本写好了系统第一次启动就能看到课程、大纲、细目、进度记录和偏差报表。4.1 补充索引与week_plan辅助表第2章五张核心表只解决“能存”还需要补索引和辅助表解决“查得快”和“周计划可对比”。进度表最频繁的查询是“某课程某周次的记录汇总”和“某教师的填报历史”这两个查询条件必须建索引。大纲细目按syllabus_id查询是常态也要索引。同时新建一张week_plan周计划表把大纲细目折算成按周次排列的计划基线。CREATE DATABASE IF NOT EXISTS edu_progress DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE edu_progress; -- 进度表高频查询索引 ALTER TABLE teaching_progress ADD INDEX idx_progress_course_week (course_id, week_no); ALTER TABLE teaching_progress ADD INDEX idx_progress_teacher (teacher_id); ALTER TABLE syllabus_item ADD INDEX idx_item_syllabus (syllabus_id); -- 周计划表按大纲周次唯一避免重复生成 CREATE TABLE week_plan ( id INT PRIMARY KEY AUTO_INCREMENT, syllabus_id INT NOT NULL, week_no INT NOT NULL, plan_content VARCHAR(500) COMMENT 本周应讲授内容摘要, plan_hours INT NOT NULL COMMENT 本周计划学时, UNIQUE KEY uk_syllabus_week (syllabus_id, week_no), KEY idx_plan_week (week_no) );索引不是越多越好。teaching_progress的联合索引(course_id, week_no)覆盖了偏差查询和防重复校验两个场景单查week_no的场景交给它也能走索引前缀规则所以不需要再单独建week_no索引。week_plan的UNIQUE KEY用(syllabus_id, week_no)因为同一份大纲下每周只能有一条计划这个约束同时防止生成脚本重复执行时产生脏数据。4.2 初始化数据账号、课程、大纲细目与样例进度初始化数据的核心目标是让系统能跑通完整演示。账号准备三个角色各一个课程准备一门大纲准备一个生效版本细目覆盖16周的教学安排进度记录准备三条其中故意留一条偏差记录这样打开报表就能看到预警效果。密码统一用123456的MD5值。-- 账号初始化密码均为 123456 的 MD5生产环境务必换 BCrypt INSERT INTO sys_user (username, password, real_name, role) VALUES (admin, e10adc3949ba59abbe56e057f20f883e, 系统管理员, ADMIN), (teacher01, e10adc3949ba59abbe56e057f20f883e, 张老师, TEACHER), (dean01, e10adc3949ba59abbe56e057f20f883e, 李主任, DEAN); INSERT INTO course (course_name, course_code, total_hours, credit, dept_name) VALUES (数据结构, CS201, 64, 4.0, 计算机系); INSERT INTO syllabus (course_id, version, total_hours, status, publish_date) VALUES (1, 2025春-01, 64, 1, 2025-02-20); -- 大纲细目8个章节总学时必须和 syllabus.total_hours 一致 INSERT INTO syllabus_item (syllabus_id, chapter_no, chapter_name, content_desc, planned_hours, start_week, end_week) VALUES (1, 01, 绪论, 算法复杂度、数据结构概念, 4, 1, 1), (1, 02, 线性表, 顺序表与链表, 8, 2, 3), (1, 03, 栈和队列, 栈、队列、表达式求值, 8, 4, 5), (1, 04, 树, 二叉树、遍历、线索树, 12, 6, 8), (1, 05, 图, 图的存储、遍历、最小生成树, 12, 9, 11), (1, 06, 查找, 顺序查找、二分查找、哈希, 8, 12, 13), (1, 07, 排序, 插入、交换、选择排序, 8, 14, 15), (1, 08, 复习, 总复习与习题, 4, 16, 16); -- 进度样例前两周正常第三周少填1学时用于触发偏差预警 INSERT INTO teaching_progress (course_id, syllabus_id, teacher_id, week_no, actual_content, actual_hours, fill_date) VALUES (1, 1, 2, 1, 讲了绪论重点讲时间复杂度, 4, 2025-02-28), (1, 1, 2, 2, 线性表顺序存储数组扩容, 4, 2025-03-07), (1, 1, 2, 3, 链表操作拖了一节课, 3, 2025-03-14);这段脚本里最容易被忽略的约束是syllabus主表的total_hours必须等于syllabus_item里sum(planned_hours)。我见过好几次初始化后偏差报表一片飘红最后发现是大纲总学时64、细目累加60两个数不一致导致计算比例全线失真。画个简单校验SELECT SUM(planned_hours) FROM syllabus_item WHERE syllabus_id 1;结果不是64就回去改数据。注意进度表的第三条记录故意让实际学时为3而按计划第3周属于“线性表”章节的第2周累计计划学时是12累计实际是11偏差为负报表页就能直接看到预警效果。这套数据是照着“演示需要”设计的不是随手造几条。4.3 配套文档各写什么四份文档怎么分工标题里提到的需求分析、概要设计、详细设计、项目总结四份文档很多人只是为凑数写的其实它们各有明确读者。需求分析给指导老师或甲方看核心是用例、业务流程和数据字典概要设计给开发组内评审看核心是模块划分、接口列表和数据库ER图详细设计给编码人员看核心是类图、时序图和核心方法伪代码项目总结给答辩或验收看核心是方案对比、测试结果和问题复盘。文档读者核心内容篇幅参考需求分析老师/甲方用例图、业务流程图、数据字典、非功能需求30-50页概要设计开发组模块划分、接口列表、数据库ER图、部署视图20-30页详细设计编码人员类图、时序图、核心方法伪代码、异常约定30-50页项目总结答辩/验收方案对比、测试报告、问题复盘、后续计划10-20页我的习惯是先把需求分析里的数据字典写到和建表SQL逐字一致再动手建表。表结构改了第一件事改数据字典。这套系统里“偏差计算公式”这种关键口径必须同时出现在需求分析和代码注释里否则答辩时被问到“为什么第三周偏差是负数”答不上来就尴尬了。如果时间紧需求分析不能省详细设计可以退化成核心方法上的注释但数据字典必须完整。5. 常见坑与排查教学进度系统最容易翻车的五个场景5.1 查询结果全是null驼峰映射没开现象接口跑通了但返回的JSON里teacherId、createTime这类多词字段全是null单字段的id、username却正常。翻车点很隐蔽因为SQL没问题、数据没问题就是映射不上。原因数据库字段是snake_caseteacher_idJava属性是camelCaseteacherIdMyBatis默认不自动映射。代码里没写Results注解也没开全局驼峰开关。解决在application.yml里加一行map-underscore-to-camel-case: true就好了。这个配置对XML和注解SQL都生效加了之后重启所有字段一次性恢复。排查时先看控制台SQL输出确认SQL查出来的列名再对照Java属性名两者不一致基本就是映射问题。5.2 MySQL 8.0连不上不是端口被封是连接串参数缺失现象项目启动报Communications link failure或者报Public Key Retrieval is not allowed。有同事会怀疑端口没放行、防火墙拦截折腾半天。原因MySQL 8.0默认认证插件是caching_sha2_passwordJDBC驱动首次连接需要向服务器请求公钥连接串里没有allowPublicKeyRetrievaltrue就拒绝另外serverTimezone不写的话驱动和服务器时区不一致直接抛异常。解决连接串补齐四个参数serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue驱动类名确认是com.mysql.cj.jdbc.Driver。注意MySQL 5.7和8.0的驱动类名不一样老代码里抄来的com.mysql.jdbc.Driver在8.0下也能跑但会有警告最好改成cj版本。5.3 大纲改版后历史进度对不上现象第一学期的大纲里“树”在第6-8周第二学期改成第5-7周。改完细目之后历史进度记录里原本属于“树”章节的填报记录章节名全变了报表数据直接乱掉。原因teaching_progress只关联了syllabus_item_id而syllabus_item是原地修改的。进度记录跟着指向了被改过的新内容历史快照丢了。解决这是典型的“改数据而不是加版本”问题。大纲改版应该新建一条syllabus记录status置为草稿审核后发布旧的置为已归档。进度表里冗余保存actual_content文本快照即使章节名后来变了历史记录里仍然保留当时的填写内容。永远不要UPDATE已经生效的大纲细目。5.4 偏差口径不统一三个人算出三个偏差现象同一门课老师说自己没落后教研室主任说落后了开发人员说数据没问题。最后发现三个人用的口径不一样一个按章节算一个按周次算一个按学时算。原因需求分析文档里只写了“统计教学进度偏差”没定义公式。代码实现时不同人按自己理解写报表展示层又没标注口径。解决把公式钉死在文档和代码里。建议统一为偏差 累计实际学时/大纲总学时 - 累计计划学时/大纲总学时。累计计划学时按“起始周 当前周”的细目学时求和这个方法在第3章已经给出实现。遇到这种问题先改需求分析文档里的定义再改代码最后在报表页面上把公式展示出来三方对不上时不用扯皮。5.5 周计划重复生成导致数据翻倍现象week_plan表里同一syllabus_idweek_no出现两条记录进度对比时数据翻倍偏差报表乱成一团。原因生成周计划的方法没有做幂等处理页面重复点击提交或者定时任务和手动触发同时跑了一次。解决两种手段叠用。数据库层靠week_plan表上的UNIQUE KEY (syllabus_id, week_no)兜底重复插入直接报错应用层在生成方法前先执行一次DELETE FROM week_plan WHERE syllabus_id ?再批量插入新数据。删除后插入放在一个事务里避免删了没插进去的中间状态。6. 把大纲细目折成周计划自动生成week_plan并验证进度的三个校验6.1 生成算法把章节学时按周次摊开第2章设计的syllabus_item带start_week和end_week现在把它变成按周分配的week_plan。算法的核心是均摊章节跨几周计划学时就分摊到这几周里余数补到最后一周。这样“第8周应该讲到树”就能从数据里直接算出来而不是靠人肉翻大纲。public void generateWeekPlan(Integer syllabusId) { ListSyllabusItem items itemMapper.findBySyllabusId(syllabusId); MapInteger, Integer weekHours new HashMap(); MapInteger, String weekContent new TreeMap(); for (SyllabusItem item : items) { int start item.getStartWeek(); int end item.getEndWeek(); int span end - start 1; int base item.getPlannedHours() / span; int remainder item.getPlannedHours() % span; for (int week start; week end; week) { int hours base (week - start remainder ? 1 : 0); weekHours.merge(week, hours, Integer::sum); // 每周只记录第一个新章节名避免周计划内容过长 weekContent.computeIfAbsent(week, k - item.getChapterName()); } } weekPlanMapper.deleteBySyllabusId(syllabusId); weekPlanMapper.batchInsert(syllabusId, weekHours, weekContent); }这段代码有两个细节值得说。remainder的分配方式是“前几周各多1学时”这样最后一周的学时不会突然变大更贴近老师实际排课节奏。weekContent用computeIfAbsent只记录每周第一个出现的章节名因为一周可能跨两个章节比如第3周既结束线性表又开始栈只展示一个名字避免界面拥挤。batchInsert方法里用批量插入一次性写入16条而不是循环单条插入。6.2 三个校验防止周计划数据自欺欺人生成了week_plan不代表它是对的。上线前花五分钟做三个校验能过滤掉九成数据问题。第一总和校验。SELECT SUM(plan_hours) FROM week_plan WHERE syllabus_id 1;结果必须等于大纲总学时64。不等说明生成时漏了章节或者学时分配算错。第二单周学时上限校验。SELECT MAX(plan_hours) FROM week_plan WHERE syllabus_id 1;超过6就要警惕。高校按每周6学时排课超过说明跨周跨度算错或者均摊逻辑有bug。第三进度对比校验这是最有价值的一个直接把进度记录和周计划拉到一张表里看差距SELECT p.week_no, w.plan_content AS 应讲内容, GROUP_CONCAT(p.actual_content) AS 已讲内容, SUM(p.actual_hours) AS 实际学时 FROM teaching_progress p LEFT JOIN week_plan w ON w.syllabus_id p.syllabus_id AND w.week_no p.week_no WHERE p.syllabus_id 1 GROUP BY p.week_no, w.plan_content ORDER BY p.week_no;这个SQL跑出来的结果比任何报表都直观。哪一周应讲内容在第6周而实际还停在第4周一眼就能看出来。这个示例数据里第3周实际学时3对应的week_plan计划学时4差值-1预警线设成-10%的话刚好能触发。我做这类管理系统养成的习惯是先生成周计划再做三个校验全部通过才开始写报表页面。数据基线一旦错了后面所有功能都是建立在错误地基上的。现在回头看这类系统真正考验人的不是增删改查而是“口径一致”四个字——偏差公式、版本策略、周计划生成这三处只要有一处含糊最终都会变成报表数据对不上的血泪经验。希望这套从业务闭环到周计划校验的拆解能帮你在做教学进度管理时少走一段弯路。本文还有配套的精品资源点击获取