基于JSP的在线家政网设计与实现：从技术选型到部署验收

简介：基于JSP的在线家政网设计与实现毕业设计文档，面向需要完成Web开发类课程设计或毕业设计的计算机专业学生，系统性地展示了在线家政网从需求分析、可行性论证到数据库设计、页面功能实现的全过程。压缩包内仅含1个docx文档，体积1.02MB，文件虽不多但内容非常完整，涵盖中英文摘要、目录、引言、项目背景与意义、可行性分析、总体设计原则、系统分析等章节，并配有功能模块图和数据库表设计思路。文档重点讲解了JSP技术、B/S模式、SQL Server 2008数据库的概念结构设计、逻辑结构设计与物理结构设计，以及MyEclipse开发平台的使用，对家政预约、家教预约、用户求职申请、个人后台管理等核心模块做了结构化分析，完整还原了一个家政网站系统的设计流程。已有126人学习下载，适合作为同类型毕业设计或课程设计参考，能帮助读者快速理清系统开发流程、模块划分与数据库表设计，避开常见的功能设计遗漏，也可用于项目答辩前的提纲复习。

1. 这份《基于 JSP 的在线家政网设计与实现》docx，我拆完直接跑通了

拿到这份资料时我第一反应是“又是一篇毕设论文”，但把配套工程在 MyEclipse 里跑起来之后，发现它比想象中完整得多。这是一个基于 JSP 的在线家政网设计与实现项目，前台能看到家政人员列表、人员详情、招聘信息，注册用户能提交家政预约和家教预约，也能以求职者身份在线投递信息；管理员登录后台后，能审核预约、增删家政人员、维护新闻和友情链接。用户提交完申请，回到个人中心能看到预约状态是“待审核”还是“已通过”，整个闭环是通的。适合两类人拆：一是做 JSP 方向毕业设计、需要一份 B/S 完整工程做参考的人；二是公司要快速搭一个轻量级“信息发布 + 预约审核”平台、想直接抄现成流程的开发者。这篇笔记按选型、数据库、核心流程、排查、验收的顺序拆完，每一步都能照着复现。

2. 技术栈选型：JSP + SQL Server 2008 现在还值不值得跑

先说结论：这套组合在 2024 年看确实“老”，但它的价值不在技术先进性，而在完整度和可复现性。项目采用 B/S 模式，用户端只有一个浏览器，服务端部署 Tomcat 跑 JSP/Servlet，数据落在 SQL Server 2008。家政公司这种“用户分散、管理员集中”的场景，B/S 最大的好处是免安装客户端，升级系统只需要替换服务器上的 Web 应用，不需要像 C/S 那样挨个机器更新。

2.1 三个选型理由：为什么不是 Spring Boot + MySQL

很多人拿到这种题目第一反应是“怎么不用 Spring Boot + MySQL”。但回到这个项目的原始约束，三点决定了它用 JSP 更合理。

第一，开发周期短。MyEclipse 里建一个 Web Project 就能直接写 JSP，不需要拉 Maven 依赖、不需要配一堆注解，一个 .jsp 文件既能写 HTML 又能写 Java 逻辑，调试链路极短——改完保存、刷新浏览器就能看到结果。这对毕设或者两三天要出 Demo 的场景非常友好。

第二，文档与代码对得上。这套系统的设计文档、数据字典、E-R 图早就按“结构化分析”写好了，代码里的表名、字段名和论文里的数据库设计完全一致，答辩时讲“概念结构设计 → 逻辑结构设计 → 物理实现”这条线非常顺畅。换成 Spring Boot 重写，反而要额外解释为什么和文档不一致。

第三，SQL Server 2008 有图形化管理工具。企业管理器里建库、建表、看数据、导脚本都方便，适合没有专职 DBA 的小团队。JSP 技术在 Java 生态里的地位类似“老黄牛”：一次编写到处运行、Servlet API 成熟、容器选择多，虽然前沿性和 Spring 系框架没法比，但做中小型信息管理系统绰绰有余。

JSP vs Spring Boot 的取舍，我的判断很直白：

