企业官网建设流程全解析

简介：《JAVA图书馆书库管理系统设计（论文+源代码）》是一份面向计算机专业毕业设计的完整项目资料，适合需要完成图书管理类课题或巩固Java Web开发流程的学生。内容涵盖需求分析、系统设计、编码实现与测试部署，技术栈涉及JDBC、Servlet/JSP与MVC分层，并包含MySQL风格的数据库设计（图书、读者、借阅记录等核心表）以及管理员/普通用户权限控制。资源共61个文件，以Java源码与class编译文件为主，辅以系统论文doc、Access数据库mdb、jcp工程配置、jar运行包及gif操作演示图，整体仅606KB，轻量但结构完整。已有774人学习浏览，适合作为毕业设计参考或工程实践模板。通过源码、论文和界面演示，读者可以掌握图书查询、借阅、归还、续借、办证等功能的实现思路，并了解异常处理、日志记录等企业级开发细节，是一份性价比较高的实战学习资料。

1. 一门最容易被低估的 Java 课程设计：书库管理系统值不值得认真做

每年课设季，JAVA图书馆书库管理系统设计(论文+源代码) 都会出现在大批计算机专业学生的选题清单里。它的典型形态是一个基于 Java Web 的图书管理应用，负责图书入库、检索、借还和读者维护，交付物是论文加整套源码。这个选题看起来朴素，但一套完整做下来，能把表单提交、Service 业务层、DAO 数据访问和 MySQL 操作全部串起来，很多 java 课程设计案例源码的骨架都是这么搭出来的。适合两类人：一是时间紧、需要一份能跑通能答辩的课设成品；二是想借一个小项目把 java 基础到框架再到数据库连接整条链路过一遍的初学者。下面按我实际交付过几次的完整思路，从设计拆到落地，再把交付避坑讲透。

2. 先从需求和技术栈下手：为什么多数书库管理系统还选 SSM + JSP

2.1 功能边界：这个系统到底要管哪几件事

课程设计最忌讳一上来就写代码。图书馆书库管理系统看起来简单，但功能边界如果不先画清楚，后面写 Service 层的时候会反复改。按最常见的需求文档拆分，整个系统只做两类角色的闭环：管理员和普通读者。

管理员负责书库管理，核心动作是图书的增删改查、借阅记录的查看和还书确认；读者负责借书和还书，能检索图书、查看自己的借阅历史。借阅流程是唯一的跨角色业务闭环：读者检索到有库存的书，发起借书；管理员确认后库存减一，生成一条未归还记录；还书时库存加一，记录闭合。

角色权限不要做得太复杂，课设答辩老师真正关注的不是权限模型，而是 CRUD 是否完整、借还流程是否闭环、数据库表设计是否合理。过度设计权限表反而会让论文难写。把借阅状态机理清楚就够了：在借、已还、逾期。超期计算放到后面做成一个可选加分点，比一开始就塞进核心需求更稳妥。

2.2 技术选型：SSM 和 Spring Boot 之间怎么拿捏

很多高校的 Java 课程设计题目还停留在 JSP + Servlet / SSM 的模板时代，题目描述里甚至直接写明必须使用 JSP 页面和 MVC 架构。如果你的课题没有强制要求，我一般建议按 Spring Boot + Thymeleaf 来做，开发效率高、后期好扩展；如果老师明确要求 SSM，那就老老实实 Spring MVC + MyBatis，不要硬顶着要求用 Boot 去挑战答辩老师的认知。

我这里按最常见的课设组合来讲：JDK 8、MySQL 5.7 / 8.0、Tomcat 8.5 或 9、Maven 管理依赖、Spring + SpringMVC + MyBatis、JSP 页面。JDK 8 到今天仍然是 java 学习路线中最稳的一档，不是因为它新，而是课设环境里老师机器上大概率装的就是 8。Tomcat 在这里扮演的是 Java 容器角色，负责运行 Servlet 和 JSP，版本选 8.5 或 9 都行，但千万别用 Tomcat 10——它默认走 Jakarta EE 包名，和传统 javax.servlet 代码不兼容，这是课设里非常常见的翻车点。

连接池我建议用 Druid 而不是默认的 DBCP。原因很现实：Druid 在 java 面试八股文里出场率高，而且它自带的监控页面能在答辩演示时成为一个小亮点。你可以在论文里写一句“采用 Druid 连接池，通过监控面板观察活跃连接数”，这一句话就能让技术选型部分显得有取舍，而不是抄配置。

