企业官网建设流程全解析

简介：面向计算机、软件工程等专业学生的JavaWeb网络书店销售管理系统课设/毕设资料包，包含完整系统源码、毕业论文、开题报告、任务书、摘要与英文文献，可直接用于毕业设计、课程设计或大作业参考。压缩包共214个文件，整体仅1.4MB，主要包含78个jsp页面、95个gif动态演示图、10个doc文档、2个pdf文献，以及mdb/db数据库、java类、配置文件等，便于对照学习与实际部署。源码覆盖servlet、jsp、javabean、JDBC等JavaWeb核心技术，论文部分按需求分析、系统设计、实现过程、测试结果完整展开，配合开题报告、任务书和英文资料，能帮助读者快速理清网络书店系统的业务逻辑与技术架构。已有162人浏览学习，适合需要系统参考完整课设/毕设流程的读者下载使用。

1. 课设和毕设常见的 JSP+Access 网络书店销售管理系统，到底在交付什么

打开网盘里那份「系统+论文+开题报告+任务书+摘要+英文文献」的压缩包，第一眼会以为它只是份学生作业，但真正动手做毕业设计或课程设计的人会明白：这个标题背后是一条完整的 JSP 学习闭环——JSP 负责页面展示，JavaBean 和 Servlet 负责业务逻辑，Access 数据库负责持久化，而那一摞论文和开题报告决定你最后能拿多少分。系统本身并不复杂：图书分类浏览、关键字查询、购物车、订单提交和后台管理，撑起这份体量刚好是一个网络书店销售管理系统能演示的全部核心流程。

值得先说明的是，这套技术选型放在生产环境里早就过时了，但对课设和毕设来说恰恰是「黄金组合」。JSP 让页面和 Java 代码混写，写起来直观，答辩时也好讲；Access 是文件型数据库，不需要单独安装数据库服务，拷个.mdb文件就能跑；至于论文部分，开题报告、任务书和英文文献是学校规定动作，和代码一样是评分重点。这篇文章会从数据层设计、分页与购物车实现、权限与订单事务，一直讲到最常见的环境报错和查重规避，让新手能照着自己的方案把这套东西从「能跑」做到「能答辩」。

需要提前泼一盆冷水：网上能下载到的 JSP+Access 网络书店项目，十个里有八个存在编码混乱、SQL 注入、Access 驱动配置过时的问题。你把它跑通只是第一步，真正要做的是理解每个模块为什么这么写，答辩时老师随便问一句「为什么用 Access 不用 MySQL」，你得能说出文件型数据库和 C/S 数据库的边界，否则代码再漂亮也经不起追问。

2. 网络书店管理系统的数据基石：Access 数据库的选型理由与表结构设计

2.1 为什么课设选 Access 而不是 MySQL：从驱动配置看两种方案的成本差异

常见做法是直接用 JDBC-ODBC 桥接，也就是sun.jdbc.odbc.JdbcOdbcDriver，配合jdbc:odbc:bookstore这样的连接 URL。但这里有一个 JSP 项目里高频踩坑的点：JDK 8 之后，JDBC-ODBC 桥接驱动被官方移除，如果你用的是 JDK 8 及以上版本，Class.forName 会直接报ClassNotFoundException。现在更靠谱的方案是使用 UCanAccess 这个纯 Java 驱动，它不需要配置 ODBC 数据源，只要把ucanaccess.jar和它依赖的commons-lang3.jar、commons-logging.jar、hsqldb.jar、jackcess.jar放进WEB-INF/lib即可。

选 Access 的另一个现实理由是答辩演示环境不可控。实验室的机器可能没有 MySQL 服务，或者你写好的建库脚本在老师的机器上因为版本差异跑不起来；而一个.mdb文件拷贝过去就能用，天然避免了服务安装这一步。代价则是并发能力几乎为零——Access 适合单机或个位数并发的演示场景，这正好匹配课设的验收规模。如果你是抱着「毕业以后还能继续用」的心态，我的建议是架构上把 DAO 层接口定义好，等答辩之后想迁移到 MySQL，只需要替换实现类和驱动依赖，页面层基本不用动。