2.2 环境搭建：JDK、Tomcat、SQL Server 2008 三个版本要对齐

这套系统对环境版本非常敏感，我实际跑通用的版本组合是：JDK 1.7 + Tomcat 7 + SQL Server 2008 + MyEclipse 自带绑定。SQL Server 2008 装好后，需要先做两件事：启用 sa 账号的“SQL Server 身份验证”，并在 SQL Server Configuration Manager 里启用 TCP/IP 协议、把端口固定成 1433。这两步千万别跳，后面连接失败八成是这里出的问题。

数据库连接公共类我一般这么写，这个工程里也是同样的套路：

package util; import java.sql.Connection; import java.sql.DriverManager; import java.sql.SQLException; public class DBHelper { private static final String DRIVER = "com.microsoft.sqlserver.jdbc.SQLServerDriver"; private static final String URL = "jdbc:sqlserver://localhost:1433;DatabaseName=homecare"; private static final String USER = "sa"; private static final String PASSWORD = "123456"; static { try { Class.forName(DRIVER); } catch (ClassNotFoundException e) { throw new RuntimeException("JDBC 驱动未找到，请检查 sqljdbc4.jar 是否放到 WEB-INF/lib", e); } } public static Connection getConn() throws SQLException { return DriverManager.getConnection(URL, USER, PASSWORD); } }

这段代码是整个系统的数据库入口，所有 Servlet 和 JSP 页面里取连接、执行 SQL 都靠它。URL 里的DatabaseName=homecare对应你导入的库名，如果脚本里建的是别的名字，这里必须改成一致，否则会报“数据库不存在”。USER 和 PASSWORD 改成你 SQL Server 里真实存在的登录名和密码。JDBC 驱动 jar 包（sqljdbc4.jar）必须放在WEB-INF/lib目录下，这是 JSP 工程里最常见的翻车点——驱动没放进 lib，类加载不到，页面一打开就是 ClassNotFoundException。

部署到 Tomcat 也有固定套路：在 MyEclipse 里右键项目 → Run As → MyEclipse Server Application，选择绑定的 Tomcat。这里要注意地址栏里的项目名，访问路径是http://localhost:8080/项目名/index.jsp，不是http://localhost:8080/index.jsp。后面避坑章节我会专门展开说这个 404 问题。

3. 数据库先行：从 E-R 图到 7 张表的设计逻辑

数据库是这套系统的核心，所有业务流程——注册、展示、预约、审核、新闻管理——最终都落到表上。原设计文档做了概念结构设计和逻辑结构设计，我拆解后整理成 7 张核心表，它们之间的关联关系直接决定了前后台代码怎么写。

3.1 概念结构设计：实体、属性与关系梳理

从数据需求分析可以抽出这些实体：管理员、会员（注册用户）、家政人员（保姆）、人员类型、预约记录、新闻、友情链接。实体之间的核心关系是：

• 会员提交预约，生成一条预约记录，关联到某个家政人员；
• 家政人员归属于某个类型（保姆、月嫂、保洁、家教等）；
• 管理员审核预约记录，修改审核状态；
• 管理员维护新闻和友情链接，供前台展示。

这些关系在表结构上体现为“外键字段 + 冗余名称字段”的混合方式。比如预约表里既有bianhao（家政人员编号）又有leixing（类型名），既方便关联查询，又能在列表页直接显示，不用每查一次预约都 JOIN 一次人员表。这是老 JSP 项目里很常见的“空间换性能”做法。

7 张表清单如下：

3.2 核心表建表语句与字段约束

我在 SQL Server 2008 里重建这三张核心表时，用了下面的脚本，字段保持与原设计一致：

