最近一直在折腾一个基于 SSM 的协同购物推荐系统，项目代号叫 lgef2，虽然名字看着像随手起的随机串，但它本质上是一个很完整的电商类 Java Web 项目。包里除了可运行的源码，还有 MySQL 数据库脚本、开发环境说明、调试部署步骤，以及一份上万字的毕业论文文档。对正在做课程设计、毕业设计，或者学完 SSM 想找一个“带算法、带完整业务闭环”的练手项目的人来说，这类项目非常值得拆开来看。尤其是“协同过滤推荐”这一块，比单纯做增删改查有意思得多，也更容易在答辩时讲出亮点。
我拿到这类项目的第一反应不是急着点“运行”，而是先理清楚三个问题：这套系统给谁用？业务上要解决什么？推荐算法到底是怎么算出来的？搞懂这三件事，后面的代码、数据库、部署问题基本都能顺着线索自己解决。
1. 项目整体设计与核心思路
1.1 项目定位：不是普通后台管理，而是一个带推荐逻辑的电商闭环
很多 SSM 课程设计都停留在“登录、CRUD、分页、权限”这个层面，跑起来容易，但答辩时老师一问“你的系统有什么难点”，基本答不出太多东西。lgef2 这个项目不一样，它把协同购物推荐放在了核心位置，围绕推荐算法搭建了完整电商功能。用户登录后能浏览商品、搜索商品、按分类筛选、把商品加入购物车、生成订单、查看订单状态；管理员登录后能管理商品、分类、用户、订单，还能查看一定程度的统计数据。
这些功能单独看都不稀奇，但组合起来就是一个标准的“用户行为驱动”的业务系统。用户浏览了哪些商品、在哪些商品上停留时间长、加了哪些购物车、下了哪些单，这些行为会被记录下来，成为推荐算法的输入数据。没有这些前置功能，推荐算法就成了无源之水。所以项目里“用户行为表”和“订单表”是数据层的核心，而不是像普通后台那样把商品表当成唯一主角。
1.2 技术栈为什么选 SSM
项目标题写得很明确，SSM 指的是 Spring + SpringMVC + MyBatis，这是 Java Web 领域非常经典的组合。有人会问，现在不是流行 Spring Boot 吗？为什么还要用 SSM 做项目？
我的理解是，SSM 适合用来理解 Web 开发的分层思想。Spring 管对象和事务，SpringMVC 管请求分发和页面跳转，MyBatis 管数据库访问。三个框架各司其职，配置过程相对繁琐，但正因为繁琐，你才能感受到一个请求从浏览器到 Controller、Service、Mapper、数据库再返回页面的完整链路。用 Spring Boot 的话，很多配置被自动封装，初学者反而容易“只会用不会改”。
另外，很多高校的课程安排和论文模板还是以 SSM 为主，项目里如果直接用 Spring Boot，可能在格式和答辩预期上会有出入。lgef2 选择 SSM，其实是很贴合“毕业设计/课程设计”这个场景的。
1.3 协同购物推荐是什么意思
“协同购物推荐”严格来说对应推荐系统里的协同过滤（Collaborative Filtering），核心思想就一句话：物以类聚，人以群分。
系统会先建一张用户-商品评分矩阵，矩阵的行是用户，列是商品。用户对商品的行为（浏览、加购、下单）可以换算成分值，比如浏览算 1 分，加购算 3 分，下单算 5 分。然后计算用户与用户之间的相似度，找到与当前用户最相似的邻居用户，把这些邻居喜欢而当前用户没买过的商品推荐出来。这就是“基于用户的协同过滤”。
还有另一种思路是基于商品的协同过滤，先计算商品与商品之间的相似度，然后根据用户历史喜欢的商品，找出相似商品进行推荐。lgef2 项目里两种思路都有体现，主推逻辑放在 Service 层的推荐模块中，核心代码量并不大，但效果很直观。
2. 数据库设计与推荐数据基础
2.1 核心表结构设计
拿到项目源码后，第一件事应该是打开数据库脚本，把表结构理清楚。lgef2 的数据库脚本通常叫shop_recommend.sql，里面包含了系统运行必需的全部表。
主要表大概有这么几张：
| 表名 | 作用 | 关键字段 |
|---|---|---|
| t_user | 用户表 | id, username, password, nickname, avatar |
| t_category | 商品分类表 | id, name, icon, sort |
| t_product | 商品表 | id, category_id, name, price, stock, image, sales |
| t_cart | 购物车表 | id, user_id, product_id, quantity, add_time |
| t_order | 订单表 | id, order_no, user_id, total_price, status, create_time |
| t_order_item | 订单明细表 | id, order_id, product_id, product_name, price, quantity |
| t_user_behavior | 用户行为表 | id, user_id, product_id, behavior_type, score, create_time |
这几张表的关系也很清楚：用户浏览或购买商品会产生行为记录，购物车是临时存储，订单和订单明细记录最终交易，商品分类用于前台筛选和后台管理。推荐算法的输入主要来自t_user_behavior，这张表是整个项目的灵魂。
2.2 用户行为数据如何采集
推荐系统最怕没有数据。lgef2 的做法是在前端 Controller 里加了一套“埋点”逻辑。用户访问商品详情页时，Controller 会记录一条行为数据；用户加入购物车时，再更新一条行为数据；用户下单支付后，还会更新行为数据。这种行为记录的代码不复杂，但在普通电商项目里很容易被忽略。
我建议在阅读源码时重点看两个地方：一个是商品详情 Controller 里的行为采集方法，另一个是订单创建成功后如何更新行为分值。
比如在商品详情页面，常见的代码风格是这样的：
@RequestMapping("/detail") public String detail(Integer productId, HttpSession session) { User user = (User) session.getAttribute("loginUser"); if (user != null) { behaviorService.record(user.getId(), productId, 1, 1); } Product product = productService.findById(productId); return "product/detail"; }这里的record方法接收四个参数：用户ID、商品ID、行为类型、分值。行为类型 1 代表浏览，2 代表加购，3 代表下单。分值对应 1、3、5。这套规则虽然简单，但对后续推荐计算来说非常实用。
2.3 数据库连接配置与连接池
SSM 项目里数据库连接一般通过jdbc.properties配置文件管理。lgef2 项目用的是 MySQL 数据库，相关配置大概是：
jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/shop_recommend?useUnicode=true&characterEncoding=utf8 jdbc.username=root jdbc.password=123456现在如果本地装的是 MySQL 8.x，驱动类名建议改成com.mysql.cj.jdbc.Driver，并且 URL 里加上serverTimezone=Asia/Shanghai，否则容易报时区错误。
项目里还集成了 Druid 连接池。Druid 的好处是自带监控页面，能看到连接池使用情况、SQL 执行耗时，对调优和排查慢 SQL 很有帮助。在 Spring 的 applicationContext 里配置 Druid 的 Bean 时，一定要确认spring.datasource相关属性能否正确加载，否则项目启动后数据库连接一直拿不到。
3. 开发环境搭建与项目导入
3.1 环境清单与版本匹配
复现项目的第一步是环境一致。lgef2 项目的开发环境一般是 JDK 8 + Maven 3.6 + Tomcat 8.5 + MySQL 5.7 + IDEA。
这套组合比较稳定，几乎没有版本冲突。如果你本地已经装了更高版本，比如 JDK 17 或者 Tomcat 10，需要特别注意兼容性。Tomcat 10 把包名从javax.servlet改成了jakarta.servlet，SSM 项目里很多代码还在用旧包名，直接跑会报 ClassNotFoundException。
版本匹配这一点我吃过不少亏，所以强烈建议先看项目里的 README 或者开发环境说明。lgef2 这套项目如果提供了环境配置.txt或部署说明.doc，一定要按里面的版本来，别自作主张用新版环境。
3.2 IDEA 导入 Maven 项目
在 IDEA 里导入项目的步骤其实很固定：
- 打开 IDEA，选择
File -> Open，选中项目的 pom.xml。 - 选择
Open as Project，IDEA 会自动识别 Maven 项目结构。 - 等待 Maven 依赖下载完成。如果下载慢，可以把 Maven 仓库换成国内镜像。
- 配置 Tomcat。在
Run -> Edit Configurations里添加 Tomcat Server，并在 Deployment 中添加项目的 war exploded 包。 - 启动前检查项目 SDK 是否为 JDK 8，Maven 的 settings 文件是否正确。
导入这一步最容易出问题的就是 Maven 依赖下载失败。SSM 项目常见的依赖包括 Spring、SpringMVC、MyBatis、MyBatis-Spring、MySQL 驱动、Druid、Jackson、JSTL 等。如果某个依赖下载失败，项目会直接显示一堆红色报错，这时候先检查网络、镜像和 Maven 本地仓库路径。
3.3 数据库导入与初始化
数据库脚本导入其实非常简单，但很多人会在这一步卡住。正确操作是先用命令行或可视化工具创建数据库，然后执行脚本。
用命令行执行的话：
mysql -uroot -p123456 source D:/shop_recommend.sql用 Navicat 的话，右键点击连接，选择“运行 SQL 文件”，然后选择脚本路径执行就可以。执行完成后，重点检查t_user表里是否有一条管理员账号，比如admin/admin123。没有管理员账号的话，后台登录入口根本进不去。
数据库导入后，还要检查jdbc.properties里的用户名密码是否和本地 MySQL 一致。这一步不对，项目启动后一旦访问数据库就会报Access denied或者Communications link failure。
4. 核心功能实现与推荐算法拆解
4.1 SSM 常用注解在项目里的体现
很多学习 SSM 的人对注解一知半解。lgef2 项目里用到的注解不算多，但覆盖了 Web 层、业务层和持久层，非常适合用来对照学习。
Controller 层常见的是@Controller、@RequestMapping、@ResponseBody。页面跳转用@Controller，接口返回 JSON 时加@ResponseBody。项目里的商品列表、搜索、推荐接口都用到了这些注解。
Service 层最常见的是@Service和@Transactional。加购、下单这种多表操作需要保证事务一致性，所以在对应方法上都会加事务注解。如果一个方法里既有订单插入，又有库存扣减，却没有事务控制，中间任何一步失败都会导致数据不一致。
持久层常见的是@Repository、@Param。Mapper 接口里如果有多个参数，必须用@Param指定参数名，否则 MyBatis 会报参数绑定错误。这个坑在 MyBatis 里特别经典，很多新手写 SQL 时直接用#{id}，但接口方法里没有声明参数名，最终报错。
4.2 登录拦截与权限控制
SSM 项目里权限控制一般通过 SpringMVC 拦截器实现。lgef2 项目里有一个LoginInterceptor，拦截需要登录才能访问的 URL。用户会话里没有loginUser时，会直接重定向到登录页。
拦截器配置在 spring-mvc.xml 里：
<mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/cart/**"/> <mvc:mapping path="/order/**"/> <mvc:mapping path="/user/**"/> <bean class="com.lgef2.interceptor.LoginInterceptor"/> </mvc:interceptor> </mvc:interceptors>这套配置重点是搞清楚哪些路径被拦截、哪些放行。商品列表和详情页应该放行，否则游客无法浏览商品；购物车、订单、个人中心必须拦截，否则会报空指针异常。
4.3 协同过滤推荐算法核心代码
推荐算法是项目里最有价值的部分。基于用户的协同过滤大致分三步：构建User-Item矩阵、计算相似度、生成TopN推荐。
在 Java 实现里，第一步通常是把t_user_behavior表的数据加载到一个 Map 中：
Map<Integer, Map<Integer, Integer>> userItemMap = new HashMap<>(); // key: userId, value: Map<productId, score>第二步计算用户相似度。假设有 A、B 两个用户，他们行为向量分别是商品评分数组，用余弦相似度计算：
public double cosineSimilarity(Map<Integer, Integer> userA, Map<Integer, Integer> userB) { double dot = 0, normA = 0, normB = 0; for (Integer key : userA.keySet()) { normA += userA.get(key) * userA.get(key); if (userB.containsKey(key)) { dot += userA.get(key) * userB.get(key); } } for (Integer value : userB.values()) { normB += value * value; } if (normA == 0 || normB == 0) return 0; return dot / (Math.sqrt(normA) * Math.sqrt(normB)); }第三步是找出相似度最高的 K 个用户，然后把这些用户行为里分值较高的商品，排除当前用户已经交互过的商品，按综合得分排序后推荐出去。
基于商品的协同过滤也类似，只不过矩阵变成“商品-用户”，先算商品相似度，再根据用户历史偏好生成推荐。lgef2 项目里推荐结果默认取前 5 条，在首页“猜你喜欢”区域展示。
4.4 购物车与订单的完整流程
购物车和订单模块是电商系统的业务核心。加购时先判断用户登录状态，再检查商品是否存在、库存是否充足。加入购物车时，如果同一用户已经加过同一商品，数量直接加一而不是插入重复记录。
下单流程一般是：
- 从购物车勾选商品。
- 生成订单主表记录，状态初始为待付款。
- 批量插入订单明细。
- 扣减库存。
- 清空对应的购物车记录。
- 更新用户行为分值，触发推荐数据更新。
这个流程里每一步都有可能出现空值或异常。我调试时遇到过一件很典型的事：下单成功后库存没扣减，原因是订单明细插入失败后事务没有回滚。后来检查发现方法上没有加@Transactional，加上之后问题就消失了。
5. 调试部署过程中的常见问题与避坑经验
5.1 从源码到本地运行的标准调试顺序
调试一个 SSM 项目要有顺序，乱点只会浪费时间。我的习惯是先看日志，再配环境，最后断点调试。
项目启动后，如果控制台没有报错但页面 404，多半是 DispatcherServlet 拦截了静态资源或者页面路径不对。如果启动直接报错，先贴出关键异常。
lgef2 项目常见的启动报错有这几类：
| 异常现象 | 常见原因 | 解决办法 |
|---|---|---|
| 启动时找不到 Spring 配置文件 | 项目没被识别为 Maven/Web 项目 | 重新导入项目，检查 Artifacts 配置 |
| 访问页面 404 | 视图解析器前缀后缀配置不对 | 检查 spring-mvc.xml 中 InternalResourceViewResolver |
| Mapper 接口报 BindingException | mapper.xml 文件没有正确加载 | 检查 MyBatis 配置里的 mapperLocations 路径 |
| 数据库连接失败 | jdbc.properties 用户名密码错误 | 核对本地 MySQL 账号密码 |
| 中文乱码 | 编码过滤器缺失 | 在 web.xml 中配置 CharacterEncodingFilter |
| 端口占用 | Tomcat 未正常关闭 | 修改端口或杀掉占用进程 |
5.2 三个特别容易被忽略的点
第一点是数据库脚本里的字符集。执行 SQL 文件时，如果表结构里的字段是utf8mb4，但导入工具的连接字符集是默认的 latin1，中文数据导入后容易变成乱码。建议在导入前先在数据库执行set names utf8mb4;。
第二点是 Tomcat 部署时的小细节。如果使用 IDEA 直接运行项目，部署方式选择“war exploded”模式即可，不要选“war”，因为后者每次修改都要重新打包，调试效率很低。
第三点是项目里的推荐结果可能因为数据太少而不明显。如果数据库里只有三五个用户，行为记录也不多，算出来的相似度基本没有参考价值。为了调试推荐效果，可以手动往行为表里插入几条明显的相似用户数据，比如让用户甲和用户乙都喜欢同一批商品。
5.3 如何确定项目已经真正跑通
判断项目跑通不能只看首页能打开，要按流程走一遍完整业务：用管理员账号登录后台，新增一个分类和商品；用普通用户注册、登录、浏览商品、加购、下单；回到管理员后台确认订单出现且库存已经扣减；最后回到首页查看“猜你喜欢”是否能根据行为记录生成推荐。
如果这几步都正常，说明数据库、前后端、拦截器、事务和推荐模块全部联动起来了。这也是我在调试时最常用的自测清单。
6. 论文文档与项目答辩准备
6.1 万字论文该怎么组织
lgef2 项目自带的论文文档超过一万字，结构对应毕业设计标准格式。大致章节是：摘要、绪论、相关技术介绍、需求分析、系统设计、数据库设计、系统实现、系统测试、总结与展望、参考文献。
很多人写论文时不知道每个章节该写多少内容。我建议这样分配：摘要和绪论可以写 1500 字左右，重点交代背景和研究意义；需求分析写 2000 字，把功能模块和用户角色梳理清楚；系统设计和数据库设计写 3000 字，包含架构图和核心表结构说明；系统实现部分写 3000 字以上，关键代码截图加文字说明；系统测试写 1500 字，表格展示测试用例和结果。这样分配下来，字数自然就超过一万了。
6.2 推荐算法部分怎么写得有深度
论文中“系统实现”章节最容易写成代码堆砌，最好把协同过滤算法的过程用文字和图表示清楚。
可以先画一张“用户-商品行为矩阵”的表格，说明怎么把浏览、加购、下单换算成分值；再对比基于用户和基于商品两种协同过滤的适用场景；最后展示相似度计算公式，结合项目里的具体用户数据手动算一个例子。答辩时老师最喜欢问的就是“你这个相似度是怎么算的”，能白板手写推导过程，基本就是加分项。
6.3 系统界面截图与文档配合
项目资料中提到“系统界面在最后面”，这是很多课程设计文档的常见做法。界面截图一般放在论文附录或者文档末尾，作用是直观展示系统效果。但要注意，截图要有针对性，每个功能配一张关键页面就够了，不要截一堆重复页面。
如果自己补截图，最好先用测试账号把界面状态调整到数据完整的情况，比如购物车里有商品、首页有推荐结果，再截图。界面空空如也，写到论文里反而显得系统功能没实现完整。
我个人做下来最深的体会是，这类 SSM 项目的价值不在“能跑”，而在你能不能把一条完整链路讲清楚。从用户打开商品详情页，到行为记录落库，再到协同过滤算出相似度，最后把推荐商品展示在首页，这一整条链路里每一个环节都有实际代码在支撑。把这条链路吃透，哪怕换成 Spring Boot、换成其他推荐算法，你也能很快迁移过去。
最后再分享一个小技巧：调试推荐算法时不要盯着“推荐结果准不准”看，先看相似度计算用的基础数据对不对。数据源一旦有脏数据，再好的算法也白搭。搞清楚数据从哪里来、如何清洗、如何落表，比优化算法本身重要得多。这套项目跑通之后，建议自己再改一版，比如把基于用户和基于商品的推荐结果做加权融合，或者把相似度计算换成更贴近实际场景的皮尔逊相关系数，改完之后你对推荐系统的理解会上一个台阶。
