简介针对JavaWeb方向学习与毕业设计人群这份运动与健康管理系统完整源代码与数据库资源可用于快速掌握用户管理、运动记录、健康监测、数据分析等典型模块的开发流程也可作为课程设计的起始模板。压缩包共707个文件约9.59MB整体以jsp页面与java类承载后端业务逻辑js与css负责前端交互与样式gif、jpg提供界面演示素材sql为数据库初始化脚本jar为依赖库另有html、xml等辅助配置目录结构清晰便于按模块对照学习。已有2019人学习查看适用于需要参考完整项目实现、理解表结构设计与Servlet/JSP开发思路的读者。通过源码可看到用户表、运动记录表、健康指标表的关联方式同时附带的项目配置与静态资源能帮助还原运行环境是JavaWeb综合项目实践的一份实用参考资料。1. JavaWeb 运动与健康管理系统为什么值得下载并且跑通它如果你搜过「javawe 运动与健康管理系统 源代码」——没错后缀少个 b 是常见拼写——大概率看到一大排压缩包链接。我拆过好几套之后有个反直觉的结论这类系统真正值钱的不是「能登录、能打卡」的 CRUD 壳子而是数据库表结构和后端分层写法能不能经得起你往里面加需求。这套基于 JSP Servlet MySQL 的经典 JavaWeb 架构几乎覆盖了课设和毕业设计里所有要求用户端运动打卡、个人健康档案、管理员后台、数据统计预览外加完整数据库脚本。适合正在做 JavaWeb 课设的学生、想练手 Servlet 全流程的开发者也想用现成源码二次改造成内部健康管理小工具的人。下面我按拆包顺序讲先立住数据模型再讲功能实现然后把部署时最容易翻车的三个坎铺开说。2. 从 ER 图到建表脚本运动打卡数据怎么存才不返工2.1 四张核心表用户、运动记录、健康指标、管理员拆开数据库脚本一般是一个.sql文件项目解压后通常放在db/或sql/目录第一件事不是双击导入而是先打开看建表结构。这套系统的核心表有四个用户表、运动记录表、健康指标表、管理员表。健康指标表是很多人做设计时候遗漏的一张表——如果没有它「个人健康档案」页面里的体重、心率、睡眠时长根本没有独立的数据载体最后会塞进用户表变成一堆冗余字段。四张表的核心字段如下表名核心字段关键设计t_userid、username、password、age、gender、height、weight、create_time密码建议 MD5 处理身高体重冗余存储方便首页直接读t_exercise_recordid、user_id、exercise_type、duration_minutes、calories、record_date、create_time日期用 DATE 类型热量允许小数t_health_metricid、user_id、weight、heart_rate、sleep_hours、metric_date、create_time同一天可有多次记录但预警统计时取最新一条t_adminid、username、password、real_name、role与业务表完全解耦登录入口独立为什么运动记录表要单独拆出来而不是合并进用户表因为「运动打卡」在业务上天然是一对多的一个用户一天可以打卡多次一次跑步一次拉伸是两条记录。如果把这些塞进用户表后面写统计 SQL 时每查一次运动时长都要做字符串切割那才是真正的返工地狱。健康指标表同理体重和心率是会变化的量必须按日期累积不然趋势图没数据可画。2.2 建表脚本主键、时间戳、唯一索引缺一不可不要直接在 Navicat 里手动画表把 SQL 文件拖进命令行或客户端执行一遍更稳妥。这套系统的核心建表语句大概是这样的结构CREATE TABLE t_exercise_record ( id INT AUTO_INCREMENT PRIMARY KEY COMMENT 主键, user_id INT NOT NULL COMMENT 关联 t_user.id, exercise_type VARCHAR(32) NOT NULL COMMENT 运动类型跑步/游泳/骑行/拉伸, duration_minutes INT NOT NULL COMMENT 运动时长单位分钟, calories DECIMAL(8,2) DEFAULT 0 COMMENT 预估消耗热量单位千卡, record_date DATE NOT NULL COMMENT 打卡日期, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 记录创建时间, UNIQUE KEY uk_user_date (user_id, record_date, exercise_type) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT运动打卡记录表;这段脚本里值得留意三个细节。第一AUTO_INCREMENT主键是常规选择删除记录后主键不会复用统计口径不会被过往数据污染。第二UNIQUE KEY uk_user_date是我拆这套系统时最想夸的地方——它防止了「同一天同一种运动重复打卡」这个约束放在应用层做要多写一堆查询放在数据库层一行就堵死了。第三DECIMAL(8,2)而不是FLOAT热量计算要的是精确两位小数浮点数在累计求和时会抖出 0.0000001 的误差虽然肉眼看不出来但报表对不上时会让人怀疑人生。2.3 数据类型选型为什么热量和体重都用 DECIMAL建表脚本里另一个值得说的是类型选型逻辑。duration_minutes用 INT因为运动时长是整数分钟calories用 DECIMAL(8,2)因为热量计算涉及运动系数结果可能是小数gmt_create这类时间字段统一 DATETIME不要用 TIMESTAMP因为 TIMESTAMP 的范围只到 2038 年而且受时区影响DATETIME 更省心。这里有个真实发生过的教训某开发者在二次开发时把体重字段改成了DOUBLE理由是「JSP 页面上显示体重后端接个字符串就转了无所谓」。后面做月度体重曲线图时发现AVG(weight)出来一串 60.00000000001前端图表点尾数全是 1。从那以后我对建表脚本的原则就是凡是展示给用户看、参与计算或者聚合的数值一律 DECIMALFLOAT/DOUBLE只允许出现在科学计算这种不追求精确的场景。3. 用户端四个功能模块登录、打卡、报表、个人中心的后端实现3.1 从 JSP 到 Servlet 的请求流转一次打卡请求怎么走完整条链路这套系统是典型的 MVC 结构JSP 负责渲染Servlet 负责接请求调业务DAO 负责和数据库打交道。很多新手把 JSP 直接写上 Java 代码页面里塞一堆%那不是不能跑但后面改需求时会变得没法看。这套系统的分层拆得比较干净——虽然代码不是最新式框架但「JSP 只负责收参数、Servlet 只负责转方向、DAO 只负责数据库」这条线是清楚的。登录请求的流转大概是这样的用户在login.jsp输入用户名密码表单methodpost提交到LoginServlet。Servlet 调用UserDao.findByUsernameAndPassword()查到了就把user对象放进 Session跳转index.jsp查不到就request.setAttribute(error, 用户名或密码错误)转发回登录页。核心代码是这样WebServlet(/login) public class LoginServlet extends HttpServlet { private UserDao userDao new UserDao(); Override protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setCharacterEncoding(UTF-8); String username request.getParameter(username); String password request.getParameter(password); User user userDao.findByUsernameAndPassword(username, password); if (user ! null) { HttpSession session request.getSession(); session.setAttribute(loginUser, user); response.sendRedirect(request.getContextPath() /index.jsp); } else { request.setAttribute(error, 用户名或密码错误); request.getRequestDispatcher(/login.jsp).forward(request, response); } } }这里有个关键参数容易被忽略request.setCharacterEncoding(UTF-8)必须放在getParameter()调用之前。如果这一行漏了或放后面中文用户名和密码会乱码查库直接失败下次登录会显示「用户名或密码错误」而实际上密码是对的——这个坑后面避坑章还会详细说。getParameter拿到的全是字符串DAO 层做密码校验后返回User对象或null这只是项目里最常见的写法不是唯一写法。3.2 打卡核心DAO 层插入前先做「重复判断」运动打卡是用户端最核心的操作。前端表单收集运动类型、时长、日期提交到AddExerciseServletServlet 调ExerciseRecordDao.insert(). 真正写代码时要处理的业务逻辑是同一天同一种运动不能重复打卡。数据库那层UNIQUE KEY是兜底但在应用层最好也先查一次因为数据库报DuplicateKeyException时异常不够友好页面直接白屏。public boolean insert(ExerciseRecord record) { String checkSql SELECT id FROM t_exercise_record WHERE user_id ? AND record_date ? AND exercise_type ?; String insertSql INSERT INTO t_exercise_record (user_id, exercise_type, duration_minutes, calories, record_date) VALUES (?, ?, ?, ?, ?); try (Connection conn DBUtil.getConnection(); PreparedStatement checkPs conn.prepareStatement(checkSql); PreparedStatement insertPs conn.prepareStatement(insertSql)) { checkPs.setInt(1, record.getUserId()); checkPs.setDate(2, new java.sql.Date(record.getRecordDate().getTime())); checkPs.setString(3, record.getExerciseType()); ResultSet rs checkPs.executeQuery(); if (rs.next()) { return false; // 当天同类型已存在返回 false 由 Servlet 提示用户 } insertPs.setInt(1, record.getUserId()); insertPs.setString(2, record.getExerciseType()); insertPs.setInt(3, record.getDurationMinutes()); insertPs.setBigDecimal(4, record.getCalories()); insertPs.setDate(5, new java.sql.Date(record.getRecordDate().getTime())); return insertPs.executeUpdate() 0; } catch (SQLException e) { e.printStackTrace(); return false; } }这段代码用了三重嵌套的try-with-resources连接和语句都会自动关闭这在 JDK 7 之后的支持很好课设代码里常见老式finally手动关连接但那样一旦中间某个语句异常连接就泄漏了。PreparedStatement用占位符?传参避免拼接 SQL 导致注入——这是这类项目必须做扎实的点因为运动健康系统涉及用户隐私数据登录接口如果用拼接字符串被注入一次就全表沦陷。3.3 个人中心把体重、心率、睡眠聚合成一张数据卡个人中心页面展示用户最近一次体重、心率以及近 7 天运动汇总。页面组装的 SQL 逻辑比 Java 循环聚合方便得多。近 7 天汇总的典型写法是在 SQL 层按日期分组SELECT record_date, SUM(duration_minutes) AS total_minutes, SUM(calories) AS total_calories FROM t_exercise_record WHERE user_id ? AND record_date DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY record_date ORDER BY record_date ASC;这段 SQL 里DATE_SUB(CURDATE(), INTERVAL 7 DAY)是计算「7 天前」的日期CURDATE()只取当前日期不取时间避免当天凌晨打卡被日期边界问题干扰。用GROUP BY record_date按天聚合返回的结果直接就是前端图表想要的数据结构Java 层只需要while(rs.next())循环塞进 List不需要在内存里做二次求和。这里不要用SELECT *再在 Java 里算总和——数据库做聚合比 Java 循环快得多而且代码量少一半。这套系统里所有涉及「按时间统计」的地方基本都是这个套路理解了这一条后面管理后台的统计图表你基本也能看懂。4. 管理后台与统计视图让运动数据变成健康画像4.1 用户管理不靠「删除」靠「状态位」管理后台的用户管理模块常见的课设实现是「点删除直接 DELETE FROM t_user」这套系统用的是软删除t_user表里有一个status字段0正常、1禁用。管理员点击「禁用」时执行的 SQL 不是删除而是更新状态位UPDATE t_user SET status 1 WHERE id ?为什么这样做因为用户的运动记录表t_exercise_record.user_id关联了用户表主键如果直接物理删除用户记录表里的历史数据就成了孤行——统计报表会出现「查不到用户名只有一串数字」的脏数据。软删除之后登录校验会自动加一个status 0的条件被禁用的用户虽然还在表里但登录不进去历史数据仍然可以被后台统计。这里有两点补充。第一删运动记录和删用户是两回事如果只是为了腾空间删的是记录表数据如果是封号动的是用户表状态位。第二如果你在二次开发时要同时干净清除某个用户的所有数据那要先把t_exercise_record、t_health_metric里的关联记录删掉最后再删t_user顺序反过来外键会报错。4.2 健康预警一条 SQL 揪出「久坐高危用户」这套系统后台有个健康预警模块逻辑很简单最近 7 天运动总时长低于 30 分钟的用户会被标为「运动不足」。这个模块的价值不在算法多高级而在 SQL 怎么写——只用一条关联子查询就能扫出全表高危用户。SELECT u.id, u.username, IFNULL(SUM(e.duration_minutes), 0) AS total_minutes FROM t_user u LEFT JOIN t_exercise_record e ON e.user_id u.id AND e.record_date DATE_SUB(CURDATE(), INTERVAL 7 DAY) WHERE u.status 0 GROUP BY u.id HAVING total_minutes 30;注意这里用的是LEFT JOIN而不是INNER JOIN因为一个用户如果在过去 7 天压根没运动他不会有任何记录行用 INNER JOIN 会把他漏掉LEFT JOIN保证每个用户都出现在结果集里IFNULL(SUM(...), 0)把没有记录的用户的汇总值填补成 0。最后HAVING total_minutes 30是在分组后过滤WHERE做不到这一点——这是新手写统计 SQL 最常见的翻车点WHERE在分组前执行它不认识聚合列加上HAVING才能对分组后的聚合结果过滤。4.3 统计图表的数据接口聚合查询怎么写才不难看管理后台的首页通常有「运动类型占比」「每日活跃用户数」等图表。这套系统的图表数据走的是 JSON 接口由一个StatisticServlet返回。典型的查询是统计每种运动类型的累计时长 TOP5SELECT exercise_type, SUM(duration_minutes) AS total_minutes FROM t_exercise_record WHERE record_date DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY exercise_type ORDER BY total_minutes DESC LIMIT 5;执行完这个查询后后台把每行结果转成 JSON 数组格式大概是[[跑步, 320], [骑行, 180]]前端图表库直接拿数组渲染饼图或柱状图。这个数据接口有两个常见问题一是LIMIT 5会截断数据饼图的「其他」类别需要 Java 层手动把第 6 名以后的数据合并成一行「其他」二是日期范围 30 天是常量如果想让管理员在页面上自定义日期范围把这个常量替换成参数即可——StatisticServlet里加一个receiveParam(days)默认 30接口就变通用了。图表联动这块这套系统的实现不算复杂但架构是通的前端定时请求/statistic/recent拿到上次时间戳之后的新增打卡记录直接更新图表数据点。如果你要把它改成实时大屏追加推送通道就行不用动后端查询接口。5. 部署避坑实录JDK 版本、字符集、连接池这几个坎最常翻车5.1 JDK 版本与 MySQL 驱动不匹配ClassNotFoundException 不是驱动没放现象Tomcat 启动后访问登录页一切正常一提交表单直接白屏控制台抛ClassNotFoundException: com.mysql.cj.jdbc.Driver。很多人第一反应是「缺 jar」把驱动包反复拷进WEB-INF/lib还是报错。原因这个项目如果数据库脚本是用 MySQL 5.x 写的而本机装的是 MySQL 8.x旧版驱动com.mysql.jdbc.Driver在 MySQL 8 连接串下已经不适用了。更隐蔽的是如果本机用的是 JDK 8 但驱动包是新版也会因为编译版本问题抛UnsupportedClassVersionError。解决先确认 MySQL 版本。MySQL 5.x 用com.mysql.jdbc.DriverMySQL 8.x 用com.mysql.cj.jdbc.Driver同时要把连接串加参数serverTimezoneAsia/ShanghaiuseUnicodetruecharacterEncodingUTF-8。改完之后重启 Tomcat如果还抛Public Key Retrieval is not allowed再在连接串加allowPublicKeyRetrievaltrue。这三个参数是这类项目里最常见的「差一个就死」配置。5.2 中文乱码三个地方字符集不一致表单提交就变问号现象登录页中文用户名输入「张三」点击登录后提示「用户名或密码错误」打开数据库查到username存的值是????。页面显示正常一写库就乱。原因字符集有三层任何一层不一致都会翻车——JSP 页面编码、Servlet 接收请求的编码、MySQL 表结构的编码。很多时候建表脚本用的utf8实际是 MySQL 的 utf8mb3而 JDBC 连接串没带characterEncodingUTF-8数据库层就把 Java 传来的字符串按默认字符集转换中文全部变成问号。解决逐层核对。把建表脚本的DEFAULT CHARSETutf8mb4统一写死JDBC 连接串带useUnicodetruecharacterEncodingUTF-8每个 Servlet 的doPost第一行加request.setCharacterEncoding(UTF-8)如果页面是动态渲染还要检查 JSP 顶部contentTypetext/html; charsetUTF-8是否漏了。这一套走完中文乱码基本根治。5.3 数据库连不上本地能跑换台机器就报 Connection refused现象源码在自己电脑上跑得好好的发给某同事或换了一台电脑启动后访问列表页直接报Communications link failure或者Access denied for user。原因这类项目的数据库配置通常写在src/jdbc.properties或db.properties里常见写法是jdbc.urljdbc:mysql://localhost:3306/health。换机器后如果目标机器的 MySQL 没建同名数据库、用户名密码不一致或者本机 MySQL 端口不是 3306直接连不上是必然的。更隐蔽的是配置里用了绝对路径加载配置文件导致别人那边资源加载失败。解决拆包后第一件事就是打开jdbc.properties或DBUtil.java里的连接常量确认库名、用户名、密码和当前环境一致。导入数据库前先确认库是否建好、脚本是否完整跑完、navicat 里能否用同样的账号密码直接连上。如果jdbc.properties路径有问题建议把配置文件直接放到src根目录用类路径加载避免FileNotFoundException。5.4 Tomcat 9 下 EL 表达式不生效页面输出 ${user.username}现象JSP 页面里写了${user.username}出来不是值而是原样显示字符串“${user.username}”。页面不上数据也不报错数据在 Servlet 端明明查到了。原因Tomcat 对 JSP 的 EL 支持默认分版本Servlet 3.0 / JSP 2.2 以上才默认开启 EL但项目如果用了老的 web.xml 头声明比如web-app版本是 2.3 或 2.4EL 会被当成普通文本。很多课设项目的 web.xml 是多年前从网上抄的头声明版本过低就等于关闭了 EL 求值。解决把web.xml头改成 Servlet 3.1Tomcat 8/9 都支持或者干脆把web-app根元素版本声明升级到 3.0 以上。如果不想动 web.xml更省事的做法是把${user.username}改成% ((User)request.getSession().getAttribute(loginUser)).getUsername() %先跑通功能再回头收拾版本号。6. 把课设升级成真实项目的第一步把 JDBC 直连接成 Druid 连接池6.1 为什么第一步要换连接池高并发只是顺带的稳定才是刚需课设代码里的DBUtil.getConnection()常见写法是DriverManager.getConnection(url, user, password)每次请求都新建物理连接。单机演示没问题一旦页面里多个图表接口同时请求MySQL 的连接数会被打满报Too many connections。Druid 连接池的核心价值不是「变快」而是「连接复用 自动回收」让应用负载上来时不会瞬间把数据库压垮。这个改造的复杂度并不高因为它只动DBUtil一个类。6.2 改造步骤DruidUtil 替换 DriverManager在src目录加一个druid.propertiesdriverClassNamecom.mysql.cj.jdbc.Driver urljdbc:mysql://localhost:3306/health?useUnicodetruecharacterEncodingUTF-8serverTimezoneAsia/Shanghai usernameroot password123456 initialSize5 maxActive20 maxWait10000 testWhileIdletrue validationQuerySELECT 1然后新建一个DruidUtil.javapublic class DruidUtil { private static DataSource dataSource; static { try (InputStream in DruidUtil.class.getClassLoader() .getResourceAsStream(druid.properties)) { Properties props new Properties(); props.load(in); dataSource DruidDataSourceFactory.createDataSource(props); } catch (Exception e) { throw new ExceptionInInitializerError(e); } } public static Connection getConnection() throws SQLException { return dataSource.getConnection(); } }改完之后原来调DBUtil.getConnection()的地方只需要把类名换成DruidUtilDAO 代码一行都不用动。initialSize5是启动时预先创建 5 个连接maxActive20是连接池上限超过这个数新请求会进入maxWait等待队列testWhileIdletrue会在连接闲置时用SELECT 1探活避免拿到已被数据库掐断的死连接。这几个参数里validationQuerySELECT 1是这套系统最值得折腾的一行——MySQL 8 默认连接超时是 8 小时如果晚上挂服务器第二天早上访问报连接断十有八九是没加探活语句。6.3 验证改造有没有生效改完后用如下方式自查正常启动项目多刷新几个图表页然后打开 MySQL 命令行执行SHOW STATUS LIKE Threads_connected;。如果连接池生效这个值应该稳定在个位数而不是随着访问量增长连续刷新 50 次页面后再看连接数不会猛增。如果报Too many connections八成是maxActive配得太高而 MySQL 的max_connections默认才 151把maxActive调到 20 以下基本不会再碰到。从那以后我每次拿到新源码不管是课设还是毕设第一件事就是先打开数据库配置文件和连接工具类配合当前环境把连接池、字符集、驱动版本一次配齐再启动项目。这套运动健康系统断断续续解剖了几天数据库脚本从头到尾过了一遍该藏的坑基本都翻出来了。希望帮到你。本文还有配套的精品资源点击获取