JSP+MySQL+Apriori网络书城关联规则推荐实战

JSP 做网络书城这个题目，我前前后后帮人看过好几个版本，绝大多数只做到“商品列表 + 购物车 + 下单”就收尾了，真正把 MySQL 里沉淀下来的订单数据捞出来、用 Apriori 关联规则算出“买过这本书的人还买了什么”的，少之又少。大部分项目卡在两个地方：一是不知道关联规则该在哪一步介入，二是挖出来的规则没法稳定地落到页面上。这篇就围绕一个可运行的 JSP + MySQL + Apriori 网络书城，把整体设计、算法落地、搜索与分类展示、购物车联动、环境部署和踩坑排查讲透，适合正在做课程设计或毕设、又不想做成“假商城”的读者，也适合想搞明白推荐位到底怎么从订单里长出来的人。

1. 项目整体设计与技术选型拆解

1.1 为什么这套技术栈组合还能打

先把话说直白：JSP + Servlet + JDBC + MySQL 这套组合，放在今天的生产环境里确实不算先进，但它在“一个人两周内交付一个能跑、能演示、能讲清楚原理的完整系统”这个目标上，性价比极高。JSP 天然把页面和 Java 代码放在同一个文件里，对不熟悉前后端分离的读者来说，调试链路短——浏览器打开就是结果，报错栈直接打在页面上，不用在 Nginx、跨域、打包工具之间来回折腾。

真正让这个项目区别于普通商城 demo 的，是 Apriori 这一层的存在。一旦引入关联规则，整个系统的数据流就从“单向读写”变成了“读写 + 离线挖掘 + 结果回灌”的闭环：用户下单产生订单明细，订单明细聚合成事务集，事务集跑 Apriori 得到规则，规则写回数据库，前台再从规则表里读推荐位。这条链路一旦打通，项目的技术含量和答辩时的可讲深度就完全不一样了。

选 MySQL 而不是文件或内存数据库，理由也很实在：关联规则挖掘本质上是集合运算，SQL 的 GROUP BY、自连接、EXISTS 在处理候选集计数时非常顺手，很多时候一条 SQL 顶几十行 Java。而且订单、商品、用户这些数据天然是关系型的，用 MySQL 存是最省心的。至于 Apriori 本身，我用纯 Java 实现而不是调用现成库，一方面是为了让每一步都可控、可调参、可打日志，另一方面答辩时被问到“算法怎么实现的”，你能指着自己的代码讲，而不是说“调了个包”。

还有一点容易被忽略：这套栈的部署成本极低。一台普通笔记本装上 JDK 和 Tomcat，把 war 包往里一扔，改一下数据库连接串就能跑，不需要 Docker、不需要容器编排。对于要交源码、要在答辩现场演示的项目来说，“五分钟能在老师电脑上跑起来”本身就是一种竞争力。

1.2 功能模块拆解与职责边界

一个完整的网络书城，功能点乍看很多，但按职责归拢其实就四层。第一层是商品域，负责书籍信息的增删改查、分类维护、上下架状态；第二层是交易域，负责购物车、下单、订单明细、库存扣减；第三层是检索与展示域，负责关键词搜索、分类浏览、新书专区、首页推荐位；第四层是推荐计算域，也就是 Apriori 的离线任务和规则表维护。

这四层的边界一定要划清楚，否则代码会迅速烂掉。我见过最常见的错误是把推荐计算写在商品详情页的 Servlet 里，用户每刷新一次详情页就重新读一遍全量订单、跑一次 Apriori。数据量小的时候看不出来，订单一多，页面直接卡死，而且 Tomcat 线程池很快就被占满。正确的做法是：详情页只做一件事——拿当前书籍 ID 去book_rule表里查已算好的规则，一次简单的SELECT就返回；Apriori 则在后台由定时任务或手动触发的入口执行，跑完把结果写表。

再往细里说，检索与展示域里，“搜索”和“分类展示”看起来都是查列表，但实现思路完全不同。搜索是用户主动输入、结果不确定、需要模糊匹配和排序；分类展示是系统预设的、结果确定、需要分页和优先级排序。把这两个功能写成同一个方法，后期加筛选条件时会非常痛苦。我的习惯是拆成两个 Servlet：SearchServlet只处理关键词，CategoryServlet只处理分类 ID，共用一个BookDao里的不同查询方法。

1.3 数据库表结构怎么设计才不返工

表结构是这类项目最容易返工的地方。很多同学一开始只建了book、user、orders三张表，做到购物车发现没地方存，于是临时加字段，做到推荐发现订单明细没拆开，于是又改表，最后 SQL 脚本一塌糊涂。下面这套结构是我用过几次之后比较稳的版本，直接给出来：

