基于JavaEE+原生Servlet+MySQL的村镇旅游网站设计与实现

简介：基于JavaEE与原生Servlet、MySQL实现的村镇旅游网站项目源码，面向JavaWeb课程设计、毕业设计及需要快速搭建完整Web项目的开发者。项目覆盖从前端页面展示到后端数据处理的完整业务链路，贴近真实项目场景，适合作为学习Servlet+JSP+MySQL整合开发的可运行范例，也能为相关课题提供工程参考。资源共739个文件，含415个GIF演示图片、111个JSP页面、69张JPG图片、40个CSS样式、23个JS脚本，以及数据库文件、JAR依赖包、Word/PPT设计文档和辅导视频等，压缩包约74.62MB，目录结构清晰，便于按源码、数据库、配置与文档分类使用，已有534人学习下载。压缩包提供经测试校正可百分百运行的完整源码、数据库脚本、设计文档及操作辅导视频，并附详细项目介绍。读者可据此理解旅游网站的功能设计、前后端交互、数据库表结构及部署流程，也可在现成代码基础上快速二次开发，或以其中思路完成自身毕业设计论文与答辩准备。 每年到课程设计季，后台就会收到大量JavaWeb课设相关的提问，其中一个被点名频率极高的题目，就是"基于JavaEE+原生Servlet+MySQL的村镇旅游网站设计与实现"。很多同学一看到"原生Servlet"就发怵，觉得不用框架怎么开发一个完整网站；但你真正把需求拆开看会发现，这个题目恰恰是最容易拿高分的类型——它把JavaWeb的经典知识全串起来了：JDBC操作、Servlet生命周期、Session会话管理、Filter过滤器、JSP页面渲染，外加一套多表关联的MySQL数据库。这篇文章我不准备讲教科书上的概念，而是按你实际写代码、跑项目、参加答辩的操作顺序，把村镇旅游网站怎么做完整盘一遍。不管你是已经拿到源码项目正在研究怎么跑起来，还是打算从零手写一个交课设，都可以照着这个思路往下走。

1. 先拆业务需求再动手写代码

1.1 村镇旅游网站到底解决谁的什么问题

做课设最容易犯的毛病，是拿到题目就开始建工程、画界面，结果做出来的系统功能零散、逻辑说不通。村镇旅游网站的业务背景其实很清晰：乡村旅游资源分散，游客在线上很难找到完整的村镇景点、民宿、特产和线路信息，只能到了当地再打听；村镇管理方又缺少一个低成本的信息展示窗口，没法统一发布内容和接收游客咨询。

所以这个项目的核心使命，就是打通"游客找信息、商家发信息"这两条线。系统天然分成两个端口：前台面向游客，提供从发现景区、查看详情、预订民宿到留言互动的完整动线；后台面向管理员，负责景点录入、订单处理、留言审核和用户管理。角色也要从一开始就分清楚：普通用户可以注册登录、浏览下单、发留言；管理员则额外持有后台权限。很多同学写着写着把前后台混在一起，就是因为在需求阶段没有把这两个角色边界划清楚。

1.2 从用户操作路径反推功能模块

我习惯用"用户故事"来拆模块。你可以把自己代入一个周末想去村镇旅游的游客：他先搜索目的地有哪些景点，点进详情页看图片和介绍，觉得不错再研究住宿，可能还想了解当地特产，最后通过电话或线上留言咨询商家。整个过程拆出来，就是一个个功能点。

• 注册登录：用户名/手机号注册，密码加密存储，登录状态用Session保存，可选"记住我"；
• 景点浏览：首页推荐位、景点分类筛选、景点详情展示图片和文字介绍；
• 特产与线路展示：游客可查看推荐旅游线路和当地特产信息，下单或发起咨询；
• 民宿预订：游客选择日期、房型，填写联系人和手机号提交订单；
• 留言评论：游客对景点或商家留言，后台审核后展示到前台页面；
• 后台管理：管理员维护景点、线路、特产、民宿信息，处理订单，审核留言，管理用户。

