图书管理系统JSP层实战：EL表达式与JSTL应用及乱码404排查指南-代码聚汇网

图书管理系统JSP层实战：EL表达式与JSTL应用及乱码404排查指南

投研帮·2026-09-03·阅读 22 GEO检测（免费）

JSPEL表达式JSTL

|难度：普通|阅读约 40 分钟

实训项目做到第4天，通常都是同一个心态：后台代码、数据库、Servlet路由这些硬骨头都啃完了，就剩下一堆JSP页面，觉得“不过是写几个网页嘛”，结果真正动手改的时候才发现，JSP层才是整个图书管理系统里最磨人的部分。如果你也是在做javaweb实训作业的图书管理系统，这几天大概也遇到了类似的情况——后台明明能查到数据，页面就是显示不出来；明明能跳转，路径就是一直404；明明写的是中文，浏览器里全变成问号。这篇文章就把我这几天完善JSP层的实战过程梳理一遍，从页面职责划分、JSP脚本片段和EL表达式的配合，到前后端数据贯通、编码路径数据库连接的坑，再到最终“源码+数据库”交付前的高分自查清单，完整走一遍。

1. JSP层在图书管理系统中的真实定位：不是“最后随便写写”，而是“成绩单的门面”

很多同学做实训项目容易陷入一个误区：把JSP当成“把Java代码塞进HTML里”的工具，觉得JavaWeb项目就是前端页面套几个Java语法。这种理解在图书管理系统这个场景里特别危险，因为实训老师评分的时候，真正打开浏览器一个一个点的，不是你的Service层写得有多优雅，而是页面能不能正常显示、操作能不能顺利走通、报错会不会直接甩出一个500页。

1.1 前3天做了什么，第4天到底还剩什么

按照正常的javaweb实训进度，前3天大概完成了这些事情：

第1天：搭项目结构，配好Tomcat、MySQL，建好数据库表（图书表、读者表、借阅表、管理员表、分类表），写好JDBC工具类。
第2天：写完实体类和DAO层，实现图书、读者、借阅记录的增删改查。
第3天：写完Servlet，配置好web.xml或者注解路由，把请求转发和重定向的基本流程调通。

到这一步，项目的“后端能力”已经齐了——你可以在Servlet里直接调用DAO拿到数据，然后用response.getWriter().println()在页面上输出一行图书列表的JSON。但实训作业要求的是完整的图书管理系统，老师要在浏览器里看到的是一个能操作、能展示、能跳转的Web应用，不是返回JSON字符串的接口。所以第4天的核心任务就是把JSP层补全，把Servlet里的数据变成浏览器里漂亮的表格和表单。

1.2 为什么说JSP层是“成绩单的门面”

实训评分有一个特别现实的逻辑：功能再怎么完善，如果打开页面白屏、布局错乱、字体全是乱码，老师的第一印象就毁了。JSP层在这个项目里承担三个角色：

数据展示：把数据库里的图书信息、读者信息、借阅记录渲染成HTML表格，让用户能“看到”数据。
流程入口：通过表单提交、超链接跳转，把用户的请求发送给对应的Servlet。
状态反馈：操作成功或失败后的提示页面，比如“借阅成功”“该图书已借出”“请先登录”。

这三个角色听起来简单，但做起来很容易翻车。尤其是第4天把JSP层完善以后，会遇到很多“后台明明没问题，页面却出问题”的情况，后面我逐一展开讲。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 实训项目里JSP页面的代码组织方式：脚本片段、EL表达式和JSTL各干各的活

刚开始写JSP的时候，大多数人都习惯这样写：在页面顶部写一大段<% ... %>JSP脚本片段，把Java代码直接怼进页面里，然后HTML里穿插无数个<%= %>输出。

jsp复制<%
    List<Book> bookList = new BookDao().findAll();
    for (Book book : bookList) {
        out.println("<tr><td>" + book.getName() + "</td></tr>");
    }
%>

