1. 为什么电商比价系统是毕设里的常青树选题每年到毕业季都能在各大论坛看到有人在问有没有好做的毕设题目。问得多了答案翻来覆去就那么几个电商比价系统绝对是其中之一。为什么这个题目年年有人做、年年不过时因为它刚好卡在一个绝妙的位置上技术覆盖面广、难度适中、可扩展空间大而且和每个人的日常购物体验直接相关答辩时老师不需要你解释这东西有什么用。先说覆盖面。一个完整的电商比价系统前端要展示商品列表和价格对比后端要提供搜索、查询、比价逻辑的接口数据层要设计商品表、价格历史表、SKU表背后还挂着爬虫模块去各大平台采集数据。这一套下来Python基础、网络请求、HTML解析、数据库设计、Web框架、前端页面、数据可视化几乎把大学四年学的核心课程串了个遍。这正是评审老师想看到的不是单点技术秀而是工程化、系统化的综合能力。再说可扩展性。2024到2025年这批毕设最大的加分项已经出现了——大模型。你可以在比价系统的基础上接入大模型能力比如让系统根据用户预算自动推荐商品、生成多商品对比的总结文案、解释为什么某款商品值得买。标题里提到的DeepSeek agent就是这么回事。这个加分项放在两年前根本不存在现在做进去既能体现技术敏感度又能让答辩展示环节非常有看点——你不再只是展示一个查询表格而是让系统会说话。最后说难度控制。比价系统的难点集中在爬虫和数据一致性上但这两块都有成熟方案可参考。选Selenium是因为很多电商平台是动态渲染页面普通requests根本拿不到完整数据Selenium模拟真人浏览器操作虽然重但稳定适合毕设这种可靠优先的场景。再加上Flask做后端足够轻量不引入Spring全家桶那样的复杂度对Python方向的学生非常友好。一句话总结这个选题的定位内容扎实、路径清晰、上限很高。你既可以做一个中规中矩的课程设计级作品也可以一路做到带大模型Agent的进阶版本工作量完全由自己掌控。2. 系统架构与数据模型先把地基画清楚2.1 四层架构让每一层都能独立测试很多学生拿到题目就直接开始写爬虫这是第一个大坑。爬虫跑了两天写了三百行代码发现数据格式没想清楚后端接口没法对接前端想要的数据字段对不上全部推倒重来。我自己的习惯是先把架构图画出来不用多复杂但要明确每一层的职责边界。比价系统我拆成了四层采集层Selenium驱动浏览器访问各电商平台抓取商品标题、价格、店铺名、销量、评价数、商品链接、图片地址。数据层MySQL存储商品主信息独立的价格历史表记录每次抓取到的价格快照供趋势分析和最低价计算使用。服务层Flask提供RESTful API处理搜索、详情、比价、趋势查询等业务逻辑。展示层前端页面用ECharts渲染价格曲线和对比图表股票式K线图在这类场景非常加分。这个结构的好处是每一层都可以单独替换。比如爬虫想换成Scrapy框架不影响数据层前端想从原生HTML换成Vue后端接口不用动。答辩时如果老师问某一块怎么改进你也能顺着分层思路给出合理回答而不是含糊地说反正能跑。2.2 数据库表设计的关键字段商品数据有个典型特点冗余信息多、重复商品多、价格变动频繁。同一个商品在京东和天猫可能都卖但标题、店铺、价格完全不同即使在同一平台不同日期的价格也可能不一样。所以表结构至少要分成三张商品主表productsCREATE TABLE products ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(255) NOT NULL, platform VARCHAR(50) NOT NULL, shop_name VARCHAR(100), sku_id VARCHAR(100), product_url TEXT, image_url TEXT, current_price DECIMAL(10,2), original_price DECIMAL(10,2), sales_count INT, comment_count INT, created_at DATETIME, updated_at DATETIME, UNIQUE KEY uk_platform_sku (platform, sku_id) );主表里的sku_id特别重要。它是平台内部唯一标识某个商品的ID存在于URL参数或页面数据里。有了它才能做去重和关联。价格历史表price_historyCREATE TABLE price_history ( id INT AUTO_INCREMENT PRIMARY KEY, product_id INT NOT NULL, price DECIMAL(10,2) NOT NULL, capture_time DATETIME, platform VARCHAR(50), INDEX idx_product_time (product_id, capture_time) );这张表的设计动机很简单比价系统要能回答这商品最近30天价格走势如何今天是不是历史最低价这类问题。没有价格历史比价就变成了一次性的快照对比毫无深度。而且这张表天然就是大数据量的积累者之后做数据分析、画趋势图全靠它。**比价结果表price_compare**可以做成缓存表记录某次比价请求的结果集合减少重复计算也让前端展示历史查询记录成为可能。在设计数据模型阶段优先级最高的一件事是确定商品唯一性的判定规则。我当时的做法是先用平台sku_id联合唯一键做初步去重再用标题相似度做二次合并。两步走既能避免同款商品被重复计算又不会因为同一商品在不同平台sku_id不同而漏掉。2.3 为什么选Flask而不是Django这个问题几乎是答辩必问题。我自己的理由是分阶段的毕设周期内Flask的开发效率远高于Django。Django自带Admin后台、ORM、模板系统、中间件体系功能完整是它的优势但对一个中小型项目来说这些开箱即用反而成为一种负担——配置项太多你想实现一个搜索接口得先理解Django的APP结构、settings配置、URL分发规则。Flask就简单直接得多。一个app.py里可以写完所有路由用蓝图Blueprint组织模块也能随时拆分。数据库用SQLAlchemy的动态绑定或者干脆用pymysqlSQLAlchemy Core灵活度非常高。对爬虫Web展示为核心的项目后端不是重点轻量、快速迭代才是关键。如果你担心Flask太简陋答辩不好看其实不需要。Flask官方文档里明确支持大规模应用组织方式你用Blueprint把crawler、api、auth几个模块拆清楚同样体现工程能力。比强行选Django但代码结构混乱要好得多。3. 商品采集模块Selenium踩坑实录3.1 为什么爬虫选了Selenium这个选择我在之前的博客里反复强调过能稳定完成任务比炫技重要。requestsBeautifulSoup/正则的方式理论上更快更轻但在2024到2025年的电商平台面前成功率非常不稳定。几乎所有主流电商平台都是SPA页面商品价格、促销信息通过JS异步加载有的还做了数据混淆和字体反爬。你用requests拿到的HTML里根本没有真实价格。Selenium直接控制一个真实的Chrome浏览器或用无头模式浏览器替你执行了所有JavaScript渲染完成后的DOM里就是你肉眼看到的商品信息。代价是慢、占内存但对毕设这个体量来说每小时几百个商品的采集量完全够用了。另外一个实用经验要给Selenium配置合理的等待策略。三种等待必须搞清楚区别time.sleep(5)固定等5秒太浪费。网络稍快就空等网络慢又可能不够。WebDriverWait(driver, 10).until(EC.presence_of_element_located(...))等待某个元素出现这是最常用的方式。显式等待EC.text_to_be_present_in_element等待某个元素内容不为空适合价格这类动态加载的字段。我当时的代码是这样写的from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By wait WebDriverWait(driver, 10, poll_frequency0.5) # 等待商品标题出现 title_element wait.until( EC.presence_of_element_located((By.CSS_SELECTOR, h1.goods-name)) )注意poll_frequency0.5这个参数实际体验提升明显。默认0.5秒轮询一次已经够快重点是不要用默认的0.5去配合time.sleep乱等。3.2 动态页面的元素定位拿到一个商品详情页我先做的是打开开发者工具查看页面结构。不同平台的页面结构差异很大哪怕同一个平台改版也可能翻天覆地。所以爬虫模块一定要遵循一个原则选择器必须集中在配置文件里不要写死在代码各处。我喜欢用Python字典维护选择器SELECTORS { jd: { price: #p-price .price, title: div.sku-name, shop: div.shopName a, comments: #comment-count, }, taobao: { price: span.sale-price, title: h1.main-title, shop: div.shop-info .shop-name, comments: span.count, }, }用CSS Selector定位时建议避免使用过于复杂的XPath表达式。XPath功能强但脆弱页面只要动一个层级就全崩。CSS选择器在绝多数场景够用且浏览器里直接右键复制也能生成。另外要小心stale element reference异常。页面在加载过程中DOM节点可能被重新渲染你之前拿到的WebElement引用就失效了。解决方法是每次操作前重新定位或者用try-except包一层重新查询。这个异常在校验阶段非常容易出现处理不好会导致整个爬虫空跑。3.3 反爬应对按正常人的节奏干活我在项目早期遇到过几次采集失败排查后发现根本原因不是IP被封而是访问频率太像机器人。解决思路很简单但也非常有效随机延时两次访问之间随机sleep 3到8秒不要固定同一个值。随机User-Agent每次请求换一个UA模拟不同设备。控制并发可以用ThreadPoolExecutor(max_workers3)限制同时打开的浏览器窗口数量。太多窗口反而因内存不足导致浏览器崩溃。失败重试对超时、元素不存在的异常做3次重试重试间隔递增。对于登录墙的问题业界通用的方案是让用户手动扫码登录一次保存浏览器的Cookie数据之后再启动时加载Cookie。因为毕设不是商业采集你可以直接设置为展示登录页面用户输入账号后自动延续会话。电商平台的反爬是动态博弈你能守住的原则只有一个身份模拟干净。绕过验证码之类的黑灰产手段我不建议碰也不该出现在毕业设计里。4. 数据处理与比价逻辑价格可不是越小越好4.1 数据清洗的细节问题爬下来的数据如果想直接用基本不可能。先列几个我实际踩过的坑价格字段格式混乱有的返回¥299有的返回299.00还有的带折扣信息到手价249.00。销量字段带单位3.5万、1.2万人付款都需要转换。标题里有大量营销词【618】限时特惠XX品牌旗舰店现货...直接入库噪音太大。图片地址可能是相对路径需要拼接完整URL。我的做法是在爬虫写完数据后立即调用一个统一的clean_product_data函数做规范化def clean_price(raw_price): 清洗价格字段返回Decimal失败返回None if not raw_price: return None price_str re.sub(r[^\d.], , raw_price) try: return Decimal(price_str) if price_str else None except InvalidOperation: return None def clean_sales(raw_sales): 清洗销量3.5万 - 35000 if raw_sales is None: return 0 m re.search(r([\d.])(万|亿)?, raw_sales) if not m: return 0 num float(m.group(1)) if m.group(2) 万: num * 10000 elif m.group(2) 亿: num * 100000000 return int(num)清洗规则越早统一越好否则后面统计、缩放、可视化全都会出问题。4.2 比价算法的设计思路比价逻辑是核心但它比大部分人想象的要简单。简单逻辑是直接按当前价格排序谁低谁赢。但这忽略了一个问题低价不等于可用。同样是全网最低价一个是无货源代发店铺一个是官方旗舰店购买体验天差地别。所以合理的比价算法应该输出一个综合评分而不仅仅是价格。我用的公式大致是score 0.45 * price_score 0.25 * sales_score 0.20 * comment_score 0.10 * platform_weight其中price_score当前商品价格与所有候选商品中最低价格的比值越低分越高。sales_score月销量在候选集合里的归一化排名用min-max缩放。comment_score评价数归一化结果评价多说明购买人多、参考价值大。platform_weight给不同平台一个固定偏好系数比如某东因为自营物流加分。实际实现并不复杂只需要在SQL里把候选商品取出来然后在Python里做归一化计算。这个设计思路在答辩时特别好讲它体现了综合分析而非单一指标排序老师会觉得你有产品思维。4.3 价格趋势与历史最低价比价系统一旦有了price_history表就能做很多有意思的数据分析。最常见的是商品价格30天曲线标识出最高点、最低点、均值。历史最低价标记如果当前价格小于历史均值的90%推荐优先级上调。不同商城同款商品价格对比柱状图。说到价格趋势我强烈建议用ECharts的折线图或boxplot图。ECharts对这类动态数据展示支持极好交互上支持悬浮显示数据点、缩放时间范围答辩演示时效果很足。而且ECharts只是前端图表库不需要额外后端服务Flask渲染模板时把历史价格列表作为JSON传入即可。这里有个细节你一定会遇到不同平台抓到的价格快照时间点不同直接画在一条线上会产生误导。我的做法是按天聚合每天取最后一次有效价格作为当天代表性价格。这一句话就能让你避开半天排错的弯路。5. 可视化与前后端对接让数据说话而不是堆表5.1 Flask API接口设计后端接口设计的核心思路是职责单一、参数明确。我设计的API大致如下接口方法参数说明/api/searchGETkeyword, page, sort搜索商品按价格/销量/综合排序/api/product/idGET无商品详情价格趋势/api/compareGETname同款商品跨平台比价/api/history/product_idGETdays指定时间范围的价格历史/api/agent/recommendPOSTproduct_ids, budget调用大模型生成推荐与分析/api/search是所有功能的入口。实现时我用SQLAlchemy执行带条件的查询配合LIKE语法做模糊匹配搜索app.route(/api/search) def search(): keyword request.args.get(keyword, ) page int(request.args.get(page, 1)) sort request.args.get(sort, score) # 支持 price_asc, sales_desc, score query Product.query.filter(Product.name.like(f%{keyword}%)) query apply_sort(query, sort) pagination query.paginate(pagepage, per_page20) return jsonify({ items: [p.to_dict() for p in pagination.items], total: pagination.total, page: page, })to_dict()方法是自己维护的保证返回字段永远是前端需要的那个集合。让所有接口统一走这个模式前端调用时就不必频繁改字段名。5.2 页面可视化实战可视化我分成了三个页面搜索页搜索框排序选项商品卡片列表卡片上显示标题、价格、平台图标、销量、查看比价按钮。商品详情页左侧商品图基本信息右侧ECharts价格趋势折线图底部是价格历史统计词条最高/最低/平均/建议购买区间。比价结果页用横向条形图展示多平台价格对比每条bar点击可以带上对应链接跳转。实现ECharts图表时有一个坑首次渲染拿不到数据因为异步接口还没返回。解决办法是页面初始化时先请求数据回调函数里初始化图表。用原生JavaScript也能实现但用了jQuery的$.ajax会更顺畅。图表配置里记得设置tooltip: { trigger: axis }鼠标悬停时能显示完整数值非常实用。如果想让可视化有大数据的感觉可以再加上一个全局统计页本平台覆盖率、总商品数、每日新增记录数、热门搜索词Top10。这些统计本质上就是几行SQL聚合操作但在展示效果上非常震撼。老师看到的不再是我做了个爬虫而是我做了个数据分析平台。6. 接入DeepSeek大模型让系统会说话6.1 大模型Agent在比价系统里的定位前面几章的内容已经能构成一个合格的毕设项目。但如果你想让项目从合格跨到优秀大模型Agent是最该加的一环。为什么是大模型而不是传统规则因为传统比价系统只能回答哪个便宜回答不了为什么这个值得买、预算3000以下有哪些选择、这两款CPU哪款更适合办公这类需要推理的问题。引入大模型Agent后系统就从查询工具变成了导购助手。具体来说它能在三个场景发挥作用生成商品摘要当一个商品被抓取入库后调用大模型生成一段百字以内的推荐理由存入数据库。智能比价解释比价结果旁边自动生成虽然A店便宜50元但B店是官方旗舰店售后更有保障这类综合分析。用户对话问答用户输入帮我选个5000到7000的轻薄本系统把搜索结果组装成Prompt大模型输出推荐结论并附上理由。DeepSeek在这个场景里的优势是中文理解能力强、上下文窗口大、API调用便宜对毕设这种小流量项目几乎可以忽略成本。6.2 API接入方式DeepSeek的OpenAI兼容API调用方式很简单。你只需要安装openai库然后改base_url和api_key即可from openai import OpenAI client OpenAI( api_key你的API Key, base_urlhttps://api.deepseek.com ) def generate_recommendation(product_list_str, user_budget): prompt f你是电商导购专家。以下是从多个电商平台采集到的同款商品数据 {product_list_str} 用户预算{user_budget}元。 请从性价比、店铺信誉、销量、售后体验等角度给出推荐并用3条以内要点说明理由。 response client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是电商导购专家回答务必简练、切中要点。}, {role: user, content: prompt} ], temperature0.7, max_tokens500 ) return response.choices[0].message.content这里有个细节API Key千万不要写在代码里更不要提交到Git仓库。放到环境变量或项目根目录的.env文件里用python-dotenv加载。答辩现场环境可能没有配置好最好在演示前生成好一些离线推荐结果截图备用。6.3 提示词设计与成本控制在毕设系统中接大模型最容易踩的坑是无限生成导致接口费用堆积和提示词设计糟糕导致返回内容不可控。我的建议是不要每次请求都调用大模型。搜索商品时每天只调用一次生成摘要并缓存到数据库比价时只有用户点击AI分析按钮才调用对话问答时需要限制上下文长度只传当前搜索结果不要传聊天历史。提示词设计也有讲究。越清楚的指令输出越稳定官方推荐的做法是提供system prompt设定角色再用few-shot示例约束格式。我建议的system prompt格式是你是电商导购专家。输出结果必须包含推荐结论、原因要点、综合评分1-10。总字数控制在150字以内不要使用Markdown加粗格式。这样得到的结果格式规整前端直接展示效果就很好。如果把大模型的返回直接当作HTML插入页面还要注意防止XSS注入调用前先对文本做HTML转义。如果你有余力还能在Agent设计上更进一步给大模型上传一份商品数据库工具描述让它能调用搜索函数形成真正的tool use流程。但说实话毕设阶段做到按需生成推荐分析并展示已经完全够用了不必过度设计。7. 性能优化、部署与毕设答辩要点7.1 性能瓶颈与优化手段项目做完能跑起来只是第一步答辩环节老师一定会追问性能问题。我当时被问到最多的问题是你这个爬虫跑一次要多久数据多了之后查询会不会卡针对这两个问题我做了三件事第一爬虫采集用多线程队列。按照平台分发任务每个平台一个工作线程用queue.Queue做任务缓冲。实测采集50个商品大约需要3到5分钟这个速度完全在可接受范围内。采集完立即入库并发插入时注意数据库连接池配置SQLAlchemy默认的连接池在并发写入时可能报TimeoutError需要调整pool_recycle和pool_pre_ping参数。第二查询缓存。价格趋势、搜索结果这类高频接口加一层Redis缓存缓存时间为5分钟。毕设项目也许用不到缓存但这个设计体现的问题意识能亮出来。第三数据归档与索引。价格历史表是会无限增长的定期把超过90天的数据聚合到小时级并把capture_time和product_id建立联合索引。这两条SQL级别的优化虽然实现简单但应对大数据量的提问时比空谈分布式靠谱得多。7.2 本地部署与演示环境毕设答辩最怕的就是现场演示翻车。Windows机器上建议直接用虚拟环境MySQL 8.0Redis可视化工具的组合。不要试图在答辩现场现场启动爬虫网络问题、验证码问题、平台反爬问题都可能随机出现。更稳妥的做法是提前把数据库里存好完整数据答辩时演示搜索、比价、可视化、大模型推荐功能全程无需联网。单独录制一段爬虫实时采集的视频插入演示PPT中展示。如果现场允许网络演示DeepSeek对话功能最后展示如果断网展示预存的截图。开发环境用requirements.txt锁定关键依赖版本。我实际用的依赖版本大致是Flask 3.0.x、Flask-SQLAlchemy 3.1.x、Selenium 4.x、openai 1.x、redis-py 5.x、ECharts通过CDN引入。确保环境一致这一条看着简单能帮你避开大量我这儿能跑你那儿跑不了的尴尬。7.3 答辩重点把做完说成做好答辩陈述的逻辑顺序我建议这样安排选题动机 → 技术架构 → 核心难点与解决思路 → 创新点 → 不足与改进方向。讲技术架构时一张四层架构图就够了别急着展示代码。讲核心难点时选择一两个真正有技术含量的点展开比如Selenium动态等待策略设计、跨平台商品去重规则、价格历史聚合查询的SQL优化每个点只要讲清楚问题是什么、为什么会有、我怎么解决、效果如何四句话即可。创新点部分重点讲大模型Agent。具体话术可以是传统比价系统只展示客观数据本系统通过接入DeepSeek大模型将商品数据分析转化为自然语言的导购建议实现了从信息展示到智能决策的升级。这句话既点出了技术创新又把项目的实用价值放在了明处。最后提前想好一两个不足点。比如目前数据采集依赖Selenium采集效率偏低后续可考虑使用企业开放API或维护更轻量的解析协议来提升采集性能。这个回答能让老师看到你对技术边界有清醒认知比硬撑着说我的系统完美无缺效果好得多。分享一个我个人的实用体会做这种全栈型毕设不要追求每个模块都完美。老师真正看重的是你能不能把一个完整系统的链条从头到尾跑通并且在关键节点上有自己独立的思考和取舍。比价系统恰好能给足你展示这些的机会——从爬虫的稳定性设计到数据模型的反规范化再到让大模型真正服务业务场景每一步都有真实的决策过程。做完之后你会发现收获的不只是一份源码而是一整套遇到问题先拆解再解决的工程思维。这套思维才是你毕业之后第一份工作里最值钱的东西。