前端界面用JSP+Bootstrap拼出来，数据访问用JDBC+连接池，中间业务控制和跳转交给Servlet。这套技术组合虽然老派，但每个层次边界特别清楚，画系统架构图、写课程设计文档、准备答辩都很顺手。

2. 技术选型：原生Servlet不是老古董，而是课设场景下的最优解

2.1 题目限制与框架自由度的权衡

很多同学会问：JavaEE方向的课设，为什么不用Spring Boot，开发效率不是高很多吗？答案就在题目里。这类课程设计通常明确限定"基于JavaEE+原生Servlet"，目的是考察你是否理解Web开发的底层原理，而不是考察你会不会调用框架。

退一步讲，就算题目不加限制，原生Servlet在这个项目里也完全够用。村镇旅游网站的并发量不大、业务复杂度不高，Servlet+JSP+JDBC这套组合足以支撑全部功能，依赖极少，部署也省心。更重要的是，答辩时你能把一个HTTP请求从浏览器发出、经过Tomcat容器处理、调用Servlet、访问数据库、再返回页面的完整过程，每一步都讲清楚。这是用Spring Boot"一键生成"的项目很难做到的——框架帮你把细节都藏起来了，被老师追问底层时容易卡壳。

另一个容易被忽略的点：JSP的本质就是Servlet。JSP页面第一次被访问时，会被Tomcat编译成一个Servlet类再执行。理解了这层关系，你写JSP时就会明白哪些逻辑该放页面、哪些逻辑必须放Servlet类里，分层意识会强很多。

2.2 环境配套与项目包结构

环境上我建议固定一套"保守组合"，不要追新：

• JDK 8 或 JDK 11
• Tomcat 8.5 或 Tomcat 9.0
• MySQL 5.7 或 8.0
• 开发工具用 IntelliJ IDEA 或 Eclipse for Java EE

Tomcat版本是重点，后面我会专门讲Tomcat 10带来的坑。开发时可以用Maven管理依赖，能少受点手动导包的苦，但工程本身不需要Spring相关依赖。一个清晰的项目包结构大概是这样的：

src/main/java com.xxx.travel controller // 存放各类Servlet service // 业务逻辑接口与实现 dao // JDBC数据访问层 entity // 实体类 filter // 过滤器 com.xxx.travel.listener // 监听器 src/main/webapp admin // 后台管理JSP页面 front // 前台页面 static/css // 样式文件 static/js images WEB-INF/web.xml

把Servlet类统一放到controller包，页面按前台后台分目录，长期维护会轻松很多。项目里还会配套一份课程设计文档，我建议包结构确定之后先截图放进文档的"系统设计"章节，后面写代码时再补细节，效率会高不少。

3. 数据库设计：8张表撑起整个村镇旅游业务

3.1 核心表之间的关系与建表要点

村镇旅游网站的数据模型可以分成"内容型"和"交易型"两类。内容型包括用户、景点、分类、特产、线路、民宿；交易型主要是订单，外加用户产生的留言评论。参照常见的实现方案，核心表可以这样设计：

订单表里用item_type和item_id同时服务民宿预订和特产购买，是一种反规范化设计。好处是前台下单和后台查单都只用一张表，减少重复代码；代价是查询具体商品时要根据item_type去对应的表里取数据。如果数据库课的老师比较强调范式，拆成tb_hotel_order和tb_product_order两张子表也没问题，只是业务代码会多一些。

景点表里的cover_img是封面图，pics可以存多个图片路径，用逗号分隔。路径建议存放相对路径，比如/upload/img/scenic01.jpg，页面渲染时再拼项目上下文，而不是把图片的二进制数据塞进数据库，那样数据库会膨胀得很快。

3.2 容易忽略的设计细节与初始化数据