这种写法在功能上没问题，也能跑通，但项目一旦复杂起来就会很难受。第4天完善JSP层的时候，我做的第一件事就是把这些脚本片段逐步替换成EL表达式和JSTL标签。不是单纯为了“看起来规范”，而是有实操层面的好处。

2.1 为什么不要在每个页面都写`<% ... %>`

图书管理系统至少有图书列表、图书添加、图书修改、图书删除确认、读者列表、借阅列表、登录页、注册页、个人信息页这些JSP页面。如果每个页面都用脚本片段写业务逻辑，会出现三个问题：

JSP页面越来越臃肿。一个图书列表页，光Java代码可能就要几十行，HTML结构反而淹没在<% %>和<%= %>里，后期维护想改个表格样式都看不清结构。
异常处理很混乱。脚本片段里的Java代码如果抛出异常，页面直接显示500，而且异常堆栈会暴露在控制台里，想定位问题得在一堆页面里找你到底在哪个JSP写了这段逻辑。
数据获取的代码会重复。比如每个页面都要从session里拿当前登录用户，如果每次都用脚本片段写一遍，代码浪费不说，还容易出现低级Bug。

实训阶段最重要的事情是保证页面稳定。把业务逻辑留在Servlet，JSP只负责用EL表达式取数据、用JSTL标签做循环和判断，页面的容错率会高很多。

2.2 EL表达式和JSTL在图书管理系统里的实际用法

EL表达式的核心作用是从作用域对象（request、session、application）里取值。比如登录成功后把管理员对象丢进session：

java复制HttpSession session = request.getSession();
session.setAttribute("admin", admin);

JSP页面里就可以这样取：

jsp复制<p>欢迎你，${sessionScope.admin.username}</p>

图书列表页是最典型的场景。Servlet查询完列表后放request里：

java复制request.setAttribute("bookList", bookList);
request.getRequestDispatcher("bookList.jsp").forward(request, response);

JSP页面里用JSTL的c:forEach循环输出：

jsp复制<table border="1">
    <tr>
        <th>编号</th>
        <th>书名</th>
        <th>作者</th>
        <th>价格</th>
        <th>库存</th>
        <th>操作</th>
    </tr>
    <c:forEach items="${bookList}" var="book">
        <tr>
            <td>${book.id}</td>
            <td>${book.name}</td>
            <td>${book.author}</td>
            <td>${book.price}</td>
            <td>${book.stock}</td>
            <td>
                <a href="BookServlet?action=edit&id=${book.id}">编辑</a>
                <a href="BookServlet?action=delete&id=${book.id}" onclick="return confirm('确定删除该图书吗？')">删除</a>
            </td>
        </tr>
    </c:forEach>
</table>

这段代码的核心优势是：页面里没有一行Java代码，c:forEach自动循环，${book.name}自动调用Book实体类的getter方法，数据和显示完全分离。就算后期修改了实体类的字段名，页面报错也会更早暴露，便于排查。

2.3 JSTL引入时最容易犯的错

用JSTL不是简单地写个<c:forEach>就能跑起来，必须在JSP页面顶部引入标签库：

jsp复制<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

很多同学写完这行还是报错，问题多半出在缺少JSTL依赖的jar包。这里要特别注意：JSTL不是Tomcat自带的，需要手动放两个jar包到WEB-INF/lib目录下——jstl.jar和standard.jar。如果你用的Jakarta EE或更新的Tomcat版本，可能需要用jakarta.servlet.jsp.jstl-api和jakarta.servlet.jsp.jstl两个Maven依赖。实训项目如果是手动拷贝jar包的方式，建议直接去Apache Tomcat官网下载JSTL 1.2版本，解压后把jar包丢进lib目录，然后重启Tomcat。

我因为这个卡了快一个小时，页面一直报javax.servlet.jsp.tagext.TagLibraryValidator相关的错误，最后发现是jar包版本和Tomcat版本不匹配。Tomcat 9及以后版本建议用JSTL 1.2.5，Tomcat 8及以前用1.2.1就行。

3. 从登录页到图书借阅：JSP层完整贯穿的业务流复盘

