JavaWeb体测管理系统源码实战：Spring Boot+MySQL评分算法设计

简介：一份面向高校学生和课程设计者的体测管理系统源码包，涵盖登录注册、成绩录入、体重/50米/跳远/1000米等常见体测项目，并配有项目说明与数据表，可直接用于期末大作业或毕业设计参考。包内共37个文件，以17个HTML页面、4个CSS样式、3个JS脚本为核心：HTML搭建基础界面，CSS定制视觉样式，JS实现表单校验与动态交互；另含字体、图片及配置文件，构成完整的前端展示与基础交互逻辑。压缩包内还包含学生端与教师端页面，登录、录入、预览等模块相互独立，便于按需查看。整体约13.47MB，目录结构清晰，便于按页面模块学习或二次修改。已有560人学习下载，适合想快速搭建体测管理原型或理解Web前端信息组织方式的初学者。通过源码可掌握多页面站点布局、图标字体引用、测试数据组织等技巧，项目说明还能帮助梳理需求与数据库设计思路，减少从零开始的摸索时间。

1. 体测管理系统到底解决什么：别再让体育老师期末拿 Excel 硬扛

期末最后一周，体育教研室要汇总几百号学生的体测数据，按最新版《国家学生体质健康标准》算出单项分、加权总分和评级，再拆成可打印的成绩单。我的体测管理系统源码包，本质就是一套能直接跑起来的 Web 项目：源码负责页面、接口、权限和评分逻辑，项目说明帮你理清部署步骤，数据表文件把 MySQL 建表脚本和初始数据一次备齐。它面向三类人：计算机专业拿来做毕业设计或课程设计的学生，想把体测工作从 Excel 里解放出来的体育信息化老师，以及想通过读别人完整项目搞懂 JavaWeb 数据流转的初学者。对第一类人，这套包的分数取决于你讲不讲得清表结构和评分算法；对后两类人，它会省掉你从头搭环境、造轮子的两周时间。

2. 拿到源码包后先理清架构：五大核心模块与技术栈选型

解压之后先别急着跑，先看目录和文档。体测管理系统这类毕设向项目，代码量不算大，但功能闭环必须完整，否则答辩或实际使用时会被追问到卡壳。包内通常能看到 src 主代码、sql 数据表脚本、README 或部署说明，这就是全部交付物。我拿到任何这类源码包，第一步永远是打开项目说明，搞清楚它声称的功能清单，再去代码里逐项核对。你要交付的不只是“能跑”，而是“跑起来之后用户愿意用”，所以架构上必须覆盖从学生数据录入到成绩输出打印的完整链路。

2.1 五大核心功能模块：从登录权限到统计报表的完整闭环

常见的体测管理系统把功能切成五块。第一块是用户与权限管理，角色一般分为管理员、教师、学生三种。管理员管账号和基础配置，教师录成绩、看报表，学生查自己的成绩和评级。实现上多是用一张用户表加一个角色字段，不走复杂的 RBAC 权限模型，够用且好解释。第二块是学生信息管理，做学号、姓名、性别、学院、班级等基本信息的增删改查，还要有 Excel 批量导入导出，不然体育老师对着几百人一个一个录入会当场崩溃。第三块是体测项目管理，因为不是所有学院同一年测的项目都一样，项目要可以配置。常见项目就那八项：身高体重、肺活量、50 米跑、立定跳远、坐位体前屈、引体向上（男）/仰卧起坐（女）、1000 米（男）/800 米（女）。第四块是成绩录入与自动评分，支持按班级批量录入原始成绩，系统根据性别和项目自动换算单项得分，这是整个系统的核心价值点。第五块是统计分析，按班级、年级、学院汇总平均分、及格率、优良率，输出柱状图和打印报表。

各个模块之间的数据流转也要在动手开发前想清楚：用户登录后进入不同的操作页面，学生信息是成绩录入的基础，项目配置决定成绩录入表单的字段结构，成绩表关联学生和项目之后才能算分，统计报表又依赖成绩明细数据。很多初学者喜欢先把页面做出来再补表结构，结果做到统计报表时发现成绩表里没有班级字段，只能临时改表。正确顺序是先设计数据表，再写评分服务，最后才做页面。模块边界上还有一个常见误区：不要在这个项目里硬塞“对接教务系统自动同步学生名单”这种功能，XML 接口、数据中台的依赖会让整个项目失去重点，手工导入 Excel 在这个场景就是最稳的方案。

