每年到毕设选题的时候总有人来问我做什么题目比较好过、又有东西写、答辩还能讲得清楚。如果你手头正在纠结我建议你认真看看DjangoVue.js小说推荐系统这个方向——它不是那种烂大街的图书管理系统而是把爬虫、推荐算法、可视化、前后端分离、大数据分析全串在了一条链路上。一个题目就能把后端框架、前端框架、数据库设计、算法实现、数据采集这些点全部覆盖工作量肉眼可见答辩的时候随便挑一个模块都能讲十分钟不冷场。这篇文章我打算从一个真正做完了这个项目的角度把小说爬虫怎么设计、推荐算法怎么落地、可视化看板怎么搭、前后端怎么联调、答辩前有哪些坑这些环节完整拆开讲一遍。不管你是打算源码二开还是从头写这篇文章都能帮你在开工之前把整体地图画清楚。1. 为什么小说推荐系统是毕设的高分题选题逻辑与价值拆解1.1 选题三要素工作量看得见、技术栈够全、答辩有讲头先聊选题逻辑。毕设最怕的不是难而是做完之后没东西可讲。一个单纯的信息管理系统比如学生选课系统仓库管理系统界面点一圈就结束了评委问两句业务逻辑就没什么可深入的了。但小说推荐系统的好处在于它天然自带一个完整的数据闭环。这个闭环长这样数据采集爬虫抓小说元数据、章节、评论→ 数据清洗与入库MySQL→ 离线计算推荐算法生成候选集→ 在线服务Django提供推荐接口→ 前端展示VueECharts图表、小说列表、推荐理由。任何一个环节拿出来都能展开讲原理而且环环相扣答辩时从爬虫讲到推荐再讲到可视化整个故事线非常完整。我见过不少同学做推荐系统类题目翻车原因高度一致只做了一个能看的搜索列表假推荐。他所谓的推荐逻辑是按热度排序这在答辩时一眼就被问穿。真正能拿到高分的做法是至少实现一种可解释的推荐算法协同过滤或者基于内容的匹配然后在可视化看板上把推荐效果展示出来。这样评委问推荐结果怎么来的你才能讲出算法逻辑。1.2 技术栈选型的理由DjangoVue.js为什么是毕设黄金组合Django和Vue.js的搭配我做了好几个项目之后仍然觉得是毕设场景下最稳的选择。Django这边它有自带Admin后台、ORM、模板系统对新手友好同时它的ORM在做推荐系统时特别有用因为推荐算法本质上离不开对用户行为表、物品表、评分表这三类数据的频繁关联查询。你写纯SQL当然也可以但用Django的ORM来做查找用户读过的所有小说→找到相似小说→排除已读→生成推荐列表这种操作代码量少一半。Vue.js则解决了前端交互的部分。小说推荐系统不是简单展示静态页面它需要用户登录后有个性化推荐位、点击小说后要看详情、评分之后推荐列表刷新、还要有看板页面展示统计图表。Vue的组件化开发让这些UI模块可以拆开写互不干扰。尤其是可视化看板这种页面用Vue组件配合ECharts一个组件就是一个图数据变了图自动更新体验比JQuery时代舒服太多。前后端之间走Restful API。Django用DRFDjango Rest Framework提供JSON接口Vue用axios调用。这个模式你工作后也会一直用所以不算为了毕设而学是真正的行业通用技能。2. 系统架构与数据流从爬虫到前端图表的完整链路2.1 总体架构三个端、一条数据管道我习惯把这个系统拆成三块采集端、服务端、展示端。采集端是Python爬虫跑在本地或者服务器上定时抓取小说数据服务端是Django负责业务接口、用户体系、推荐计算、数据统计展示端是Vue单页应用负责页面交互和可视化。三个端之间的数据流向你要在脑海中画一条清晰的线爬虫抓取 → 清洗入库(MySQL) → Django定时任务触发推荐计算 → 推荐结果写入Redis/数据表 → 前端调用接口 → Vue渲染 → 用户点击/评分 → 行为数据回写MySQL → 更新推荐这条链路的好处是它把大数据的概念落在了实际操作上。虽然小说数据量可能达不到几十亿那样夸张的规模但几万本小说、几十万条用户行为记录已经足够让你用上离线计算在线读取这套大数据系统里最常见的架构思路。毕设答辩时讲为什么推荐结果要预计算而不是实时算本身就是一个很好的技术选型问题。2.2 数据库设计五张表的关联逻辑小说推荐系统的核心表我建议至少设计这么五张表名关键字段作用小说表(book)book_id、书名、作者、分类、简介、字数、状态、封面、最新章节存储爬虫采集的图书元数据用户表(user)user_id、用户名、密码哈希、注册时间系统用户基础信息用户行为表(user_behavior)behavior_id、user_id、book_id、行为类型阅读/收藏/评分/点击、评分值、时间戳推荐算法的核心数据来源推荐结果表(recommendation)id、user_id、book_id、推荐分值、生成时间离线计算后写入在线接口直接读取评论/书评表(comment)id、user_id、book_id、评论内容、时间可挂在小说详情页增加内容维度要特别提醒的是用户行为表它直接决定了推荐算法的上限。我见过有人只做了收藏功能没有做评分也没有记录点击行为结果协同过滤算法跑起来几乎没有数据可用。正确的做法是用户打开小说详情页记录一条点击行为点收藏记录收藏行为打星评记录评分行为这样每个用户至少有几条有效行为数据推荐算法才有东西算。3. 小说爬虫模块的工程化设计采集、清洗、入库3.1 爬虫目标与合规边界小说爬虫是整个系统的原材料来源。没有数据推荐算法就是空中楼阁可视化也没东西可展示。所以爬虫看似是辅助模块实际上是整个大数据链路的起点。先说合规问题。很多同学一听到爬虫就心虚其实只要把握住几点就没问题只采集公开可访问的数据、遵守目标网站的robots协议、采集频率控制不要造成对方服务器压力、不采集任何需要付费或登录后才能看到的内容。毕设场景下数据用途是学习研究采集对象尽量选公开的小说信息页书名、作者、简介、分类、字数不要去动VIP章节内容。这样做既安全也够用——推荐算法只需要元数据和行为数据并不需要全文。3.2 抓取与解析的关键实现爬虫技术选型上我推荐用requests配合BeautifulSoup。为什么不用ScrapyScrapy当然更专业但对毕设来说学习成本偏高而且你自己写框架能更好展示爬虫原理——答辩时评委问你的爬虫怎么写的你能从URL构造、请求头、响应解析、异常重试讲得清清楚楚比说我用了框架更有说服力。核心逻辑可以分成四步列表页URL构造分析目标网站的小说分类列表URL规则按分类和页数循环生成待爬取URL。请求与容错每个请求带伪装User-Agent加随机延时0.5到1.5秒设置超时和重试机制。内容解析用BeautifulSoup按HTML结构提取书名、作者、简介、分类、封面图地址、最后更新时间等字段。入库更新数据交给Django的ORM写入MySQL。给个简化版解析代码让你感受下结构import requests from bs4 import BeautifulSoup def parse_book_list(html): soup BeautifulSoup(html, html.parser) books [] for item in soup.select(.book-item): book { title: item.select_one(.title a).text.strip(), author: item.select_one(.author).text.strip(), category: item.select_one(.category).text.strip(), intro: item.select_one(.intro).text.strip()[:200], book_url: item.select_one(.title a)[href], cover_url: item.select_one(img)[src] } books.append(book) return books def fetch(url): headers {User-Agent: Mozilla/5.0 ...} resp requests.get(url, headersheaders, timeout10) resp.raise_for_status() return parse_book_list(resp.text)3.3 数据清洗与归一化处理爬下来的数据一定脏。这个坑我踩过所以后面每个项目都老老实实加清洗步骤。常见的脏数据包括书名里有全角空格、简介超过配置的字段长度、分类字段不统一有的叫玄幻有的叫玄幻小说、封面图URL失效、字数字段带万字这种中文单位。这些不处理干净后面做分类统计图的时候会出现一团乱麻。清洗方案我建议在入库前用一个统一的clean_book_data()函数处理字符串字段统一strip()并去除不可见字符分类字段映射到标准分类字典比如把玄幻小说映射为玄幻字数、点击量等数字字段从123.4万这种格式解析为整数简介截断到不超过指定长度过长会导致Django字段超长报错我的经验是清洗逻辑所占的工作量往往不亚于爬虫本身。但这一步做好了后面所有统计图表、推荐算法、搜索功能都会非常省心。3.4 增量更新与调度策略小说数据不是爬一次就结束的因为小说网站每天都有更新新书上架、连载小说更新章节。如果是毕设演示数据爬一次基本够用但如果你的系统要持续运行需要一个增量更新的策略。我当时的做法是建一个crawl_task表记录每次爬虫运行的时间和采集数量爬虫启动时按上次记录的页数和当前页数差决定增量范围。由于是毕设不需要上Celery那种重量级的东西直接写一个Django management command用python manage.py crawl_books手动触发或者挂在系统cron上每天跑一次。这样做代码简洁、逻辑清晰而且答辩时讲起来也好理解——我校准了增量爬取每次只采集新增和更新的数据避免重复抓取。4. 推荐引擎核心从协同过滤到混合推荐的落地实现4.1 三种推荐算法的适用场景对比推荐算法是系统的灵魂。对这个项目来说市面上最常见的三种算法你可以全部实现然后对比效果这本身就是很好的毕设工作量和答辩亮点。算法原理适用场景实现难度基于内容的推荐根据用户读过的书的内容属性分类、标签、作者找相似书籍冷启动时管用新用户也有推荐低基于物品的协同过滤找到喜欢同一本书的用户群推荐他们喜欢的其他书用户行为数据充足时效果好中基于用户的协同过滤找到相似用户推荐相似用户喜欢的书用户量大且行为丰富时效果好中我建议主推基于物品的协同过滤ItemCF。原因很直接小说站里热门书籍数量有限大部分用户不会读过太多的书ItemCF计算物品之间的相似度比UserCF计算用户之间的相似度更稳定而且结果也更好解释——因为你读过《A》和《B》所以给你推荐《C》。4.2 基于物品的协同过滤实现细节ItemCF的核心分两步第一步算物品间的相似度矩阵第二步根据用户历史行为生成推荐。相似度我这里用余弦相似度公式不展开了用Python代码落地大约是这样from math import sqrt from collections import defaultdict def build_item_similarity(user_behavior): # user_behavior: {user_id: {book_id: rating}} # 1. 统计喜欢每个物品的用户列表 item_users defaultdict(list) for user, books in user_behavior.items(): for book in books: item_users[book].append(user) # 2. 计算物品间共同被喜欢的次数 co_occur defaultdict(int) for book, users in item_users.items(): for i in range(len(users)): for j in range(i 1, len(users)): # 这里简化为任意两个被同一用户喜欢的物品的共现计数 u1, u2 users[i], users[j] for b1 in user_behavior[u1]: for b2 in user_behavior[u2]: if b1 ! b2: co_occur[(b1, b2)] 1 # 3. 归一化得到相似度矩阵 similarity {} for (b1, b2), cnt in co_occur.items(): similarity[(b1, b2)] cnt / sqrt(len(item_users[b1]) * len(item_users[b2])) return similarity这是最基础的思路。实际项目里我会用user_behavior表里的阅读收藏行为构造正反馈评分数作为权重。为了效率相似度计算只在离线任务里跑算完之后把每个物品最相似的Top-N物品写入book_similarity表。在线推荐时就简单了找到用户最近读过的几本书去相似度表里查找对应的相似书加权累加排序取前20本就是推荐结果。这段逻辑建议你讲答辩时画图配合从离线计算到在线召回到排序三个阶段评委听到这里基本就能确认这不是一个花架子系统。4.3 冷启动问题的处理冷启动是推荐系统最经典的问题也是评委最爱问的问题。新用户没有行为数据协同过滤必然失效怎么办我当时用了两个方案组合起来效果很好基于内容的兜底推荐如果用户行为表为空直接按分类偏好或者不区分偏好推荐热门高分小说。用户可以手动选择我喜欢的分类系统按分类推荐该分类下评分最高的书。最近热门推荐统计近7天阅读/收藏量最高的书作为新用户的默认推荐列表。这两个方案本质上就是规则推荐不用复杂模型但它在产品逻辑上把推荐系统做完整了。答辩时被问冷启动怎么解决你直接回答协同过滤覆盖不了的时候用内容召回和热门召回兜底这就很有说服力。4.4 离线计算与在线接口的配合说到离线计算和在线接口很多同学觉得是高大上的分布式系统才有的概念其实在单机项目里一样可以实现这种分工。我当时的做法是写一个recommend/management/commands/offline_compute.py命令里面调相似度计算和推荐结果生成函数跑完把每个用户的预测推荐列表写入recommendation表。这个命令手动执行或者放定时任务。在线接口呢就是一个Django DRF的GET /api/recommendations/逻辑非常简单——到recommendation表查当前用户的推荐列表返回即可。这样做的好处是在线接口响应只有几十毫秒前端体验流畅而离线计算任务跑十几秒也不会卡住页面。如果答辩老师问为什么不用实时计算你可以说——实时计算每请求一次都要做物品相似度计算在大数据量下延迟不可控业界通用做法就是离线计算好结果、在线读取。这个思想用到真实企业项目里也是一样的。5. 可视化交互层VueECharts的图表设计与复用5.1 看板设计哪些图表是评委爱看的可视化模块是很多人忽略的加分项。小说推荐系统的可视化不只是把数据画出来更关键的是用图表讲清楚系统里的数据情况。我做的看板包含这么几块图书分类分布饼图展示各个分类的小说数量占比一眼看出书库里玄幻、都市、科幻各占多少。热门小说Top10柱状图按阅读量/收藏量排序展示系统内最受欢迎的小说。用户活跃度趋势折线图按天展示每日新增用户数和行为数体现系统运营情况。推荐效果统计图展示推荐位曝光数、点击次数、推荐位点击率这个图是我最推荐做的一个因为它直接证明推荐算法有效果。其中推荐效果统计图特别提一下我从第一次做完项目后的复盘经验是推荐系统的可视化不能只展示输入数据更要展示输出效果。你展示了推荐点击率从无推荐时的X%提升到了有推荐时的Y%这就是推荐算法价值的直接证据答辩时拿着这个数据讲比任何理论都硬。5.2 前端组件化图表组件怎么拆Vue这边我建议把ECharts封装成可复用的图表组件。不要每个页面都写一堆配置项那代码会非常臃肿。我的做法是写一个BaseChart.vue组件接收option作为prop内部完成ECharts初始化、自动resize、数据更新监听template div refchartRef stylewidth: 100%; height: 400px/div /template script import * as echarts from echarts; export default { name: BaseChart, props: { option: { type: Object, required: true } }, data() { return { chart: null }; }, mounted() { this.chart echarts.init(this.$refs.chartRef); this.chart.setOption(this.option); window.addEventListener(resize, this.resize); }, watch: { option: { deep: true, handler(newVal) { this.chart.setOption(newVal); } } }, methods: { resize() { this.chart this.chart.resize(); } }, beforeUnmount() { window.removeEventListener(resize, this.resize); this.chart this.chart.dispose(); } }; /script这样在页面里用的时候只需要传入不同的option就行。分类饼图、热门柱状图、趋势折线图各自写一个数据加载函数调用同一个组件渲染。代码量一下子少了一半。5.3 前后端联调的接口规范前后端分离的项目接口设计规范直接影响联调效率。我开始时吃过亏前端要的数据结构和后端返回的差别很大就靠前端再转换越转越乱。后来定了规矩所有列表接口返回{ code, data, message }的固定结构data里统一用{ list, total }分页结构后端字段名一律用驼峰转下划线后再转换一次前端只用驼峰字段Django的serializer可以配置字段名时间字段统一返回时间戳前端自己格式化。这些规矩看起来琐碎但没有它们Vue页面和后端会互相扯皮改来改去。定好规矩之后前后端基本可以并行开发——前端拿Mock数据先写页面后端好了再切换真实接口。6. 部署联调与答辩准备最容易翻车的几个环节6.1 本地联调与跨域问题Django跑在8000端口Vue跑在5173或8080端口这样的前后端分离项目必遇跨域问题。解决办法有两个方向后端用django-cors-headers放行前端的域名这是开发阶段最简单的方式生产环境把Django和Vue的构建产物放到同一个服务下用Nginx托管就不存在跨域了。我个人的建议是开发阶段用cors-headers最终部署用Nginx统一托管。这样开发效率高演示的时候也不会因为浏览器拦截跨域请求而出洋相。跨域问题还有一个坑要提醒不要在演示时打开两个页面同时访问前后端万一前端开发服务器的端口忘了开页面打不开。最终演示最好用打包后的静态文件。6.2 打包部署的注意事项Vue项目npm run build之后会生成dist目录里面是纯静态文件。Django这边你需要把dist目录配置为STATICFILES_DIRS之一同时让Django直接渲染一个index.html入口。这样评委访问你部署好的地址一个端口搞定所有功能不用解释两个服务的问题。数据库方面如果换一台电脑演示一定要记得导出MySQL数据。标题里写了源码文档讲解但很多人容易漏掉数据库初始化脚本。我的习惯是提供两个文件install.sql建库建表和seed_data.sql爬虫抓取的核心数据。否则别人拿到源码启动后端啥都没有推荐算法跑不动看板全是空图表直接整个系统就崩了。6.3 答辩演示的预演清单毕设答辩翻车十次有八次在上台前没检查环境。列个简单的预演清单提前一天在答辩用的电脑上完整跑一遍系统确认Python、Node、MySQL、Redis的依赖都齐了。准备离线模式如果现场没网爬虫展示就用现有的seed_data可视化展示直接读取数据库。有一个万能方案——录一段3分钟的演示视频放在U盘里万一环境崩塌放视频也比干站着强。准备讲故事的顺序不要从首页代码开始讲而是从数据→算法→展示→效果这条链路走讲清楚每个环节做了什么以及为什么这么做。6.4 文档与演示材料组织最后说下配套文档。毕设评审最看重的是你的工作量是否饱满、逻辑是否清楚。所以文档里我建议按这个顺序组织需求分析系统分为哪几个模块每个模块有什么功能点系统设计架构图、数据库ER图、接口清单核心模块实现爬虫设计、推荐算法详解、可视化图表设计系统演示截图与效果分析放上实际运行时看板截图和推荐点击率数据。PPT就不要和文档一样了PPT是讲故事用的一页一个主题。我的经验是封面标题之后先放一张全链路架构图让评委30秒内知道你做了什么然后按数据流转顺序讲三四个核心模块的实现最后放演示截图和效果数据收尾。你按这个顺序讲过之后基本不会出现讲得不清不楚的评价。做这个项目最容易掉进去的坑其实就是贪多。有人爬虫要爬12个网站推荐要上深度神经网络看板要搞3D大屏——最后全卡住。我在实际带项目时一直跟人说毕业设计的本质是完整不是炫技。把爬虫做到干净、把推荐做到可解释、把可视化做到能说明问题这一条链路跑通就已经超过大多数人了。如果后续还有时间再考虑加语义标签、弹幕热词、实时协同过滤这些进阶玩法不迟。
每年到毕设选题的时候总有人来问我做什么题目比较好过、又有东西写、答辩还能讲得清楚。如果你手头正在纠结我建议你认真看看DjangoVue.js小说推荐系统这个方向——它不是那种烂大街的图书管理系统而是把爬虫、推荐算法、可视化、前后端分离、大数据分析全串在了一条链路上。一个题目就能把后端框架、前端框架、数据库设计、算法实现、数据采集这些点全部覆盖工作量肉眼可见答辩的时候随便挑一个模块都能讲十分钟不冷场。这篇文章我打算从一个真正做完了这个项目的角度把小说爬虫怎么设计、推荐算法怎么落地、可视化看板怎么搭、前后端怎么联调、答辩前有哪些坑这些环节完整拆开讲一遍。不管你是打算源码二开还是从头写这篇文章都能帮你在开工之前把整体地图画清楚。1. 为什么小说推荐系统是毕设的高分题选题逻辑与价值拆解1.1 选题三要素工作量看得见、技术栈够全、答辩有讲头先聊选题逻辑。毕设最怕的不是难而是做完之后没东西可讲。一个单纯的信息管理系统比如学生选课系统仓库管理系统界面点一圈就结束了评委问两句业务逻辑就没什么可深入的了。但小说推荐系统的好处在于它天然自带一个完整的数据闭环。这个闭环长这样数据采集爬虫抓小说元数据、章节、评论→ 数据清洗与入库MySQL→ 离线计算推荐算法生成候选集→ 在线服务Django提供推荐接口→ 前端展示VueECharts图表、小说列表、推荐理由。任何一个环节拿出来都能展开讲原理而且环环相扣答辩时从爬虫讲到推荐再讲到可视化整个故事线非常完整。我见过不少同学做推荐系统类题目翻车原因高度一致只做了一个能看的搜索列表假推荐。他所谓的推荐逻辑是按热度排序这在答辩时一眼就被问穿。真正能拿到高分的做法是至少实现一种可解释的推荐算法协同过滤或者基于内容的匹配然后在可视化看板上把推荐效果展示出来。这样评委问推荐结果怎么来的你才能讲出算法逻辑。1.2 技术栈选型的理由DjangoVue.js为什么是毕设黄金组合Django和Vue.js的搭配我做了好几个项目之后仍然觉得是毕设场景下最稳的选择。Django这边它有自带Admin后台、ORM、模板系统对新手友好同时它的ORM在做推荐系统时特别有用因为推荐算法本质上离不开对用户行为表、物品表、评分表这三类数据的频繁关联查询。你写纯SQL当然也可以但用Django的ORM来做查找用户读过的所有小说→找到相似小说→排除已读→生成推荐列表这种操作代码量少一半。Vue.js则解决了前端交互的部分。小说推荐系统不是简单展示静态页面它需要用户登录后有个性化推荐位、点击小说后要看详情、评分之后推荐列表刷新、还要有看板页面展示统计图表。Vue的组件化开发让这些UI模块可以拆开写互不干扰。尤其是可视化看板这种页面用Vue组件配合ECharts一个组件就是一个图数据变了图自动更新体验比JQuery时代舒服太多。前后端之间走Restful API。Django用DRFDjango Rest Framework提供JSON接口Vue用axios调用。这个模式你工作后也会一直用所以不算为了毕设而学是真正的行业通用技能。2. 系统架构与数据流从爬虫到前端图表的完整链路2.1 总体架构三个端、一条数据管道我习惯把这个系统拆成三块采集端、服务端、展示端。采集端是Python爬虫跑在本地或者服务器上定时抓取小说数据服务端是Django负责业务接口、用户体系、推荐计算、数据统计展示端是Vue单页应用负责页面交互和可视化。三个端之间的数据流向你要在脑海中画一条清晰的线爬虫抓取 → 清洗入库(MySQL) → Django定时任务触发推荐计算 → 推荐结果写入Redis/数据表 → 前端调用接口 → Vue渲染 → 用户点击/评分 → 行为数据回写MySQL → 更新推荐这条链路的好处是它把大数据的概念落在了实际操作上。虽然小说数据量可能达不到几十亿那样夸张的规模但几万本小说、几十万条用户行为记录已经足够让你用上离线计算在线读取这套大数据系统里最常见的架构思路。毕设答辩时讲为什么推荐结果要预计算而不是实时算本身就是一个很好的技术选型问题。2.2 数据库设计五张表的关联逻辑小说推荐系统的核心表我建议至少设计这么五张表名关键字段作用小说表(book)book_id、书名、作者、分类、简介、字数、状态、封面、最新章节存储爬虫采集的图书元数据用户表(user)user_id、用户名、密码哈希、注册时间系统用户基础信息用户行为表(user_behavior)behavior_id、user_id、book_id、行为类型阅读/收藏/评分/点击、评分值、时间戳推荐算法的核心数据来源推荐结果表(recommendation)id、user_id、book_id、推荐分值、生成时间离线计算后写入在线接口直接读取评论/书评表(comment)id、user_id、book_id、评论内容、时间可挂在小说详情页增加内容维度要特别提醒的是用户行为表它直接决定了推荐算法的上限。我见过有人只做了收藏功能没有做评分也没有记录点击行为结果协同过滤算法跑起来几乎没有数据可用。正确的做法是用户打开小说详情页记录一条点击行为点收藏记录收藏行为打星评记录评分行为这样每个用户至少有几条有效行为数据推荐算法才有东西算。3. 小说爬虫模块的工程化设计采集、清洗、入库3.1 爬虫目标与合规边界小说爬虫是整个系统的原材料来源。没有数据推荐算法就是空中楼阁可视化也没东西可展示。所以爬虫看似是辅助模块实际上是整个大数据链路的起点。先说合规问题。很多同学一听到爬虫就心虚其实只要把握住几点就没问题只采集公开可访问的数据、遵守目标网站的robots协议、采集频率控制不要造成对方服务器压力、不采集任何需要付费或登录后才能看到的内容。毕设场景下数据用途是学习研究采集对象尽量选公开的小说信息页书名、作者、简介、分类、字数不要去动VIP章节内容。这样做既安全也够用——推荐算法只需要元数据和行为数据并不需要全文。3.2 抓取与解析的关键实现爬虫技术选型上我推荐用requests配合BeautifulSoup。为什么不用ScrapyScrapy当然更专业但对毕设来说学习成本偏高而且你自己写框架能更好展示爬虫原理——答辩时评委问你的爬虫怎么写的你能从URL构造、请求头、响应解析、异常重试讲得清清楚楚比说我用了框架更有说服力。核心逻辑可以分成四步列表页URL构造分析目标网站的小说分类列表URL规则按分类和页数循环生成待爬取URL。请求与容错每个请求带伪装User-Agent加随机延时0.5到1.5秒设置超时和重试机制。内容解析用BeautifulSoup按HTML结构提取书名、作者、简介、分类、封面图地址、最后更新时间等字段。入库更新数据交给Django的ORM写入MySQL。给个简化版解析代码让你感受下结构import requests from bs4 import BeautifulSoup def parse_book_list(html): soup BeautifulSoup(html, html.parser) books [] for item in soup.select(.book-item): book { title: item.select_one(.title a).text.strip(), author: item.select_one(.author).text.strip(), category: item.select_one(.category).text.strip(), intro: item.select_one(.intro).text.strip()[:200], book_url: item.select_one(.title a)[href], cover_url: item.select_one(img)[src] } books.append(book) return books def fetch(url): headers {User-Agent: Mozilla/5.0 ...} resp requests.get(url, headersheaders, timeout10) resp.raise_for_status() return parse_book_list(resp.text)3.3 数据清洗与归一化处理爬下来的数据一定脏。这个坑我踩过所以后面每个项目都老老实实加清洗步骤。常见的脏数据包括书名里有全角空格、简介超过配置的字段长度、分类字段不统一有的叫玄幻有的叫玄幻小说、封面图URL失效、字数字段带万字这种中文单位。这些不处理干净后面做分类统计图的时候会出现一团乱麻。清洗方案我建议在入库前用一个统一的clean_book_data()函数处理字符串字段统一strip()并去除不可见字符分类字段映射到标准分类字典比如把玄幻小说映射为玄幻字数、点击量等数字字段从123.4万这种格式解析为整数简介截断到不超过指定长度过长会导致Django字段超长报错我的经验是清洗逻辑所占的工作量往往不亚于爬虫本身。但这一步做好了后面所有统计图表、推荐算法、搜索功能都会非常省心。3.4 增量更新与调度策略小说数据不是爬一次就结束的因为小说网站每天都有更新新书上架、连载小说更新章节。如果是毕设演示数据爬一次基本够用但如果你的系统要持续运行需要一个增量更新的策略。我当时的做法是建一个crawl_task表记录每次爬虫运行的时间和采集数量爬虫启动时按上次记录的页数和当前页数差决定增量范围。由于是毕设不需要上Celery那种重量级的东西直接写一个Django management command用python manage.py crawl_books手动触发或者挂在系统cron上每天跑一次。这样做代码简洁、逻辑清晰而且答辩时讲起来也好理解——我校准了增量爬取每次只采集新增和更新的数据避免重复抓取。4. 推荐引擎核心从协同过滤到混合推荐的落地实现4.1 三种推荐算法的适用场景对比推荐算法是系统的灵魂。对这个项目来说市面上最常见的三种算法你可以全部实现然后对比效果这本身就是很好的毕设工作量和答辩亮点。算法原理适用场景实现难度基于内容的推荐根据用户读过的书的内容属性分类、标签、作者找相似书籍冷启动时管用新用户也有推荐低基于物品的协同过滤找到喜欢同一本书的用户群推荐他们喜欢的其他书用户行为数据充足时效果好中基于用户的协同过滤找到相似用户推荐相似用户喜欢的书用户量大且行为丰富时效果好中我建议主推基于物品的协同过滤ItemCF。原因很直接小说站里热门书籍数量有限大部分用户不会读过太多的书ItemCF计算物品之间的相似度比UserCF计算用户之间的相似度更稳定而且结果也更好解释——因为你读过《A》和《B》所以给你推荐《C》。4.2 基于物品的协同过滤实现细节ItemCF的核心分两步第一步算物品间的相似度矩阵第二步根据用户历史行为生成推荐。相似度我这里用余弦相似度公式不展开了用Python代码落地大约是这样from math import sqrt from collections import defaultdict def build_item_similarity(user_behavior): # user_behavior: {user_id: {book_id: rating}} # 1. 统计喜欢每个物品的用户列表 item_users defaultdict(list) for user, books in user_behavior.items(): for book in books: item_users[book].append(user) # 2. 计算物品间共同被喜欢的次数 co_occur defaultdict(int) for book, users in item_users.items(): for i in range(len(users)): for j in range(i 1, len(users)): # 这里简化为任意两个被同一用户喜欢的物品的共现计数 u1, u2 users[i], users[j] for b1 in user_behavior[u1]: for b2 in user_behavior[u2]: if b1 ! b2: co_occur[(b1, b2)] 1 # 3. 归一化得到相似度矩阵 similarity {} for (b1, b2), cnt in co_occur.items(): similarity[(b1, b2)] cnt / sqrt(len(item_users[b1]) * len(item_users[b2])) return similarity这是最基础的思路。实际项目里我会用user_behavior表里的阅读收藏行为构造正反馈评分数作为权重。为了效率相似度计算只在离线任务里跑算完之后把每个物品最相似的Top-N物品写入book_similarity表。在线推荐时就简单了找到用户最近读过的几本书去相似度表里查找对应的相似书加权累加排序取前20本就是推荐结果。这段逻辑建议你讲答辩时画图配合从离线计算到在线召回到排序三个阶段评委听到这里基本就能确认这不是一个花架子系统。4.3 冷启动问题的处理冷启动是推荐系统最经典的问题也是评委最爱问的问题。新用户没有行为数据协同过滤必然失效怎么办我当时用了两个方案组合起来效果很好基于内容的兜底推荐如果用户行为表为空直接按分类偏好或者不区分偏好推荐热门高分小说。用户可以手动选择我喜欢的分类系统按分类推荐该分类下评分最高的书。最近热门推荐统计近7天阅读/收藏量最高的书作为新用户的默认推荐列表。这两个方案本质上就是规则推荐不用复杂模型但它在产品逻辑上把推荐系统做完整了。答辩时被问冷启动怎么解决你直接回答协同过滤覆盖不了的时候用内容召回和热门召回兜底这就很有说服力。4.4 离线计算与在线接口的配合说到离线计算和在线接口很多同学觉得是高大上的分布式系统才有的概念其实在单机项目里一样可以实现这种分工。我当时的做法是写一个recommend/management/commands/offline_compute.py命令里面调相似度计算和推荐结果生成函数跑完把每个用户的预测推荐列表写入recommendation表。这个命令手动执行或者放定时任务。在线接口呢就是一个Django DRF的GET /api/recommendations/逻辑非常简单——到recommendation表查当前用户的推荐列表返回即可。这样做的好处是在线接口响应只有几十毫秒前端体验流畅而离线计算任务跑十几秒也不会卡住页面。如果答辩老师问为什么不用实时计算你可以说——实时计算每请求一次都要做物品相似度计算在大数据量下延迟不可控业界通用做法就是离线计算好结果、在线读取。这个思想用到真实企业项目里也是一样的。5. 可视化交互层VueECharts的图表设计与复用5.1 看板设计哪些图表是评委爱看的可视化模块是很多人忽略的加分项。小说推荐系统的可视化不只是把数据画出来更关键的是用图表讲清楚系统里的数据情况。我做的看板包含这么几块图书分类分布饼图展示各个分类的小说数量占比一眼看出书库里玄幻、都市、科幻各占多少。热门小说Top10柱状图按阅读量/收藏量排序展示系统内最受欢迎的小说。用户活跃度趋势折线图按天展示每日新增用户数和行为数体现系统运营情况。推荐效果统计图展示推荐位曝光数、点击次数、推荐位点击率这个图是我最推荐做的一个因为它直接证明推荐算法有效果。其中推荐效果统计图特别提一下我从第一次做完项目后的复盘经验是推荐系统的可视化不能只展示输入数据更要展示输出效果。你展示了推荐点击率从无推荐时的X%提升到了有推荐时的Y%这就是推荐算法价值的直接证据答辩时拿着这个数据讲比任何理论都硬。5.2 前端组件化图表组件怎么拆Vue这边我建议把ECharts封装成可复用的图表组件。不要每个页面都写一堆配置项那代码会非常臃肿。我的做法是写一个BaseChart.vue组件接收option作为prop内部完成ECharts初始化、自动resize、数据更新监听template div refchartRef stylewidth: 100%; height: 400px/div /template script import * as echarts from echarts; export default { name: BaseChart, props: { option: { type: Object, required: true } }, data() { return { chart: null }; }, mounted() { this.chart echarts.init(this.$refs.chartRef); this.chart.setOption(this.option); window.addEventListener(resize, this.resize); }, watch: { option: { deep: true, handler(newVal) { this.chart.setOption(newVal); } } }, methods: { resize() { this.chart this.chart.resize(); } }, beforeUnmount() { window.removeEventListener(resize, this.resize); this.chart this.chart.dispose(); } }; /script这样在页面里用的时候只需要传入不同的option就行。分类饼图、热门柱状图、趋势折线图各自写一个数据加载函数调用同一个组件渲染。代码量一下子少了一半。5.3 前后端联调的接口规范前后端分离的项目接口设计规范直接影响联调效率。我开始时吃过亏前端要的数据结构和后端返回的差别很大就靠前端再转换越转越乱。后来定了规矩所有列表接口返回{ code, data, message }的固定结构data里统一用{ list, total }分页结构后端字段名一律用驼峰转下划线后再转换一次前端只用驼峰字段Django的serializer可以配置字段名时间字段统一返回时间戳前端自己格式化。这些规矩看起来琐碎但没有它们Vue页面和后端会互相扯皮改来改去。定好规矩之后前后端基本可以并行开发——前端拿Mock数据先写页面后端好了再切换真实接口。6. 部署联调与答辩准备最容易翻车的几个环节6.1 本地联调与跨域问题Django跑在8000端口Vue跑在5173或8080端口这样的前后端分离项目必遇跨域问题。解决办法有两个方向后端用django-cors-headers放行前端的域名这是开发阶段最简单的方式生产环境把Django和Vue的构建产物放到同一个服务下用Nginx托管就不存在跨域了。我个人的建议是开发阶段用cors-headers最终部署用Nginx统一托管。这样开发效率高演示的时候也不会因为浏览器拦截跨域请求而出洋相。跨域问题还有一个坑要提醒不要在演示时打开两个页面同时访问前后端万一前端开发服务器的端口忘了开页面打不开。最终演示最好用打包后的静态文件。6.2 打包部署的注意事项Vue项目npm run build之后会生成dist目录里面是纯静态文件。Django这边你需要把dist目录配置为STATICFILES_DIRS之一同时让Django直接渲染一个index.html入口。这样评委访问你部署好的地址一个端口搞定所有功能不用解释两个服务的问题。数据库方面如果换一台电脑演示一定要记得导出MySQL数据。标题里写了源码文档讲解但很多人容易漏掉数据库初始化脚本。我的习惯是提供两个文件install.sql建库建表和seed_data.sql爬虫抓取的核心数据。否则别人拿到源码启动后端啥都没有推荐算法跑不动看板全是空图表直接整个系统就崩了。6.3 答辩演示的预演清单毕设答辩翻车十次有八次在上台前没检查环境。列个简单的预演清单提前一天在答辩用的电脑上完整跑一遍系统确认Python、Node、MySQL、Redis的依赖都齐了。准备离线模式如果现场没网爬虫展示就用现有的seed_data可视化展示直接读取数据库。有一个万能方案——录一段3分钟的演示视频放在U盘里万一环境崩塌放视频也比干站着强。准备讲故事的顺序不要从首页代码开始讲而是从数据→算法→展示→效果这条链路走讲清楚每个环节做了什么以及为什么这么做。6.4 文档与演示材料组织最后说下配套文档。毕设评审最看重的是你的工作量是否饱满、逻辑是否清楚。所以文档里我建议按这个顺序组织需求分析系统分为哪几个模块每个模块有什么功能点系统设计架构图、数据库ER图、接口清单核心模块实现爬虫设计、推荐算法详解、可视化图表设计系统演示截图与效果分析放上实际运行时看板截图和推荐点击率数据。PPT就不要和文档一样了PPT是讲故事用的一页一个主题。我的经验是封面标题之后先放一张全链路架构图让评委30秒内知道你做了什么然后按数据流转顺序讲三四个核心模块的实现最后放演示截图和效果数据收尾。你按这个顺序讲过之后基本不会出现讲得不清不楚的评价。做这个项目最容易掉进去的坑其实就是贪多。有人爬虫要爬12个网站推荐要上深度神经网络看板要搞3D大屏——最后全卡住。我在实际带项目时一直跟人说毕业设计的本质是完整不是炫技。把爬虫做到干净、把推荐做到可解释、把可视化做到能说明问题这一条链路跑通就已经超过大多数人了。如果后续还有时间再考虑加语义标签、弹幕热词、实时协同过滤这些进阶玩法不迟。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