图书管理系统的核心业务流其实很清晰：登录验证身份，进入主页面后管理图书、管理读者、处理借阅和归还。每个环节的JSP页面不是孤立的，它们通过Servlet接收请求、跳转页面、携带数据串成一条链。第4天完善JSP层的时候，最好沿着完整的业务流走一遍，每走到一个页面就检查那个页面的数据展示、表单提交和跳转逻辑。

3.1 登录页与登录校验：表单提交后的页面去向

登录页的JSP应该是最简单的，但是有一个细节容易被忽视：登录表单的action路径和Servlet的映射路径必须匹配。很多同学会用相对路径，结果页面在/book/login.jsp的时候能提交，但一旦跳转到/book/admin/index.jsp再点登录，就404了。

我的建议是登录表单统一用绝对路径：

jsp复制<form action="${pageContext.request.contextPath}/LoginServlet" method="post">
    <label>用户名：</label>
    <input type="text" name="username" required>
    <label>密码：</label>
    <input type="password" name="password" required>
    <button type="submit">登录</button>
</form>

${pageContext.request.contextPath}是JSP里获取项目上下文路径的标准写法，不管页面放在哪个目录，拼出来的URL都是/项目名/LoginServlet，不会再出现相对路径导致的404问题。这一点在第4天完善JSP层时值得统一替换一次，把所有表单的action和所有<a>超链接的href都改成这种写法。

登录成功的跳转也要分情况：如果你是管理员登录，跳转到admin/main.jsp；如果你是普通读者，跳转到reader/main.jsp。这个判断逻辑放在Servlet里完成，不要在JSP里写<% if (...) %>。JSP只负责在顶部判断当前session里存的是管理员还是读者，分别展示不同的导航菜单。

3.2 图书列表页和分页展示：JSP层如何优雅地显示数据

图书列表页是整个系统的核心页面，因为几乎所有的操作——添加、修改、删除、借阅——都要先看到图书列表才能发起。第4天完善列表页的时候，有几个点值得重点处理：

第一，数据为空的状态。 如果数据库里一行数据都没有，表格下面会空空荡荡，体验很差。用c:if判断一下列表是否为空：

jsp复制<c:if test="${empty bookList}">
    <tr><td colspan="6" style="text-align:center;">暂无图书数据，请先添加</td></tr>
</c:if>

第二，分页逻辑。 图书数量多的时候不分页，页面会非常长。分页需要SQL层面的LIMIT配合，Servlet里接收页码参数，计算总页数，JSP里渲染上一页/下一页按钮。分页的核心参数有四个：当前页码currentPage、每页条数pageSize、总记录数totalCount、总页数totalPages。把这些参数通过request传递到JSP后，页面里可以这样渲染分页按钮：

jsp复制<div class="page-bar">
    <c:if test="${currentPage > 1}">
        <a href="BookServlet?action=list&page=${currentPage - 1}">上一页</a>
    </c:if>
    <span>第 ${currentPage} / ${totalPages} 页</span>
    <c:if test="${currentPage < totalPages}">
        <a href="BookServlet?action=list&page=${currentPage + 1}">下一页</a>
    </c:if>
</div>

第三，操作列。 列表中的“编辑”“删除”“借阅”操作要拼上图书id，URL里参数用EL表达式输出。这里特别提醒：删除操作建议加一个onclick="return confirm('确定删除吗？')"，在客户端弹一次确认框，减少误操作。等价的提交确认逻辑在借阅和归还操作里也可以加上。

3.3 添加和修改图书的表单页：表单回显的两种实现

添加图书和修改图书可以共用一个bookForm.jsp页面。添加时表单所有字段都是空的；修改时表单要把当前图书的信息回显到输入框里。实现的思路是：Servlet在跳转到表单页之前，给request设置一个book对象，JSP页面通过EL表达式给输入框的value赋值。

jsp复制<input type="text" name="name" value="${book.name}" required>
<input type="text" name="author" value="${book.author}" required>
<input type="text" name="price" value="${book.price}" required>
<input type="hidden" name="id" value="${book.id}">