2.2 技术栈怎么选：SSM/JSP 与 Spring Boot 的取舍和理由

体测管理系统这类项目的技术栈高度趋同，主流是两大派别。一派是 SSM（Spring + SpringMVC + MyBatis）加 JSP，页面用 JSTL 标签和服务端渲染；另一派是 Spring Boot 加 MyBatis-Plus 加 Thymeleaf，页面模板在服务端渲染，配合 Bootstrap 或 layui 做界面。两者都能跑，但选型直接关系到你部署和改代码的体验。下面的对比来自我维护这类项目的实际感受：

对比项	SSM + JSP	Spring Boot + MyBatis-Plus
上手门槛	需要手动配 Spring 和 MyBatis 的 XML	自动装配，起步快
部署方式	打 war 包丢进 Tomcat	打 jar 直接 java -jar 跑
适合人群	课程还在教 SSM 的在校生	自学为主、想快速落地的人
排障成本	配置多，报错经常指向 XML	排查相对集中，日志更友好
与标题匹配度	老项目喜欢 JSP，改起来费劲	现在的新源码包主流是 Spring Boot

我一般会优先选 Spring Boot 2.x 加 MyBatis-Plus，原因很直接：它把数据访问层的样板代码省掉了，分页插件也内置，写体测成绩查询这种带条件的列表会快很多。依赖文件里核心的依赖大致是这样的：

<dependencies> <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.4.2</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> </dependencies>

MyBatis-Plus 3.4.2 这个版本在 JDK 8 下特别稳，配合 Spring Boot 2.5.x 不需要额外处理版本冲突。mysql-connector-java 的版本由 Spring Boot 父工程统一管理，不要手动写死版本号，否则容易和数据库服务端协议不匹配。如果你拿到的是 SSM 项目，也别急着重构，把注意力放在业务代码和数据表上，框架只要能稳定运行就保住核心价值。

3. 数据表设计是系统的地基：核心建表语句与字段边界

体测管理系统的数据表通常控制在六到八张，核心四张是学生表、体测成绩表、体测项目表、评分标准表，再加用户表和辅助的业务表。数据表是整个系统的命脉，因为在评分标准、成绩换算这些场景里，业务逻辑其实是跟着表结构走的。我曾见过一个项目把成绩和标准全部塞进一张大宽表，结果每次版本更新改标准都要动十几行字段，得不偿失。下面两张核心表的设计值得直接抄作业。

3.1 学生信息表与体测成绩表：外键、唯一索引与数据类型陷阱

学生信息表是最基础的数据源，学号必须唯一，这是批量导入 Excel 时去重的关键。性别字段用 TINYINT 存 1 和 2，而不是用 CHAR 存“男”“女”，原因有两个：一是程序判断性别决定引体向上还是仰卧起坐时，数字比较比字符串判断更稳妥；二是标准表里的性别条件也要用数字匹配。以下是常用的建表语句：

CREATE TABLE student ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_no VARCHAR(20) NOT NULL UNIQUE COMMENT '学号', name VARCHAR(50) NOT NULL COMMENT '姓名', gender TINYINT NOT NULL COMMENT '性别 1=男 2=女', birth_date DATE COMMENT '出生日期', college VARCHAR(100) COMMENT '学院', major VARCHAR(100) COMMENT '专业', class_name VARCHAR(100) COMMENT '班级', phone VARCHAR(20) COMMENT '联系电话', created_time DATETIME DEFAULT CURRENT_TIMESTAMP, updated_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生信息表';

student_no 上的 UNIQUE 索引有两个作用：第一是防止重复导入同一学号；第二是给按学号关联查询提供索引加速。id 用 BIGINT 自增而不是学号做主键，是因为学号属于业务字段，未来可能因学制变化重新编码，不应该作为关联外键。字符集用 utf8mb4 而非 utf8，是因为部分学生姓名含生僻字，utf8 存不下，在 MySQL 5.7 及以上版本直接统一 utf8mb4 是唯一正确选择。