2.3 项目目录和论文大纲的对应关系：源代码不是乱扔的

“论文+源代码”这种交付形式，评委老师最反感的是代码和论文各说各话。我见过太多学生把 GitHub 上拉下来的项目改了名字就交，论文里画的流程图和实际页面完全对不上。所以目录结构一开始就要按论文的章节逻辑组织。

标准的 Maven 结构是 src/main/java 下面按 controller、service、dao、entity、filter 分包，src/main/resources 放 MyBatis 的 mapper 和数据库配置，src/main/webapp 放 JSP、CSS、JS。论文的第三章“系统设计”对应工程结构，第四章“系统实现”对应具体模块代码，附录放核心代码片段。你甚至可以在论文里放一张工程目录截图，然后用一句话说明每个包的作用——这比贴大段代码更有说服力，因为老师能直观看出你理解项目结构。

数据库脚本放 resources 下的一个 sql 文件夹里，命名 init.sql。这一点很重要，很多人只交代码不交建表语句，老师导入工程后连数据库都没有。init.sql 是你交付时的第一印象，绝对不能省。

3. 数据库建模与初始化脚本：三张表把业务兜住，连接池参数别乱配

3.1 三张核心表的字段设计：宁冗余不外键迷路

图书馆书库管理系统最忌讳把一切塞进一张大表。按业务正常拆，至少要有图书表、读者表、借阅表三张。图书表负责书库信息，读者表负责读者信息，借阅表是中间表，关联前两张表并记录借还状态。

图书表必需的字段：图书主键、书名、作者、出版社、价格、分类、库存数量、馆藏位置。分类字段用字符串存分类名称就行，不需要单独建分类表，课设的复杂度撑不起那么多表。馆藏位置这个字段容易被忽略，但它非常能体现“书库管理”这个主题，答辩时被问到“如何快速定位一本书”时，它就是答案。

读者表：读者编号、用户名、密码、姓名、手机号、最大借阅量。密码这里建议至少存 MD5，不要明文入库。虽然 JDBC 中可以很容易地直接存字符串，但论文里写一句“密码经过 MD5 摘要后入库”就能体现安全意识，性价比极高。

借阅表：记录主键、图书 ID、读者 ID、借出时间、应还时间、实际归还时间、状态。状态字段用 tinyint，0 在借、1 已还、2 逾期。应还时间在借书时直接用借出时间加固定天数算出，有一个默认值总比每次查询时现算要稳。

3.2 建表和初始化数据：一份能直接跑起来的 init.sql

下面这份 SQL 我按上述三张表写下，并塞入了能支撑演示的初始化数据。课程设计演示最尴尬的瞬间是打开页面后图书列表是空的，所以初始化数据必须包含管理员账号、几本有库存的书和一个借阅记录，让页面一打开就有内容可看。