CREATE TABLE `book` ( `book_id` INT PRIMARY KEY AUTO_INCREMENT, `title` VARCHAR(120) NOT NULL, `author` VARCHAR(60), `publisher` VARCHAR(80), `publish_date` DATE, `shelf_time` DATETIME COMMENT '上架时间，新书判定用它', `category_id` INT, `price` DECIMAL(8,2) NOT NULL DEFAULT 0.00, `stock` INT NOT NULL DEFAULT 0, `sales` INT NOT NULL DEFAULT 0, `cover` VARCHAR(200), `description` TEXT, `is_new` TINYINT DEFAULT 0, `status` TINYINT DEFAULT 1 COMMENT '1上架 0下架', KEY `idx_cat` (`category_id`), KEY `idx_title` (`title`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `order_item` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `order_id` BIGINT NOT NULL, `book_id` INT NOT NULL, `quantity` INT NOT NULL DEFAULT 1, `price` DECIMAL(8,2) NOT NULL, KEY `idx_order` (`order_id`), KEY `idx_book` (`book_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `book_rule` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `antecedent` VARCHAR(64) NOT NULL COMMENT '前项，书籍ID逗号拼接', `consequent` VARCHAR(64) NOT NULL COMMENT '后项，书籍ID', `support` DOUBLE, `confidence` DOUBLE, `lift` DOUBLE, `update_time` DATETIME, KEY `idx_ante` (`antecedent`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

有两个设计细节值得单独讲。一是book表里publish_date和shelf_time必须分开。很多人图省事，用出版日期判断新书，结果一本五年前出版的书今天刚进货上架，前台不认为它是新书；反过来一本刚出版但压了半年才上架的书，也不会出现在新书专区。用上架时间判断“新书”，才符合电商语境里“新”的含义——用户关心的是“最近有什么新东西可以买”，不是“作者什么时候写完的”。

二是book_rule表里antecedent用逗号拼接书籍 ID 而不是存名称。原因是书籍改名、下架、重新上架都是会发生的，存 ID 才能保证规则和商品的一一对应；前台查询时用FIND_IN_SET或者干脆把前项拆成rule_item子表都可以。数据量小的项目直接存 ID 串，一条 SQL 就能查出来，简单够用。

2. Apriori算法在网络书城中的落地细节

2.1 关联规则到底解决书城的什么问题

书城的推荐位如果只是“销量前五”或者“同分类随机”，本质上和货架没区别，用户看到的永远是那几本畅销书。关联规则要解决的是一个更具体的问题：当用户对某本书产生了明确兴趣时，哪些书和它存在真实的购买共现关系。注意关键词是“真实”，不是“人工配置的”。人工配置的搭配往往是编辑凭经验写的——“买 Java 的推数据库”，听起来合理，但数据上未必成立；Apriori 挖出来的规则，每一条背后都有订单数撑着，置信度和提升度都是可查的。

这里必须把三个指标讲清楚，否则调参全靠蒙。支持度 support指的是一组书籍组合在全部订单里出现的比例，衡量“这个组合够不够常见”；置信度 confidence指的是买了 A 的人里有多大比例也买了 B，衡量“规则的可靠程度”；提升度 lift是置信度除以 B 本身的基础购买率，衡量“A 的出现到底有没有真的提升 B 的购买概率”。

提升度是最容易被忽略但最关键的指标。举个例子：某本书 B 本身就是畅销书，全站 30% 的订单都含它，那么不管 A 是什么，只要 A 和 B 一起出现过几次，置信度很容易做到 40% 以上，看起来规则很强，实际上 lift 只有 1.3，说明 A 对 B 几乎没什么带动作用，这条规则放到推荐位上毫无意义。我的做法是前台只展示 lift 大于 1.2 且 support 达到阈值的规则，把那些“因为 B 太火所以看起来很强”的伪规则筛掉。

下面这张表是我在几次数仓规模的测试里总结出来的参数区间，可以直接当起点：

2.2 从订单表到事务集：数据预处理

Apriori 的输入是“事务集”，一条事务就是一个用户一次性买走的若干本书。从order_item表到事务集，中间要做四步清洗，任何一步偷懒，后面挖出来的规则都会脏。

第一步，按order_id分组聚合。同一个订单里的多本书构成一个事务，数量字段在这里不重要——买两本《算法导论》和买一本，对“共现关系”的贡献是一样的。所以事务里只保留去重后的book_id集合。

第二步，剔除无效订单。已取消、已退款、测试账号下的订单必须过滤掉，否则这些“买了又退”的记录会把共现关系搅乱。这一点在实际操作中特别容易被忽略，因为测试阶段自己会下一堆乱七八糟的订单，如果不清理，跑出来的第一批规则基本全是自己测试时随手加购的组合。

第三步，剔除低频书籍。一本书如果在全部订单里只出现过一两次，它参与构成的任何项集都不可能达到支持度阈值，却会在候选集生成阶段制造大量无效组合。我的做法是先统计单本书的出现次数，把低于minCount的书直接从事务里删掉，这一步能把候选集规模压下来一个数量级。

第四步，控制事务规模。一个订单里如果有二十本书，理论上它会产生 2^20 个子集，虽然实际不会全枚举，但对候选计数仍然是负担。我的处理是给单个事务设一个上限（比如 15 本），超出的订单按销量截断，只保留卖得最多的那几本。听起来有点粗暴，但书城场景下一次买二十本的情况本来就少，截断对结果影响微乎其微。

下面是这一步对应的 SQL，一条语句就能把事务集捞出来：

SELECT oi.order_id, GROUP_CONCAT(DISTINCT oi.book_id ORDER BY oi.book_id) AS items FROM order_item oi JOIN book_order o ON o.order_id = oi.order_id WHERE o.status IN (1, 2) -- 已支付/已发货，排除取消退款 AND o.create_time >= DATE_SUB(NOW(), INTERVAL 180 DAY) GROUP BY oi.order_id HAVING COUNT(DISTINCT oi.book_id) BETWEEN 2 AND 15;

加时间窗口是个实用技巧：只挖最近半年的订单，既能反映当下的购买习惯，又能控制参与计算的数据量。全量订单一起挖，两年前的消费偏好会把今年的信号稀释掉。

2.3 算法核心实现与参数选择

Java 侧的 Apriori 实现，核心就三块：频繁项集挖掘、候选集生成、规则导出。下面这份代码是我实际用过的版本，做了简化但逻辑完整：

public class Apriori { private final List<Set<Integer>> txns; private final int minCount; public Apriori(List<Set<Integer>> txns, double minSupport) { this.txns = txns; // 向上取整，避免 0.02 * 1999 = 39.98 被截断成 39 this.minCount = (int) Math.ceil(minSupport * txns.size()); } public Map<Set<Integer>, Integer> findFrequentItemsets() { Map<Set<Integer>, Integer> all = new HashMap<>(); Map<Set<Integer>, Integer> current = new HashMap<>(); // 1-项集 Map<Integer, Integer> single = new HashMap<>(); for (Set<Integer> t : txns) { for (Integer id : t) single.merge(id, 1, Integer::sum); } single.forEach((k, v) -> { if (v >= minCount) current.put(Collections.singleton(k), v); }); all.putAll(current); int k = 2; while (!current.isEmpty()) { Set<Set<Integer>> candidates = genCandidates(current.keySet(), k); Map<Set<Integer>, Integer> next = new HashMap<>(); for (Set<Integer> cand : candidates) { int c = 0; for (Set<Integer> t : txns) if (t.containsAll(cand)) c++; if (c >= minCount) next.put(cand, c); } all.putAll(next); current = next; k++; if (k > 3) break; // 书城场景限制到 3 项集，够用且可控 } return all; } private Set<Set<Integer>> genCandidates(Set<Set<Integer>> prev, int k) { List<Set<Integer>> list = new ArrayList<>(prev); Set<Set<Integer>> res = new HashSet<>(); for (int i = 0; i < list.size(); i++) { for (int j = i + 1; j < list.size(); j++) { Set<Integer> union = new TreeSet<>(list.get(i)); union.addAll(list.get(j)); if (union.size() != k) continue; boolean ok = true; for (Integer item : union) { Set<Integer> sub = new TreeSet<>(union); sub.remove(item); if (!prev.contains(sub)) { ok = false; break; } } if (ok) res.add(union); } } return res; } }

代码里if (k > 3) break;这一行是刻意的取舍。理论上书籍之间的关联可能是四本、五本的组合，但实际业务里，推荐位展示的是“买过 A 的人还买了 B/C/D”，三项以上的前项在页面上根本没法用一句话表达清楚，而且支持度衰减极快，能过阈值的组合本来就少。限制到 3 项集，计算量可控，结果也够用，这是我在实际项目里反复验证过的一点。

规则导出部分，重点是提升度的计算不能漏：

for (Map.Entry<Set<Integer>, Integer> e : freq.entrySet()) { Set<Integer> itemset = e.getKey(); if (itemset.size() < 2) continue; for (Set<Integer> ante : properSubsets(itemset)) { Set<Integer> cons = new TreeSet<>(itemset); cons.removeAll(ante); int supAnte = freq.getOrDefault(ante, 0); if (supAnte == 0) continue; double conf = e.getValue() * 1.0 / supAnte; if (conf < minConf) continue; double supAll = e.getValue() * 1.0 / total; double supCons = freq.getOrDefault(cons, 0) * 1.0 / total; double lift = conf / supCons; if (lift >= minLift) { rules.add(new Rule(ante, cons, supAll, conf, lift)); } } }

举个具体算例，把参数怎么起作用说透。假设参与挖掘的订单总数是 2000 条，最小支持度设 0.02，那么minCount = ceil(2000 × 0.02) = 40，意思是任何书籍组合必须在至少 40 个订单里同时出现过才算频繁。现在有书籍 A（《Java 编程思想》）和 B（《深入理解 Java 虚拟机》），它们同时出现在 55 个订单里，55 ≥ 40，通过支持度检验，sup(A,B) = 55/2000 = 2.75%。A 单独出现在 130 个订单里，那么 conf(A→B) = 55/130 = 42.3%，超过 0.4 的阈值。B 单独出现在 200 个订单里，基础购买率是 200/2000 = 10%，lift = 0.423 / 0.1 = 4.23，远大于 1，说明买 A 的人买 B 的概率是不买 A 人群的 4.23 倍，这条规则非常值得推。

反过来再看一条反例：C 是《新华字典》，几乎人人会买，基础购买率 25%；D 是某本畅销小说，基础购买率 30%。C 和 D 共现 60 次，但 C 出现 500 次，conf(C→D) = 60/500 = 12%，直接低于阈值被砍掉。这就是置信度和提升度联合过滤的价值。

2.4 把算法从请求线程里挪出去

这一步是整个项目最重要的架构决定，也是绝大多数同类项目做得最差的地方。正确姿势是：Apriori 绝不出现在任何用户请求的处理路径上。原因很简单——算法耗时随订单量增长，而用户请求要求毫秒级响应，两者天然冲突。哪怕现在只有 2000 条订单跑一秒就完，将来数据涨到两万条，详情页就会出现明显的白屏。

我的做法是给规则计算单独开一个入口，两种触发方式二选一。第一种是手动触发，做一个只有管理员能访问的RuleBuildServlet，点一下按钮跑一次，跑完把日志打出来告诉管理员挖了多少条频繁项集、生成了多少条规则、耗时多久。这种方式最省事，适合演示场景。第二种是定时任务，用ServletContextListener启动时起一个ScheduledExecutorService，每天凌晨跑一次，跑完覆盖规则表。

无论哪种方式，写回规则表的时候都建议用“先清空再批量插入”而不是逐条 update。原因是规则集合每次计算都可能整体变化，逐条对比新旧规则的逻辑很啰嗦，而且容易出现旧规则残留。清空重插配合事务，出问题能整体回滚：

conn.setAutoCommit(false); try (Statement st = conn.createStatement()) { st.executeUpdate("DELETE FROM book_rule"); } try (PreparedStatement ps = conn.prepareStatement( "INSERT INTO book_rule(antecedent,consequent,support,confidence,lift,update_time) VALUES(?,?,?,?,?,NOW())")) { for (Rule r : rules) { ps.setString(1, join(r.getAntecedent())); ps.setString(2, String.valueOf(r.getConsequent().iterator().next())); ps.setDouble(3, r.getSupport()); ps.setDouble(4, r.getConfidence()); ps.setDouble(5, r.getLift()); ps.addBatch(); } ps.executeBatch(); } conn.commit();

还有一个细节：规则表里只存“后项”是单本书的规则。如果后项本身是多本书的集合，前台展示时还要再拆一次，代码复杂度陡增，收益却很低——用户看到“还买了 B、C、D”和分别看三条“还买了 B”“还买了 C”“还买了 D”，感受差别不大。所以生成规则时加个判断，consequent.size() > 1的直接丢弃，这条经验能省掉大量前台展示的麻烦。

3. 商品搜索、分类展示与购物车的实现

3.1 商品搜索的模糊匹配与分页

搜索功能看起来简单，真正做好有讲究。用户输入“java”期望搜到《Java 编程思想》，输入“虚拟机”期望搜到《深入理解 Java 虚拟机》，输入作者名、出版社名也应该命中。所以搜索范围至少要覆盖书名、作者、出版社三个字段。

最直接的实现是LIKE '%关键字%'，配合OR连起来：

SELECT book_id, title, author, price, cover, sales FROM book WHERE status = 1 AND (title LIKE CONCAT('%', ?, '%') OR author LIKE CONCAT('%', ?, '%') OR publisher LIKE CONCAT('%', ?, '%')) ORDER BY sales DESC, book_id DESC LIMIT ?, ?;

必须用PreparedStatement而不是字符串拼接，这不是可选项。我见过太多课程设计的搜索框直接把输入拼进 SQL，输入一个单引号就报错，输入' OR '1'='1就把全库商品捞出来，这种问题答辩时被指出来非常扣分。用占位符能挡住绝大部分注入，成本几乎为零。

排序策略上，ORDER BY sales DESC让畅销书排前面，符合用户预期。但如果用户搜的是精确书名，畅销排序反而可能把目标书挤到第二页。一个折中的做法是加一层“标题完全匹配优先”：ORDER BY (title = ?) DESC, sales DESC，用一次额外的参数传入原始关键词。

分页这块，很多项目只做了列表没做总数，导致页码永远是固定的几页。正确做法是单独一条 count 查询：

SELECT COUNT(*) FROM book WHERE status = 1 AND (title LIKE CONCAT('%',?,'%') OR author LIKE CONCAT('%',?,'%') OR publisher LIKE CONCAT('%',?,'%'));

总数拿到后，在 Java 里算totalPage = (total + pageSize - 1) / pageSize，这个向上取整的写法比Math.ceil更安全，不会因为浮点精度出问题。页码参数要做边界保护，传 0 或负数时强制置为 1，传超过总页数时置为最后一页，否则LIMIT的偏移量算出来是负数，SQL 直接报语法错误。

至于要不要上全文索引或者搜索引擎，我的建议是：数据量在一万条以内，LIKE完全够用，不要为了炫技引入额外组件。LIKE '%x%'走不了索引确实是真的，但一万条数据的全表扫描在现代硬件上也就几十毫秒，用户完全感知不到。真正该优化的地方在别处。

3.2 新书分类与首页商品展示的组织方式

首页是用户对系统的第一印象，信息组织得好不好，直接影响“这个项目做完没做完”的判断。我的首页布局固定为五块：顶部导航与搜索框、分类导航栏、新书上架区、销量榜、推荐位。

新书上架区的取数逻辑，前面提过要用shelf_time。但只用时间排序还不够，还得防止“一下子上了 200 本书，新书区被同一批书占满”的情况。我的处理是加一个时间窗口和数量限制：

SELECT book_id, title, author, price, cover FROM book WHERE status = 1 AND shelf_time >= DATE_SUB(NOW(), INTERVAL 30 DAY) ORDER BY shelf_time DESC LIMIT 8;

30 天是个经验值。太短了（比如 7 天），如果最近没上新，新书区就空了；太长了，用户会觉得“这书都上架俩月了还叫新书”。如果窗口期内数量不足 8 本，再补一条兜底查询按shelf_time倒序补足，保证页面上永远有内容，不会出现空荡荡的一块区域。

分类展示的关键是层级组织。书籍分类天然是两级的，比如“计算机”下面分“编程语言”“数据库”“算法与数据结构”。表结构上可以用parent_id自关联，也可以用两个字段category和sub_category直接平铺。项目规模不大的话，我更推荐平铺——自关联查询要递归，JSP 里写递归渲染很啰嗦，而平铺之后一条GROUP BY就能把所有二级分类和数量取出来：

SELECT sub_category, COUNT(*) AS cnt FROM book WHERE status = 1 GROUP BY sub_category ORDER BY cnt DESC;

这个数量统计还有个额外用途：分类导航栏上直接显示“编程语言（128）”，用户一眼能看出哪个分类书多。这个小细节做过和没做过，观感差别很大。

商品详情页的展示顺序也有讲究。用户点进详情页，第一眼要看到的是封面、书名、价格、库存、加入购物车按钮，这些必须在首屏；第二屏才是简介、目录、作者介绍；最底部才是“买过这本书的人还买了”的推荐位。推荐位放太靠上会干扰购买决策，放太靠下又没人看得到，底部偏上的位置是个平衡点。

3.3 购物车的三种存法怎么选

购物车是这类项目里最容易被做残的功能。残在哪？大部分实现只支持“登录后加购”，未登录用户点加入购物车直接跳登录页。用户体验极差，而且演示的时候一上来就要登录，很不友好。

三种存法各有取舍。Session 存最简单，一个Map<Integer, Integer>往 session 里一扔就行，未登录也能用，缺点是关掉浏览器就没了，换设备也不同步。Cookie 存能持久化，但容量只有 4KB 左右，存十几本书的 ID 和数量就顶到上限了，而且用户可以随手改，价格和数量都不可信。数据库存最可靠，能跨设备同步，但要求用户必须登录。

实际项目里我用的是混合方案：未登录时用 Session 存，登录成功的那一刻把 Session 里的购物车合并进数据库。合并逻辑要注意三点：同一个book_id的数量是相加而不是覆盖；相加后的数量不能超过库存；合并完要清空 Session，避免下次登录重复合并。

for (Map.Entry<Integer, Integer> e : sessionCart.entrySet()) { int bookId = e.getKey(); int addQty = e.getValue(); int stock = bookDao.getStock(bookId); // INSERT ... ON DUPLICATE KEY UPDATE 保证同书只留一行 cartDao.mergeItem(userId, bookId, Math.min(addQty, stock)); } session.removeAttribute("cart");

数据库表要加唯一索引UNIQUE KEY uk_user_book (user_id, book_id)，配合INSERT ... ON DUPLICATE KEY UPDATE quantity = quantity + ?，一条 SQL 就把“有则加、无则插”搞定，不用先查后插，少一次往返也避免了并发下的重复插入。

购物车页面还有几个细节不能漏。数量输入框要允许用户直接改，改完实时重算小计；单本删除和批量删除都要有；底部要显示总件数和总金额，金额用BigDecimal算，绝对不能用double——0.1 + 0.2 != 0.3这个坑在金额计算上是致命的，用户会看到 99.99999999 这种价格。库存不足时该行要高亮提示，并且“去结算”按钮要禁用或者给出明确提示，不能等到下单才报错。

3.4 推荐位与购物车的联动

推荐位如果只在详情页出现，价值就浪费了一半。真正能提升客单价的位置是购物车页面——用户已经决定买了，这时候在下面推两本“经常一起被买走”的书，转化率远高于详情页。

实现上，购物车推荐要做一个“多前项聚合”：把购物车里所有书的 ID 拿出来，去book_rule表里查前项包含其中任意一本的规则，按 lift 倒序取前 4 条，再去重、排除购物车里已经有的书。SQL 大概是这样：

SELECT r.consequent, MAX(r.lift) AS max_lift FROM book_rule r WHERE r.lift > 1.2 AND (FIND_IN_SET(?, r.antecedent) OR FIND_IN_SET(?, r.antecedent) OR FIND_IN_SET(?, r.antecedent)) AND r.consequent NOT IN (?, ?, ?) GROUP BY r.consequent ORDER BY max_lift DESC LIMIT 4;

FIND_IN_SET的性能一般，但规则表通常只有几百上千行，影响可以忽略。如果购物车里的书超过三本，就取销量最高的三本来做查询，避免 SQL 里拼太多OR条件。查询结果为空时，兜底显示同分类的销量前四，保证推荐位不空——这一条很重要，空白区域比“不够精准的推荐”更伤体验。

另外，推荐位的点击行为可以顺手记一下。建一张recommend_click表，记下“从哪本书的推荐位点了哪本书”，这个数据将来可以用来评估推荐效果，也可以作为答辩时的加分项——“我不仅做了推荐，还做了效果回收”。

4. 环境搭建与部署实操

4.1 版本组合与依赖

版本搭配是新手最容易翻车的地方。我推荐的组合是 JDK 8 + Tomcat 8.5 或 9 + MySQL 5.7 或 8.0，这个组合资料最多，出了问题好搜。JDK 8 之后的一些版本对 JSP 的支持有调整，直接用高版本 JDK 配 Tomcat 8 可能在某些容器里出问题，稳妥起见还是 8。

数据库驱动要注意版本对应。MySQL 5.7 用mysql-connector-java5.1.x，驱动类是com.mysql.jdbc.Driver；MySQL 8.0 用 8.0.x，驱动类是com.mysql.cj.jdbc.Driver。混用会报ClassNotFoundException或者Unknown system variable之类的错，这类报错信息往往很含糊，新手容易卡很久。

连接串有几个参数必须带：

jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/bookstore?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true jdbc.username=root jdbc.password=你的密码

useSSL=false是为了避开 8.0 版本默认开启 SSL 导致的握手警告；serverTimezone=Asia/Shanghai不写的话，8.0 驱动会报时区未指定，而且存进去的时间可能差 8 小时；characterEncoding=utf8配合useUnicode=true是中文不乱码的前提；allowPublicKeyRetrieval=true在 8.0 的新认证插件下不加会连不上。

依赖的 jar 包，最少需要三个：mysql-connector-java、jstl（如果 JSP 里用了 c 标签）、standard。都放到WEB-INF/lib目录下，不要只加进 IDE 的 build path——IDE 里配好了但部署到 Tomcat 找不到，是极其常见的坑，因为 IDE 的 classpath 和容器的 classpath 是两回事。

4.2 数据库导入与连接配置

建库语句建议写成脚本，一次性跑完：

CREATE DATABASE IF NOT EXISTS bookstore DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE bookstore; -- 依次执行建表语句、初始数据

字符集用utf8mb4而不是utf8。MySQL 里的utf8其实是utf8mb3，最多三字节，存不了某些生僻字和特殊符号；utf8mb4才是完整的四字节 UTF-8。书籍简介里出现个书名号、生僻人名，用utf8就可能插不进去。

初始数据要准备得像个样子。至少 60 本以上的书，覆盖 8 到 10 个分类，每本有封面图、简介、价格、库存。推荐书目不要瞎编，按每个分类的真实经典书来准备，这样演示时点开分类，内容看起来是像那么回事的。另外准备 300 到 500 条订单数据，这是 Apriori 能挖出规则的底线——订单少于 100 条，支持度阈值一卡，啥都挖不出来。

连接池的问题也要说一句。直接用DriverManager.getConnection每次新建连接，功能上没毛病，但每个请求都建连接开销不小。用 Druid 或者 C3P0 配个连接池会让系统看起来更专业，配置也就十几行：

druid.initialSize=5 druid.maxActive=20 druid.maxWait=3000 druid.validationQuery=SELECT 1

不过这里有个提醒：引入连接池之后，close()的行为变了，直接关连接会被还回池里，如果你在 finally 里手动关了两次，或者把连接存成了静态变量，会出各种奇怪的问题。改造成本不高，但一定要测一遍所有涉及数据库的页面。

4.3 打包部署与运行

部署路径有两条，看你的习惯。用 Eclipse 的话，把项目建成 Dynamic Web Project，配置好 Tomcat 运行时，右键 Run on Server 就行，改动即时生效，调试最方便。用 IDEA 的话，配置一个 Tomcat Local 的 Run Configuration，Deployment 里加上 artifact 为 war exploded，效果一样。

如果不想依赖 IDE，手动部署也不复杂：项目打成 war 包丢进TOMCAT_HOME/webapps，启动 Tomcat 后访问http://localhost:8080/项目名/即可。手动部署时最容易出问题的是访问路径，很多人访问根路径http://localhost:8080/看到 Tomcat 欢迎页，就以为部署失败了，其实是没带项目名。

启动后按这个顺序验一遍，能迅速定位问题出在哪一层：先访问首页看能不能出来，出不来就是 JSP 编译或路径问题；首页出来但没有商品，就是数据库连不上或者查询有问题；商品出来了但图片全是碎图，就是封面路径配置错了；能登录但加购报错，就是购物车表或者 session 配置的问题。这个顺序的核心逻辑是“从静态到动态、从简单到复杂”，一层一层排除，比漫无目的地看日志快得多。

5. 常见问题与排查技巧实录

5.1 中文乱码与编码链路

中文乱码是这类项目绕不过去的第一道坎，而且它有四条独立的链路，每条链路都要单独配置，漏一处就出问题。

第一条是 JSP 页面本身的编码，每个 JSP 文件顶部必须有<%@ page contentType="text/html;charset=UTF-8" pageEncoding="UTF-8" %>，少了pageEncoding，包含中文的 JSP 编译出来就是乱码。

第二条是请求参数的编码。POST 请求必须在读取任何参数之前调用request.setCharacterEncoding("UTF-8")，注意“之前”——如果代码里先getParameter再设编码，编码设置不生效。这一条我踩过，排查了半天才发现是顺序问题。GET 请求在 Tomcat 8 之后默认用 UTF-8 解码，8 之前需要在server.xml的 Connector 上加大URIEncoding="UTF-8"。

第三条是响应编码。response.setContentType("text/html;charset=UTF-8")要写在getWriter()之前，否则输出流已经按默认编码建好了，再设没用。

第四条是数据库链路。库和表都要utf8mb4，连接串要有characterEncoding=utf8，这一条前面说过，不再重复。

排查乱码有个笨但有效的办法：在页面某个角落输出System.getProperty("file.encoding")和request.getCharacterEncoding()，看看 JVM 默认编码是不是 GBK。Windows 上默认编码经常是 GBK，如果 JVM 编码和页面声明的编码不一致，就很容易出问题。启动参数加-Dfile.encoding=UTF-8能一次性解决大部分环境层面的乱码。

5.2 推荐位空白的排查路径

推荐位不显示，是从业者最常被问的问题之一。它不像报错那样有明确提示，往往就是一块白，所以要用排除法定位。

第一步，直接查book_rule表有没有数据。SELECT COUNT(*) FROM book_rule;如果是 0，说明算法根本没跑或者跑了没结果。这时候再去看后台任务日志，日志里应该有“共 X 条事务、Y 个频繁项集、Z 条规则”这样的输出。如果频繁项集有但规则是 0，基本就是置信度或者提升度阈值定太高了，把minConf从 0.5 降到 0.3 试试。

第二步，如果规则表有数据，但前台还是空的，就去查规则里涉及的书籍是不是已经下架或者删除了。这是最常见的隐性故障——书删了，规则还在，前台的关联查询JOIN book ON b.status = 1就把整条规则过滤掉了。解决办法有两种：要么在推荐查询里加INNER JOIN保证只返回有效书，虽然会少几条规则但不会出空窗；要么在删书时顺手清理相关规则。我倾向第一种，简单可靠，而且规则表就那么点数据，多一次 JOIN 无所谓。

第三步，检查缓存。如果项目里用了一级缓存或者把推荐结果存进了application作用域，规则重算之后缓存没更新，前台看到的还是旧数据甚至空数据。这种情况重启一下 Tomcat 就好了，但要知道原因，不然下次还得懵。

第四步，检查 SQL 的FIND_IN_SET参数顺序。FIND_IN_SET(?, r.antecedent)里第一个参数是单个 ID，第二个是逗号串，顺序写反了会静默返回 NULL，不报错但不匹配。这个坑很隐蔽，因为它不产生任何异常。

5.3 购物车与库存、并发的问题

购物车相关的故障里，最严重的是超卖。场景是这样：某本书库存 1 本，两个用户同时点结算，各自的代码都是“先查库存够不够，够了就扣减”，两个线程同时通过了检查，最后库存变成 -1。

解决办法不是加锁，而是把判断条件放进 SQL 的 WHERE 里，让数据库来保证原子性：

UPDATE book SET stock = stock - ?, sales = sales + ? WHERE book_id = ? AND stock >= ? AND status = 1;

执行后看executeUpdate()的返回值，返回 0 说明库存不足，整个订单要回滚。这个写法的好处是判断和扣减在一条语句里完成，InnoDB 的行锁保证不会出现两个事务同时通过检查。订单主表和明细表、库存扣减要放在同一个事务里，任何一步失败都整体回滚，否则会出现“订单创建了但库存没扣”或者“库存扣了但订单没创建”的脏数据。

第二个常见问题是购物车数量异常。用户手动把数量改成 999，或者点加号点了几十下，前端没拦住，后端也没校验，最后下单时数量是个荒谬的值。后端必须在加购和结算两处都做校验：数量必须是正整数，且不超过当前库存；如果超过，按库存值截断并给用户一个提示。前端可以用<input type="number" min="1" max="库存">做第一层拦截，但后端不能依赖前端，这是基本原则。

第三个是 session 购物车丢失。用户加了几本书，过一会儿回来发现购物车空了，通常是 Tomcat 重启导致 session 丢失，或者 session 超时时间设得太短（默认 30 分钟，但有些配置里被改成了几分钟）。开发阶段频繁重启 Tomcat 的话，这个现象会非常频繁地打断测试。解决办法是在本地测试时把 session 超时调长，或者干脆在重启之前先登录，让购物车落到数据库里。

5.4 问题速查表

下面这张表是我这些年被问到最多的问题的汇总，遇到问题时可以按现象直接对号入座：

最后分享一个我在实际操作中的体会：这类项目真正的分水岭不在功能多少，而在“数据是不是真的流动起来了”。一个只有商品列表和购物车、数据全靠手工插入的商城，和一个订单能产生规则、规则能改变推荐位、推荐位能被人点击的商城，代码量可能只差三成，但完整度差了一个量级。所以如果你正在做这个题目，我建议优先把“下单 → 订单明细 → 跑 Apriori → 写规则表 → 详情页读规则”这条链打通，哪怕页面做得朴素一点，这条链路跑通的那一刻，项目就从作业变成了系统。至于规则挖得准不准，先不用纠结，把支持度调到 0.01、置信度调到 0.2，先把规则跑出来看到效果，再回头慢慢收紧参数，比一上来就追求精准要现实得多。