体测成绩表是评分逻辑的落点，设计上有个容易被忽略的点：原始成绩 raw_result 用 VARCHAR 存储，而不是用 DECIMAL 或 INT。因为八个项目的原始成绩类型完全不一样：50 米跑存“8.1”，立定跳远存“245”，肺活量存“3200”，800 米存“3:25”，身高体重甚至要支持“170.5/65.2”。强行统一成数值类型反而别扭。成绩表的建表语句：

CREATE TABLE physical_test ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL COMMENT '学生ID', test_year YEAR NOT NULL COMMENT '测试年份', item_id BIGINT NOT NULL COMMENT '体测项目ID', raw_result VARCHAR(50) NOT NULL COMMENT '原始成绩，格式随项目而定', standard_score DECIMAL(5,2) NOT NULL COMMENT '单项标准分', test_date DATE COMMENT '测试日期', operator_id BIGINT COMMENT '录入人ID', created_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_student_item (student_id, test_year, item_id), KEY idx_test_year (test_year), CONSTRAINT fk_test_student FOREIGN KEY (student_id) REFERENCES student(id), CONSTRAINT fk_test_item FOREIGN KEY (item_id) REFERENCES test_project(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='体测成绩明细表';

uk_student_item 这个唯一索引是整套系统防止数据错乱的核心：同一个学生同一年同一个项目只能有一条成绩。如果没有它，Excel 重复导入一次就会出现两条记录，总分统计直接翻倍。这里还要注意，standard_score 用 DECIMAL(5,2) 而不是 DOUBLE，是为了避免浮点数累加时出现 87.9999 这类精度问题，Java 侧对应使用 BigDecimal 处理。

3.2 评分标准表：区间匹配模型让所有换算都在 SQL 里完成

体测评分逻辑如果用代码写 if else，会写得你想骂人。男生一千米和女生八百米的评分标准不同，BMI 男女标准不同，肺活量是数值越大分越高，跑步是时间越小分越高，坐位体前屈又是数值越大越好。这四种规则如果散落在代码里，每次改标准都要改代码重新部署。评分标准表就是来解决这个问题的：把规则数据化，让评分算法变成一条通用 SQL。

我的做法是建一张 score_standard 标准表，每个项目每个性别定义多行区间，每行对应一个得分档位：

CREATE TABLE score_standard ( id BIGINT PRIMARY KEY AUTO_INCREMENT, item_id BIGINT NOT NULL COMMENT '项目ID', gender TINYINT NOT NULL COMMENT '性别 1=男 2=女', score_type TINYINT NOT NULL COMMENT '评分方向 1=越小越好 2=越大越好', min_value DECIMAL(6,2) COMMENT '区间下限(含)', max_value DECIMAL(6,2) COMMENT '区间上限(不含)', standard_score DECIMAL(5,2) NOT NULL COMMENT '该区间对应的标准分', UNIQUE KEY uk_item_gender_range (item_id, gender, min_value, max_value) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='体测评分标准表';

score_type 字段是整个设计的点睛之笔。跑步类项目属于“越小越好”，查询时成绩落在 min_value 和 max_value 区间内，取对应的 standard_score；肺活量和立定跳远属于“越大越好”，方向相反。有了这个字段，通用查询逻辑就不用区分项目类型了。这里必须注意一个边界规则：区间设计为左闭右开，即包含下限、不包含上限。例如 50 米跑男生 8.0 秒到 8.1 秒（不含 8.1）是 95 分。如果两行区间一个写 8.0-8.1，另一个写 8.1-8.5，成绩恰好等于 8.1 时会同时命中两行，查询就报错。把区间设计成左闭右开之后，查询条件统一用 min_value <= 成绩 AND 成绩 < max_value，成绩 8.1 只会命中第二行。

体测项目表本身相对简单，核心字段是项目名称、项目编码、适用性别和排序号。项目编码建议用英文标识，比如 height_weight、vital_capacity、run_50m、long_jump、sit_forward、pull_up、sit_up、run_800m、run_1000m，这样代码里判断项目类型时用编码而不是用中文字段名，避免编码不一致带来的坑。

4. 把体测评分标准写成代码：单项换算、总分加权与评级

表结构设计好之后，最核心的业务代码就是评分算法。评分分为两步：第一步把原始成绩换算成单项标准分，第二步把所有单项分加权求和并评级。这两步的代码往往只有几十行，但却是整个项目里最容易翻车的部分。我在第 3 章设计的 score_standard 表，就是为这一步服务的。

4.1 单项成绩换算：解析“3:25”并查询标准表的 Java 实现

单项换算的逻辑包含两个动作：解析原始成绩成可比较的数值，再按性别和项目查询标准表。原始成绩解析是最容易忽略的细节，尤其是 800 米和 1000 米这类以“分:秒”存储的成绩。如果直接拿字符串和标准表里的数值比较，“10:05”会被排到“3:25”前面，因为字符串比较只认第一位数字。所以解析时必须统一转成秒。以下是核心实现：

@Service public class ScoreCalculateService { @Autowired private ScoreStandardMapper standardMapper; public BigDecimal calcSingleScore(String rawResult, Long itemId, Integer gender) { double value = parseRawToNumber(rawResult); ScoreStandard standard = standardMapper.selectOne(new QueryWrapper<ScoreStandard>() .eq("item_id", itemId) .eq("gender", gender) .le("min_value", value) .lt("max_value", value)); if (standard == null) { throw new RuntimeException("成绩超出评分标准范围: " + rawResult); } return standard.getStandardScore(); } private double parseRawToNumber(String raw) { if (raw.contains(":")) { String[] parts = raw.split(":"); int minutes = Integer.parseInt(parts[0]); int seconds = Integer.parseInt(parts[1]); return minutes * 60 + seconds; } return Double.parseDouble(raw.trim()); } }

这里查询条件用了 .le("min_value", value).lt("max_value", value)，对应第 3 章设计的左闭右开区间；如果你把查询写成 between，就会撞上边界值双命中问题。parseRawToNumber 方法有一个隐含假设：所有带冒号的成绩都是“分:秒”格式。如果谁在录入时写了“3分25秒”，这里就会抛 NumberFormatException，所以录入表单里应当做格式校验，提前把输入限制为数字加半角冒号。另外，rawResult 里可能混入空格，所以解析前先 trim，这个细节能避免很多莫名其妙的报错。

4.2 总分加权与评级：八个项目权重和等级判定代码

单项分拿到之后，总分计算就是把八个单项分按权重累加。2014 年版《国家学生体质健康标准》的权重分布是：体重指数（BMI）15%，肺活量 15%，50 米跑 20%，立定跳远 10%，坐位体前屈 10%，引体向上（男）/仰卧起坐（女）10%，1000 米（男）/800 米（女）20%。这组权重计算出来的总分可以直接用于评级。权重建议放配置或者常量 map 里，不要写成一长串 if else：

public BigDecimal calcTotalScore(Long studentId, Integer testYear) { Map<String, BigDecimal> weightMap = new HashMap<>(); weightMap.put("bmi", new BigDecimal("0.15")); weightMap.put("vital_capacity", new BigDecimal("0.15")); weightMap.put("run_50m", new BigDecimal("0.20")); weightMap.put("long_jump", new BigDecimal("0.10")); weightMap.put("sit_forward", new BigDecimal("0.10")); weightMap.put("pull_up", new BigDecimal("0.10")); weightMap.put("sit_up", new BigDecimal("0.10")); weightMap.put("run_800m", new BigDecimal("0.20")); weightMap.put("run_1000m", new BigDecimal("0.20")); List<PhysicalTest> tests = physicalTestMapper.selectList( new QueryWrapper<PhysicalTest>() .eq("student_id", studentId) .eq("test_year", testYear)); if (tests.size() != 8) { throw new RuntimeException("该学生体测项目不完整，无法计算总分"); } BigDecimal total = BigDecimal.ZERO; for (PhysicalTest test : tests) { BigDecimal weight = weightMap.get(test.getItemCode()); total = total.add(test.getStandardScore().multiply(weight)); } return total.setScale(1, RoundingMode.HALF_UP); }

这里有个业务规则值得说明：如果学生缺项，我不建议按零分计入总分，因为这样会严重拉低评级，引发学生质疑。更稳妥的做法是保存成绩时就做完整性校验，八个项目全部录入后才能生成总分。weightMap 是运行时构造，实际项目里可以直接放 static 常量，如果标准调整了再改常量或者做成数据库配置。评级判断相对简单，但边界值要小心：

public String judgeGrade(BigDecimal totalScore) { if (totalScore.compareTo(new BigDecimal("90")) >= 0) { return "优秀"; } else if (totalScore.compareTo(new BigDecimal("80")) >= 0) { return "良好"; } else if (totalScore.compareTo(new BigDecimal("60")) >= 0) { return "及格"; } else { return "不及格"; } }

90 分整算优秀，80 分整算良好，60 分整算及格，这是标准里明确写的。用 compareTo 而不是 >= 是因为 BigDecimal 的 compareTo 才比较数值大小，equals 会连小数点位数一起比较，直接写 >= 在 Java 里对 BigDecimal 不适用。如果你在代码里看到了用 totalScore.intValue() >= 90 的判断，那是隐患：89.9 会被截断成 89，评级结果出错。

5. 大学生体测管理系统避坑指南：从启动失败到成绩错乱的四条血泪经验

这部分是我最想写的内容。体测管理系统看着简单，真正跑起来问题一个接一个。以下四条来自我排查多个类似项目的经验，每条按现象、原因、解决三步写清楚，你照着检查能省下大量时间。

5.1 项目启动失败：先查 JDK 版本、文件编码与数据库连接串

现象：项目导入 IDE 后一启动就报错，要么是 UnsupportedClassVersionError，要么是 CGLIB 相关异常，还有控制台输出乱码、数据库连接超时。这类问题占了“项目跑不起来”案例的八成。原因通常有三个：JDK 版本不匹配、工程文件编码不统一、连接串没适配 MySQL 8。UnsupportedClassVersionError 说明编译用的 JDK 比运行时的 JDK 新，反过来 CGLIB 报错则常见于用 JDK 9 以上跑老版本 Spring。解决方式：统一使用 JDK 8 的最新补丁版本，在 IDE 里把 Project SDK、Modules、Maven 的 Java 版本全部改成 1.8，不要只改一个地方。文件编码在 IDE 的 Settings 里把 Global Encoding、Project Encoding、Properties Files 全部设为 UTF-8，否则 JSP 或 properties 里的中文注释直接变乱码。数据库连接串用下面这个模板最稳妥：

spring.datasource.url=jdbc:mysql://localhost:3306/physical_test?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false spring.datasource.username=root spring.datasource.password=123456 spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

MySQL 8 的驱动类名是 com.mysql.cj.jdbc.Driver，不再是老旧的 com.mysql.jdbc.Driver，同时必须带 serverTimezone 参数，否则报时区错误。如果你的包是 SSM 项目，数据源配置在 XML 里，格式同理。这段配置是排查数据库连接问题的第一站，百分之六十的 Communications link failure 都是因为它。

5.2 成绩算错：小数位、NULL 缺项与唯一索引缺失

现象：某个学生总分算出来是 87.999999，数据库里存了一条重复成绩，或者明明没录肺活量，总分却高得离谱。原因和处理方式分三个层面。第一，小数精度问题来自 DOUBLE 类型和 Java 的 double 累加，改成 DECIMAL 加 BigDecimal 彻底根治。第二，缺项问题出在成绩保存时没做完整性校验，正确做法是保存时判断该生该年已有记录数，不满八项不允许提交，而不是让总分计算兜底。第三，重复成绩是 physical_test 表缺少唯一索引导致的，Excel 导入时第一次插入成功，第二次又插了一条。解决方式是执行 ALTER TABLE physical_test ADD UNIQUE KEY uk_student_item (student_id, test_year, item_id); 已经插入的重复数据要先清理，否则索引建不上。清理语句可以先查重复：

SELECT student_id, test_year, item_id, COUNT(*) FROM physical_test GROUP BY student_id, test_year, item_id HAVING COUNT(*) > 1;

查出来之后保留 id 最小的一条，其余删掉，再补建唯一索引。这一步做完，重复导入的隐患才从根上解除。

5.3 长跑与肺活量的特例字段：别拿 VARCHAR 存可比较数值

现象：成绩排序时 10:05 排到了 3:25 前面；肺活量录 3200 和 3.2 的都有，标准分换算乱套。原因很直接：800 米、1000 米用“分:秒”文本存储后，SQL 的 ORDER BY 按字符串排，数字比较规则失效；肺活量的单位在不同录入者手里漂移了。这不是偶发问题，每个月都有人踩。解决方式分两步：第一，入库前做一次格式规整，写一个工具方法把分:秒统一转成秒数存一个额外字段，原始展示字段可以保留，但排序、比较、换算全部用数值字段。第二，肺活量在导入 Excel 时做单位校验，如果单元格是 3.2 且目标项目是肺活量，自动乘以 1000 转成毫升，避免录入者按习惯填升。工具方法很简单：

public static String secondsToMinuteSecond(int seconds) { return String.format("%d:%02d", seconds / 60, seconds % 60); }

展示给体育老师看的时候用这个格式转回“分:秒”，老师看到的是熟悉的时间格式，系统内部存的是可计算的秒数。这个习惯比你在 SQL 里写一堆函数硬解析字符串要稳得多。

5.4 项目说明与源码不一致：先导入脚本再跑代码

现象：项目说明文档里写用 MySQL 5.5，脚本里的 utf8mb4 字符集却要求 5.5 以上，按文档部署直接报错；或者是文档截图上的页面和实际代码渲染出来的页面长得不一样。原因不是交付的人骗你，而是很多开发者改完代码忘了同步文档，数据表脚本和源码版本存在错位。这种包比比皆是，关键在于处理顺序。我拿任何一个源码包，不管文档吹得多完整，都先把 SQL 脚本打开看一遍，确认表结构和第 3 章描述的核心字段一致，再导入数据库，最后才启动服务。如果启动后发现页面字段和表结构对不上，以源码为准，因为代码是最终运行的事实。文档只作为参考，不要按文档去改代码，那是自己给自己挖坑。

6. 让系统被体育老师真正认可的两个小改造：统计大屏与预警名单

基础功能做完之后，真正的加分项在于让系统用起来“贴心”。体育老师期末最烦两件事：一是要按班级算及格率优良率，二是要从一堆成绩里挑出不及格的学生单独通知。这两个场景适合做两个轻量改造：一是班级对比统计大屏，二是未达标预警名单自动导出。

第一个改造的核心是一条分组聚合 SQL 加一个前端图表组件。SQL 按班级聚合平均分和优秀人数，数据源来自 student 和 physical_test 的关联：

SELECT s.class_name, ROUND(AVG(ts.total_score), 1) AS avg_score, SUM(CASE WHEN ts.grade = '优秀' THEN 1 ELSE 0 END) AS excellent_cnt, COUNT(*) AS total_cnt FROM student s JOIN test_total ts ON s.id = ts.student_id WHERE ts.test_year = 2025 GROUP BY s.class_name ORDER BY avg_score DESC;

前端用图表组件把这几列渲染成柱状图和雷达图，班级之间高低立判。这个改造不需要新增任何复杂表，一个视图或者临时结果集就够了，对源码包的改动面很小，但演示效果和实际价值都很突出。

第二个改造是预警名单。规则可以定为“任一单项得分低于 60 分”或“总分低于 60 分”，查询条件写在 service 层：

List<Student> warnList = studentMapper.selectList( new QueryWrapper<Student>() .inSql("id", "SELECT student_id FROM test_total WHERE test_year = 2025 AND total_score < 60") .orderByAsc("class_name"));

查出来后用 Excel 工具导出，列包含班级、学号、姓名、总分、评级、不及格项目，体育老师直接按名单通知学生，不用自己翻成绩单。我做这类系统时养成的习惯是：凡是老师要手工汇总的报表，系统里就一定要有一键导出；凡是老师要人工盯的异常，系统里就要有自动标记。这两个小改造做完，系统的使用率才会真正上去。

我自己做体测项目时吃过亏的地方也简单提醒一句：不要让系统只做“录成绩查分数”，评分标准一变代码就改。把标准塞进数据库表、把权重放进配置之后，改标准这件事就从改代码降级成了改数据。希望这套思路对你有帮助。

本文还有配套的精品资源，点击获取