企业官网建设流程全解析

选毕业设计题目这件事，每年都有一批人卡在同一个地方：题目不是太空就是太旧，代码量不够还凑不出亮点。今天聊的这套“京东淘宝多平台比价可视化系统”算是比较实在的一个方向，技术栈是 Flask、Selenium、MySQL、ECharts，再挂一个大模型 Agent 做智能问答，整条链路从数据采集到业务展示全部打通。对大数据方向的学生来说，这套系统最值钱的地方在于它覆盖了一个完整项目的每个环节，而且每一个环节都能在论文里写出实质内容，不是那种靠堆砌名词撑起来的假大空项目。这篇文章我把整个项目的拆解思路、核心模块的实现逻辑、还有实际跑通时容易踩的坑都整理出来，算是给准备复现或者准备拿它做底子扩展的人一份参考。

1. 为什么选这个题目：需求分析与项目定位

1.1 比价系统解决的到底是什么问题

先说业务场景。日常购物里同一个商品在不同平台的价格差异是真实存在的，有时候差价甚至能到百分之二三十。靠人工在两个 App 之间来回切换、对比规格、看历史价格，成本很高，而且人的记忆不可靠，看完了转头就忘。比价系统本质上就是把"人工反复对比"这件事自动化：定时采集商品信息，把同款商品的价格放在同一个界面里对比，再把价格走势和优惠信息可视化，让用户一眼看到"现在买还是再等等"。

从毕业设计的角度来评估，这个题目有一个很关键的优势——它的业务链路完整且清晰。从爬虫采集数据，到清洗入库，到接口层输出，到前端图表展示，最后再到 AI 层做自然语言交互，每一步都是可以独立成章的内容。与其找个概念新但落不了地的题目，不如选一个接地气、能跑通、能演示、还能写清楚的项目。比价系统恰好属于那种"看起来简单、做起来有细节、讲起来有深度"的题目。

1.2 技术选型：为什么是 Flask、Selenium 和 Agent 的组合

给这个项目定技术栈的时候，我逐一对比过常用选项，核心原则是"够用、好讲、能展示工程能力"。

这套组合还有一个实际的好处：每个技术点都不算深，但合在一起，刚好构成一个"从传统爬虫到 AI Agent"的演进脉络。论文里可以按数据层、服务层、应用层的递进关系来写，逻辑上很顺。

2. 架构设计与数据链路规划

2.1 系统整体架构

这套比价系统的整体架构拆成五层来看会比较清楚。最底层是数据采集层，用 Selenium 控制浏览器去目标平台搜索商品页面，模拟用户行为采集列表页和详情页的数据。往上一层是数据治理层，负责清洗、去重、归一化，把各个平台不一致的字段统一成标准格式。再往上是存储层，MySQL 里存放商品主数据、价格历史数据和平台配置信息。服务层用 Flask 提供 RESTful API，给前端可视化看板和 Agent 模块供应数据。最上层是应用层，包括 ECharts 看板、Agent 智能问答、价格提醒三个主要业务入口。

数据链路里的关键动作是"一次采集、多次消费"。爬虫采集到的商品数据不只用于价格对比展示，还会被沉淀成价格历史记录，后续的价格走势分析和价格预测模型都依赖这份历史数据。所以从需求分析阶段就要给 price_history 这张表预留足够的设计空间，不要只想着当前页面能不能显示出来，还要想着一个月后能不能支撑趋势分析。

2.2 核心模块划分与职责边界

模块划分上，我建议按功能边界拆成六个独立模块，不要混在一起写。第一个是搜索爬虫模块，封装 Selenium 的搜索和采集逻辑，输入是商品关键词，输出是结构化的商品信息列表。第二个是价格采集模块，负责定时抓取单个商品的最新价格并写入历史表，这个模块要支持简单的增量更新策略。第三个是数据清洗模块，处理掉采集数据里的脏数据、缺失字段和格式不一致问题。第四个是Flask Web 模块，提供商品查询、价格对比、历史查询等接口。第五个是数据可视化模块，前端页面加 ECharts 图表的配置。第六个是Agent 问答模块，接收用户自然语言问题，调用大模型进行意图识别和参数抽取，再根据结果查询数据库并生成回答。