-- 会员注册表 CREATE TABLE yonghuzhuce ( ID INT IDENTITY(1,1) PRIMARY KEY, yonghuming VARCHAR(50), -- 用户名，登录账号 mima VARCHAR(50), -- 密码，明文存储是老项目特征 xingbie VARCHAR(50), dianhua VARCHAR(50), QQ VARCHAR(50), shenfenzheng VARCHAR(50), dizhi VARCHAR(50), ye FLOAT, -- 余额字段，扩展用 addtime DATETIME DEFAULT GETDATE() ); -- 家政人员信息表 CREATE TABLE baomu ( ID INT IDENTITY(1,1) PRIMARY KEY, bianhao VARCHAR(50), -- 人员编号，页面展示用 xingming VARCHAR(50), -- 姓名 xingbie VARCHAR(50), nianling VARCHAR(50), xueli VARCHAR(50), -- 学历 dizhi VARCHAR(50), jiguan VARCHAR(50), -- 籍贯 zhaopian VARCHAR(50), -- 照片路径 hunyin VARCHAR(50), -- 婚姻状况 dianhua VARCHAR(50), gongling VARCHAR(50), -- 工龄 leixing VARCHAR(50), -- 类型：保姆/月嫂/家教 jiankangzheng VARCHAR(50),-- 健康证情况 gongziyaoqiu VARCHAR(50), -- 工资要求 shisuyaoqiu VARCHAR(50), -- 食宿要求 gongzuoshijian VARCHAR(50),-- 工作时间 jianjie VARCHAR(500), -- 个人简介 addby VARCHAR(50), -- 添加人 issh VARCHAR(50) DEFAULT '1', -- 审核状态，1显示 0隐藏 addtime DATETIME DEFAULT GETDATE() ); -- 预约申请表 CREATE TABLE baomuyuyue ( ID INT IDENTITY(1,1) PRIMARY KEY, bianhao VARCHAR(50), -- 被预约人员编号 leixing VARCHAR(50), -- 类型：家政/家教 yonghuming VARCHAR(50), -- 提交预约的用户名 xingming VARCHAR(50), -- 联系人 dianhua VARCHAR(50), dizhi VARCHAR(200), -- 服务地址 beizhu VARCHAR(500), -- 备注 issh VARCHAR(10) DEFAULT '0', -- 审核状态：0待审核 1已通过 addtime DATETIME DEFAULT GETDATE() );

建表时有几个细节值得注意。IDENTITY(1,1)是 SQL Server 的自增主键写法，等价于 MySQL 的AUTO_INCREMENT，做删除操作后不会自动复用编号，所以页面上的bianhao字段是用来给人看的业务编号，和主键 ID 不是一回事。issh字段在这个项目里是真正的“状态开关”：baomu 表里默认1表示前台直接可见，baomuyuyue 表里默认0表示预约提交后需要管理员审核。两个表同样叫issh，含义却完全不同，写代码时容易搞混，这个坑后面细说。zhaopian字段存的是相对路径而不是二进制图片，实际项目里要配合一个 upload 目录存放图片文件。

4. 前后台核心流程：预约、求职、审核怎么串起来

整个系统的业务主线是“用户浏览 → 提交预约 → 管理员审核 → 用户查看状态”。这条线前后台分开实现，前台面向注册用户，后台面向管理员，中间靠baomuyuyue表和issh字段衔接。

4.1 前台流程：列表展示与预约提交

前台首页展示家政人员列表，查询逻辑很简单：从 baomu 表里取issh = '1'的记录，表示只展示审核通过的人员。页面用一个 JSP 文件就能搞定：

<%@ page import="java.sql.*, util.DBHelper" %> <%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %> <% Connection conn = DBHelper.getConn(); PreparedStatement ps = conn.prepareStatement( "SELECT * FROM baomu WHERE issh = ? ORDER BY addtime DESC"); ps.setInt(1, 1); // 1 表示审核通过，前台才可见 ResultSet rs = ps.executeQuery(); %> <table> <tr><th>姓名</th><th>类型</th><th>年龄</th><th>学历</th><th>操作</th></tr> <% while (rs.next()) { %> <tr> <td><%=rs.getString("xingming")%></td> <td><%=rs.getString("leixing")%></td> <td><%=rs.getString("nianling")%></td> <td><%=rs.getString("xueli")%></td> <td><a href="baomuDetail.jsp?ID=<%=rs.getInt("ID")%>">查看详情并预约</a></td> </tr> <% } %> </table> <% rs.close(); ps.close(); conn.close(); %>