2.2 网络书店销售管理系统的核心表：从用户表到订单明细的 6 张表设计

数据层设计直接决定后面 JSP 页面和业务代码的撰写难度。常见的网络书店销售管理系统至少要有用户表、图书表、图书分类表、购物车表、订单表和订单明细表。其中购物车表在多数实现里是临时的，更合理的做法是用 Session 保存购物车，订单提交时再落库，这样能省掉处理「游客购物车残留数据」的麻烦。下面给出一个可以直接用的 Access 建表 SQL，注意 Access 的 SQL 语法和 MySQL 略有差异，AUTOINCREMENT是 Access 的自增关键字：

CREATE TABLE users ( user_id AUTOINCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL, password VARCHAR(50) NOT NULL, realname VARCHAR(50), email VARCHAR(100), role VARCHAR(10) DEFAULT 'customer', reg_time DATETIME DEFAULT NOW() ); CREATE TABLE book_category ( category_id AUTOINCREMENT PRIMARY KEY, category_name VARCHAR(50) NOT NULL, description VARCHAR(200) ); CREATE TABLE books ( book_id AUTOINCREMENT PRIMARY KEY, book_name VARCHAR(100) NOT NULL, author VARCHAR(50), publisher VARCHAR(100), price CURRENCY, stock INT DEFAULT 0, sales_count INT DEFAULT 0, category_id INT, publish_date DATETIME, cover_image VARCHAR(200), description MEMO ); CREATE TABLE orders ( order_id AUTOINCREMENT PRIMARY KEY, user_id INT NOT NULL, order_no VARCHAR(30) NOT NULL, total_price CURRENCY, order_time DATETIME DEFAULT NOW(), status VARCHAR(20) DEFAULT 'unpaid' ); CREATE TABLE order_items ( item_id AUTOINCREMENT PRIMARY KEY, order_id INT NOT NULL, book_id INT NOT NULL, quantity INT NOT NULL, unit_price CURRENCY );

这套结构里最容易被忽略的是CURRENCY类型和MEMO类型。CURRENCY在 Access 里是定点数，适用于价格这种不允许浮点误差的场景，如果你用DOUBLE来存价格，两个 99.99 相加可能出现 199.9800000000002 的结果，传到 JSP 页面显示时还要做格式化，等于给自己挖坑。MEMO相当于 MySQL 的TEXT，用于存图书简介这种长文本。订单表里单独设计order_no而不是直接拿自增主键当订单号，是考虑到答辩时老师可能问「为什么订单号不用自增 ID」——自增 ID 会暴露一天的下单量，而且不方便拆出日期，业务上也不规范。

2.3 数据库连接池：用一个 DBUtil 类统一管理 Access 连接

JSP 项目里最容易写乱的就是数据库连接代码。常见做法是每个 Servlet 里Class.forName一次、DriverManager.getConnection一次，最后finally里关连接，代码量大且容易漏关连接导致 Access 文件被锁死。UCanAccess 本身支持连接池，但课设级别不需要引入第三方池组件，写一个静态的 DBUtil 类就够了：

package com.bookstore.dao; import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.SQLException; import java.sql.Statement; public class DBUtil { private static final String DB_PATH = "D:/bookstore/bookstore.mdb"; private static final String URL = "jdbc:ucanaccess://" + DB_PATH; private static final String USER = ""; private static final String PASSWORD = ""; static { try { Class.forName("net.ucanaccess.jdbc.UcanaccessDriver"); } catch (ClassNotFoundException e) { throw new ExceptionInInitializerError("UCanAccess 驱动未找到，请检查 WEB-INF/lib 下的 jar"); } } public static Connection getConnection() throws SQLException { return DriverManager.getConnection(URL, USER, PASSWORD); } public static void close(Connection conn, Statement stmt, ResultSet rs) { if (rs != null) { try { rs.close(); } catch (SQLException e) { } } if (stmt != null) { try { stmt.close(); } catch (SQLException e) { } } if (conn != null) { try { conn.close(); } catch (SQLException e) { } } } }