如果是添加操作，Servlet没有设置book属性，${book.name}会输出空字符串，表单就是空白的。这个共用一个页面的方案可以少写一个JSP文件，也方便统一维护样式。但是要注意：price这种数字类型的字段，如果数据库里是DECIMAL(10,2)，实体类里对应的字段是BigDecimal，EL表达式输出时不会自动保留两位小数。更稳妥的方案是实体类把price定义成String，或者JSP里用<fmt:formatNumber>标签格式化：

jsp复制<fmt:formatNumber value="${book.price}" pattern="#0.00"/>

使用fmt标签也需要在页面顶部引入标签库：

jsp复制<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>

3.4 借阅与归还页面：状态联动是JSP层的重头戏

图书管理系统的高分亮点通常在借阅和归还的交互设计。一个基础版借阅流程是：点击图书列表里的“借阅”按钮，跳转到借阅页面，页面里显示当前图书的信息和当前读者的信息，然后提交借阅表单。

这个环节的JSP页面有一个关键细节：借阅页面需要同时拿到图书信息和读者信息。所以对应的Servlet处理逻辑要同时调用图书DAO和读者DAO，然后把两个对象分别放进request：

java复制request.setAttribute("book", bookDao.findById(bookId));
request.setAttribute("reader", readerDao.findById(readerId));
request.getRequestDispatcher("borrow.jsp").forward(request, response);

JSP页面里展示借阅信息时，直接用EL表达式取：

jsp复制<p>图书名称：${book.name}</p>
<p>图书作者：${book.author}</p>
<p>借阅人：${reader.name}</p>
<p>借阅日期：${borrowDate}</p>
<p>应还日期：${returnDate}</p>

归还页面更简单，通常只需要在借阅记录的列表中显示“应还日期”和“实还日期”，点击“归还”按钮把该条记录的returnDate更新为当前日期，同时将图书库存加一。这个操作的结果反馈，通常用一个message.jsp页面统一展示：

jsp复制<p>${message}</p>
<a href="${pageContext.request.contextPath}/BorrowServlet?action=list">返回借阅列表</a>

这样的页面虽然简单，但可以复用于所有操作成功或失败的提示，是JSP层“状态反馈”角色的标准实现。

4. 编码、路径、数据库连接与浏览器行为：JSP层最容易踩的坑和排查链路

第4天做完业务流之后，通常会进入一个“改Bug地狱”的阶段。JSP层的Bug不太一样，它们往往不是逻辑问题，而是环境、编码、路径这些“外围因素”导致的。这里把这几天实测踩过的坑和排查思路完整列出来，这些才是实训项目里最能拉开分数差距的经验。

4.1 中文乱码问题：为什么页面、数据库、URL三处都要设UTF-8

图书管理系统是中文数据重灾区——书名、作者、读者姓名、出版社全是中文。处理中文乱码必须从三条链路同时解决：

第一，JSP页面本身的编码。 每个JSP页面都要在顶部写全三个指令：

jsp复制<%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>

注意：pageEncoding是告诉JSP引擎这个页面文件本身用什么编码解析；contentType是告诉浏览器以什么编码显示。这两个不一致，页面就会乱码。

第二，Servlet接收请求参数的编码。 如果表单提交的是POST请求，Servlet里必须在读取任何参数之前设置请求编码：

java复制request.setCharacterEncoding("UTF-8");

如果漏了这行，表单里的中文会以默认的ISO-8859-1编码被解析，到DAO层入库的时候全变成“?????”。更保险的做法是在Servlet的doPost方法第一行就执行这个设置，或者用Filter统一设置。

第三，数据库连接URL的编码。 JDBC连接MySQL时，URL里要带上characterEncoding和useSSL参数：

properties复制jdbc:mysql://localhost:3306/library?useUnicode=true&characterEncoding=UTF-8&useSSL=false&serverTimezone=Asia/Shanghai

useUnicode=true和characterEncoding=UTF-8两个参数要同时出现，serverTimezone在MySQL 8.0以上的版本必须配置，否则会报时区错误。