模块之间只通过数据库和接口通信，爬虫模块不直接调用 Web 模块的函数，Web 模块也不关心爬虫怎么抓数据。这样设计的好处是后期调试时定位问题非常快，爬虫出问题只碰爬虫的代码，页面不显示只查接口和前端，不用在一个巨大文件里从头翻到尾。

3. 爬虫模块：比价系统的数据基础

3.1 为什么选 Selenium 而不是 requests

项目刚开始的时候，我一度想过用 requests 直接请求页面，代码写起来会简单很多，不需要处理浏览器驱动。但实际测试下来发现行不通，目标平台的商品列表和价格信息基本都是异步加载的，直接请求拿到的 HTML 里只有一段空的骨架结构，真正的商品数据藏在后面的 XHR 接口里。不走浏览器渲染的话，你得先分析接口、构造参数、处理加密逻辑，这一套起来工作量不小，而且平台接口一旦改动，前面的分析全部作废。

Selenium 的好处在于它把问题从"模拟接口请求"简化成"模拟用户浏览"。驱动浏览器去搜索关键词、等待页面渲染、滚动加载更多商品、读取 DOM 里的价格文本，这种思路在应对动态渲染页面时稳定很多，也不容易被接口参数变化波及。代价是它比纯网络请求慢不少、吃内存，但毕业设计场景下的数据量和采集频率完全能接受，稳定性比速度重要。实际上我在测试中发现，把 Selenium 的隐性等待和显性等待组合用好，采集一个商品列表页花两三秒完全在可接受范围内。

3.2 抓取流程的完整实现思路

Selenium 爬虫的核心流程可以按步骤拆成四段。第一段是浏览器初始化，需要配置的无非是这几项：headless 模式、User-Agent、禁掉自动化提示、关闭图片加载。其中关闭图片加载这个细节挺重要，商品列表页图片非常多，不关的话页面加载会拖慢很多，采集效率至少差一倍。第二段是进入搜索页并输入关键词，定位搜索框、输入关键词、按下回车，这里要注意 Selenium 对输入框的定位建议用显式等待，等元素准备好再操作，不要睡死一个固定秒数。

第三段是等待列表加载并翻页或滚动。目标平台的搜索结果通常不是一次性全渲染出来的，需要模拟滚动到底部触发懒加载。我习惯写一个循环，每次滚动后检查商品卡片数量是否增长，连续几次没有变化就认为加载结束。第四段是解析元素并抽取字段，用 CSS 选择器或 XPath 定位商品标题、价格、链接、店铺名等节点。这里有一个关键的经验：不要用页面展示出来的文本直接入库，商品价格经常会出现整百减券、满减折算、首单优惠这类实际计算后的价格，展示文本未必是真实成交价。在抽取阶段尽量找到价格节点的原始数据属性，或者只记录展示价并在数据清洗阶段做标记，把"展示价"和"估算到手价"区分开。

整个流程跑通之后，再封装成一个可复用的函数，输入关键词、返回商品列表，后续所有采集任务都调用这个统一入口。

3.3 反爬与合规：稳定采集的边界

这个话题必须展开聊，因为很多人一上来就想着怎么突破各种限制，结果账号被封、IP 被限制，反而把整个项目的进度拖垮了。

我的建议是保持一个原则：做低频、做公开数据、不碰登录态、不搞并发。所谓低频，就是控制采集频率，页面加载完成后间隔一秒钟再发起下一次请求，给每次请求之间加随机延时，不要出现规律的间隔。所谓公开数据，就是只采集搜索页和商品详情页公开可见的信息，不尝试绕过登录、不抓取用户数据、不碰任何需要特定权限才能访问的内容。所谓不搞并发，就是不要同时开十个浏览器窗口去抓一个平台的页面，这种行为既不稳定也不合适。