这段代码展示了老 JSP 项目最典型的写法：页面里直接写 Java 脚本片段（Scriptlet），查完数据再循环拼接 HTML。这里有两个关键点：一是查询用PreparedStatement而不是字符串拼接，issh用?占位，避免 SQL 注入；二是每次用完 ResultSet、PreparedStatement、Connection 都要手动 close，老项目没有连接池，不关连接很快会把数据库连接池耗尽。ORDER BY addtime DESC让新添加的人员排前面，这个排序在管理员后台也适用。

点击“查看详情并预约”进入人员详情页，页面下方是预约表单：

<form action="addBaomuYuyue.jsp" method="post"> <input type="hidden" name="bianhao" value="<%=rs.getString("bianhao")%>" /> <input type="hidden" name="leixing" value="<%=rs.getString("leixing")%>" /> <input type="text" name="xingming" placeholder="联系人姓名" /> <input type="text" name="dianhua" placeholder="联系电话" /> <input type="text" name="dizhi" placeholder="服务地址" /> <textarea name="beizhu" rows="3" placeholder="备注，如期望服务时间"></textarea> <button type="submit">提交预约</button> </form>

表单提交到addBaomuYuyue.jsp，处理逻辑是插入一条预约记录：

<%@ page import="java.sql.*, util.DBHelper" %> <% request.setCharacterEncoding("UTF-8"); String bianhao = request.getParameter("bianhao"); String leixing = request.getParameter("leixing"); String yonghuming = (String) session.getAttribute("username"); // 从会话取登录用户 String xingming = request.getParameter("xingming"); String dianhua = request.getParameter("dianhua"); String dizhi = request.getParameter("dizhi"); String beizhu = request.getParameter("beizhu"); Connection conn = DBHelper.getConn(); String sql = "INSERT INTO baomuyuyue(bianhao, leixing, yonghuming, xingming, dianhua, dizhi, beizhu, issh, addtime) " + "VALUES (?, ?, ?, ?, ?, ?, ?, 0, GETDATE())"; PreparedStatement ps = conn.prepareStatement(sql); ps.setString(1, bianhao); ps.setString(2, leixing); ps.setString(3, yonghuming); ps.setString(4, xingming); ps.setString(5, dianhua); ps.setString(6, dizhi); ps.setString(7, beizhu); int n = ps.executeUpdate(); ps.close(); conn.close(); if (n > 0) { response.sendRedirect("myAppointment.jsp"); // 跳到“我的预约”页面 } else { out.print("提交失败，请重试"); } %>

这段提交逻辑有几个参数层面的细节。session.getAttribute("username")是登录时写入会话的用户名，如果用户没登录直接提交，这里取到 null，插入数据库就会违反非空约束——所以前台页面在表单提交前要校验 session。issh固定写 0，意思是提交的预约先进入待审核状态，等管理员后台操作。GETDATE()是 SQL Server 的当前时间函数，让数据库生成时间戳，避免应用层传字符串时间格式不匹配。提交成功后response.sendRedirect跳转到“我的预约”页面，用户能立刻看到自己新提交的这条记录，状态显示“待审核”。这就是原设计里说的“个人信息展示页面”的闭环。

家教预约和在线求职走的是同一条预约表。家教信息也挂在 baomu 表里，leixing字段设为“家教”；在线求职的信息同样插入 baomuyuyue，只是leixing区分成“求职”。用户在个人中心看到的“我的应聘信息”，本质上就是查baomuyuyue WHERE yonghuming = 当前用户名，不需要额外的表。这也是这套设计比较省事的地方。

4.2 后台流程：登录校验与预约审核

后台登录界面校验的是 allusers 表，查用户名和密码是否匹配，匹配后把管理员身份写进 session。关键判断是cx字段（权限级别），普通用户和管员理进后台看到的功能菜单不一样。

预约审核是后台最核心的操作，逻辑概括起来一句话：修改baomuyuyue.issh字段。我封装成一个独立的审核方法：