第四，数据库表本身和连接字符集。 建库的时候用utf8mb4来支持emoji和特殊字符，建表的默认字符集也顺手指定：

sql复制CREATE DATABASE library DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

这四处设置缺一个，中文乱码就会以各种诡异的形态出现。排错的时候不要无头苍蝇一样乱改，建议依次检查“数据库表编码——JDBC连接编码——Servlet请求编码——JSP页面编码”这一条链路。

4.2 路径404问题：相对路径和绝对路径的边界到底在哪

第4天完善JSP层时，最常遇到的现象就是：从index.jsp点击“图书管理”能正常跳转，但从bookList.jsp点击“删除”就404。原因99%是路径写错了。

举个具体的例子：项目部署名为library，页面在/library/admin/bookList.jsp，这个时候在页面里写了<a href="BookServlet?action=list">——浏览器解析出的地址是/library/admin/BookServlet。如果BookServlet的映射路径是/BookServlet，Servlet容器会去/library/BookServlet找，路径对不上，自然404。

解决方案就是我前面提到的，在JSP页面里一律用${pageContext.request.contextPath}拼URL前缀。更规范的做法是做一个公共的base标签：

jsp复制<%
    String basePath = request.getScheme() + "://" + request.getServerName()
            + ":" + request.getServerPort() + request.getContextPath() + "/";
%>
<base href="<%=basePath%>">

把这个<base>标签放在每一个JSP页面的<head>里，之后页面里所有相对路径的URL都会自动以项目根目录为基准来解析，不管是href、action还是src属性都不会再出现404。要特别注意：使用<base>之后，页面里的锚点跳转（比如<a href="#section">）需要改成绝对URL，否则也会被base带偏，这是很多人在用<base>标签时踩过的坑。

4.3 浏览器缓存导致的“代码改了但页面没变”

JSP层改样式或者改JavaScript后，经常遇到浏览器里看到的效果没变化。这不是你的代码问题，也不是Tomcat没生效，而是浏览器把JSP渲染后的HTML缓存了。尤其是在调试阶段，同一个URL反复访问，很容易被缓存干扰。

最简单的处理办法是JSP页面的响应头里设置禁止缓存：

java复制<%
    response.setHeader("Cache-Control", "no-store");
    response.setHeader("Pragma", "no-cache");
    response.setDateHeader("Expires", 0);
%>

或者你在浏览器里强制刷新（Ctrl+F5）也能解决大部分问题。但如果项目里涉及到静态资源文件（CSS、JS），建议开发阶段在引用链接后面加一个版本参数：

jsp复制<link rel="stylesheet" href="${pageContext.request.contextPath}/css/style.css?v=20250101">

改一次样式就换一次v的值，这样能确保浏览器拉取到最新的文件。这个技巧在实训答辩演示的时候特别有用，避免现场演示时页面样式还是旧的，显得项目没改完。

4.4 数据库驱动类找不到和时区报错：两个最常见的启动失败场景

完善JSP层的过程中，你可能会在启动Tomcat时碰到两个非常经典的报错：

第一个是java.lang.ClassNotFoundException: com.mysql.jdbc.Driver。这个问题说明mysql-connector-java的jar包没有放到WEB-INF/lib目录下，或者放到了别的位置。Tomcat的类加载机制决定了WEB-INF/lib下的jar包才能被Web应用使用。如果是Maven项目，检查pom.xml里是否引入了依赖：

xml复制<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>8.0.33</version>
</dependency>

第二个是com.mysql.cj.jdbc.Driver和serverTimezone相关的报错。MySQL 8.0以上版本的驱动类名改成了com.mysql.cj.jdbc.Driver，而且要求必须指定serverTimezone。驱动加载代码统一写成：

java复制Class.forName("com.mysql.cj.jdbc.Driver");
String url = "jdbc:mysql://localhost:3306/library?useUnicode=true&characterEncoding=UTF-8&useSSL=false&serverTimezone=Asia/Shanghai";

把这两处处理掉，数据库连接层面的启动问题基本就清零了。

4.5 JSP页面上直接写Java代码的风险，以及为什么实训阶段尤其要避免

