基于SpringBoot的图书商城智能推荐系统设计与实现

又到一年毕设季每年这个时候总有同学拿着“图书商城推荐系统”这种题目来找我问的无外乎是怎么把推荐功能做出亮点、怎么让答辩老师觉得这个项目有技术含量、以及最关键的一步——代码到底怎么落地。这个题目很多人做但绝大多数人都停留在“增删改查一个按销量排行的假推荐”这种程度代码跑得通但没什么含金量。这篇博文我就以这个基于 SpringBoot 的在线图书商城智能推荐平台为例把项目从设计思路、算法选型、表结构设计、核心代码实现到答辩避坑一条龙拆给你看。这套项目本质上不是一个普通的商城系统它的核心卖点是“个性化导购”。同样是新用户进首页有的商城给他推畅销书有的商城给他推他刚搜过的同类书区别就在于有没有一个能感知用户兴趣的推荐层。我用 SpringBoot 做后端服务配合一套可解释的混合推荐策略基于内容的相似度召回 基于用户行为的协同过滤把登录、浏览、加购、下单这些行为数据串起来真正做到根据不同用户的阅读偏好展示不同的图书列表。这套方案特别适合 SpringBoot 方向或者推荐系统方向的毕设也适合想在工作中接触推荐业务的后端同学拿来练手。1. 内容整体设计与思路拆解1.1 为什么推荐系统是图书商城的最佳切入点图书这个品类在电商里有一个很特别的性质它的信息密度高、长尾效应极强。一本书的主题、作者、出版社、标签、适用人群都能构成特征而读者的阅读兴趣又往往集中在少数几个方向上。一个计算机专业的学生和一个做产品经理的人他们逛书城的路径完全是两条线。如果商城没有推荐就是把所有书平铺在一个页面上用户要在上千条数据里自己捞书转化率天然就低。所以图书商城做个性化推荐不是噱头而是真实存在的业务痛点。从毕设选题的角度讲这个切入点的优势也很明显第一推荐算法不需要做得很深基于标签匹配和协同过滤就能达到不错的效果但又有足够的理论深度可以写进论文第二它天然需要“用户—行为—物品”三层数据能展示你数据库设计的功底第三它跟前端交互有强关联首页展示、搜索结果、详情页推荐位都可以动态变化演示效果非常直观。1.2 总体架构与技术选型的取舍逻辑我当时定的技术方案是SpringBoot 2.7.x MyBatis Plus MySQL 8.0 Redis可选前端部分用 Vue 3 Element Plus 做管理端C端首页服务端渲染用 Thymeleaf。之所以选 SpringBoot 2.7 而不是 3.x这里有个很现实的考虑很多学校的毕设环境 JDK 还停留在 8而且老版本的各种教程、依赖兼容性资料最丰富出了坑容易查到解决方案。整体上走的是一个轻量化单体应用架构不整微服务那套因为毕设场景下微服务只会徒增部署复杂度。但单体不代表结构可以乱。我按职责拆了四个核心模块系统管理模块、商品与订单模块、用户行为采集模块、推荐引擎模块。推荐引擎独立成一个模块服务输入是用户ID和上下文输出是推荐书单内部屏蔽了具体算法细节。这样后面你无论是想替换算法还是给论文里画架构图都清晰好讲。1.3 推荐策略的组合思路这个项目里我设计了三层推荐策略按优先级排列基于用户行为相似度的协同过滤UserCF用于老用户的首页猜你喜欢。基于图书内容标签的相似度推荐Content-Based用于图书详情页的“相似书籍推荐”和搜索结果扩展。基于热门榜和编辑精选的兜底推荐用于新用户冷启动阶段和登录前的游客态。这三层不是孤立的。实际加载首页推荐位时系统会先判断用户有没有足够的行为数据有就走前两种策略混合加权没有就降级到兜底推荐。这种“策略分层 自适应降级”的设计是我自己实际开发中比较常用的套路也契合生产环境里推荐系统的常规做法。答辩时把这个链路讲清楚老师就知道你不是随手糊一个协同过滤完事。架构上要额外注意的一点是推荐结果不要实时算。我当时是每晚用定时任务先把所有用户的推荐列表算好写入一张 redis或者推荐结果表用户请求首页时直接读缓存。如果有人在凌晨修改了图书信息也不至于让推荐立刻失效。这个异步预计算的思路比用户每次请求都现场跑一遍算法要合理得多实际效果也好很多。2. 核心模块设计与数据库建模2.1 用户行为数据的采集链路推荐系统的基础是数据没有行为数据的推荐系统都是空中楼阁。这套项目里我埋了一套非常轻量的行为采集方案用户在商城内的三类核心行为会被写入行为日志表分别是浏览BROWSE、加购CART、下单ORDER。每种行为都记录用户ID、图书ID、行为类型、行为发生时间以及当时所在的页面场景首页推荐位、搜索页、详情页。埋点不需要用复杂的消息队列。我的做法是在Controller层的AOP切面里做统一拦截用户触发上述行为时异步写一条行为记录到数据库。这里有个设计细节值得注意行为权重不一样。我计算用户相似度时下单权重是3加购是2浏览是1。你可以在配置中心调这些系数也可以把它们参数化写进配置文件。按行为类型加权比单纯统计次数要科学得多也是论文里一个可以展开讲的改进点。2.2 核心表结构设计思路这个项目里我设计了八张核心表这里挑三张最关键的讲一下设计逻辑。图书表book字段包括主键、书名、作者、出版社、ISBN、分类ID、价格、库存、封面图URL、出版日期、总销量、平均评分、内容简介。其中分类ID是外键关联分类表。重点是两张辅助表图书标签表book_tag和图书标签关联表book_tag_relation。图书与标签是多对多的关系所以我单独抽了一张关联表每个标签存一条记录。你在算图书相似度时实际上就是比较两本书的标签集合的重合程度。用户行为表user_behavior上面说过了字段精简为行为ID、用户ID、图书ID、行为类型、场景来源、创建时间。这个表会越积越大我给“用户ID 行为类型”建了联合索引。毕设的数据量其实不会太大但设计时就要考虑查询优化索引这个点写进论文里是加分的。推荐结果表recommend_result字段是用户ID、推荐位类型首页猜你喜欢、详情页相似推荐等、图书ID列表、算法标识用的哪种策略算的、创建时间。这个表挺重要的因为有它你就可以在界面上打开一个类似“为你推荐”的页面直接展示历史推荐结果而不用每次重新跑算法。2.3 交易闭环模块的边界控制既然是商城就绕不开购物车和订单。购物车我用的是传统的关系表方案每条购物车记录关联一个用户和一本图书。这里注意几个边界问题库存不足时要在下单前校验并提示同一本书重复加购时要做合并处理而不是另起一行下单后要同步扣减库存。订单表我是按“主订单 从表”的思路拆的一笔订单可以包含多种图书但毕设阶段不追求高并发所以直接用一张订单表加一个订单项表就够了。下单时我会做一个事务控制保证订单创建和库存扣减要么同时成功要么同时失败。这个在 SpringBoot 里实现非常简单Service 方法上加 Transactional 注解即可。但要注意一点事务方法内部不能捕获异常后吞掉否则回滚不会生效这个细节在实操环节再细说。3. 推荐引擎的核心算法实现3.1 基于内容标签的相似度推荐这是项目里最有实操价值的一段逻辑。我的思路是给每本书打标签标签越相似的书越容易被一起推荐。比如《Java编程思想》的标签是[Java, 编程, 后端开发]《深入理解Java虚拟机》的标签是[Java, JVM, 性能优化]两本书的Java标签重合就有了相似度。计算相似度我提供两种方式。第一种是杰卡德相似系数公式是交集元素数除以并集元素数。两个集合的交集越大、并集越小相似度越高。这种算法实现简单集合操作在Java里直接用 retainAll 和 addAll 就能搞定适合数据量不大的场景。第二种方式是把标签向量化之后算余弦相似度。做法是把所有标签做成一个全局标签字典每本书根据自身标签构建一个高维向量向量每个维度是标签权重。两本书的相似度就是两个向量夹角的余弦值。余弦相似度的好处是它对向量长度不敏感能弱化“标签多的书天然跟谁都相似”的问题。我在代码里两种算法都实现了通过一个策略枚举切换论文里可以对比两种结果也是一处不错的实验分析素材。代码层面我给每本书维护一个预处理好的标签集合存储时直接把标签用逗号拼接存在一个字段里读取时按逗号split成数组。这样省掉多次联表查询相似度计算时只需要从数据库一次性加载所有图书ID和标签串在内存里两两计算生成全量相似度矩阵。这个矩阵我会缓存在一个静态Map里或者存Redis避免每次请求都重新计算。涉及到的关键方法如下public ListBookVO recommendSimilarBooks(Long bookId, int topN) { // 从缓存中获取全量相似度矩阵 MapLong, MapLong, Double simMatrix getSimilarityMatrix(); MapLong, Double simMap simMatrix.get(bookId); if (simMap null) { return Collections.emptyList(); } return simMap.entrySet().stream() .sorted((e1, e2) - Double.compare(e2.getValue(), e1.getValue())) .limit(topN) .map(entry - bookService.getBookVO(entry.getKey())) .collect(Collectors.toList()); }上面这段就是把相似度最高的前N本书取出包装成VO返回给前端。细节上要注意计算相似度矩阵时要过滤掉无标签的“脏数据”否则会出现全零向量算余弦得到NaN的问题。3.2 基于用户的协同过滤UserCF基于内容的推荐有一个很死板的缺点它永远只会推荐和你已看过书同类的书做不到“跨类发现”。图书商城里很多人其实是杂食动物既看技术书又看历史书。协同过滤就是为了解决这个问题。UserCF 的核心逻辑很直白分三步。第一步构建用户—图书行为矩阵。行是用户列是图书值是综合行为得分。比如用户A给《活着》打3分下单行为权重3给《百年孤独》打1分浏览行为权重1。矩阵可以用稀疏编码方式存成一个Map不要用稠密二维数组因为图书数量大了以后内存会爆。第二步计算用户之间相似度。我用的皮尔逊相关系数变形实际上也是余弦相似度的一个变种。行为向量之间的余弦值越高代表两个用户的兴趣越接近。这里用相似度排序找到当前用户的K个最近邻。第三步生成推荐项。把这K个邻居有过正向行为、但当前用户没有行为记录的图书集合拿出来按“邻居相似度*行为权重”加权求和排序后取前N本作为推荐结果。实际实现时我不用每次都实时跑全量矩阵。用户登录时只加载当前用户的行为记录和系统的预计算用户相似度矩阵做交互这样响应时间可控在100毫秒以内。如果数据量大了这一步可以换成Spark或者向量检索库但毕设场景下纯Java实现完全够用。这里有一个很关键的工程细节需要提醒你注意新用户的协同过滤结果可能为空。因为一个新注册用户没有任何行为记录无法算相似度。所以协同过滤的结果必须做空值兜底为空时返回热门图书列表前端展示不至于空白一片。这也是我在1.3节里说的“策略分层”落地的关键点。3.3 冷启动与混合推荐加权冷启动是推荐系统里绕不开的实际问题也是论文里的一个重要小节。新用户没有行为这时候再怎么算协同过滤都是无米之炊。我的处理方式是新用户注册后强制走一步偏好选择引导让用户至少从十本经典分类畅销书中选三本感兴趣的作为初始行为写入一个虚拟行为表。这一步本质上是把“冷启动问题”转化成了“一次显式反馈采集”。有了初始偏好系统就可以立刻走基于内容的推荐给用户推他选中图书的同标签图书。等用户积累了一定量的真实行为我设置了阈值比如浏览行为超过10条或者有效行为超过5条系统自动切换成“协同过滤为主、内容推荐为辅”的混合模式。混合加权我采用的还是一个线性加权公式推荐得分 a * 协同过滤得分 b * 内容推荐得分 c * 热榜得分热度分归一化其中a、b、c由配置文件动态调整。答辩时如果被问“为什么比单一算法好”你就说协同过滤擅长挖掘潜在兴趣但冷启动表现差基于内容的推荐稳定可解释但容易信息茧房两者加权可以互补而热榜项保证了探索性。这是很标准的业界话术但你的代码里是真实现了的不是空谈。4. 核心业务模块的落地实现4.1 商城前台的完整链路前台这个商城不是让你只做一个展示页面。我的完整链路是游客可以浏览首页和图书详情页但不能加购和下单必须登录。登录后可以搜索、筛选、加购物车、结算下单、查看订单状态。搜索模块我用的 MySQL Like 加倒排思路。不要在一个搜索框里只做书名匹配要把搜索词和作者、分类名、标签做拼接匹配这样搜“Java高并发”也能命中《Java并发编程实战》尽管书名本身不完全包含“高并发”。这个搜索扩展逻辑也可以接 HanLP 分词属于项目里的加分项。我的热搜词里也提到了 HanLP 在 SpringBoot 中的整合如果你时间充裕可以引入 HanLP 轻量级分词把用户搜索词切成多个关键词再分别匹配书名、标签、分类搜出来的结果质量能提升一大截。订单和购物车部分前台逻辑没有太多花活但要注意两个点一是加购、下单前都要校验库存二是一本书在购物车里重复点击加购时要合并数量。下单成功后购物车里对应条目要清除订单状态初始是待付款支付模块毕设常用方案是做一个模拟支付点击“去支付”后直接跳转成功页省去接第三方支付的繁琐。4.2 推荐位的接入方式推荐位我做了三个首页的“猜你喜欢”瀑布流、图书详情页的“相似书籍推荐”、购物车页面的“搭配购买推荐”。这三个推荐位的实现逻辑略有不同首页猜你喜欢核心是用户维度的推荐用 UserCF 和混合加权策略返回一个按得分排序的图书列表每本书展示封面、书名、评分、价格点击进入详情。详情页相似书籍推荐属于物品维度的推荐直接复用3.1节基于内容标签的相似度推荐实时计算当前图书的Top10相似书。详情页还有一种做法是关联规则挖掘买了A的人也买了B但毕设阶段用标签相似度更简单效果也够。购物车搭配推荐我用的策略是“已加购图书的热门同分类书”。这个逻辑很简单计算购物车中所有图书的分类分布找到占比最高的两三个分类从这些分类中按销量和评分排序取TopN。这种“人有我优”的细节能让你的系统看起来像一个完整商品不是几个页面的拼接。这三个推荐位的数据来源都统一定义在一个接口类里public interface RecommendStrategy { ListRecommendItem recommend(Long userId, int topN); String getStrategyName(); }Spring 容器里注册了三个策略 Bean前端传不同场景码后端用工厂模式从 Spring 上下文里按名称取对应策略 Bean。一旦后面你想加新的推荐位只需新增一个实现类不用改任何已有代码。这也是我在论文里愿意拿出来讲的一个设计模式落地案例。4.3 后台管理模块后台管理不做完整的企业级功能但至少要有这几个模块图书管理增删改查、上下架、标签编辑、订单管理查看订单列表、发货状态流转、用户管理禁用用户、重置密码、数据统计销量Top10、分类占比。推荐引擎的管理单独做了一个“推荐参数配置”页面把策略权重、近邻K值、TopN、行为权重这些参数都做成可以热更新的配置项。后台管理前端我用 Vue3 Element Plus 搭的和 SpringBoot 之间走 JSON 接口。这里的一个实操建议是不要花太多时间打磨后台的 UI 细节后台的核心是“功能完整、接口规范”六个字。你的精力应该大头放在前台展示效果和推荐算法的实现上因为答辩的时候老师大部分时间在看前台。5. 实战过程中的高频问题排查与避坑5.1 SpringBoot 版本与依赖兼容性问题这个坑几乎人人都踩。SpringBoot 3.x 出来后它把javax.*包名切换成了jakarta.*如果你照着网上老教程的代码去写会直接编译报错找不到包。我当时为了保险起见直接选了 SpringBoot 2.7.13 版本配套 MyBatis Plus 3.5.3JDK 1.8这套组合的资料齐全、兼容性好基本不会出幺蛾子。另外有一类问题很常见Maven 依赖冲突导致的方法找不到NoSuchMethodError。比如 Spring Boot 自带的 Jackson 版本和你项目里引入的其他 JSON 库版本不一致。我的建议是统一用 Maven 的dependencyManagement锁版本不要一个库一个版本号随手加加依赖前先在 mvn repository 查一下当前版本和依赖传递关系。5.2 中文字段排序与查询的坑MySQL 里按销量排序没问题但如果你在代码里用 MyBatis Plus 的orderByDesc(sales)也一切正常。真正的坑是你在做搜索模块时想按“图书名”做加权排序直接用ORDER BY name会按照拼音排序但如果你建表时字段用了 utf8mb4 默认排序规则那排序顺序是二进制码点顺序中文会排得很乱。更隐蔽的一个问题是在 MySQL 8.0 中如果你的查询条件里用了WHERE name LIKE %Java%因为 Java 是英文走的索引策略和中文条件完全不同。英文关键词匹配时大小写也需要注意MySQL 默认排序规则下 LIKE 不区分大小写但如果你改过字段排序规则可能会出现 Java 搜不到 java 的情况。安全做法是建表时统一设置成utf8mb4_general_ci这个排序规则不区分大小写中文场景最省心。5.3 MyBatis Plus 使用细节MyBatis Plus 确实方便但有几个地方容易踩雷。第一个是逻辑删除。我给图书表和订单表都加了逻辑删除字段deleted配置了TableLogic注解后普通 CRUD 都会自动拼接deleted 0查询条件但你自己手写 XML 的 SQL 里容易漏掉这个条件导致查出已经删除的数据。第二个是字段自动填充。创建时间字段如果定义了TableField(fill FieldFill.INSERT)需要在代码里写一个 MetaObjectHandler 实现类否则字段不会自动赋值很多人加了注解但忘了写处理器最后存进去的时间全是 null。第三个是关于分页插件。MyBatis Plus 的分页插件需要在配置类中显式注入PaginationInnerInterceptor你不配置的话page()方法不会真正分页而是查全量数据后再内存分页数据一大性能立刻拉胯。这个坑我也踩过原以为只需要引入分页插件依赖就行了结果忘了注册拦截器运行日志能看到 SQL 里根本没有 LIMIT 关键字。5.4 推荐结果为空和重复的异常处理推荐系统实现过程中最常见的问题就是推荐列表为空。原因通常是三类用户行为表没数据、行为表里关联的图书未上架被过滤掉了、相似度矩阵构建时正则错了导致全是0相似度。排查思路很简单第一步先查用户行为表中的记录第二步看推荐策略日志里打印的候选集大小第三步核对相似度计算结果。我当时在推荐策略里加了日志输出log.info(用户:{}, 策略:{}, 候选数量:{}, 最终返回:{}, userId, strategy, candidates.size(), result.size());这个日志对排查问题帮助巨大。另一个问题是推荐结果重复。多策略混合加权时同一本书可能既出现在协同过滤结果里又出现在内容推荐结果里。我做了两层去重策略内部对列表去重混合后的最终结果集再用LinkedHashSet保持顺序的前提下做一次全局去重。另外同一个用户多次刷新首页如果看到完全一样的列表会显得这个推荐系统有些假我后来加入了“排除用户最近浏览过的5本书”的逻辑让推荐位有一定的新鲜感这个细节答辩时也可以提一下属于工程层面的小优化。5.5 事务回滚不生效的常见原因下单操作我前面提到了Transactional但很多人在实操时会碰到“抛了异常数据却还是写进去了”的情况。最常见的原因是方法内部 catch 了异常但没有往外抛。Spring 事务默认只在 RuntimeException 和 Error 时回滚checked exception 是不回滚的。如果 catch 住异常并且没有重新抛出事务管理器压根感知不到异常自然不回滚。另外一个原因是同类内部方法调用时事务失效。比如 OrderService 里的createOrder()方法调用了同类里的deductStock()方法即使deductStock()上标注了 Transactional也是不生效的因为 Spring 代理机制只有通过外部调用才能触发。解决方式是把库存扣减逻辑放到另一个 Service 类里或者通过AopContext.currentProxy()获取代理对象再调用但后者需要配置exposeProxytrue比较麻烦。6. 论文写作与答辩展示的实用建议6.1 论文逻辑线的规划毕设论文不是项目文档的堆砌要有一个让人读完记得住的逻辑线。我建议的主线是“背景与痛点分析 → 相关技术介绍 → 需求分析 → 系统设计 → 推荐算法设计与实验 → 系统实现与测试”。其中最值得花笔墨的是“推荐算法设计与实验”这一章因为这是你区别于普通商城系统的核心所在。算法实验章不要只贴代码。我的做法是自己构造一个小实验数据集比如随便选20个用户、50本书、几百条模拟行为记录分别跑只有内容推荐、只有协同过滤、混合推荐三种策略然后对比一个最直观的指标用户对推荐结果的平均点击率CTR。通过图表展示混合策略的效果优于单一策略哪怕数据是模拟的这个过程也能说明你理解评估方法比空洞地说“推荐效果很好”有说服力得多。6.2 答辩演示时的高频问题与应答思路答辩老师针对这类项目最常见的几个问题我整理一下以及你该怎么应对。问题一“你这个推荐算法和别人的有什么不同”回答思路先简述三种策略各自的原理和适用场景然后重点强调你做的策略分层和冷启动处理方案。特别是冷启动很多同学做的项目根本不管新用户你能主动说“我用偏好选择引导解决冷启动用策略降级保证展示效果”这就在认知上超过了平均水平。问题二“你的系统性能怎么样数据量大了怎么办”这个问题有两层含义。小数据量下你直接讲你的响应时间测试结果比如推荐位平均响应80ms接口QPS实测多少。大数据量加一层演进思路“目前采用 MySQL 存储和内存计算数据量到百万级以后可以引入 Redis 缓存、离线预计算、甚至用 ES 来做检索和向量召回。”到了这一步说明你懂系统瓶颈在哪比支支吾吾好太多。问题三“推荐结果是怎么保证不推已购图书的”这个属于业务逻辑校验问题你的代码里要真正实现过滤逻辑简单说就是在推荐候选集中filter(bookId - !userPurchasedBookIds.contains(bookId))并且这个逻辑要有单元测试覆盖。答辩时你把测试代码的截图一亮效果非常好。6.3 演示环境的准备工作最后特别提醒一句答辩前请一定把演示环境跑顺。我把这些年在答辩现场看到的翻车情况给你总结一下数据库忘记启动了、端口被占用、Redis 启动失败导致首页直接报错、演示账号密码记错、IDEA 里配置了太多测试代码导致编译慢得让人失去耐心。我的建议是准备一份启动清单按顺序执行启动 MySQL → 启动 Redis如果你用了→ 执行数据库初始化脚本 → 启动 SpringBoot 应用 → 打开前端页面 → 用测试账号登录。面向前台演示的时候提前准备两个账号一个新注册的账号用于展示冷启动推荐和偏好选择一个老账号用于展示行为记录丰富后的猜你喜欢效果。这两个账号对应的界面效果差异越大给老师的印象就越深。7. 项目功能扩展与优化方向如果时间和精力允许这个项目还可以往几个方向做增强每个方向都能作为论文的“未来展望”或者答辩时的加分扩展。第一个方向引入 Redis 做推荐结果缓存。在上面的实现里我已经用 Java 内存做了一层缓存但进程重启后就丢了。如果引入 Redis预计算结果可以序列化后存储设置合理的过期时间比如24小时冷热数据分开管理系统响应速度还能更快。第二个方向把关键词提取能力引入搜索模块。目前搜索主要靠书名和标签匹配如果你想展示更高级的 NLP 能力可以引入 HanLP 分词库先把用户搜索词分词再把分词结果做词频统计和图书内容的摘要、简介做相似度打分。我实际试过效果提升非常明显而且 HanLP 在 SpringBoot 中集成的成本并不算高——引入依赖写一个分词服务剩下就是调 API 的问题。第三个方向做一个热门排行榜的定时刷新。毕设项目如果全部是静态推荐展示效果太单一。我后来在项目里加了一个定时任务每晚重新计算周销量榜、好评榜、新品榜三个榜单写入缓存首页轮播图位置展示。定时任务在 SpringBoot 里实现非常轻量一个 Scheduled 注解就搞定了但整个系统的“实时性”观感强了很多。第四个方向引入用户画像的可视化。在用户中心增加一个“我的阅读偏好”页面前端用 ECharts 展示用户最近一个月浏览/购买的图书分类占比生成标签云。这个功能不涉及复杂算法只要有个接口查用户行为数据然后按分类聚合前端画图就行但对“个性化”这个主题的直观展示能力非常强答辩演示时光靠这一张图就能打动不少老师。我在实际动手做这套系统时最深的体会其实是推荐系统这个词听起来很高大上但拆到落地层面它考验的更多是工程思维——你怎么设计数据表、怎么组织策略模块、怎么处理边界情况。把这层窗户纸捅破了你会发现它不过是一个“基于已有数据用一种可解释的规则猜用户下一步想买什么”的工具。而真正让你在毕设中脱颖而出的从来不是你用了多高级的算法而是你对每个细节深思熟虑之后愿意动手把想法一点点变成能跑通的东西。这个项目我建议你花三到四周去打磨前期把精力放在表结构设计与推荐策略先行验证上中期做框架搭建和功能填充后期专门腾出时间做推荐效果的调参与演示脚本的演练。遇到问题的时候别急着改代码先去看日志日志不会骗你它能告诉你系统里正在发生什么。用这个思路走下去你的毕设作品和论文一定不会差。