package admin; import java.sql.Connection; import java.sql.PreparedStatement; import util.DBHelper; public class AppointmentAudit { /** * 审核预约 * @param id 预约记录 ID * @param isSh 审核结果："1" 通过，"0" 驳回 */ public boolean audit(int id, String isSh) { String sql = "UPDATE baomuyuyue SET issh = ? WHERE ID = ?"; try (Connection conn = DBHelper.getConn(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, isSh); ps.setInt(2, id); return ps.executeUpdate() == 1; } catch (Exception e) { e.printStackTrace(); return false; } } }

审核的逻辑核心就是 Update 一条记录。issh置为1，用户在前台“我的预约”里看到状态变成“已通过”；置为0，就是驳回。同一个方法干两件事，通过与否只取决于传入的isSh参数。这里要注意 try-with-resources 的写法在 JDK 1.7 才支持，如果环境是 JDK 1.6 会编译不过。我在 MyEclipse 里给这个工程建的 JDK 是 1.7，Tomcat 7 也原生支持，没问题。

后台的家政人员信息管理和新闻管理，本质是对 baomu 表和 xinwentongzhi 表的增删改查。添加家政人员时，页面里的“类型”下拉框数据来自 leixing 表，存进 baomu.leixing 字段；新闻管理则是往 xinwentongzhi 表插记录，前台首页读取时按addtime倒序显示最新公告。整个后台没有复杂的权限分级，只要 session 里有管理员标记就能进，适合小范围内的内部管理场景。

5. 避坑记录：从“论文”到“能跑”的五个常见问题

这套工程在 MyEclipse 里跑通的过程，我踩了不少坑，每一个都有代表性。下面五条是我实际遇到的问题，按“现象、原因、解决”的套路记录，后面接手这类 JSP 项目的人可以直接对照排查。

5.1 SQL Server 2008 连不上：先查 TCP/IP 和 1433 端口

现象：JDBC 执行DriverManager.getConnection时报错，提示Error opening socket或Connection refused: connect，但 SQL Server Management Studio 能正常连接。

原因：SQL Server 2008 默认没启用 TCP/IP 协议，或者服务运行时没有监听 1433 端口。Management Studio 走的是共享内存或命名管道，JDBC 走 TCP/IP，两者通道不一样，所以 SSMS 能连、JDBC 连不上。

解决：打开 SQL Server Configuration Manager → SQL Server 网络配置 → 启用 TCP/IP，然后在 IP 地址标签页把 1433 端口填上，重启 SQL Server 服务。如果服务器开了防火墙，还要加一条 1433 端口的入站规则。改完配置后用命令行telnet localhost 1433测一下端口通不通，通了再跑页面。

5.2 Tomcat 部署后 404：多半是项目名写对了没

现象：Tomcat 启动成功，但访问http://localhost:8080/index.jsp报 404，页面死活打不开。

原因：MyEclipse 里项目名、部署名和浏览器地址栏路径三者不一致。工程文件叫homecaresys，部署到 Tomcat 后上下文路径可能是OnlineHome，访问路径就得是http://localhost:8080/OnlineHome/index.jsp。实际项目里项目名五花八门，很多人漏了中间的项目名直接访问根路径。

解决：在 MyEclipse 的 Servers 视图里双击 Tomcat，查看 Deploy Location 和 Web Context 的实际值；或者到 Tomcat 的webapps目录看部署出来的文件夹名，那个才是真实路径。以后遇到 JSP 项目 404，第一优先排查上下文路径，而不是怀疑代码写错。

5.3 JSP 页面中文乱码：三层编码要统一

现象：页面显示的中文全是问号，或者从表单提交的中文到后台变成乱码，存进数据库再查出来还是乱码。

原因：三层编码不一致——JSP 文件本身的存储编码、HTTP 响应的Content-Type编码、数据库表的排序规则。老 MyEclipse 工程默认 GBK，但如果页面里写了pageEncoding="UTF-8"，文件元数据又是 GBK，就会冲突。

解决：每个 JSP 页面顶部统一加<%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>；接收请求的页面在取参数前先执行request.setCharacterEncoding("UTF-8")；数据库表创建时排序规则选 Chinese_PRC，如果表已经建好，用ALTER DATABASE ... COLLATE Chinese_PRC_CI_AS调整。三条都做了，乱码基本能杜绝。