有几个设计细节值得提前定好。第一，密码字段不要明文存储，哪怕课设要求不高，也至少做一层MD5加盐，注册时生成随机盐值，登录时把用户输入的密码和盐值一起做哈希再比对，答辩时这是一个非常自然的加分点。第二，外键能不用就不用。MySQL外键在级联删除时容易把数据搞乱，课程设计的数据量根本到不了需要数据库级外键的程度，外键逻辑放在Java的Service层维护更清晰，删除顺序自己控制。第三，订单号建议用时间戳+随机数生成，比如202505021030123456这种格式，避免主键自增裸奔。

初始化数据也特别重要。空荡荡的网站演示效果很差，建议预置10个以上景点、5个分类、若干条特产和民宿数据，再插入一个管理员账号，比如admin / admin123。这些INSERT语句写进一个data.sql文件，和建表语句放一起，文档中要写清楚导入步骤。答辩现场最尴尬的情况就是拿着一个空数据库讲功能，提前塞好数据能避免这种场面。

4. 核心请求链路：从登录、浏览到后台管理一次讲透

4.1 登录与会话：Session、Cookie和过期时间

登录模块是整个系统里被复用得最多的功能，几乎每个页面都要用到用户状态。实现思路很固定：用户提交用户名密码，LoginServlet调用UserService查询用户表，比对成功后把用户信息放入Session，需要"记住我"就再写一个Cookie保存加密后的用户标识，有效期设置成7天。

Session的过期时间要提前想好。Tomcat默认是30分钟，游客在前台浏览时间长一点就掉线了，下单时被提示"请重新登录"很影响体验。在web.xml里可以显式调整：

<session-config> <session-timeout>60</session-timeout> </session-config>

管理员和普通用户的登录态建议用不同的Session Key，比如admin_user和login_user，防止两个角色在同一个浏览器会话里互相覆盖登录状态。这一点尤其在演示的时候特别重要：你先登录了用户端，再打开后台登录，如果用的是同一个Key，后台登录会把用户登录状态挤掉，页面跳转就会乱掉。

4.2 列表与详情：request域、forward和JSP渲染

游客首页要展示推荐景点、精品线路和特产，数据加载模式都是一样的：Servlet调用Service查询数据，把结果List放进request域，然后forward转发到JSP，JSP用JSTL的forEach标签循环渲染。以景点列表为例：

List<Scenic> list = scenicService.listByCategory(catId); request.setAttribute("scenicList", list); request.getRequestDispatcher("/front/scenic_list.jsp") .forward(request, response);

JSP里遍历输出：

<c:forEach items="${scenicList}" var="scenic"> <div class="card"> <img src="${pageContext.request.contextPath}${scenic.coverImg}" /> <h3><a href="scenicDetail?id=${scenic.id}">${scenic.name}</a></h3> <p>${scenic.description}</p> <span>门票：${scenic.ticketPrice}</span> </div> </c:forEach>

这里有个新手最容易踩的坑：用request.setAttribute存数据之后，如果跳转用的是sendRedirect重定向，数据会直接丢；只有forward转发才能把request域中的数据带给JSP。所以"查询数据并跳页面"的场景一定要用forward，而"提交完表单之后刷新列表避免重复提交"的场景才用重定向。

4.3 后台权限控制：用一个Filter挡住未登录请求