连接 URL 里的D:/bookstore/bookstore.mdb是绝对路径，这意味着项目换一台机器就必须改这里。更稳妥的做法是把路径写到WEB-INF/classes/db.properties里，用ClassLoader.getResourceAsStream("db.properties")加载，这样部署时只需要改配置文件。UCanAccess 驱动加载后会自动创建hsqldb的内存缓存来模拟 SQL 能力，所以第一次查询会比较慢，这是正常现象，别急着优化。要注意的是，Access 对文件并发写入有限制，如果同时开了多个Connection且长时间不关闭，可能出现「文件正在使用」的报错，所以finally里关连接不能偷懒。

3. 网络书店的核心功能落地：JSP 页面上的分页查询与购物车会话实现

3.1 图书列表分页：手动计算数据总量和每页偏移量

图书列表是网络书店的门面，但如果一次性把所有图书都渲染出来，数据量到几百条时页面就会明显变卡，而且答辩时翻页功能往往是被重点演示的模块。分页实现思路很直接：先查总记录数，再算出总页数，最后用LIMIT offset, rows拉取当前页数据。Access 的 SQL 不直接支持LIMIT，但 UCanAccess 兼容了这条语法，所以LIMIT ?, ?可以直接用。分页需要三个参数：currentPage当前页码、pageSize每页条数、totalCount总记录数，页面上永远只显示当前页的数据。

// BookDAO 中的分页查询方法 public List<Book> findBooksByPage(int currentPage, int pageSize) throws SQLException { String countSql = "SELECT COUNT(*) FROM books"; String pageSql = "SELECT * FROM books ORDER BY book_id LIMIT ?, ?"; List<Book> bookList = new ArrayList<>(); try (Connection conn = DBUtil.getConnection(); PreparedStatement ps1 = conn.prepareStatement(countSql); ResultSet rs1 = ps1.executeQuery()) { if (rs1.next()) { totalCount = rs1.getInt(1); } } int offset = (currentPage - 1) * pageSize; try (Connection conn = DBUtil.getConnection(); PreparedStatement ps2 = conn.prepareStatement(pageSql)) { ps2.setInt(1, offset); ps2.setInt(2, pageSize); try (ResultSet rs2 = ps2.executeQuery()) { while (rs2.next()) { Book book = new Book(); book.setBookId(rs2.getInt("book_id")); book.setBookName(rs2.getString("book_name")); book.setPrice(rs2.getBigDecimal("price")); bookList.add(book); } } } return bookList; }

这段代码里LIMIT ?, ?的语义是跳过前 offset 条记录，再取之后的 pageSize 条。PreparedStatement的setInt从 1 开始编号，和 SQL 里?的出现顺序一一对应。JSP 页面里接收page参数时一定要做非空和边界校验：用户第一次访问时page是 null，默认赋 1；当用户手动在地址栏输入page=999时，要让currentPage强制回弹为总页数。这些都是容易被答辩老师抓到的小细节，写进代码注释里也算是一种「项目完备性」的体现。分页查询的COUNT(*)在数据量大的时候每次都要全表扫描，但 Access 单表几千条的体量完全不需要索引优化，这是选型边界带来的设计红利。

3.2 购物车为什么不建表：用 HttpSession 管理用户的选择状态

购物车在课设项目里有两种实现路线：一种是把购物车表建在 Access 里，每次加购都写数据库；另一种是用 Session 保存，结账时一次落库。我建议用第二种：购物车是典型的「会话级临时状态」，如果做成数据库表，游客关闭浏览器后车内留下大量垃圾数据，还得写定时清理任务，复杂度完全超出课设范畴。Session 方案天然按用户隔离，同一个浏览器的多个标签页共享同一个 Session，这正是购物车想要的体验——在 A 标签页加购，B 标签页能看到。

定义一个CartItem对象，持有 bookId、bookName、price、quantity 字段，再定义一个Cart对象，内部维护Map<Integer, CartItem>。加购时先从 Session 里取 Cart，取不到就new一个放进去：

