基于JavaWeb的高职院系任务积分管理系统：从Excel台账到全栈落地

简介：这份资源是一篇基于JavaWeb的高职二级院系任务积分管理系统原创毕业论文，面向专科与本科计算机相关专业的毕业生，尤其适合需要完成毕业设计、撰写论文或搭建教务管理类项目的学生参考。论文围绕任务发布、任务接收、积分记录与查询统计等核心功能展开，完整覆盖需求分析、系统设计、技术选型、环境搭建、系统实现及测试优化等环节，技术栈涉及JavaWeb、Spring Boot、MyBatis与MySQL，并讨论了用户角色权限划分与HTTPS数据传输等安全措施。资源包共1个docx文件，约28KB，内容为论文正文，目录结构清晰，包含引言、系统分析与设计、技术选型与环境搭建、系统实现、系统测试与优化、总结与展望等章节，便于读者按模块查阅与借鉴。目前已有87人学习，适合作为毕业设计选题、论文写作与项目开发的参考材料。

1. 高职院系任务积分系统：从 Excel 台账到 JavaWeb 的落地路径

每到学期末，二级院系的办公室总会陷入同一种混乱：教学任务、科研任务、学生管理任务、临时性专项任务散落在七八个 Excel 表格里，谁做了多少、该记多少分、排名第几，全靠人工核对。我见过最夸张的一次，一个院系用三张表来回 VLOOKUP，最后因为一个教师姓名多了个空格，整张排名表全错位。基于 JavaWeb 的高职二级院系任务积分管理系统，要解决的就是这件事——把任务发布、认领、审核、积分累计、排名公示这条链路搬到浏览器里，让数据只录一次、规则写死在代码里、结果随时可查。它适合两类人：一类是院系行政岗，想用一套自己可控的系统替代手工台账；另一类是计算机相关专业的教师或学生，想拿一个真实业务场景练 JavaWeb 全栈。下面我按自己做过的一套方案，把选型、建表、编码、踩坑讲透。

2. 需求拆解与技术选型：为什么是 JSP+Servlet 而不是一上来就 SpringBoot

2.1 先把「任务积分」翻译成四张核心实体

很多同行一上来就写代码，结果做到一半发现字段不够用。我一般会先画实体关系，这个系统抽象下来就四张核心表：用户（教师/管理员）、任务（Task）、任务认领记录（TaskRecord）、积分流水（PointLog）。任务本身带基础分值，认领后进入待审核状态，管理员审核通过才写入积分流水，流水是排名的唯一数据源。这里有个关键设计决策：积分不直接存在用户表上，而是每次由流水汇总计算。原因很简单——积分会涉及撤销、申诉、补录，直接改用户表字段，历史就丢了，出了问题连后悔药都没有。

任务表要预留「任务类型」字段，因为高职院系的积分规则通常是分类计分的：教学类、科研类、学生管理类、专项类，每类权重不同。这个字段决定了后面统计报表能不能按类别出图。认领记录表要带时间戳和状态机（待审核/通过/驳回），状态机是整个系统最容易出 bug 的地方，后面避坑章节会细说。

2.2 技术栈选型：JavaWeb 原生三件套的适用边界

标题写的是 JavaWeb，那核心就是 Servlet + JSP + JDBC。有人会问，2024 年了为什么不用 SpringBoot+Vue？我的判断是：高职院系这类系统，用户量通常几十到几百人，并发极低，部署环境往往是学校机房一台老服务器甚至一台办公电脑。原生 JavaWeb 打成 war 包丢进 Tomcat 就能跑，不依赖 Node 环境、不需要前后端分离部署，运维成本几乎为零。这不是技术落后，是场景匹配。

具体选型：JDK 8 或 11（学校环境兼容性好）、Tomcat 8.5/9、MySQL 5.7/8.0、前端用 JSP + JSTL + 少量原生 JS，不引入重型前端框架。数据库连接用 Druid 连接池，比裸 DriverManager 稳。分层上严格走 Controller（Servlet）→ Service → DAO 三层，别把 SQL 写在 JSP 里，这是新手最容易翻车的地方。

2.3 环境搭建：IDEA 里跑通第一个 Servlet 的最小配置

新手卡在第一步的概率极高，我把最小可运行配置列清楚。IDEA 新建项目选 Java Enterprise，勾选 Web Application，注意勾选「Create web.xml」。Project SDK 选 1.8 或 11，Application Server 指向本地解压的 Tomcat 目录。

# 项目结构约定（我一般这么放） src/ main/ java/ com/college/point/ controller/ # Servlet service/ # 业务逻辑 dao/ # 数据访问 entity/ # 实体类 util/ # DBUtil 等工具 webapp/ WEB-INF/ web.xml lib/ # 放 mysql-connector、druid、jstl 的 jar index.jsp