后台管理模块通常包括景点管理、订单管理、留言审核、用户管理等。安全上最基础的一条，就是不能让未登录的人直接通过URL访问后台JSP页面。如果每个后台Servlet里都写一遍Session判断，代码会很啰嗦，正确做法是写一个权限过滤器，统一拦截/admin/*路径：

public class AdminAuthFilter implements Filter { @Override public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) req; HttpSession session = request.getSession(false); if (session != null && session.getAttribute("admin_user") != null) { chain.doFilter(req, resp); } else { request.getRequestDispatcher("/admin/login.jsp").forward(req, resp); } } }

页面资源也有一个安全技巧：把后台JSP放到WEB-INF目录下面。WEB-INF下的文件不能被浏览器直接URL访问，只能通过Servlet内部forward跳转，这样即使Filter配置漏了一个路径，用户也没法直接打开后台页面源码。

4.4 连接池、字符集监听器与全局过滤器

Servlet项目里，数据库连接不能每次都new一个Connection，频繁创建销毁连接的开销太大了。建议用Druid或DBCP连接池，在项目启动时通过ServletContextListener初始化一次DataSource，放进ServletContext里供全局使用：

@WebListener public class AppInitListener implements ServletContextListener { @Override public void contextInitialized(ServletContextEvent sce) { DruidDataSource ds = new DruidDataSource(); ds.setUrl("jdbc:mysql://localhost:3306/travel" + "?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8"); ds.setUsername("root"); ds.setPassword("123456"); ds.setInitialSize(5); ds.setMaxActive(20); sce.getServletContext().setAttribute("dataSource", ds); } }

同时强烈建议配一个全局字符编码过滤器，把请求和响应统一成UTF-8，尤其是POST请求要在读取参数之前调用setCharacterEncoding。另外要提醒一下：连接池不是连上就完事，每次从池里取连接用完必须归还，否则运行一段时间连接池耗尽，页面就开始卡死，这个问题后面会有专门一节展开。

5. 复现这个项目时最容易翻车的六个细节

5.1 Tomcat版本和javax/jakarta包名

这是近几年新增的坑。Tomcat从10.0开始，把Servlet API的包名从javax.servlet改成了jakarta.servlet。如果你拿到手的源码里import的是javax.servlet.http.HttpServlet，一定别放在Tomcat 10里运行，否则编译直接报错，或者页面404找不到请求路径。

判断方法很简单：打开源码看一眼import。如果是javax开头，匹配Tomcat 8.5或9.0；如果是jakarta开头，才需要Tomcat 10及以上。这个版本匹配问题，是很多拿到源码的同学第一关就卡住的原因。

5.2 MySQL 8.0驱动类、时区和字符集

MySQL 8.0开始，官方驱动类从com.mysql.jdbc.Driver改成了com.mysql.cj.jdbc.Driver，连接URL也要带上时区和SSL设置：

String url = "jdbc:mysql://localhost:3306/travel" + "?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8";

如果项目里还在用老的5.x驱动去连8.0数据库，通常会报ClassNotFoundException或者Unsupported major.minor version。出现这类错误时，先从lib目录检查mysql-connector-java的版本，别急着改代码。另外线上环境如果用MySQL 8.0，而手头代码是很多年前的SQL脚本，导入时也可能会遇到排序规则不兼容的问题，稍后单独讲。

5.3 DAO层的连接泄漏

很多课设源码在DAO层取Connection之后，finally块里没有正确关闭PreparedStatement和ResultSet，运行时间一长，连接池被耗尽，页面响应越来越慢直到超时。

排查连接泄漏的办法不复杂：把Druid的maxActive调小一点，比如设为10，跑一遍功能后打开数据库的进程列表，如果看到大量Sleep状态的连接堆积，基本可以断定是连接没有释放。写DAO时务必把释放操作放在finally里，推荐直接用JDK 7引入的try-with-resources写法：

try (Connection conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement(sql); ResultSet rs = ps.executeQuery()) { // 处理结果集 }

这种写法在编译后会自动调用close，比自己写finally还保险。

5.4 中文乱码的三段排查

中文乱码不是单一原因造成的，要从请求、数据库、响应三段一起排查。请求方面，POST提交要在读取参数前执行request.setCharacterEncoding("utf-8")，最好统一放到Filter里；数据库方面，连接URL带characterEncoding=utf8还不够，建表时也要保证表和字段的字符集是utf8mb4；响应方面，JSP页面头部的pageEncoding和contentType要都是UTF-8。

如果GET请求出现乱码，还要注意Tomcat版本。Tomcat 8.0以上对URI的默认解码就是UTF-8，而老版本需要手动修改server.xml里的URIEncoding。现在的环境基本不会遇到老问题，但如果你用的是别人提供的配置，留个心。

5.5 图片上传后的文件丢失

景点、特产都要上传图片，很多项目用commons-fileupload来实现。最容易踩的坑是把图片保存到了项目的target或build目录里，这样一旦重新部署，上传的图片就全丢了，数据库里只剩一堆死链接。

更稳妥的方案是配置独立上传目录，比如在web.xml里给图片上传写一个虚拟路径映射，把磁盘上的/data/travel/upload映射成URL路径/upload/*。数据库里存相对路径/upload/img/xxx.jpg，页面展示用${pageContext.request.contextPath}${picPath}拼接，这样项目重新发布也不怕丢图。

5.6 SQL脚本导入时被忽略的表结构与字符集问题

工程里通常附带travel.sql或database.sql，导入时请先查看脚本开头有没有CREATE DATABASE语句，以及是否指定了utf8mb4字符集。如果脚本是在MySQL 5.7时代写的，导入到MySQL 8.0时可能会出现排序规则不兼容的警告，通常不影响运行，但建议直接用图形化工具新建一个utf8mb4数据库，再导入表结构，会稳妥很多。

图形化工具方面，Navicat、DBeaver或者IDEA自带的Database面板都可以。DBeaver是开源免费的，教学环境下用起来没有授权顾虑，连上MySQL之后导入SQL脚本也很方便。

6. 从"跑通交差"到"高分答辩"的提升路径

6.1 低成本高分的三个改造点

项目跑通之后，你可以做三个低成本的改造，提升整体完成度。第一个，把DAO层里的SQL全部改成PreparedStatement方式，杜绝SQL注入风险。这个动作看起来基础，但很多课设源码为了省事直接用字符串拼接SQL，被老师一追问就露馅。第二个，给前台加一个搜索框，用关键字模糊匹配景点名称、地址和介绍三个字段。第三个，给后台列表加分页，用LIMIT offset, pageSize实现，再配合一个页码导航条，视觉效果和工程规范度立刻不一样。

如果时间还有富余，可以在后台加一个简单的统计页面，把景点浏览量和订单量用ECharts画成柱状图或折线图。图表一出，演示环节的观感提升非常明显，而且ECharts的使用难度很低，网上半小时就能学会。

6.2 答辩前必须能脱稿讲清的三件事

答辩环节最考验的不是功能多不多，而是你对系统的理解。我建议把下面三个问题练到脱稿能讲的程度：

第一，一个完整请求从浏览器到页面显示的流转过程。要能把Filter、Servlet、Service、DAO、MySQL每个环节分别做了什么说清楚。第二，会话状态是怎么管理的。要能答出Session和Cookie的区别，登录状态为什么能保存，"记住我"的实现原理是什么。第三，数据库表之间怎么关联。要能说出每张表的主键外键逻辑，以及订单表用item_type同时服务两种业务的取舍原因。

这三个问题基本覆盖了答辩老师八成以上的提问方向。每写完一个Servlet，顺手在文档里画一张它的请求流程图，把请求路径和数据流向标出来，等答辩前一晚翻出来看，效果比临时背稿子好太多。

6.3 这个项目还能往哪扩展

村镇旅游网站是个很适合做扩展的题目。你可以给游客加一个行程规划模块，把多个景点串成自定义路线；也可以在前台接入地图API，展示每个景点的地理位置；更实际的方向是学完Spring Boot之后，把这个项目里的Service层和DAO层原封不动搬过去，把Servlet替换成Controller注解方式，体验一次从"手动路由"到"自动路由"的迁移过程。这种迁移本身就是一次很好的对比学习。

最后提一句题外话：这类课设项目，很多人抱着"跑通就行"的心态在做。但如果你愿意在跑通之后多花一个晚上，把其中任意一个Servlet的完整请求链路讲给同学听一遍，你会发现JavaWeb的知识密度比想象中大得多。源码和文档都是参考，真正能带走的是你对这套请求模型的掌握，别浪费了这个练手机会。

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