-- 图书表 CREATE TABLE book ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '图书主键', book_name VARCHAR(100) NOT NULL COMMENT '书名', author VARCHAR(50) NOT NULL COMMENT '作者', publisher VARCHAR(100) COMMENT '出版社', price DECIMAL(10,2) DEFAULT 0 COMMENT '价格', category VARCHAR(50) COMMENT '分类', stock INT NOT NULL DEFAULT 0 COMMENT '库存', location VARCHAR(50) COMMENT '馆藏位置', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='图书表'; -- 读者表 CREATE TABLE reader ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '读者主键', username VARCHAR(50) NOT NULL UNIQUE COMMENT '登录名', password CHAR(32) NOT NULL COMMENT 'MD5密码', name VARCHAR(50) COMMENT '读者姓名', phone VARCHAR(20) COMMENT '手机号', max_borrow INT DEFAULT 5 COMMENT '最大借阅量', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='读者表'; -- 借阅表 CREATE TABLE borrow_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '记录主键', book_id BIGINT NOT NULL COMMENT '图书ID', reader_id BIGINT NOT NULL COMMENT '读者ID', borrow_time DATETIME NOT NULL COMMENT '借出时间', due_time DATETIME NOT NULL COMMENT '应还时间', return_time DATETIME DEFAULT NULL COMMENT '归还时间', status TINYINT DEFAULT 0 COMMENT '0在借 1已还 2逾期', KEY idx_book_id (book_id), KEY idx_reader_id (reader_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='借阅记录表'; -- 初始化数据：管理员/读者/图书/借阅记录 INSERT INTO reader (username, password, name, phone) VALUES ('admin', MD5('123456'), '系统管理员', '13800000001'); INSERT INTO reader (username, password, name, phone) VALUES ('zhangsan', MD5('123456'), '张三', '13800000002'); INSERT INTO book (book_name, author, publisher, price, category, stock, location) VALUES ('Java核心技术卷I', '凯·霍斯特曼', '机械工业出版社', 119.00, '编程', 5, 'A-01-02'); INSERT INTO book (book_name, author, publisher, price, category, stock, location) VALUES ('深入理解Java虚拟机', '周志明', '机械工业出版社', 129.00, '编程', 3, 'A-01-03'); INSERT INTO borrow_record (book_id, reader_id, borrow_time, due_time) VALUES (1, 2, NOW(), DATE_ADD(NOW(), INTERVAL 30 DAY));

这段建表 SQL 的关键设计点有两个。第一个是外键，我没有写 FOREIGN KEY 而是用普通索引 idx_book_id 和 idx_reader_id 去关联。课设项目里外键约束看着正规，但实际操作时很容易因为插入顺序、删除限制而报错，普通索引配合 Service 层控制逻辑已经足够，这也是企业里常见的取舍。第二个是 status 字段的注释，0、1、2 必须和 Java 代码里的枚举或常量一一对应，否则后期查 bug 会查得很难受。

初始化数据里借阅记录的 due_time 用 DATE_ADD 动态生成，这样无论哪一天执行脚本，演示时都能看到一个正常的在借记录。管理员和读者密码都是 MD5 过的 123456，答辩演示时直接报账号 admin 密码 123456 就行——当然，你也可以在论文里提醒用户首次登录后修改密码，这样更正规。

3.3 连接池参数和数据库地址：让项目换台电脑也能一次连上

数据库配置是课程设计交付时最容易出问题的地方。我见过一份源码里写着 jdbc:mysql://localhost:3306/library?useUnicode=true&characterEncoding=utf8 ，没有数据库名、没有时区参数、驱动类还是老版的 com.mysql.jdbc.Driver，拿到 MySQL 8 的新机器上必报错。

连接配置我建议放在 src/main/resources 下的 jdbc.properties，用 Druid 连接池管理。下面这份配置是按 MySQL 8.0 环境写的，同时兼容绝大多数常见课设环境。

# 数据库驱动：MySQL 8 必须用 com.mysql.cj.jdbc.Driver jdbc.driver=com.mysql.cj.jdbc.Driver # serverTimezone 解决时区问题，useSSL=false 去掉 SSL 握手警告 jdbc.url=jdbc:mysql://localhost:3306/library_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false jdbc.username=root jdbc.password=123456 # Druid 连接池参数 pool.initialSize=5 pool.minIdle=5 pool.maxActive=20 pool.maxWait=30000

这里逐项说明参数含义。initialSize 是启动时初始化的连接数，5 个足够课设用；maxActive 是最大活跃连接数，20 够支撑并发演示；maxWait 是获取连接的超时毫秒数，30000 表示最多等 30 秒，超过直接抛异常。要注意的是 jdbc.username 和 jdbc.password 中的值必须与本地 MySQL 实际账号一致，很多人忽略这一步，代码里写的是 root/123456，本机密码是 root/root，于是启动时一直报 Access denied。

另外提一句，时区参数 serverTimezone=Asia/Shanghai 是 MySQL 8 连接报错的高频原因。如果你看到 java.sql.SQLException: The server time zone value '???ú±??' is unrecognized，不用怀疑，就是没配这个参数。

4. 核心 Java 模块落地：登录拦截、图书检索、借阅事务三个关键代码

4.1 用 Filter 给整个系统加一道登录拦截的门

图书馆书库管理系统的所有页面除了登录页之外，都应当是登录后才能访问的。很多课设只在前端跳转时判断 session，后端接口完全裸奔，这不叫完整实现。正确做法是写一个 Filter，在请求进入 Controller 之前统一检查 session，没登录就重定向到登录页。

// LoginFilter.java 登录拦截器 public class LoginFilter implements Filter { @Override public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; // 放行登录接口和静态资源，避免死循环跳转 String path = request.getRequestURI().substring(request.getContextPath().length()); if ("/login.jsp".equals(path) || "/user/login".equals(path) || path.startsWith("/css") || path.startsWith("/js")) { chain.doFilter(request, response); return; } // 检查 session 是否存在登录用户 Object loginUser = request.getSession().getAttribute("loginUser"); if (loginUser == null) { response.sendRedirect(request.getContextPath() + "/login.jsp"); return; } chain.doFilter(request, response); } }

这段代码的核心逻辑是白名单加 session 检查。路径判断放在最前面，凡是登录页、登录请求、静态资源一律放行，其余请求进入 session 检查。如果 session 里没有 loginUser，直接重定向到登录页。这里的参数 path 取自请求 URI 减去项目上下文路径，如果你在 IDEA 里部署的项目名是 library，那请求 /library/book/list 会被截成 /book/list 再参与判断，这样写比直接用完整 URI 更稳。

在 web.xml 中注册这个 Filter 时，映射路径用 /，表示拦截所有请求。我见过有人配成 /book/，结果读者页面没拦截，等于把门只锁了一半。另外要注意把 Filter 注册放在前端控制器 DispatcherServlet 之前，否则请求先进了 Spring MVC，拦截器逻辑就乱了。

4.2 图书检索：模糊查询和分页参数这样写才不翻车

书库管理系统的图书检索看起来只是一个 LIKE 查询，但分页参数的处理有很多细节。最常见的问题是页数从 0 开始还是从 1 开始，以及前端传过来的页码没有做边界校验。按用户习惯，页数从 1 开始，后端计算偏移量时用 (pageNum - 1) * pageSize，这是从 MySQL 的 LIMIT offset, size 语法反推出来的参数设计。

用 MyBatis 的话，建议把查询写在 BookMapper.xml 而不是 Java 里拼字符串。XML 里写动态 SQL 比 Java 代码里拼 % 号可读性强太多，出了问题也容易单独调。下面是我常用的写法。

<!-- BookMapper.xml 图书分页模糊查询 --> <select id="listBooks" resultType="Book"> SELECT id, book_name, author, publisher, price, stock, location FROM book <where> <if test="keyword != null and keyword != ''"> book_name LIKE CONCAT('%', #{keyword}, '%') </if> </where> ORDER BY id LIMIT #{offset}, #{pageSize} </select>

上面这段 SQL 里，keyword 为空时 where 条件自动消失，变成一次无筛选的列表查询；keyword 不为空时用 CONCAT 拼接模糊匹配。这里要注意 MyBatis 的 where 标签会自动去掉多余的 AND 或 OR，所以你不需要手工加 WHERE 1=1 这种丑写法。LIMIT #{offset}, #{pageSize} 中的 offset 和 pageSize 由 Service 层传入，Mapper 层只负责执行，职责边界清晰。

对应 Java 层的查询方法参数，我在 Service 里通常会定义一个分页查询条件对象或直接用两个 int 传参。核心计算只有一行：int offset = (pageNum - 1) * pageSize。这里的坑是前端传 pageNum 为 0 或负数，一减变成负偏移，SQL 执行不会报错但结果完全不对。所以入口处必须做防御：

if (pageNum < 1) { pageNum = 1; } if (pageSize < 1 || pageSize > 100) { pageSize = 10; }

pageSize 限制在 1 到 100 是有讲究的。课设数据量小看不出来，但如果论文里写了“系统支持分页查询”，评委可能追问分页参数是否做了安全限制。封顶 100 能防止有人传 99999 一次拉走全表数据，这个细节在 java 面试题里也属于常见考点，你可以顺便写进论文的性能考虑部分。

4.3 借阅与归还：事务边界和库存扣减的原子性

借书是整个系统中业务逻辑最重的操作，它涉及两次写操作：扣减库存和插入借阅记录。如果扣了库存但记录插入失败，书就凭空消失了一本；如果插入了记录但库存没扣，就会超卖。必须把这两个操作放进同一个事务，并且用带条件的 UPDATE 防止库存变负数。

// BorrowService.java 借书核心方法 @Service public class BorrowService { @Autowired private BookDao bookDao; @Autowired private BorrowDao borrowDao; @Transactional(rollbackFor = Exception.class) public void borrowBook(int bookId, int readerId, int maxBorrow) { // 1. 查询图书是否存在且有库存 Book book = bookDao.selectById(bookId); if (book == null || book.getStock() <= 0) { throw new RuntimeException("图书不存在或库存不足"); } // 2. 判断读者未归还数量是否达到上限 int unreturnedCount = borrowDao.countUnreturned(readerId); if (unreturnedCount >= maxBorrow) { throw new RuntimeException("已达到最大借阅数量"); } // 3. 带条件扣减库存：stock > 0 条件在数据库层兜底 int rows = bookDao.decreaseStock(bookId); if (rows == 0) { throw new RuntimeException("扣减库存失败，该书可能刚被人借走"); } // 4. 写入借阅记录，应还时间默认借出后 30 天 borrowDao.insertBorrowRecord(bookId, readerId); } }

这段代码最关键的是第 3 步的 decreaseStock 方法。它的 SQL 不是简单的 UPDATE book SET stock = stock - 1 WHERE id = ?，而是带了一个库存判断条件：

UPDATE book SET stock = stock - 1 WHERE id = #{bookId} AND stock > 0

这一步的意义在于数据库行锁。当两个并发请求同时借同一本书时，第一个请求执行 UPDATE 会拿到行锁，第二个请求阻塞；第一个提交后库存变成 0，第二个请求的 WHERE stock > 0 条件不再满足，影响行数为 0，然后在 Java 层抛出异常触发事务回滚。光靠先查库存再扣减的“检查-然后-执行”模式在并发下必翻车，这是并发控制里最容易踩的坑，也是把这条写进论文“系统安全性设计”章节的素材。

事务注解 @Transactional(rollbackFor = Exception.class) 里的 rollbackFor 参数很多人不理解。默认情况下 Spring 只对 RuntimeException 回滚，如果异常是检查性异常，比如 IOException，事务不会回滚。这里显式指定 rollbackFor = Exception.class，等于告诉 Spring 任何异常都回滚，对课设来说更安全。归还操作是对称的：先根据记录 ID 把借阅状态置为已还，再执行 UPDATE book SET stock = stock + 1。归还不需要库存条件判断，但两个操作同样必须在同一事务内。

5. 论文+源代码交付避坑：五个让课设翻车的实际故障排查

5.1 现象：自己电脑上跑得好好的，换台机器就起不来

这是课设答辩前最普遍的问题。现象是在自己 IDEA 里能正常启动，拷贝到老师电脑上要么 Tomcat 报错，要么 JSP 编译 500。原因几乎都出在环境不一致上：老师的 JDK 是 1.7，你的代码用了 JDK 8 的 Lambda 表达式；或者你本地是 Tomcat 9，对方是 Tomcat 7；又或者是项目编码是 UTF-8，对方系统默认编码是 GBK，JSP 页面中文全乱。

解决思路是把环境写成一个 README，和论文、源代码放在同一层目录。里面固定写明三行字：JDK 1.8 并配好 JAVA_HOME 环境变量、Tomcat 8.5+、MySQL 5.7+。如果你的机器上 java 环境变量配置没做对，直接在系统变量里新增 JAVA_HOME 指向 JDK 安装目录，再在 Path 里加 %JAVA_HOME%\bin。交付前在另一个全新目录里按 README 从零部署一遍，这个过程能暴露绝大多数环境问题。

5.2 现象：Maven 依赖一直下载失败，IDEA 报红一片

课设源码用了 Maven 管理依赖，但是第一次打开工程时 pom.xml 里 spring-webmvc、mybatis、mysql-connector 全部下载不下来，或者卡在某个 jar 包上不动。这个问题的根源基本只有一个：Maven 默认中央仓库在国外，网络访问不稳定。

解决方式是在 Maven 的 settings.xml 里配置阿里云镜像，这个配置属于 java 基础操作但极其关键。在 mirror 节点中加入：

<mirror> <id>aliyun</id> <mirrorOf>central</mirrorOf> <url>https://maven.aliyun.com/repository/public</url> </mirror>

配置后再让 IDEA 的 Maven 设置指向这份 settings.xml，并执行 clean 重新下载依赖。注意如果本地仓库已经下载过损坏的 jar，要把本地仓库里对应的目录删掉再重新拉取，否则会一直报同一个包读取失败。这个坑我在多个课设项目里重复遇到，删除本地仓库损坏目录是让人重新怀疑人生的后悔药。

5.3 现象：数据库连接报时区异常或 Public Key Retrieval 错误

项目部署后启动日志出现 java.sql.SQLException: The server time zone value '???ú±??' is unrecognized，或者 JDBC Connection 建立时报 Public Key Retrieval is not allowed。前者是 MySQL 8 和 5.x 的时区处理差异，后者是 MySQL 8 的 caching_sha2_password 插件在非 SSL 连接下的安全策略导致的。

解决方式是双管齐下。第一，驱动依赖确保是 mysql-connector-java 8.0.x，不要用 5.1 版本去连 MySQL 8；第二，JDBC URL 里显式加上时区和 SSL 参数，完整的写法在第 3 章配置里已经给过。如果仍然报 Public Key Retrieval，再在 URL 末尾追加 allowPublicKeyRetrieval=true。这里我需要说清楚 allowPublicKeyRetrieval 为什么默认关闭——因为它在非 SSL 通道上允许客户端向服务端请求公钥，有中间人攻击风险，但本地课设环境完全可控，打开它没问题。这个知识点讲给答辩老师听能明显加深印象。

5.4 现象：论文里的 ER 图、流程图和实际的表结构、页面完全对不上

这种情况在“论文+源代码”的交付模式里几乎每个班都有几例。论文第二章画了 reader 表 6 个字段，实际 init.sql 里只有 5 个；论文里写了“管理员可以修改图书信息”，实际页面根本没有编辑按钮。老师只要随手翻一下附录 SQL 或者点开页面，就对不上了，这比代码有 bug 还致命，因为说明论文是抄的。

解决方法是建立一套对照检查流程：先对照论文的数据表设计和 init.sql 里的 CREATE TABLE，逐字段核对；再对照论文的功能模块和 webapp 下的 JSP 页面，逐页面点一遍。这项工作放在交付前两天做，改论文比改代码快。我把这条放在避坑章节而不是写作章节，是因为它踩坑的人太多，而且一旦被质疑，整篇论文的可信度都会崩塌。改库之后必须同步改文档，这是课设和真实项目里通用的一条规则。

5.5 现象：借书后库存变成负数

功能测试阶段发现当两个浏览器同时操作借阅同一本书时，偶尔出现库存 -1。这是典型的并发事务问题。原因在于我最早写的借书逻辑是先 SELECT 查库存，判断大于 0，再 UPDATE 减库存。两个会话同时查到库存为 1，都认为可以借，结果库存被减成 -1。这就是“检查-然后-执行”竞态条件。

解决方式已经写在第 4 章：把 UPDATE 语句改成带 stock > 0 条件的版本，让数据库行锁做最终裁决，配合 @Transactional 让失败操作回滚。如果项目用的是纯 JDBC 或者 MyBatis 配合手动 commit，也可以用 SELECT ... FOR UPDATE 锁行，但课设里直接用条件更新更简洁。验证方法是在 Controller 里写一个循环，模拟 100 个并发请求同时借同一本书，观察最终库存不为负且成功率正确。这个测试过程写进论文“系统测试”章节，含金量比罗列 20 条功能测试高得多。

6. 答辩前怎么验证项目：功能清单和超期罚款加分逻辑

6.1 按这个顺序自测，能覆盖九成课设演示场景

演示翻车多半发生在临场操作路径不对。我习惯按一条固定顺序过验收：先启动 MySQL 并执行 init.sql，再启动 Tomcat；打开登录页用 admin/123456 登录；新增一本测试图书；用 zhangsan 账号登录；检索刚才新增的图书并借阅；回到管理员端确认借阅记录；执行还书；最后检查库存是否恢复。这个顺序覆盖了登录拦截、增删改查、借还闭环四条主链路。为了方便自查，我列了一个验收表格：

6.2 一个能写进论文的加分点：超期罚款计算

如果你的时间有余量，我强烈建议加一个超期罚款逻辑，代码量不大但论文和答辩都能用。它的价值在于把借阅表里的 due_time 和 return_time 两个字段真正用起来，而不是躺在数据库里当摆设。

// FineCalculator.java 超期罚款计算 public double calcFine(Date dueTime, Date returnTime) { long overdueDays; if (returnTime == null) { // 还没归还：按当前时间计算超期天数 overdueDays = (System.currentTimeMillis() - dueTime.getTime()) / (24 * 60 * 60 * 1000L); } else { overdueDays = (returnTime.getTime() - dueTime.getTime()) / (24 * 60 * 60 * 1000L); } double fine = overdueDays > 0 ? overdueDays * 0.5 : 0; return Math.min(fine, 50); }

这段计算逻辑是按每天 0.5 元罚款、50 元封顶设计的。returnTime 为 null 表示书还没还，超期天数按当前时间计算，这样管理员查看在借列表时能实时看到每本书的超期金额。Math.min 封顶是故意为之，避免出现天文数字罚款，这个设计在答辩时可以解释为“防止罚款无限累积的合理策略”。我自己的习惯是演示前都会先构造一条超期数据，把罚款金额显示在页面上，这个环节基本必能赢得点头。希望这个验证技巧和整套交付流程的思路能帮到你，让课程设计不只是跑通，而是真正成为简历上拿得出手的一段经历。

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