网上搜索“jsp脚本片段”“如果在jsp上写java代码的风险”能搜到很多讨论，很多人仍然习惯把查询数据库、判断权限的逻辑直接写在<% %>里。从实训评分的角度讲，这个习惯至少会带来三个风险：

数据库连接对象容易泄漏。在JSP脚本片段里写new BookDao().findAll()，如果DAO内部没有正确处理连接的关闭，每次页面访问都会占用一个数据库连接，实训这种短时间多次点击演示的场景，很快就会把连接池耗尽。
业务逻辑暴露在视图层。如果一个JSP页面里既能查询图书又能查询读者，代码的耦合度会越来越高。后面想加一个“仅管理员可见”的判断，每个页面都要写一遍权限检查，改动量大且容易漏。
页面调试混乱。脚本片段里的异常不会像Servlet那样有清晰的日志，很多时候直接在浏览器里显示NullPointerException，但你根本不知道是页面顶部还是页面中部的代码抛出来的。

我建议的“安全边界”是：JSP页面里允许出现的最复杂Java代码，仅限于<%=basePath%>这种路径拼接和创建SimpleDateFormat这样的格式化工具，凡是涉及数据库操作的、涉及业务判断的，全部放到Servlet和Service层。这样第4天做完之后，后续不管是自己改功能还是老师抽查代码，都会轻松很多。

5. 源码+数据库打包交付前的高分自查清单：实训老师到底在看什么

实训作业的最终交付物通常是“项目源码+数据库脚本+讲解演示”。很多同学的代码功能是完整的，但最后分数不够高，缺的就是交付细节。第4天完善JSP层之后，建议对照下面这个自查清单逐项过一遍，这是几天项目实战下来总结出的实训评分视角。

检查项	自查标准	常见问题
数据库脚本	是否包含建库、建表、测试数据三段脚本，文件命名清晰	只有建表语句没有测试数据，老师导入后看不到效果
项目结构和命名	包名分层清晰，类名和方法名有语义	所有Servlet堆在一个包，DAO和Service混在一起
页面显示	浏览器打开所有页面，排版正常、中文无乱码	编码设置遗漏导致中文乱码
登录权限	未登录时直接访问内部页面是否被阻止	登录校验Filter缺失，绕过登录直接访问列表页
操作反馈	增删改查后是否有明确的成功/失败提示页面	操作完直接返回列表，用户不知道自己操作是否成功
代码规范	JSP中无大量脚本片段，EL和JSTL合理使用	页面里写满`<% %>`导致代码混乱
README	是否有项目简介、运行环境、数据库导入步骤	老师拿到项目不知道从哪里跑起来

5.1 数据库脚本的“三个文件原则”

数据库相关的内容建议整理成三个SQL文件，分别命名为01_create_database.sql、02_create_table.sql、03_insert_data.sql，放在一个db目录下。三个文件职责分离的好处是，老师导入数据时可以分步执行，排查问题也容易定位。尤其是03_insert_data.sql里要准备充分的测试数据，图书至少要10本以上，读者至少3个，借阅记录至少5条，这样演示的时候页面才丰满，不会“空空如也”影响观感。

5.2 登录校验Filter：一个JSP层“隐形但加分”的组件

实训老师在演示的时候一定会试一个操作：不登录，直接输入admin/bookList.jsp的地址访问内部页面。如果这个请求直接打开了图书列表，说明你的项目存在严重的权限漏洞，会在评分时被扣分。

解决办法是写一个登录拦截Filter，在JSP层前面加一道关卡：

java复制public class LoginFilter implements Filter {
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {
        HttpServletRequest req = (HttpServletRequest) request;
        HttpServletResponse resp = (HttpServletResponse) response;
        HttpSession session = req.getSession();
        Object user = session.getAttribute("user");
        if (user == null) {
            resp.sendRedirect(req.getContextPath() + "/login.jsp");
        } else {
            chain.doFilter(request, response);
        }
    }
}

然后在web.xml里配置Filter的映射范围：