5.4 JDBC 驱动和 JDK 版本不匹配：ClassNotFoundException 的隐蔽来源

现象：启动 Tomcat 后访问页面直接报java.lang.ClassNotFoundException: com.microsoft.sqlserver.jdbc.SQLServerDriver，或者提示Unable to load the class，但WEB-INF/lib下明明有驱动 jar。

原因：SQL Server 的 JDBC 驱动分多个版本，sqljdbc.jar只支持 JDK 5，sqljdbc4.jar需要 JDK 6 及以上。环境是 JDK 1.7 却放了一个老的sqljdbc.jar，类名一样但版本不对。还有一种情况是同时存在多个版本的驱动 jar，Tomcat 加载顺序不定，加载了旧版本。

解决：统一用sqljdbc4.jar（或者更新的sqljdbc42.jar），删掉WEB-INF/lib下所有其他版本的 SQL Server 驱动。同时右键项目 → Build Path → Configure Build Path，确认驱动 jar 没有被重复引用。这个坑最隐蔽的地方在于错误信息不直接说版本问题，而是报 ClassNotFound，容易让人误判为 jar 没放进去。

5.5 图片路径和显示定位：家政人员照片不显示的排查思路

现象：baomu 表zhaopian字段有值，比如upload/1.jpg，但页面上<img>标签显示空白或红叉。这就是“jsp 图片如何对坐标定位”这类问题的实际场景——路径定位不对。

原因：JSP 页面里写的图片路径是相对路径，但当前页面 URL 层级不同，相对路径解析结果就不一样。比如当前 URL 是http://localhost:8080/homecare/baomuDetail.jsp，图片路径写upload/1.jpg，浏览器会解析成http://localhost:8080/homecare/upload/1.jpg，如果图片实际上存放在http://localhost:8080/homecare/WebRoot/upload/1.jpg，自然找不到。

解决：图片路径统一存“相对于 WebRoot 的完整路径”，页面展示时用request.getContextPath()拼接根路径。老 JSP 项目里最常见的写法是<img src="<%=request.getContextPath()%>/upload/<%=rs.getString("zhaopian")%>" />。还有一个相关的小问题：管理员上传图片后，页面没刷新导致看起来“图片没上传成功”，提交后做一个response.sendRedirect回列表页，或者用<meta http-equiv="refresh" content="0;url=...">让页面加载完后自动刷新一次，就能看到最新结果。

6. 部署与验收：用一张清单确认系统真的可以交付

系统跑通只是第一步，判断“能不能交付”要靠一张验收清单。我每次拆这类 JSP 项目都会走一遍完整验收流程，从用户注册到管理员审核，把主链路全部测一遍。下面这张表可以直接抄作业：

验收时有两个容易忽略的细节。第一，用两个不同的浏览器分别登录用户和管理员，避免共享 session 导致判断错误；第二，预约提交流程可以用 HTTP 工具做一次 POST 请求，验证接口是否强制校验登录状态——如果没带登录态也能提交成功，说明接口存在越权风险，交付前至少要在页面端加 session 校验。这个项目的老代码对越权防护比较粗糙，我在跑通后自己补了一层 session 空值判断。

线上正式部署时还有两个习惯，是我从长期维护老项目里养成的：部署前在 SQL Server 里做一次完整备份，给一个“后悔药”；改代码时给每个 JSP 页面文件前加一行注释标注修改人和日期。老项目不比新框架，没有热部署和单元测试兜底，改错一个字段可能在页面上没有任何报错，只是数据悄悄不对了。

这套系统真正的价值是“完整”——它有前台展示、用户注册、预约提交、后台审核、状态回显，麻雀虽小五脏俱全，所有 JSP 毕设、B/S 课程设计、预约类管理系统的常见需求它都覆盖到了。从那以后我每次接这种老 JSP 项目，都强制先跑一遍上面的验收清单再谈改代码，能少走好几个小时的弯路。希望帮到你。

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