从技术层面讲，Selenium 驱动浏览器本身是有特征的，常见的自动化检测手段能识别 webdriver 标识。做项目的时候可以设置一些基础的浏览器参数（比如去掉扩展名特征、用正常的 UA 头），但最核心的还是"别频繁、别高调"。数据采集量够用就行，毕业设计演示根本不需要上百万条数据，能有一个能跑通、覆盖几个常见品类的数据集，已经能支撑后续所有功能的展示了。至于验证码这类情况，遇到就退避一下，降低频率、换关键词重试，真过不去就人工辅助走一次，没必要在绕过验证码这件事上花时间。

3.4 数据清洗与归一化

爬虫拿到的原始数据直接入库是行不通的，几个平台的字段格式差异很大。清洗这一步要处理四类问题。

第一类是价格格式。有的平台展示"1999.00"、有的展示"1,999"、还有的会有"券后价1980"和"原价2199"两套价格，统一换算成浮点数并标注价格类型。第二类是商品标题。同一个商品在两个平台的标题写法差异很大，有的带促销语、有的带规格信息，要做一个简单的关键词归一，把"官方标配""限时特惠""爆款直降"这类营销词清洗掉，保留核心商品名、品牌名和规格信息。第三类是去重。同一平台内部可能出现同一个商品被多次收录的情况，用商品链接的标准化 URL 作为唯一标识能解决大部分重复问题。第四类是缺失处理。有些商品没有店铺信息或者没有销量数据，统一填充为"未知"或 0，不要留空字符串，避免后面统计时出现意想不到的类型错误。

清洗逻辑放在采集入库之前跑一遍，同时把清洗前后的记录数、异常类型数量打出来，这样论文里写"数据预处理保障了数据质量"的时候也有实际数据支撑，不是空话。

4. 数据存储与可视化展示

4.1 表结构设计：三张核心表足够用

存储设计上不要贪多，三张核心表就能撑起整个项目，分别是平台表、商品表、价格历史表。平台表记录平台编码和平台名称，比如京东、淘宝这两条基础数据。商品表是最核心的表，字段包括商品 ID、标题、品牌、规格、所属平台、商品链接、销量、当前价格、图片地址、抓取时间。价格历史表记录每次采集到的价格快照，字段是商品 ID、价格、采集时间、采集来源。

商品表和价格历史表之间是一对多的关系，一张商品对应 N 条历史价格记录。这个设计是整套系统的地基，因为后面所有跟价格趋势相关的功能都得从历史表取数。我记得早期做的时候图省事，把价格直接更新在商品表里，没有单独建历史表，结果要做降价提醒和 30 天走势图时完全没有数据可用，只能推倒重来。所以这里特别强调一句：比价系统的核心资产不是商品信息，而是价格随时间变化的历史记录。表结构设计时建议把抓取时间字段加上普通索引，后续查询某段时间的价格区间会快很多。

4.2 可视化指标体系与页面布局

可视化看板是毕业设计展示的门面，这一块的指标选择决定了演示时给人的第一印象。我的建议是围绕"对比"这个核心动作来设计，而不是堆一堆没关联的图表。核心指标分四块：同款商品跨平台价格对比用柱状图，一眼看出哪个平台便宜；同一商品 30 天价格走势用折线图，同时标注出当前价格参考线；搜索商品的平台价格分布用散点图或者箱线图，展示同一品类在不同平台的价格带宽；降价幅度排行用列表，挑出最近一周降幅最大的几件商品。

页面布局上，顶部是搜索框和筛选条件，中间部分用一个大尺寸的横向柱状图承载同款对比的结果，下方左侧放价格走势折线图，右侧放降价排行列表。这个布局的逻辑是"先看差异、再看趋势、最后看机会点"，演示时从搜索到分析结论可以一条线讲下来，节奏顺滑。

数据接口方面，Flask 端只需要暴露三个接口就能覆盖看板需求：商品搜索接口、价格对比接口、价格历史接口。前端页面通过 fetch 调用接口，拿到 JSON 数据后交给 ECharts 渲染。ECharts 的配置本身不难，主要注意两点：一个是图表的容器 div 要有明确高度，不然图表不渲染；另一个是后端返回的字段名要和 ECharts 的 data 字段严格对应，最好是后端直接返回格式化好的 series 数据，前端不要做太多二次处理。

4.3 前后端交互与页面渲染模式

Flask 这边的显