依赖 jar 直接丢进 WEB-INF/lib，别只加在 IDEA 的 Libraries 里，否则打 war 包会丢。这是血泪经验：本地跑得好好的，一部署到服务器就 ClassNotFound，八成是 jar 没进 lib。web.xml 里配好欢迎页和 Servlet 映射，或者用 @WebServlet 注解也行，但两者别重复配，会冲突。

提示：Tomcat 的端口如果被占用，改 conf/server.xml 里的 Connector port，别去改 IDEA 的运行配置，那个只影响当前项目。

3. 数据库设计与建表：积分流水表是整个系统的账本

3.1 四张核心表的字段设计与索引

建表这一步决定了后面所有查询的性能和扩展性。我把实际用的 DDL 贴出来，字段名和类型都是踩过坑之后定下来的。

-- 用户表：教师和管理员共用，用 role 区分 CREATE TABLE sys_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE COMMENT '登录名', password VARCHAR(64) NOT NULL COMMENT '存 MD5 加盐后的值', real_name VARCHAR(50) NOT NULL, dept_id INT COMMENT '所属院系，为多院系扩展预留', role TINYINT DEFAULT 0 COMMENT '0教师 1管理员', status TINYINT DEFAULT 1 COMMENT '1正常 0禁用', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 任务表：基础分值 + 类型 CREATE TABLE task ( id INT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(200) NOT NULL, task_type TINYINT NOT NULL COMMENT '1教学 2科研 3学管 4专项', base_point INT NOT NULL COMMENT '基础积分', quota INT DEFAULT 1 COMMENT '可认领人数上限', claimed INT DEFAULT 0 COMMENT '已认领数', deadline DATETIME COMMENT '截止时间', status TINYINT DEFAULT 1 COMMENT '1开放 0关闭', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_type_status (task_type, status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 认领记录表：状态机核心 CREATE TABLE task_record ( id INT PRIMARY KEY AUTO_INCREMENT, task_id INT NOT NULL, user_id INT NOT NULL, status TINYINT DEFAULT 0 COMMENT '0待审核 1通过 2驳回', apply_time DATETIME DEFAULT CURRENT_TIMESTAMP, audit_time DATETIME, auditor_id INT, remark VARCHAR(255), UNIQUE KEY uk_task_user (task_id, user_id), INDEX idx_user_status (user_id, status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 积分流水表：排名的唯一数据源 CREATE TABLE point_log ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, record_id INT NOT NULL, point INT NOT NULL COMMENT '正数为加分，负数为撤销', reason VARCHAR(200), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_user (user_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

几个设计要点必须说清楚。第一，task_record上的uk_task_user唯一索引，从数据库层面防止同一个人重复认领同一任务，比在代码里查一遍再插入可靠得多——并发下代码校验会失效，唯一索引不会。第二，point_log的point允许负数，撤销积分时插一条负记录，而不是删原记录，这样账本永远可追溯。第三，claimed字段是冗余计数，用的时候要配合UPDATE task SET claimed = claimed + 1 WHERE id = ? AND claimed < quota这种带条件的更新，靠数据库行锁保证不超领。

3.2 积分汇总查询：别用循环累加，一条 SQL 搞定

排名是高频操作，如果每个用户循环查一次流水再累加，一百个用户就是一百次查询，页面直接卡死。正确做法是一条 GROUP BY 出结果。

-- 积分排行榜：只统计有效流水 SELECT u.id, u.real_name, IFNULL(SUM(p.point), 0) AS total FROM sys_user u LEFT JOIN point_log p ON u.id = p.user_id WHERE u.role = 0 AND u.status = 1 GROUP BY u.id, u.real_name ORDER BY total DESC;

用 LEFT JOIN 是为了让零积分的教师也出现在榜上，否则新入职教师查不到自己会来问。IFNULL处理没有流水的情况，不然显示 NULL 很难看。如果数据量涨到几千人，可以在point_log上再建(user_id, create_time)联合索引，支持按学期时间段筛选统计。

3.3 用 DBUtil 封装连接：Druid 配置与常见连接泄漏

DAO 层不要每次DriverManager.getConnection，用连接池。我一般用 Druid，配置文件放src下，注意打包后路径问题。

public class DBUtil { private static DataSource ds; static { try { Properties p = new Properties(); // 注意：配置文件要放在 classpath 根下 p.load(DBUtil.class.getClassLoader().getResourceAsStream("druid.properties")); ds = DruidDataSourceFactory.createDataSource(p); } catch (Exception e) { throw new ExceptionInInitializerError("数据源初始化失败: " + e.getMessage()); } } public static Connection getConn() throws SQLException { return ds.getConnection(); } // 关闭顺序：ResultSet -> Statement -> Connection public static void close(Connection c, Statement s, ResultSet r) { try { if (r != null) r.close(); } catch (SQLException ignored) {} try { if (s != null) s.close(); } catch (SQLException ignored) {} try { if (c != null) c.close(); } catch (SQLException ignored) {} } }

druid.properties 里至少配url、username、password、initialSize、maxActive。学校场景maxActive给 10 到 20 足够。连接泄漏是新手重灾区：DAO 里开了连接忘了关，跑一天 Tomcat 就报Too many connections。养成 finally 里关连接的习惯，或者用 try-with-resources。注意 Druid 的close()是归还连接到池，不是真关闭，所以必须调。

4. 核心功能编码：任务认领、审核与积分入账的完整链路

4.1 任务认领的并发控制：一条带条件的 UPDATE

认领功能看着简单，其实是并发问题最集中的地方。两个教师同时点「认领」一个只剩 1 个名额的任务，如果先查claimed < quota再更新，两人都会通过校验，最后超领。正确做法是把校验和更新合并成一条原子 SQL。

// TaskDao.java public boolean claim(int taskId, int userId) { String sql = "UPDATE task SET claimed = claimed + 1 " + "WHERE id = ? AND status = 1 AND claimed < quota AND deadline > NOW()"; try (Connection c = DBUtil.getConn(); PreparedStatement ps = c.prepareStatement(sql)) { ps.setInt(1, taskId); return ps.executeUpdate() == 1; // 返回 1 才算认领成功 } catch (SQLException e) { e.printStackTrace(); return false; } }

这条 SQL 把「任务开放、未超员、未过期」三个条件全压在 WHERE 里，数据库执行时对行加锁，天然串行化。executeUpdate返回受影响行数，等于 1 说明抢到了，等于 0 说明名额没了或任务关了。Service 层拿到 false 就提示「手慢了，名额已满」。接着再往task_record插一条待审核记录，这一步如果因为唯一索引冲突失败，说明该用户已经认领过，捕获异常提示即可。

4.2 审核状态机：通过、驳回、撤销三种流转

审核是业务规则最密集的地方。状态流转必须收敛在 Service 层，Controller 只负责收参数和跳转。

// AuditService.java public String audit(int recordId, int auditorId, int action, String remark) { TaskRecord r = recordDao.findById(recordId); if (r == null) return "记录不存在"; if (r.getStatus() != 0) return "该记录已审核，不能重复操作"; if (action == 1) { // 通过 recordDao.updateStatus(recordId, 1, auditorId, remark); Task t = taskDao.findById(r.getTaskId()); // 积分入账：写流水，不直接改用户表 pointLogDao.insert(r.getUserId(), recordId, t.getBasePoint(), "任务通过:" + t.getTitle()); return "审核通过"; } else if (action == 2) { // 驳回 recordDao.updateStatus(recordId, 2, auditorId, remark); // 驳回要释放名额，否则任务永远占着 taskDao.releaseQuota(r.getTaskId()); return "已驳回"; } return "非法操作"; }

这里有两个容易漏的点。第一，驳回后必须把task.claimed减回去，不然名额被占死，其他教师认领不了。第二，积分入账只写流水，绝不UPDATE sys_user SET point = point + ?，前面说过原因。撤销场景（比如事后发现任务造假）就是再插一条负数流水，reason写清撤销原因，账本完整。

4.3 积分排行榜与个人明细的分页查询

排行榜用 3.2 的汇总 SQL，个人明细要分页。分页别用LIMIT offset, size在大数据量下的深分页，学校场景几百条无所谓，但养成习惯用游标或至少加索引。

// PointLogDao.java 个人积分明细分页 public List<PointLog> pageByUser(int userId, int page, int size) { String sql = "SELECT * FROM point_log WHERE user_id = ? " + "ORDER BY create_time DESC LIMIT ?, ?"; List<PointLog> list = new ArrayList<>(); try (Connection c = DBUtil.getConn(); PreparedStatement ps = c.prepareStatement(sql)) { ps.setInt(1, userId); ps.setInt(2, (page - 1) * size); ps.setInt(3, size); try (ResultSet rs = ps.executeQuery()) { while (rs.next()) { PointLog log = new PointLog(); log.setId(rs.getInt("id")); log.setPoint(rs.getInt("point")); log.setReason(rs.getString("reason")); log.setCreateTime(rs.getTimestamp("create_time")); list.add(log); } } } catch (SQLException e) { e.printStackTrace(); } return list; }

ORDER BY create_time DESC保证最新的流水在最上面，教师最关心「最近加了什么分」。分页参数page从 1 开始，(page-1)*size是偏移量，这个公式写错会导致第一页重复或漏数据，是新手高频 bug。

4.4 权限拦截：一个 Filter 挡住未登录和越权

别在每个 Servlet 里写登录校验，用 Filter 统一处理。登录放行，其余请求检查 session，管理员路径再查 role。

@WebFilter("/*") public class AuthFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; String uri = request.getRequestURI(); // 放行登录页、静态资源 if (uri.endsWith("login.jsp") || uri.endsWith("/login") || uri.contains("/static/")) { chain.doFilter(req, resp); return; } Object user = request.getSession().getAttribute("user"); if (user == null) { response.sendRedirect(request.getContextPath() + "/login.jsp"); return; } // 管理员路径校验 if (uri.contains("/admin/") && ((User) user).getRole() != 1) { response.sendError(403, "无权限"); return; } chain.doFilter(req, resp); } }

@WebFilter("/*")拦截所有请求，放行规则要写在最前面。注意getRequestURI()包含 contextPath，判断时用endsWith或contains更稳。越权是这类系统最该防的：教师能访问/admin/audit直接审核自己的任务，那积分就失去意义了。

5. 避坑与排查：上线后最容易被问到的五个问题

5.1 中文乱码：POST 和 GET 要分开治

现象：表单提交的中文任务名存进数据库变成问号，或者页面显示乱码。原因：Tomcat 8 以后 GET 默认 UTF-8，但 POST 请求体默认不是，且 JSP 页面没声明编码。解决：JSP 顶部加<%@ page contentType="text/html;charset=UTF-8" %>，Servlet 里在取参数前调request.setCharacterEncoding("UTF-8")，数据库连接 URL 加useUnicode=true&characterEncoding=utf8，建表用utf8mb4。四处缺一处都可能乱码，我一般四处全配齐。

5.2 重复认领：唯一索引报错被当成系统故障

现象：教师点两次认领按钮，第二次页面报 500 错误。原因：task_record的uk_task_user唯一索引拦截了重复插入，抛SQLIntegrityConstraintViolationException，代码没捕获。解决：DAO 里捕获这个异常返回 false，Service 提示「您已认领过该任务」，而不是让异常冒到页面。这个坑的本质是把「业务预期内的冲突」当成了「系统错误」。

5.3 积分对不上：审核通过但排行榜没变

现象：管理员明明审核通过了，教师排行榜积分没涨。原因排查顺序：先看point_log有没有插入记录，没有就是 Service 里入账逻辑没执行；有记录但排行榜没变，看汇总 SQL 的 WHERE 条件是不是把该用户过滤掉了（比如 status 被禁用）；都对就是浏览器缓存了旧页面。我遇到过最隐蔽的一次，是审核事务没提交——JDBC 默认自动提交，但如果手动开了事务忘了 commit，数据就丢了。

5.4 部署到服务器 404：war 包名和访问路径

现象：本地 IDEA 跑得好好的，war 包丢进 Tomcat 的 webapps 后访问 404。原因：war 包名决定了访问路径，point.war部署后访问路径是/point/，不是/。解决：要么访问时带上项目名，要么把 war 包改名ROOT.war部署成根应用。另外确认 web.xml 的欢迎页配置和 index.jsp 位置对得上。

5.5 连接池耗尽：Too many connections

现象：系统跑一段时间后所有请求卡死，日志报连接池满。原因：某个 DAO 方法异常路径下没关连接，连接被占死。解决：所有数据库操作走 try-with-resources 或 finally 关闭；Druid 配removeAbandoned=true和removeAbandonedTimeout=300作为兜底，强制回收超过 5 分钟没归还的连接。这是后悔药，但别依赖它，根因还是代码要关连接。

6. 进阶技巧：把积分规则做成可配置，而不是写死在代码里

系统上线后，院系几乎一定会改积分规则——今年科研任务分值翻倍，明年专项任务取消。如果分值写死在代码里，每次改都要重新编译部署，行政岗根本搞不定。我的做法是把规则抽到一张配置表，让管理员在页面上改。

CREATE TABLE point_rule ( id INT PRIMARY KEY AUTO_INCREMENT, task_type TINYINT NOT NULL, rule_name VARCHAR(100), point_value INT NOT NULL, effective_date DATE COMMENT '生效日期', INDEX idx_type_date (task_type, effective_date) );

审核入账时不再直接取task.base_point，而是按任务类型和当前日期查生效的规则。这样改规则只是插一条新记录，历史流水不受影响，因为流水里存的是当时算出的具体分值。这个设计的关键认知是：规则会变，账本不能变。流水一旦生成就是历史事实，规则表只影响未来的计算。

验证方法也简单：改一条规则，新建一个任务走完认领审核，看入账分值是不是新规则的值，同时查历史流水有没有被改动。我一般还会加一个「规则变更日志」，谁在什么时候改了什么，出问题能追溯。

最后一个习惯送给你：这个系统我做完后，坚持每周导出一次point_log全表备份，因为积分涉及教师切身利益，一旦数据丢了，解释成本远高于备份成本。数据库可以重建，账本丢了就真没后悔药了。希望帮到你。

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