public void addBookToCart(HttpServletRequest request, int bookId, int quantity) { HttpSession session = request.getSession(); Cart cart = (Cart) session.getAttribute("cart"); if (cart == null) { cart = new Cart(); session.setAttribute("cart", cart); } cart.addItem(bookId, quantity); }

Cart.addItem里的逻辑要看具体情况：如果 Map 里已经有了这本书，就把数量累加；如果没有，就创建新的 CartItem。结账生成订单后，别忘记session.removeAttribute("cart")，否则用户下单之后再进购物车，看到的还是旧的商品列表。修改购物车数量、删除单项这两个操作相对简单，只在quantity为 0 或负数时从 Map 移除即可。Session 的默认超时时间是 30 分钟，这个值在web.xml里可以调，但购物车场景保持默认就够。另一个要注意的点是，会话里不要直接放 JavaBean 的完整对象，放 id 和价格就够了——图书价格可能被后台管理员修改，如果 Session 里存的是旧价格，用户下单时页面显示 59 元、落库时却按最新价格 69 元结算，容易引发逻辑不一致的 BUG。

3.3 商品分类联动与关键字查询：拼接 SQL 时的安全底线

分类浏览和关键字查询在图书列表页通常是两种入口。分类浏览是点左侧的「计算机」「文学」等链接，URL 形如bookList.jsp?categoryId=3&page=1，SQL 是WHERE category_id = ?，这个相对简单。关键字查询则是搜索框提交，keyword参数会传到后台，很多网络书店课设代码直接写成WHERE book_name LIKE '%" + request.getParameter("keyword") + "%'"。这种字符串拼接是 SQL 注入的重灾区，答辩老师只要在搜索框里输入一个单引号，页面就报错，然后追问你「为什么 LIKE 查询会报错」——这就是恶意参数穿透到 SQL 语法的直接证据。

正确的做法是全程使用PreparedStatement的?占位符，把 keyword 作为参数绑定进去：

<% String keyword = request.getParameter("keyword"); if (keyword == null) { keyword = ""; } %> <form action="bookList.jsp" method="get"> <input type="text" name="keyword" value="<%= keyword %>" placeholder="输入书名或作者" /> <button type="submit">搜索</button> </form>

后端 DAO 里用LIKE ?并传入"%" + keyword + "%"即可，PreparedStatement 会自动转义参数里的特殊字符。分类和关键字同时存在时，SQL 的 where 子句要用AND拼接：WHERE category_id = ? AND (book_name LIKE ? OR author LIKE ?)，此时注意参数在占位符里的顺序必须和 setString 的调用顺序一致。很多新手会把「参数顺序不对」错判成「SQL 语法错误」，排查时要养成先打印PreparedStatement预处理后的 SQL 控制台输出的习惯，UCanAccess 可以通过设置showsql=true来输出实际执行语句。

4. 订单与权限：网络书店销售管理系统从「能演示」到「能加分」的关键模块

4.1 用户权限路由：用 Filter 拦截后台 JSP 页面，而不是在页面里重复判断

后台管理页面是网络书店区别于「静态页面」的关键证据，但太多课设把权限判断写在每个 JSP 的<% if(session.getAttribute("admin") == null) { response.sendRedirect("login.jsp"); return; } %>里。这段代码如果复制粘贴到 10 个页面，就有 10 处维护点。更工程化的做法是写一个统一的AuthFilter，在请求进入 JSP 之前拦截，检查 Session 里的登录状态和角色，这样才能在答辩时表现出「架构分层」的意识。

package com.bookstore.filter; import javax.servlet.*; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.http.HttpSession; import java.io.IOException; public class AuthFilter implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest) request; HttpServletResponse resp = (HttpServletResponse) response; HttpSession session = req.getSession(false); String path = req.getRequestURI(); if (path.endsWith("login.jsp") || path.endsWith("loginServlet")) { chain.doFilter(request, response); return; } if (session == null || session.getAttribute("loginUser") == null) { resp.sendRedirect(req.getContextPath() + "/login.jsp"); return; } Object role = session.getAttribute("role"); if (path.contains("/admin/") && !"admin".equals(role)) { resp.sendRedirect(req.getContextPath() + "/error.jsp"); return; } chain.doFilter(request, response); } }