xml复制<filter>
    <filter-name>LoginFilter</filter-name>
    <filter-class>com.library.filter.LoginFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>LoginFilter</filter-name>
    <url-pattern>/admin/*</url-pattern>
    <url-pattern>/reader/*</url-pattern>
</filter-mapping>

这样admin和reader目录下的所有JSP页面在展示前都会校验session中是否有用户信息，没有就跳回登录页。这个Filter是第4天完善JSP层时性价比最高的一个组件，代码量不大，但对项目安全性和评分的提升非常明显。

5.3 README文档怎么写才能让老师“一眼看懂”

实训作业提交后，老师拿到你的项目压缩包，第一反应肯定是打开README看怎么运行。如果README写不清楚，老师可能连项目都跑不起来，后面功能再完善也白搭。

一个合格的README至少包含以下内容：

项目名称和简介：一行话说清楚“这是一个基于JSP+Servlet+MySQL的图书管理系统”。
运行环境：JDK版本、Tomcat版本、MySQL版本。
数据库导入步骤：从01_create_database.sql开始按顺序执行三个脚本。
项目部署步骤：Eclipse/IDEA里如何导入项目，如何配置Tomcat，如何修改db.properties里的数据库连接信息。
默认管理员账号密码：比如admin / 123456。
功能模块列表：列清楚系统有哪些功能，方便老师对照评分表勾选。

README不用写得多花哨，但一定要能让人照着操作就能跑起来。第4天完善JSP层的过程中，每修改一个页面，README中对应的功能模块说明也应该同步更新一次，避免最后提交时文档和代码对不上。

5.4 浏览器兼容与基本交互细节

实训老师通常会在自己的电脑上用Chrome或者Edge浏览器演示项目，所以JSP页面里尽量用基础的HTML元素和通用的CSS写法，避免使用太新或太特殊的浏览器特性。以下细节是我在检查中实际遇到过的：

登录状态检查：页面顶部的导航栏，根据登录用户类型动态显示不同的菜单。管理员可以看到“图书管理”“读者管理”“借阅管理”，读者只能看到“图书查询”“我的借阅”。这个可以通过<c:if test="${sessionScope.user.role == 'admin'}">实现。
删除确认：所有删除操作都加上confirm确认框，避免误删数据。
表单必填验证：除了使用HTML的required属性，在Servlet端也要做一次非空校验，返回错误信息到页面。因为客户端验证很容易被绕过，实训项目虽然简单，但这个思路会体现你的工程意识。
日期格式统一：借阅日期、应还日期用yyyy-MM-dd格式，避免显示Tue Jan 07 00:00:00 CST 2025这种奇怪的格式。

6. 最后一步完善JSP层时的实操体会与收尾建议

整个项目做到第4天，最大的感受是：JSP层看起来是“最后一步”，但它决定了一个实训作业能不能从“功能和后台完整”上升到“可以直接演示且体验良好”。这几天踩过的坑——JSTL标签库版本、相对路径404、中文乱码、浏览器缓存、数据库连接时区——几乎全都在JSP层爆发，而且每一类问题都会让你在演示现场手忙脚乱。

我个人在实际操作中的体会是：JSP层的完善应该以“业务流”为单位推进，而不是以“页面”为单位推进。 意思是说，不要一个页面一个页面地孤立修改，而是从“登录—图书列表—添加图书—借阅—归还”这条完整链路开始，每打通一个业务流就顺手把相关的权限、提示、样式都做完善。这样到了验收的时候，整个系统已经是一个能跑通闭环的完整应用，而不是一堆页面散落在一起。

最后再分享一个收尾的小技巧：交付前把项目重新导入一个干净的Tomcat环境，从新建数据库开始，完整跑一遍登录、图书添加、借阅、归还、注销的流程，模拟老师拿到项目的操作顺序。这一步的“最后一跑”能帮你发现很多之前开发环境里没暴露的问题，比如漏掉的jar包、写死的绝对路径、数据库连接配置差异。图书管理系统这个实训项目虽然不算复杂，但真正让你拿高分的地方，往往就在这些细节里。