拓冰网站定制 
简介Java Web开发中Servlet、JSP与JDBC构成经典的三层架构至今仍是许多课程设计与毕业设计的核心选型。其原理清晰请求经Servlet分发JSP负责展示JDBC完成数据库读写每一层职责分离便于调试与答辩讲解。这套架构尤其适合登录鉴权、分页查询、一对多关联查询等高频业务场景是理解后端数据链路的理想起点。在实际项目中常见的小说网站、信息管理系统均可复用这套骨架从五张核心表的设计到Filter拦截、MyBatis迁移都有相对成熟的实践范式。本文基于一份典型的Java Web小说网站源码逐层拆解从数据库建表到阅读页渲染的完整路径并梳理本地运行与部署中的常见陷阱为课设或毕设改造提供可落地的参考。1. 基于Java Web的网络在线小说网站课设源码别只拿去改名字要看得懂才能跑得通打开一个标题为“基于Java Web的网络在线小说网站开发项目设计源码”的压缩包里面往往是一个标准的Java Web工程Servlet JSP JDBC带SQL脚本、项目文档和若干张表的数据库设计。这个项目本质上是把常见的信息管理系统换了个业务壳——小说替代图书、书架替代收藏、书评替代留言。对做Java课程设计或毕业设计的人来说它的价值不只是“能跑”而是能拆出登录鉴权、分页查询、一对多关联查询这几块可复用的写法正好覆盖课设答辩里最常被追问的点。这套源码适合两类人一类是要交Java Web课设、需要一个完整参考实现的学生另一类是刚学完Servlet和JSP、想看看一个业务系统从数据库到页面的完整数据链路怎么走的初学者。你要解决的核心问题就三个数据库的表怎么设计、请求怎么分发给对应的Servlet、JSP页面怎么写才能不把逻辑堆在页面上。下面按这个顺序把整个源码项目拆开讲。2. Java Web小说网站的架构选择为什么老三层仍是课设最优解2.1 Servlet JSP JDBC与SSM两条路径怎么选拿到标题之后第一件事不是看代码而是确认技术路线。市面上这类“基于Java Web”的小说网站源码绝大多数跑在两条路上经典Servlet JSP JDBC或者Spring MVC MyBatisSSM的简化版。从标题字面看“Java Web”指向的是前者但不少毕设源码会把Spring Boot版本也打包进去命名上仍然叫“Java Web”。我的建议很直接如果课程要求里只写了“Java Web”而没有限定框架选Servlet JSP JDBC。理由有三个。第一答辩环节老师最常问的是“请求进来之后经历了哪些步骤”三层架构每一步都能拆开讲而Spring Boot版本很容易被追问“那你讲讲Spring IoC是怎么管理的”一句话答不深就露怯。第二Servlet JSP的源码在部署时只需要一个Tomcat和一个MySQL不需要Maven中央仓库下载依赖离线环境也能跑。第三这套代码改造成Spring Boot的成本不高后面想升级随时可以迁。如果你手头的源码已经是SSM结构也不用排斥处理逻辑是等价的——Controller对应ServletMapper对应DAOJSP照样是视图层。下面讲的内容两条路线都能对照。2.2 源码包的目录结构与起手要看的文件一份规范的课设源码包通常包含WebRoot或webapp、src、SQL脚本和一份设计文档。打开后先按这个顺序看SQL脚本建库建表和初始化数据决定了你能看到多少小说可以点src里的实体类小说、章节、用户、书架、书评五个类基本覆盖全部业务Filter和Servlet看web.xml里配置了哪些映射能数出来这个项目有几个功能模块JSP页面index.jsp通常做的是小说列表detail.jsp是小说详情reader.jsp是阅读页不要一上来就双击startup.bat启动Tomcat。先把SQL脚本导入MySQL确认数据库名、用户名和密码再去改JDBC连接配置——绝大多数“跑不起来”的源码问题都出在数据库连接串和后端代码里写死的账号密码对不上。提示源码里如果存在多个项目目录优先选名字带web或war的那个。带ssm或boot字样的是框架版带jsp字样的是纯JSP版两个不要混着部署。3. 把核心链路写明白登录、书库分页、阅读页三段代码直接复用3.1 一块能兜住全部受保护页面的登录拦截Filter小说网站的“登录后才能阅读/收藏/评论”是一个典型鉴权场景。很多课设源码的做法是在每个Servlet里手动检查session代码重复不说漏一个页面就能绕过登录。正确做法是写一个Filter在web.xml里把需要保护的路径全部拦住。public class LoginFilter implements Filter { private static final String LOGIN_PAGE /login.jsp; Override public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request (HttpServletRequest) req; HttpServletResponse response (HttpServletResponse) resp; Object user request.getSession().getAttribute(loginUser); if (user null) { String contextPath request.getContextPath(); response.sendRedirect(contextPath LOGIN_PAGE); return; } chain.doFilter(req, resp); } }这段Filter的逻辑核心是从session里取loginUser这个属性取不到就重定向到登录页取到了就放行。注意放行要调用chain.doFilter(req, resp)不能自己直接return否则请求到不了后面的Servlet。参数说明LOGIN_PAGE用的是相对路径但重定向时拼上了request.getContextPath()这是处理项目名带路径时最稳妥的写法——不知道的项目永远会栽在“页面跳转404”上。在web.xml里配置这个Filter时把/reader/*、/bookshelf/*、/comment/*三组URL都映射进来。3.2 书库列表分页五个参数管住整页数据小说网站的书库列表是典型的分页场景SQL骨架固定靠limit偏移量控制。源码里常见的写法是PageBean DAO两层封装这里把最核心的查询方法写出来。// BookDao.java public ListBook findBooksByPage(int pageNo, int pageSize, String keyword) { String sql SELECT book_id, book_name, author, cover_url, intro, click_count FROM t_book WHERE book_name LIKE ? OR author LIKE ? ORDER BY click_count DESC LIMIT ?, ?; String like % keyword %; int offset (pageNo - 1) * pageSize; PreparedStatement ps connection.prepareStatement(sql); ps.setString(1, like); ps.setString(2, like); ps.setInt(3, offset); ps.setInt(4, pageSize); }注意offset的计算pageNo从1开始第一页的偏移是0所以(1 - 1) * pageSize正好是0。很多源码在这里直接写pageNo * pageSize导致第一页永远少一条、最后一页多一页空数据这是分页最常见的翻车现场。keyword的LIKE查询前后都拼接了%说明这里用的是模糊匹配。如果要兼顾查询效率可以改成前缀匹配——把%只放在keyword前面走索引的概率会高一点但课设规模不用过度优化。pageSize一般在8到12之间书库封面图是网格布局选10最合适。页面底部要显示总页数所以源码里必然还有一个统计SQLSELECT COUNT(*) FROM t_book WHERE book_name LIKE ? OR author LIKE ?这两条SQL的where条件必须保持一致否则总数和列表对不上。3.3 阅读页与章节翻页别把小说正文写进SQL小说阅读页是这类项目里最特殊的一块——正文不是一行而是几千字的大文本。很多课设源码在这里会踩一个很深的坑把章节正文和书籍信息放在同一张表里每次进入阅读页都查出整个正文列表页也把正文load出来页面直接卡死。正确的拆分方式是t_book保存书名、作者、简介等元信息t_chapter保存章节标题、正文和所属书籍的外键。阅读页只按chapter_id查一条记录上下章切换再分别查前一章和后一章的id这是最稳的单表查询方案。%-- reader.jsp 正文输出片段替换掉模板里的纯文本输出 --% div classchapter-content c:out value${chapter.content} / /div div classchapter-nav a href${pageContext.request.contextPath}/reader?id${prevChapterId}上一章/a a href${pageContext.request.contextPath}/reader?id${nextChapterId}下一章/a /div正文用c:out输出不是为了装饰是为了把script和iframe这类字符串转义成普通文本防的是XSS注入。小说正文里有对话和特殊符号如果直接${chapter.content}输出风险很大。上一章和下一章靠prevChapterId和nextChapterId两个属性驱动这两个值在Servlet里用一条SQL查出来SELECT id FROM t_chapter WHERE book_id ? AND chapter_no ? - 1 SELECT id FROM t_chapter WHERE book_id ? AND chapter_no ? 1注意chapter_no是章节序号字段不是主键id。如果直接用主键id做上一章下一章删除某个章节后翻页就断链了。4. 数据库设计五张表撑起在线小说的全部业务4.1 五张表的字段与关系看源码时第一个检查点是建表语句。小说网站的典型表结构是五张表t_user用户、t_book小说、t_chapter章节、t_bookshelf书架/收藏、t_comment评论。这之间有三个关联关系小说对章节是主表对子表的级联关系用户对书架是多对多简化成的用户一对多书架记录评论表通过外键同时关联用户和书籍。实际的建表DDL去掉约束和注释的精简版大体长这样CREATE TABLE t_user ( user_id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, nickname VARCHAR(50) DEFAULT ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_book ( book_id INT PRIMARY KEY AUTO_INCREMENT, book_name VARCHAR(100) NOT NULL, author VARCHAR(50) NOT NULL, cover_url VARCHAR(200) DEFAULT , intro VARCHAR(500) DEFAULT , click_count INT DEFAULT 0, status TINYINT DEFAULT 0 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_chapter ( chapter_id INT PRIMARY KEY AUTO_INCREMENT, book_id INT NOT NULL, chapter_no INT NOT NULL, title VARCHAR(100) NOT NULL, content MEDIUMTEXT ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_bookshelf ( shelf_id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, book_id INT NOT NULL, add_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_comment ( comment_id INT PRIMARY KEY AUTO_INCREMENT, book_id INT NOT NULL, user_id INT NOT NULL, content VARCHAR(1000) NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;charsetutf8mb4是必须项。小说正文里会出现千分号、破折号、特殊空格这类UTF-8三字节覆盖不完整的字符utf8mb4才能存全。t_chapter的content用MEDIUMTEXT不是TEXT——TEXT上限只有64KB一个章节字数稍微多点就溢出报错或截断MEDIUMTEXT上限16MB课设体量下完全够用。username加了UNIQUE约束是防止注册重名这个校验在DAO层插数据时也要先查一遍不能只靠数据库报错兜底。t_bookshelf需要加一个UNIQUE KEY (user_id, book_id)这是防止同一本书重复收藏的关键靠业务代码判断“是否已收藏”不是不行但数据库约束才是最后的防线。4.2 阅读量自增和收藏去重的SQL陷阱阅读量click_count计数大多数人在Servlet里写成“先查出来再加一再更新回去”两步操作在高并发下会丢更新。正确做法是直接在UPDATE语句里对字段做自增UPDATE t_book SET click_count click_count 1 WHERE book_id ?收藏去重则要用INSERT IGNORE或者ON DUPLICATE KEY UPDATE但前提是表上建了对应的唯一索引。收藏接口的完整写法是先按user_id和book_id查一遍书架表有记录就返回“已收藏”没有记录就INSERT。源码里如果只做了“查-插”那么连点两次收藏按钮就会插两条重复记录这个问题答辩时最容易暴露。另一个容易漏的点是删除书籍数据的完整性t_book里的书被删掉后t_chapter里的章节还在书架上收藏这本书的记录也在导致前端页面出现“书籍不存在”的脏数据。所以建表时外键要带ON DELETE CASCADE或者在DAO层手动按顺序删先删评论、再删章节、再删书架记录、最后删书籍信息。看源码时重点看它有没有处理这个顺序。5. Java Web小说网站排错避坑本地能跑、部署翻车的5个典型现场5.1 中文全变问号页面一片乱码现象启动Tomcat后打开小说阅读页所有中文都变成问号或者乱码JSP页面的静态中文正常但数据库里读出来的内容是乱码。原因典型的双重编码不一致。第一层是数据库连接串没指定characterEncoding第二层是Tomcat对GET请求的解码方式和页面声明的编码不一致。常见的是MySQL和连接串都用UTF-8但Tomcat 8.5以后对URL里的中文参数默认用ISO-8859-1解码。解决JDBC连接串固定写成jdbc:mysql://localhost:3306/novel?useUnicodetruecharacterEncodingutf8同时给项目加一个CharacterEncodingFilter把request和response的编码都设成UTF-8。注意Tomcat的server.xml里Connector加URIEncodingUTF-8这一步很容易被忽略没有它搜索关键字“三体”这样的GET参数就会乱码。5.2 部署后CSS和JS全部404现象源码在Eclipse里跑一切正常导出WAR包部署到另一台机器的Tomcat后页面光秃秃的没有任何样式。原因JSP里引静态资源时写了绝对路径如/css/style.css而不是${pageContext.request.contextPath}/css/style.css。当项目部署名不是ROOT时浏览器实际请求的路径是/项目名/css/style.css自然404。解决全局搜索href/和src/统一改成href${pageContext.request.contextPath}/开头。这是这类源码里最常见的“本地能跑换个环境就翻车”的根源。另外在WEB-INF/web.xml里确认welcome-file配置的是index.jsp还是servlet跳转有的源码首页是servlet-mapping映射到/index配错了也会白屏。5.3 数据库连接报Communications link failure现象启动项目登录时报错Communications link failure或者Could not create connection to database server。原因大多数是JDBC驱动版本和MySQL版本不匹配。老源码里写的是com.mysql.jdbc.Driver对应MySQL 5.x而本机装的是MySQL 8.x驱动类名已经迁移到com.mysql.cj.jdbc.Driver并且需要显式配置时区。解决换用com.mysql.cj.jdbc.Driver连接串里加serverTimezoneAsia/Shanghai。如果是MySQL 8.x驱动还要注意allowPublicKeyRetrievaltrue这个参数否则还会抛出Public Key Retrieval is not allowed。这个参数只建议在本机开发环境开生产环境要换用SSL加密连接。5.4 小说正文换行全丢了显示成一大段现象小说章节从数据库读出来后在浏览器里全是连续文本没有段落换行但数据库里看是有换行符的。原因textarea里存的是\r\n换行符HTML页面渲染时把换行符当空白字符折叠了。数据库里存的是换行HTML源文件里也确实有换行但浏览器不渲染\r\n为视觉上的换行。解决两种方案。第一种简单粗暴正文容器用pre标签或CSS加white-space: pre-wrap;缺点是文本字体和排版不好控制。第二种是渲染前把\r\n替换成br /但注意这里必须用c:out先转义HTML再替换换行顺序反了就引入XSS风险。5.5 一键部署脚本里的用户名密码写死现象把源码分享或提交到Git仓库后数据库连接配置里带上了本机的root密码。别人拉下来代码连不上直接改数据库密码才能跑。原因JDBC工具类里把usernameroot和password123456硬编码成常量没有任何外部配置化。解决建议至少把连接参数挪到一个db.properties文件里用Properties类加载这样换机器只改配置文件不动代码。如果项目用的Maven结构还可以把配置放在src/main/resources下配合build的filter功能做环境切换但这个对课设来说不是必需的有一层外部化配置就够用了。6. 验证与进阶把课设源码升级成能拿得出手的作品源码跑通只是起点答辩时“能不能讲清楚系统有哪些非功能性的考虑”才是拉开差距的地方。先做一轮基础验证注册一个新账号、登录、打开十本不同的小说、每本翻两三章、收藏其中几本、发两条评论。这个流程如果全部通顺说明主链路没硬伤。接着再测边界搜索一个不存在的关键字看是否有友好提示、越权直接访问/reader?id一个不存在的章节是否报500、把登录状态清掉再访问书架页面会不会被Filter拦回登录页。这三项在答辩现场最容易被打出来。如果还有余力用JMeter做一轮轻量压测验证页面响应时间。不需要复杂脚本一个线程组加一个HTTP请求就走完一圈参数设置值说明Number of Threads线程数10模拟10个并发用户Ramp-up Period秒11秒内拉满到10个线程Loop Count循环次数20每个用户连续访问20次监听器Aggregate Report看平均响应时间和错误率这个规模下用Servlet JSP MySQL的传统三层架构平均响应时间应该稳定在200ms以内错误率接近0%。如果响应时间飙到秒级优先检查SQL有没有在循环里查询——比如列表页里每本小说都去查一次最新章节那就是典型的N1问题把关联查询改成一次性LEFT JOIN就能解决。想往Spring Boot方向升级的话迁移路径是清晰且机械的原Servlet对应Controller层把doGet/doPost里的逻辑挪到RequestMapping方法里DAO层替换成MyBatis的Mapper接口SQL不动只改参数绑定方式JSP可以继续用Spring Boot里配好InternalResourceViewResolver即可。核心技术点从“Servlet生命周期”变成了“Spring容器管理Bean”但业务代码的骨架可以直接平移。我自己的习惯是交源码之前把项目在另一台空机器上从头部署一遍数据库重新导入、Tomcat重新解压、WAR包重新部署完全模拟拿到这份源码的人的操作路径。这比在开发环境里跑通一百次都有价值——你才能发现哪些步骤是依赖了你本机隐性的环境配置。这个习惯救过我很多次希望帮到你。本文还有配套的精品资源点击获取 Java Web小说网站课设源码拆解：Servlet+JSP+JDBC全流程
简介Java Web开发中Servlet、JSP与JDBC构成经典的三层架构至今仍是许多课程设计与毕业设计的核心选型。其原理清晰请求经Servlet分发JSP负责展示JDBC完成数据库读写每一层职责分离便于调试与答辩讲解。这套架构尤其适合登录鉴权、分页查询、一对多关联查询等高频业务场景是理解后端数据链路的理想起点。在实际项目中常见的小说网站、信息管理系统均可复用这套骨架从五张核心表的设计到Filter拦截、MyBatis迁移都有相对成熟的实践范式。本文基于一份典型的Java Web小说网站源码逐层拆解从数据库建表到阅读页渲染的完整路径并梳理本地运行与部署中的常见陷阱为课设或毕设改造提供可落地的参考。1. 基于Java Web的网络在线小说网站课设源码别只拿去改名字要看得懂才能跑得通打开一个标题为“基于Java Web的网络在线小说网站开发项目设计源码”的压缩包里面往往是一个标准的Java Web工程Servlet JSP JDBC带SQL脚本、项目文档和若干张表的数据库设计。这个项目本质上是把常见的信息管理系统换了个业务壳——小说替代图书、书架替代收藏、书评替代留言。对做Java课程设计或毕业设计的人来说它的价值不只是“能跑”而是能拆出登录鉴权、分页查询、一对多关联查询这几块可复用的写法正好覆盖课设答辩里最常被追问的点。这套源码适合两类人一类是要交Java Web课设、需要一个完整参考实现的学生另一类是刚学完Servlet和JSP、想看看一个业务系统从数据库到页面的完整数据链路怎么走的初学者。你要解决的核心问题就三个数据库的表怎么设计、请求怎么分发给对应的Servlet、JSP页面怎么写才能不把逻辑堆在页面上。下面按这个顺序把整个源码项目拆开讲。2. Java Web小说网站的架构选择为什么老三层仍是课设最优解2.1 Servlet JSP JDBC与SSM两条路径怎么选拿到标题之后第一件事不是看代码而是确认技术路线。市面上这类“基于Java Web”的小说网站源码绝大多数跑在两条路上经典Servlet JSP JDBC或者Spring MVC MyBatisSSM的简化版。从标题字面看“Java Web”指向的是前者但不少毕设源码会把Spring Boot版本也打包进去命名上仍然叫“Java Web”。我的建议很直接如果课程要求里只写了“Java Web”而没有限定框架选Servlet JSP JDBC。理由有三个。第一答辩环节老师最常问的是“请求进来之后经历了哪些步骤”三层架构每一步都能拆开讲而Spring Boot版本很容易被追问“那你讲讲Spring IoC是怎么管理的”一句话答不深就露怯。第二Servlet JSP的源码在部署时只需要一个Tomcat和一个MySQL不需要Maven中央仓库下载依赖离线环境也能跑。第三这套代码改造成Spring Boot的成本不高后面想升级随时可以迁。如果你手头的源码已经是SSM结构也不用排斥处理逻辑是等价的——Controller对应ServletMapper对应DAOJSP照样是视图层。下面讲的内容两条路线都能对照。2.2 源码包的目录结构与起手要看的文件一份规范的课设源码包通常包含WebRoot或webapp、src、SQL脚本和一份设计文档。打开后先按这个顺序看SQL脚本建库建表和初始化数据决定了你能看到多少小说可以点src里的实体类小说、章节、用户、书架、书评五个类基本覆盖全部业务Filter和Servlet看web.xml里配置了哪些映射能数出来这个项目有几个功能模块JSP页面index.jsp通常做的是小说列表detail.jsp是小说详情reader.jsp是阅读页不要一上来就双击startup.bat启动Tomcat。先把SQL脚本导入MySQL确认数据库名、用户名和密码再去改JDBC连接配置——绝大多数“跑不起来”的源码问题都出在数据库连接串和后端代码里写死的账号密码对不上。提示源码里如果存在多个项目目录优先选名字带web或war的那个。带ssm或boot字样的是框架版带jsp字样的是纯JSP版两个不要混着部署。3. 把核心链路写明白登录、书库分页、阅读页三段代码直接复用3.1 一块能兜住全部受保护页面的登录拦截Filter小说网站的“登录后才能阅读/收藏/评论”是一个典型鉴权场景。很多课设源码的做法是在每个Servlet里手动检查session代码重复不说漏一个页面就能绕过登录。正确做法是写一个Filter在web.xml里把需要保护的路径全部拦住。public class LoginFilter implements Filter { private static final String LOGIN_PAGE /login.jsp; Override public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request (HttpServletRequest) req; HttpServletResponse response (HttpServletResponse) resp; Object user request.getSession().getAttribute(loginUser); if (user null) { String contextPath request.getContextPath(); response.sendRedirect(contextPath LOGIN_PAGE); return; } chain.doFilter(req, resp); } }这段Filter的逻辑核心是从session里取loginUser这个属性取不到就重定向到登录页取到了就放行。注意放行要调用chain.doFilter(req, resp)不能自己直接return否则请求到不了后面的Servlet。参数说明LOGIN_PAGE用的是相对路径但重定向时拼上了request.getContextPath()这是处理项目名带路径时最稳妥的写法——不知道的项目永远会栽在“页面跳转404”上。在web.xml里配置这个Filter时把/reader/*、/bookshelf/*、/comment/*三组URL都映射进来。3.2 书库列表分页五个参数管住整页数据小说网站的书库列表是典型的分页场景SQL骨架固定靠limit偏移量控制。源码里常见的写法是PageBean DAO两层封装这里把最核心的查询方法写出来。// BookDao.java public ListBook findBooksByPage(int pageNo, int pageSize, String keyword) { String sql SELECT book_id, book_name, author, cover_url, intro, click_count FROM t_book WHERE book_name LIKE ? OR author LIKE ? ORDER BY click_count DESC LIMIT ?, ?; String like % keyword %; int offset (pageNo - 1) * pageSize; PreparedStatement ps connection.prepareStatement(sql); ps.setString(1, like); ps.setString(2, like); ps.setInt(3, offset); ps.setInt(4, pageSize); }注意offset的计算pageNo从1开始第一页的偏移是0所以(1 - 1) * pageSize正好是0。很多源码在这里直接写pageNo * pageSize导致第一页永远少一条、最后一页多一页空数据这是分页最常见的翻车现场。keyword的LIKE查询前后都拼接了%说明这里用的是模糊匹配。如果要兼顾查询效率可以改成前缀匹配——把%只放在keyword前面走索引的概率会高一点但课设规模不用过度优化。pageSize一般在8到12之间书库封面图是网格布局选10最合适。页面底部要显示总页数所以源码里必然还有一个统计SQLSELECT COUNT(*) FROM t_book WHERE book_name LIKE ? OR author LIKE ?这两条SQL的where条件必须保持一致否则总数和列表对不上。3.3 阅读页与章节翻页别把小说正文写进SQL小说阅读页是这类项目里最特殊的一块——正文不是一行而是几千字的大文本。很多课设源码在这里会踩一个很深的坑把章节正文和书籍信息放在同一张表里每次进入阅读页都查出整个正文列表页也把正文load出来页面直接卡死。正确的拆分方式是t_book保存书名、作者、简介等元信息t_chapter保存章节标题、正文和所属书籍的外键。阅读页只按chapter_id查一条记录上下章切换再分别查前一章和后一章的id这是最稳的单表查询方案。%-- reader.jsp 正文输出片段替换掉模板里的纯文本输出 --% div classchapter-content c:out value${chapter.content} / /div div classchapter-nav a href${pageContext.request.contextPath}/reader?id${prevChapterId}上一章/a a href${pageContext.request.contextPath}/reader?id${nextChapterId}下一章/a /div正文用c:out输出不是为了装饰是为了把script和iframe这类字符串转义成普通文本防的是XSS注入。小说正文里有对话和特殊符号如果直接${chapter.content}输出风险很大。上一章和下一章靠prevChapterId和nextChapterId两个属性驱动这两个值在Servlet里用一条SQL查出来SELECT id FROM t_chapter WHERE book_id ? AND chapter_no ? - 1 SELECT id FROM t_chapter WHERE book_id ? AND chapter_no ? 1注意chapter_no是章节序号字段不是主键id。如果直接用主键id做上一章下一章删除某个章节后翻页就断链了。4. 数据库设计五张表撑起在线小说的全部业务4.1 五张表的字段与关系看源码时第一个检查点是建表语句。小说网站的典型表结构是五张表t_user用户、t_book小说、t_chapter章节、t_bookshelf书架/收藏、t_comment评论。这之间有三个关联关系小说对章节是主表对子表的级联关系用户对书架是多对多简化成的用户一对多书架记录评论表通过外键同时关联用户和书籍。实际的建表DDL去掉约束和注释的精简版大体长这样CREATE TABLE t_user ( user_id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, nickname VARCHAR(50) DEFAULT ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_book ( book_id INT PRIMARY KEY AUTO_INCREMENT, book_name VARCHAR(100) NOT NULL, author VARCHAR(50) NOT NULL, cover_url VARCHAR(200) DEFAULT , intro VARCHAR(500) DEFAULT , click_count INT DEFAULT 0, status TINYINT DEFAULT 0 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_chapter ( chapter_id INT PRIMARY KEY AUTO_INCREMENT, book_id INT NOT NULL, chapter_no INT NOT NULL, title VARCHAR(100) NOT NULL, content MEDIUMTEXT ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_bookshelf ( shelf_id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, book_id INT NOT NULL, add_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_comment ( comment_id INT PRIMARY KEY AUTO_INCREMENT, book_id INT NOT NULL, user_id INT NOT NULL, content VARCHAR(1000) NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;charsetutf8mb4是必须项。小说正文里会出现千分号、破折号、特殊空格这类UTF-8三字节覆盖不完整的字符utf8mb4才能存全。t_chapter的content用MEDIUMTEXT不是TEXT——TEXT上限只有64KB一个章节字数稍微多点就溢出报错或截断MEDIUMTEXT上限16MB课设体量下完全够用。username加了UNIQUE约束是防止注册重名这个校验在DAO层插数据时也要先查一遍不能只靠数据库报错兜底。t_bookshelf需要加一个UNIQUE KEY (user_id, book_id)这是防止同一本书重复收藏的关键靠业务代码判断“是否已收藏”不是不行但数据库约束才是最后的防线。4.2 阅读量自增和收藏去重的SQL陷阱阅读量click_count计数大多数人在Servlet里写成“先查出来再加一再更新回去”两步操作在高并发下会丢更新。正确做法是直接在UPDATE语句里对字段做自增UPDATE t_book SET click_count click_count 1 WHERE book_id ?收藏去重则要用INSERT IGNORE或者ON DUPLICATE KEY UPDATE但前提是表上建了对应的唯一索引。收藏接口的完整写法是先按user_id和book_id查一遍书架表有记录就返回“已收藏”没有记录就INSERT。源码里如果只做了“查-插”那么连点两次收藏按钮就会插两条重复记录这个问题答辩时最容易暴露。另一个容易漏的点是删除书籍数据的完整性t_book里的书被删掉后t_chapter里的章节还在书架上收藏这本书的记录也在导致前端页面出现“书籍不存在”的脏数据。所以建表时外键要带ON DELETE CASCADE或者在DAO层手动按顺序删先删评论、再删章节、再删书架记录、最后删书籍信息。看源码时重点看它有没有处理这个顺序。5. Java Web小说网站排错避坑本地能跑、部署翻车的5个典型现场5.1 中文全变问号页面一片乱码现象启动Tomcat后打开小说阅读页所有中文都变成问号或者乱码JSP页面的静态中文正常但数据库里读出来的内容是乱码。原因典型的双重编码不一致。第一层是数据库连接串没指定characterEncoding第二层是Tomcat对GET请求的解码方式和页面声明的编码不一致。常见的是MySQL和连接串都用UTF-8但Tomcat 8.5以后对URL里的中文参数默认用ISO-8859-1解码。解决JDBC连接串固定写成jdbc:mysql://localhost:3306/novel?useUnicodetruecharacterEncodingutf8同时给项目加一个CharacterEncodingFilter把request和response的编码都设成UTF-8。注意Tomcat的server.xml里Connector加URIEncodingUTF-8这一步很容易被忽略没有它搜索关键字“三体”这样的GET参数就会乱码。5.2 部署后CSS和JS全部404现象源码在Eclipse里跑一切正常导出WAR包部署到另一台机器的Tomcat后页面光秃秃的没有任何样式。原因JSP里引静态资源时写了绝对路径如/css/style.css而不是${pageContext.request.contextPath}/css/style.css。当项目部署名不是ROOT时浏览器实际请求的路径是/项目名/css/style.css自然404。解决全局搜索href/和src/统一改成href${pageContext.request.contextPath}/开头。这是这类源码里最常见的“本地能跑换个环境就翻车”的根源。另外在WEB-INF/web.xml里确认welcome-file配置的是index.jsp还是servlet跳转有的源码首页是servlet-mapping映射到/index配错了也会白屏。5.3 数据库连接报Communications link failure现象启动项目登录时报错Communications link failure或者Could not create connection to database server。原因大多数是JDBC驱动版本和MySQL版本不匹配。老源码里写的是com.mysql.jdbc.Driver对应MySQL 5.x而本机装的是MySQL 8.x驱动类名已经迁移到com.mysql.cj.jdbc.Driver并且需要显式配置时区。解决换用com.mysql.cj.jdbc.Driver连接串里加serverTimezoneAsia/Shanghai。如果是MySQL 8.x驱动还要注意allowPublicKeyRetrievaltrue这个参数否则还会抛出Public Key Retrieval is not allowed。这个参数只建议在本机开发环境开生产环境要换用SSL加密连接。5.4 小说正文换行全丢了显示成一大段现象小说章节从数据库读出来后在浏览器里全是连续文本没有段落换行但数据库里看是有换行符的。原因textarea里存的是\r\n换行符HTML页面渲染时把换行符当空白字符折叠了。数据库里存的是换行HTML源文件里也确实有换行但浏览器不渲染\r\n为视觉上的换行。解决两种方案。第一种简单粗暴正文容器用pre标签或CSS加white-space: pre-wrap;缺点是文本字体和排版不好控制。第二种是渲染前把\r\n替换成br /但注意这里必须用c:out先转义HTML再替换换行顺序反了就引入XSS风险。5.5 一键部署脚本里的用户名密码写死现象把源码分享或提交到Git仓库后数据库连接配置里带上了本机的root密码。别人拉下来代码连不上直接改数据库密码才能跑。原因JDBC工具类里把usernameroot和password123456硬编码成常量没有任何外部配置化。解决建议至少把连接参数挪到一个db.properties文件里用Properties类加载这样换机器只改配置文件不动代码。如果项目用的Maven结构还可以把配置放在src/main/resources下配合build的filter功能做环境切换但这个对课设来说不是必需的有一层外部化配置就够用了。6. 验证与进阶把课设源码升级成能拿得出手的作品源码跑通只是起点答辩时“能不能讲清楚系统有哪些非功能性的考虑”才是拉开差距的地方。先做一轮基础验证注册一个新账号、登录、打开十本不同的小说、每本翻两三章、收藏其中几本、发两条评论。这个流程如果全部通顺说明主链路没硬伤。接着再测边界搜索一个不存在的关键字看是否有友好提示、越权直接访问/reader?id一个不存在的章节是否报500、把登录状态清掉再访问书架页面会不会被Filter拦回登录页。这三项在答辩现场最容易被打出来。如果还有余力用JMeter做一轮轻量压测验证页面响应时间。不需要复杂脚本一个线程组加一个HTTP请求就走完一圈参数设置值说明Number of Threads线程数10模拟10个并发用户Ramp-up Period秒11秒内拉满到10个线程Loop Count循环次数20每个用户连续访问20次监听器Aggregate Report看平均响应时间和错误率这个规模下用Servlet JSP MySQL的传统三层架构平均响应时间应该稳定在200ms以内错误率接近0%。如果响应时间飙到秒级优先检查SQL有没有在循环里查询——比如列表页里每本小说都去查一次最新章节那就是典型的N1问题把关联查询改成一次性LEFT JOIN就能解决。想往Spring Boot方向升级的话迁移路径是清晰且机械的原Servlet对应Controller层把doGet/doPost里的逻辑挪到RequestMapping方法里DAO层替换成MyBatis的Mapper接口SQL不动只改参数绑定方式JSP可以继续用Spring Boot里配好InternalResourceViewResolver即可。核心技术点从“Servlet生命周期”变成了“Spring容器管理Bean”但业务代码的骨架可以直接平移。我自己的习惯是交源码之前把项目在另一台空机器上从头部署一遍数据库重新导入、Tomcat重新解压、WAR包重新部署完全模拟拿到这份源码的人的操作路径。这比在开发环境里跑通一百次都有价值——你才能发现哪些步骤是依赖了你本机隐性的环境配置。这个习惯救过我很多次希望帮到你。本文还有配套的精品资源点击获取