在web.xml里配置 filter-mapping 时，要把/admin/*和/user/*分别映射，或者统一映射/*后在过滤器里判断 URI 是否包含/admin/。注意req.getSession(false)和req.getSession()的区别：前者当 Session 不存在时返回 null，不会自动创建；后者则会强制 new 一个 Session，如果没登录的用户访问首页就会产生一个空会话，排查「为什么游客也能产生 Session」时容易绕弯路。过滤器的拦截顺序按 web.xml 中 filter-mapping 的声明顺序决定，如果项目里还有编码过滤器，它必须声明在最前面；把编码过滤器放在 AuthFilter 后面，请求参数里中文会乱码，这类问题通常要查配置文件才想得起来。

4.2 订单提交的事务边界：多张表写入时保证数据一致性

网络书店的订单提交至少要操作三张表：orders 插入主单、order_items 插入明细、books 表扣减库存。这三步任何一步失败，都不能留下「有订单没明细」或「库存扣了订单没生成」的脏数据。Access 引擎支持事务，UCanAccess 也将java.sql.Connection的事务语义映射到了底层引擎，所以可以直接用标准 JDBC 事务：

public boolean createOrder(Order order, List<OrderItem> items) throws SQLException { String insertOrder = "INSERT INTO orders(user_id, order_no, total_price, status) VALUES(?,?,?,?)"; String insertItem = "INSERT INTO order_items(order_id, book_id, quantity, unit_price) VALUES(?,?,?,?)"; String updateStock = "UPDATE books SET stock = stock - ? WHERE book_id = ? AND stock >= ?"; Connection conn = null; PreparedStatement ps = null; boolean success = false; try { conn = DBUtil.getConnection(); conn.setAutoCommit(false); ps = conn.prepareStatement(insertOrder, Statement.RETURN_GENERATED_KEYS); ps.setInt(1, order.getUserId()); ps.setString(2, order.getOrderNo()); ps.setBigDecimal(3, order.getTotalPrice()); ps.setString(4, "unpaid"); ps.executeUpdate(); ResultSet keys = ps.getGeneratedKeys(); int orderId = 0; if (keys.next()) { orderId = keys.getInt(1); } for (OrderItem item : items) { ps = conn.prepareStatement(insertItem); ps.setInt(1, orderId); ps.setInt(2, item.getBookId()); ps.setInt(3, item.getQuantity()); ps.setBigDecimal(4, item.getUnitPrice()); ps.executeUpdate(); ps = conn.prepareStatement(updateStock); ps.setInt(1, item.getQuantity()); ps.setInt(2, item.getBookId()); ps.setInt(3, item.getQuantity()); int affected = ps.executeUpdate(); if (affected == 0) { throw new SQLException("库存不足，图书ID: " + item.getBookId()); } } conn.commit(); success = true; } catch (SQLException e) { if (conn != null) { conn.rollback(); } throw e; } finally { if (conn != null) { conn.setAutoCommit(true); conn.close(); } } return success; }

事务代码里要盯住三个细节。第一，getGeneratedKeys()在 UCanAccess 里能否拿到自增主键取决于驱动版本和建表语句，如果拿不到就改为「先查询最大 order_id + 1」，但并发下可能重复，课设演示通常不需要那么严谨。第二，UPDATE books SET stock = stock - ? WHERE book_id = ? AND stock >= ?用了「乐观锁」写法，update 返回影响行数为 0 就说明库存不够，这比先 SELECT 再判断再 UPDATE 少了竞态窗口。第三，finally里conn.close()之前最好恢复setAutoCommit(true)，因为连接池复用连接时，残留的事务状态可能污染下一次使用。Access 的锁粒度是整表级别的，多个请求同时写订单可能出现Could not lock file错误，部署后如果多人同时下单，这是第一个要排查的方向。

4.3 JSP 项目的常见坑：中文乱码、Access 驱动冲突和页面刷新重复下单

把 JSP+Access 网络书店从一个压缩包变成能演示的系统，会遇到一批和业务无关的疑难杂症。中文乱码是最典型的：Tomcat 8.5 以后 GET 请求的 URI 编码默认是 UTF-8，但 Access 里的字符串如果是从旧系统导入的，可能是 GBK 编码，于是 JSP 页面展示书名时出现「銆婁功銆?」这类乱码。统一方案是数据库建表时把文本字段保持默认，JSP 页面顶部写<%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>，同时在 web.xml 里加 CharacterEncodingFilter 并设forceEncoding=true。如果数据库本身已经混入乱码数据，只能写个 Java 程序用new String(old.getBytes("ISO-8859-1"), "GBK")清洗一遍，没有其他捷径。

刷新重复下单是另一个隐蔽问题：用户点了「提交订单」后页面卡顿，又刷新一次，浏览器重新提交了上一 POST 请求，订单就生成两条。常见处理是订单号在服务端生成后写入 Session，提交前校验 Session 中的订单号与当前订单一致，一致则继续，不一致则视为重复请求直接返回。相比通过 JavaScript 禁用按钮，服务端校验在任何浏览器下都能生效，也更适合写进论文的「系统安全性设计」一节。

Access 驱动冲突则多发生在建设项目时：有些压缩包自带的驱动是 JDK 6 时代的sun.jdbc.odbc.JdbcOdbcDriver，在 JDK 8+ 环境必然失败。如果代码里同时存在 UCanAccess 和 JDBC-ODBC 两种驱动加载逻辑，其中一个失败会抛ExceptionInInitializerError，但真正的原因不会直接显示，要打开WEB-INF/lib检查是否同时存在两套 jar。对于下载的现成项目，务必先确认 JDK 版本、Tomcat 版本、Access 驱动三者的兼容矩阵，再决定是否要改写连接工具类。

4.4 部署中的配置陷阱：数据源路径、Tomcat 端口和 Access 文件权限

一份交付物从自己电脑挪到答辩电脑，宿命般的报错往往集中在这几处：process exited with code 3221225477 / 0xc0000005这类访问违规错误，在 Java Web 项目里通常指向 JDK 与 Tomcat 位数不匹配或某个本地库加载失败；数据库文件路径配死导致驱动初始化失败，则是最常见的「UCanAccess 加载后连接不上」元凶。把 bookstore.mdb 放在项目目录内看似方便，但 Tomcat 部署时会复制整个 war 包，Access 文件被锁定在临时目录，修改数据后重新部署就丢数据。我的习惯是把.mdb放到 Tomcat 之外的固定目录，比如D:/data/bookstore.mdb，用配置文件注入路径。

Access 文件权限在 Windows 下还有一层隐形坑：如果 Tomcat 以 Windows 服务形式运行，运行账户通常是Local System，它访问D:/data可能没有写入权限，表现为「前台访问正常，后台修改图书死活报错」。解决方式是给该目录添加Users组的完全控制权限，或者干脆用命令行窗口前台启动 Tomcat（startup.bat），用当前登录用户身份运行，省去权限配置。如果部署环境是 Linux 服务器，UCanAccess 依赖的某些本地文件锁机制表现会有差异，课程设计阶段不建议折腾 Linux，Windows 桌面环境是最低摩擦的演示场所。

5. 从能跑通到高分交付：Access 数据库安全、查重规避与答辩前验证清单

5.1 Access 数据库的固定时间刷新技术与安全防护

Access 是文件型数据库，.mdb文件直接暴露在项目目录里，任何人都能拷走，这让「数据安全」成为答辩时一个容易主动加分的提问点。常见的做法有两层：第一层是把数据库文件移到 Tomcat 的 webapps 之外的目录，让浏览器无法通过http://localhost:8080/bookstore/bookstore.mdb这种路径直接下载；第二层是给 Access 数据库设置打开密码。UCanAccess 驱动连接加密数据库时，需要在 JDBC URL 里追加参数：

jdbc:ucanaccess://D:/data/bookstore.mdb;password=yourpwd123

但注意 UCanAccess 的密码参数名是password，全部小写，跟在分号后面不加空格。设置 Access 密码需要在 Microsoft Access 里以独占方式打开数据库，然后「文件 -> 信息 -> 用密码加密」。如果你手头没有安装 Office，常见的做法是用 Access 的 VBA 脚本或第三方库设置，课设阶段如果不想增加复杂度，可以只做文件位置隔离，然后跟老师解释「数据库本身的密码由系统管理员定期更新」。

另一件容易被忽略的事是「定时刷新」：Access 文件型数据库长时间运行后，删除操作产生的碎片和记录锁残留会影响性能，常见做法是写一个DatabaseBackup.jsp管理页，管理员点击按钮后，用 Java 的文件复制 API 把bookstore.mdb复制成带时间戳的备份文件。这里注意不能在 Tomcat 运行时直接覆盖正在被连接的.mdb文件，UCanAccess 会持有一个文件句柄，强制覆盖轻则备份失败，重则损坏数据库。更稳妥的做法是先停止数据源连接，或者用 Access 自带的「压缩和修复数据库」功能。这段逻辑可以直接写进论文的「系统维护」章节，体现项目完成了运维层面的思考。

5.2 查重规避的几个思路：改什么、保留什么

与代码查重同理，论文查重在中国知网等平台拉取的比对库越来越全，冲掉重复率的有效手段是重构「系统设计」和「数据库设计」两章的描述方式。前人的论文喜欢画完 E-R 图后逐表罗列字段，这种写法在查重库里高度雷同。我的建议是表单结构继续保留，但对每张表的「设计原因」「冗余字段的选择」「范式与非范式的取舍」写出自己的推导过程，比如「订单表冗余了 user_name 和 book_name 字段，虽然违反第三范式，但避免了每次查询订单都 JOIN 两张表，在 Access 单文件场景下，减少 JOIN 是更实际的选择」——这种内容的重复率天然低，而且显示了真实的工程思考。

代码部分的查重则看学校用的是代码查重还是文本查重。如果是文本查重，注释和变量名是重灾区，把bookDao换成bookHelper意义不大，核心的类名和页面结构一致就会被标记。常见处理是先理解代码逻辑，把 Servlet 中的业务代码按「参数校验、数据处理、跳转封装」重新拆分，同时把原来一两百行的大方法拆成几个短方法。这不仅是查重规避，也是答辩时讲代码更顺手的做法——老师让你指着一页代码说明「这个方法是做什么的」，你显然不想面对一个 200 行的巨型函数。

5.3 最终自查清单：启动、功能、知识盲区，一项都不能落下

在把论文和项目打包上交之前，建议按下面这份清单做最后一次完整走查。它能帮你把「系统能跑」的判断从「好像能玩」变成「经得起所有提问」：

1. 冷启动测试：解压后在全新目录部署，确认 JDK、Tomcat、Access 驱动版本匹配。 2. 必跑路径测试：从注册、登录、分类浏览、搜索、加入购物车、修改数量、下单、付款、后台登录、图书管理、订单管理，全流程走一遍并截图留档。 3. 异常输入测试：搜索框输入单引号，用户 ID 输入负数，购物车数量输入 0，看是否被合理处理。 4. 数据一致性测试：下单后检查 orders、order_items、books 三张表的对应记录和库存变化。 5. 权限测试：未登录访问后台页面应跳转登录；普通用户访问 admin 目录应被拒绝。 6. 知识盲区清单：Access 和 MySQL 的区别、JDBC 原理、Session 与 Cookie 的区别、为何用 PreparedStatement 防注入——写在本子上，对着镜子能讲清楚再上场。

最后必须检查的是.mdb文件是否真的能打开。经常出现这种情况：项目在你自己电脑上运行正常，但因为 Access 数据库文件被打包进了 war，而在 war 展开到临时目录的路径含空格或中文时，UCanAccess 可能报路径解析错误。验证方式是删掉 war 包后重新部署一次，确认冷启动能过，才算真正交付。这份系统的价值不在代码量，而在所有模块能否串成一个能够自圆其说的业务闭环——网络书店销售管理系统的每个环节你都亲手动过，答辩时老师提问的点，也就都在你胸有成竹的射程之内了。

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