企业官网建设流程全解析

每年毕业季都会有大量"XX管理系统"的题目出现，但真正能在答辩现场让评委眼前一亮的，往往是那种既体现技术广度、又有完整业务闭环的选题。今天想聊聊"基于Python与机器学习的淘宝商品数据分析可视化系统"这套源码和设计思路——它把Selenium爬虫、数据仓库、机器学习、Echarts可视化、Vue.js前端全部串在一条链路上，做出来的是一个能讲完整故事的毕业设计，而不是孤立的CRUD页面。整篇文章我会按设计思路、技术选型、核心实现、踩坑实录四个部分展开，适合正在选型或已经选了这类题目的同学直接参考。

先给大家交个底：这套系统最终形态是一个Web应用，用户可以输入商品关键词，系统自动爬取电商平台的商品列表数据，经过清洗、存储、建模分析之后，用大屏图表展示价格分布、销量趋势、评论情感、品牌占比等维度。如果你是准备毕业设计，或者想系统入门数据采集与分析这条链路，这篇文章能帮你少走至少两周的弯路。

1. 系统整体设计与选题思路

做这类系统，最大的误区是一上来就写代码。很多同学拿到题目之后先去研究Selenium语法、Echarts配置，结果做到一半发现架构乱成一团，爬虫数据没有地方放，机器学习模型接不进去，前端图表和后端接口对不上。我建议先把整体设计想清楚，再动手。

1.1 这个题目为什么值得做

"淘宝商品数据分析"这个方向在计算机毕业设计里属于性价比很高的选题，原因在于它覆盖了数据采集、数据存储、数据分析和数据可视化四个核心环节，任何一个环节都能单独拿出来讲技术点。

更重要的是，这套系统的业务逻辑非常清晰：用户关心的是"某类商品在市场上卖得怎么样"，系统给出的答案是"价格集中在什么区间、哪个区间的商品销量最好、用户评论的总体情绪偏正面还是负面"。这种"输入关键词，输出分析报告"的交互模式，比单纯做一个后台管理系统的演示效果强很多，答辩的时候也更容易陈述。

另外，机器学习在这个系统里不是强行凑上去的，它能真实处理三个问题：商品评论的情感倾向判断、商品价格区间聚类、基于历史数据的销量趋势预测。每落一个算法都能对应具体的业务场景，评委问起来也解释得清楚。

1.2 系统架构与技术栈梳理

整套系统我按分层思想拆成四层：

• 数据采集层：Python + Selenium，模拟浏览器行为，采集商品列表、价格、销量、评论等公开页面数据
• 数据存储层：MySQL 做数据仓库的主存储，按照ODS、DWD、ADS分层建模
• 数据分析层：Pandas做清洗转换，scikit-learn做机器学习建模，jieba做中文分词
• 可视化展示层：Vue.js 搭建前端页面，Echarts负责图表渲染，后端用Flask/FastAPI提供JSON接口

用一张典型的数据流来说明：Selenium采集到的原始HTML经过BeautifulSoup解析，转成结构化DataFrame，Pandas完成去重、缺失值处理、价格单位统一之后写入MySQL的ODS层；再用SQL做聚合计算，把结果落到ADS层供API调用；前端请求API拿到JSON数据后，由Echarts渲染成图表。整条链路是通的，每一层都有产物，这也意味着论文的每一章都有实际内容可以写。

1.3 功能模块划分与数据流设计

实际操作中，我把系统拆成了5个功能模块：

• 商品采集模块：支持按关键词搜索商品，可配置采集页数
• 数据管理模块：查看采集历史、清洗结果、数据量统计
• 分析建模模块：展示价格聚类、情感分析、销量预测的结果
• 可视化看板模块：核心大屏，汇总所有图表
• 系统管理模块：关键词任务管理、爬虫运行日志

数据流设计上有一处容易被忽略：爬虫采集的数据不建议直接提供给前端，而必须经过"采集->清洗->入仓->聚合->出接口"这套流程。原因是爬虫拿到的原始数据质量参差不齐，同一个商品在不同页面可能重复出现，价格字段可能是"¥129.00"含单位，评论数可能为空，这些脏数据不处理，后面机器学习模型的效果会非常差。

数据仓库分层这块，很多人会问：毕业设计有必要搞ODS、DWD、ADS吗？我的回答是有必要，哪怕数据量不大也要在结构上体现分层的意识。ODS层存放原始数据，与原页面保持一致；DWD层做清洗和标准化；ADS层面向业务需求输出指标数据。这个设计在答辩时是一个重要的加分点，因为评委能看到你不仅会写SQL，还懂数据建模的规范。

2. 核心方案选型与关键原理

方案选型是整个项目的前期重点。很多同学会在一些细节上反复纠结，比如用不用Docker、要不要上Redis、前端选Vue2还是Vue3。我的建议是从"能稳定跑通"和"答辩够讲"两个角度去做选择，不要为了炫技引入太多组件。

2.1 数据采集：Selenium爬虫方案为什么比纯requests更靠谱

采集电商平台商品数据，最常见的有requests+解析和Selenium模拟浏览器两种方案。对这类项目，我更推荐Selenium。

核心原因在于电商平台的页面大量使用JavaScript动态渲染，部分接口还有加密参数——直接用requests很难构造出合法的请求参数，而Selenium通过真实浏览器内核执行渲染流程，拿到的就是浏览器最终呈现的完整页面数据。

另外，电商平台普遍有反爬策略，比如账号登录校验、滑块验证、IP频率限制。Selenium配合浏览器指纹伪装、随机延迟、人工操作模拟，能够显著提高采集的稳定性。

当然，Selenium也有明显缺点：速度慢、资源占用高。一次采集几百条商品数据，可能需要好几分钟，但这对于毕业设计的演示场景来说完全够用。如果追求更高性能，可以改用Playwright，但引入新工具会增加学习成本，Selenium的生态文档和案例在毕业设计里更有保障。

这里要单独提醒一点：爬虫必须遵守网站的robots协议和法律法规，采集数据仅用于学习研究，不能用于商业用途。毕设演示时控制好采集频率和规模，不要对目标网站造成压力。千万别为了展示技术去绕过反爬机制，这不是技术水平问题，是边界问题。

2.2 数据仓库：从采集到分析的数据分层设计

很多同学把MySQL当成简单的存储，建一张表把所有字段塞进去，这在小项目里能用，但一旦涉及多维度分析和机器学习训练，数据管理就会混乱。

我的项目里采用的是简洁的三层建模方案。ODS层是一张宽表，承载爬虫采集出的原始字段：商品标题、价格、原始价格、销量、店铺名、店铺所在地、商品链接、图片链接、评论数、好评率、评论内容快照等。这一层的特点是"有什么存什么"，不做太强的清洗。

DWD层做标准化处理，核心工作包括：价格统一转为浮点数，去除单位字符；空评论数按0填充；商品标题去除多余空格；重复商品通过链接去重；对评论内容做基础清洗和分词。DWD层的表结构比ODS更干净，是机器学习建模的输入来源。

ADS层则是面向前端展示的聚合结果：比如按价格区间统计的商品数量分布、按销量区间统计的商品平均价格、按评论情感分组统计占比等。这些数据直接通过API返回给前端展示，查询效率高，图表绘制也简单。

这种设计的另一个好处在数据回填。如果后续想增加新的分析维度，不需要重新跑爬虫，只需要在DWD层或ADS层写新的SQL处理逻辑即可，原始数据还在ODS层躺着，随时可回溯。

2.3 机器学习：商品数据分析里的算法选择

这个题目里的"机器学习"环节往往是最容易被挑战的地方。开题时我见过不少同学写"用神经网络预测商品销量"，这在高性能GPU条件下可行，但在普通笔记本跑电商评论数据，效果往往很差，答辩现场容易翻车。

我最终选用了三个常规但有效的场景：

第一个是商品价格聚类，采用KMeans算法。输入是商品价格、销量、评论数的标准化特征，聚类结果能自动把商品划分成低端、中端、高端三个价格档位。这种无监督学习有直观的可视化效果，用Echarts散点图按聚类结果着色，非常直观。

第二个是评论情感分析，这是一个二分类（正面/负面）任务。我先用已有的中文情感词典做一轮初步判定，再用TF-IDF把评论文本转成特征向量，最后用逻辑回归或朴素贝叶斯训练分类器。由于毕业设计里手动标注样本量有限，模型精度能够达到一个合理水平即可，没必要追求98%以上的准确率。

第三个是销量趋势预测，如果用真实的历史时间序列数据量不大，可以直接采用线性回归或随机森林回归。这里我额外构造了一个辅助特征：把价格、评论数、好评率、商品评分纳入回归模型，观察哪些因素最能影响销量，并用SHAP值解释特征重要性，这在答辩中非常加分。

选算法的原则是"用最小的复杂度解释清楚业务现象"，而不是"把准确率刷得越高越好"。评委想听到的是你为什么选这个算法、业务上有什么含义，而不是听到你堆了一堆深度学习模型但解释不清楚原理。

3. 关键模块的实现过程

下面进入具体实现。我按照实际开发的顺序来讲，也就是先采集、再存储、再建模、最后做前端展示。注意，以下代码是核心部分的示意，完整源码的结构在文末说明。

3.1 爬虫模块：环境准备与核心代码结构

爬虫模块是数据来源，也是最容易出问题的环节。环境准备阶段需要安装Python、Selenium库、Chrome浏览器以及对应版本的ChromeDriver。这里有一个经常踩的坑：ChromeDriver版本必须与Chrome浏览器版本严格匹配，否则会报session not created错误。

采集流程核心代码如下：

from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC import time import random import pandas as pd def start_driver(headless=False): options = webdriver.ChromeOptions() options.add_argument('--window-size=1280,800') options.add_argument('--disable-blink-features=AutomationControlled') options.add_experimental_option('excludeSwitches', ['enable-automation']) if headless: options.add_argument('--headless=new') driver = webdriver.Chrome(options=options) return driver def search_and_scrape(keyword, pages=3): driver = start_driver(headless=False) all_data = [] search_url = f'https://s.taobao.com/search?q={keyword}' driver.get(search_url) time.sleep(random.uniform(2, 4)) for page in range(pages): # 等待商品列表加载 WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.CSS_SELECTOR, '[class*="Content--content"]')) ) items = driver.find_elements(By.CSS_SELECTOR, '[class*="Card--doubleCardWrapper"]') for item in items: try: title = item.find_element(By.CSS_SELECTOR, '[class*="Title--title"]').text.strip() price_text = item.find_element(By.CSS_SELECTOR, '[class*="Price--priceText"]').text.strip() sales_text = item.find_element(By.CSS_SELECTOR, '[class*="Price--realSales"]').text.strip() shop_name = item.find_element(By.CSS_SELECTOR, '[class*="ShopInfo--shopName"]').text.strip() location = item.find_element(By.CSS_SELECTOR, '[class*="ShopInfo--location"]').text.strip() link = item.find_element(By.CSS_SELECTOR, 'a').get_attribute('href') price = float(price_text.replace('¥', '').replace('到手', '').strip()) sales = int(''.join(filter(str.isdigit, sales_text)) or 0) all_data.append({ 'keyword': keyword, 'title': title, 'price': price, 'sales': sales, 'shop_name': shop_name, 'location': location, 'link': link }) except Exception as e: # 单个商品解析失败不影响整体 continue # 翻页并随机延迟，模拟人类行为 try: next_btn = driver.find_element(By.CSS_SELECTOR, 'button[class*="next-btn-next"]') next_btn.click() time.sleep(random.uniform(3, 6)) except: break driver.quit() df = pd.DataFrame(all_data) df.to_csv(f'raw_data_{keyword}.csv', index=False, encoding='utf-8-sig') return df

这里有几个细节值得注意。第一，选择器建议写成class包含匹配的方式，因为淘宝页面的class名字会不定期变化，用contains匹配能降低更新频率；第二，解析单个商品必须用try/except包住，页面里总有几个卡片结构异常，不能让它们中断整个采集流程；第三，翻页按钮的定位方式要提前在浏览器控制台验证，不同时间页面结构会变。

关于采集频率，我建议每翻一页随机sleep 3到6秒。这不是矫情，是为了降低对目标站点的压力，同时也让采集行为更接近真人操作，减少被反爬策略拦截的概率。

3.2 数据清洗与存储：从CSV到数据仓库

采集到的CSV文件只是中间产物，真正入库之前必须经过清洗。我写了独立的清洗脚本，核心逻辑包括：

import pandas as pd import re def clean_data(df): # 1. 去除完全重复的记录 df = df.drop_duplicates(subset=['title', 'shop_name']) # 2. 清洗价格字段：处理到手价、区间价 def parse_price(x): if isinstance(x, str): nums = re.findall(r'\d+\.?\d*', x) return float(nums[0]) if nums else None return x df['price'] = df['price'].apply(parse_price) df = df.dropna(subset=['price']) # 3. 销量补零 df['sales'] = df['sales'].fillna(0).astype(int) # 4. 截断过长的标题，并去除特殊字符 df['title'] = df['title'].str.replace(r'[^\u4e00-\u9fa5a-zA-Z0-9]', '', regex=True) df['title'] = df['title'].str[:50] # 5. 添加采集日期，便于后续时间维度分析 df['collect_date'] = pd.Timestamp.now().date() # 6. 价格区间的异常值处理（超过3倍四分位距视为异常） q1 = df['price'].quantile(0.25) q3 = df['price'].quantile(0.75) iqr = q3 - q1 df = df[(df['price'] >= q1 - 3 * iqr) & (df['price'] <= q3 + 3 * iqr)] return df

这个清洗流程我有意做了两个决定。第一是价格字段保留到第一位数字，因为"到手价"和原价混在一起时，第一位数字通常是用户实际支付的金额，一致性比精确性更重要。第二是IQR异常值过滤，它能把因为特殊活动出现极低价格、或者标价虚高的异常商品剔除，机器学习建模的时候不会被这些噪声点干扰。

数据入库我用的是MySQL。需要注意Python操作MySQL时，字符串编码统一用utf8mb4，否则商品标题里的emoji表情会报Incorrect string value错误。建表时关键字段建议加上索引，比如keyword、collect_date，这样ADS层聚合查询会快很多，用户体验也更好。

3.3 机器学习分析：价格聚类与评论情感

数据清洗完成之后，进入机器学习环节。我用代码和注释梳理核心流程：

from sklearn.preprocessing import StandardScaler from sklearn.cluster import KMeans import joblib # 价格聚类 def price_cluster(df, k=3): features = df[['price', 'sales']].dropna() scaler = StandardScaler() X_scaled = scaler.fit_transform(features) model = KMeans(n_clusters=k, random_state=42, n_init=10) labels = model.fit_predict(X_scaled) df['price_cluster'] = labels cluster_desc = { 0: '低端价位', 1: '中端价位', 2: '高端价位' } df['price_level'] = df['price_cluster'].map(cluster_desc).fillna('未知') joblib.dump(model, 'models/kmeans_price_model.pkl') joblib.dump(scaler, 'models/scaler.pkl') return df

聚类结果会生成一个值得在论文和答辩中描述的现象：不同关键词的聚类分布差异很大。"手机壳"这类商品价格聚集在9.9到30元之间，高端组占比极低；而"机械键盘"类商品中端和高端组占比明显上升。这个发现本身就说明关键词的商业价值差异，是很好的分析结论。

评论情感分析部分，我用的方案是根据评论文本做分词，结合TF-IDF向量化，再训练朴素贝叶斯分类器。核心代码：

import jieba from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.naive_bayes import MultinomialNB def tokenize(text): return ' '.join(jieba.cut(text)) def train_sentiment_model(df): # df需要包含review_text和sentiment两列 df['cut_text'] = df['review_text'].apply(tokenize) vectorizer = TfidfVectorizer(max_features=5000) X = vectorizer.fit_transform(df['cut_text']) y = df['sentiment'] model = MultinomialNB() model.fit(X, y) joblib.dump(vectorizer, 'models/tfidf_vectorizer.pkl') joblib.dump(model, 'models/sentiment_model.pkl') return model, vectorizer

这里有个非常实用的经验：直接拿原始评论文本训练，模型很难收敛，一定先分词。jieba本身就支持中文分词，用它把句子切词后以空格分隔再交给TfidfVectorizer，效果立竿见影。

对于中文NLP任务，我建议用逻辑回归或朴素贝叶斯而非集成模型。原因是评论文本经过TF-IDF转换后是稀疏高维矩阵，朴素贝叶斯在稀疏数据上处理快且不容易过拟合，逻辑回归效果也不错且更易解释。随机森林在这种场景下反而容易在少数类别上失效。

3.4 可视化大屏：Vue.js与Echarts的前端展示

可视化的选题和实现，是整个系统最直观的门面。我选用Vue.js加Element UI搭前端框架，用Echarts做图表渲染，理由很简单：Echarts是国内开源社区最成熟的可视化库，中文文档齐全，示例丰富，且对Vue的适配方案成熟。

大屏的整体布局是顶部标题栏加统计数字，中间走图表网格，左侧放价格分布和销量趋势，中上放核心指标卡片，中下放商品价格分区散点图，右侧放品牌占比和评论情感分析。这套布局在演示时一眼能看到系统全貌。

关键图表的核心配置示例，比如价格分布直方图：

const chart = echarts.init(document.getElementById('distributionChart')); chart.setOption({ title: { text: '商品价格分布', left: 'center' }, tooltip: { trigger: 'axis' }, xAxis: { type: 'category', data: priceRanges }, yAxis: { type: 'value', name: '商品数量' }, series: [{ type: 'bar', data: counts, itemStyle: { // 用渐变增强视觉效果 color: new echarts.graphic.LinearGradient(0, 0, 0, 1, [ { offset: 0, color: '#3b82f6' }, { offset: 1, color: '#93c5fd' } ]) } }] });

Echarts配置有几个容易踩的细节。第一，数据从后端接口拿到之后一定确认字段类型，很多图表不显示是因为拿到的price是字符串导致排序和区间聚合异常；第二，折线图的x轴刻度如果显示不全，需要设置axisLabel的interval为0或者进行旋转；第三，中国地图类图表如果后面选用，需要单独引入geo数据，这个在使用Echarts时是很常见的出错点。

后端接口我用Flask实现，暴露以下核心接口：

• /api/overview：返回商品总量、平均价格、总销量等统计卡片数据
• /api/price_distribution?keyword=xxx：价格区间商品分布
• /api/cluster_scatter：价格聚类散点数据
• /api/sentiment_analysis：评论情感占比
• /api/sales_prediction：销量预测结果与影响因素

Vue.js端用axios请求接口，拿到数据后更新图表配置。要特别处理Vue生命周期，建议在mounted阶段中this.$nextTick里初始化图表，确保DOM已经渲染完成。

3.5 前后端联调与部署

前后端联调是我觉得最容易出问题的环节。刚开始经常遇到前端请求跨域失败，后来我统一在后端配置了CORS，并且在Vue的vue.config.js里设置了开发环境代理：

module.exports = { devServer: { proxy: { '/api': { target: 'http://127.0.0.1:5000', changeOrigin: true } } } }

这样做的好处是开发时前端请求相对路径/api，不用每次改接口地址。联调时还有一个隐藏问题：Flask返回的数据中，Numpy的float类型不能被json.dumps直接序列化。我的解决办法是把所有数值统一转成Python原生类型再返回，否则前端会报JSON解析错误。

部署到生产环境时，我用简单的方案：后端用Gunicorn启动Flask，前端npm run build生成静态文件后由Nginx托管，并统一反向代理到后端服务。这个部署链路很容易讲解，也是答辩演示时最能体现工程能力的地方。

4. 常见问题与排查技巧实录

做这类项目最大的时间消耗不是写功能，而是排查问题。下面我把实际遇到过的、能复现的典型问题整理出来，每一个都给到了排查路径和最终解决办法。

4.1 Selenium爬虫相关的典型问题

ChromeDriver版本不匹配是个高频问题。错误信息通常是"session not created: This version of ChromeDriver only supports Chrome version 114"，解决办法很简单：去ChromeDriver官网下载和你本机浏览器主版本完全相同的驱动，替换后重启。

第二个问题是元素定位失败。淘宝页面经过改版，class名经常带随机后缀。我前面代码里用的都是contains匹配方式，能一定程度上规避。如果还定位不到，优先在浏览器开发者工具中用元素的唯一父级节点做定位，不要写太长的绝对路径。

第三个问题是页面无法自动翻页。有的情况下翻页按钮不是常规button，而是div或aria属性标识。排查时先在浏览器控制台验证document.querySelector是否命中，确认以后再同步到Selenium脚本。这里还有一个小技巧：如果目标网页在无头模式翻页异常，可以暂时关闭无头模式调试一次，多半是窗口大小或字体渲染问题，而不是代码逻辑问题。

4.2 数据仓库和编码问题

MySQL写入商品标题报"Incorrect string value"是一个很常见的问题。根源是数据库或表字符集不是utf8mb4。解决办法一并转换：

ALTER DATABASE taobao_analysis CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE product_info CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

如果数据量到达十几万级别，建议给keyword和collect_date建联合索引。我在没有索引时，按关键词聚合一次查询要将近2秒，建索引之后降到几十毫秒。另外，清洗后的数据不要直接覆盖原始表，保留ODS原始表能给排查建模问题提供回溯依据。

4.3 机器学习模型效果不理想

情感分析模型如果准确率低于70%，优先检查训练数据的标注质量。我最初用算法自动标注的样本做训练，结果模型只有65%的准确率。后来改为人工精选了500条正负样本，重新训练后准确率提升到82%。在数据量有限的前提下，高质量标注比增加样本量更重要。

KMeans聚类如果出现聚成一团的情况，通常是特征标准化没做。标准化是聚类的前提，价格和销量的量纲差异太大，不标准化会导致销量在距离计算中占绝对主导。另一个经验是，初始聚类数K不一定选3，可以通过轮廓系数来验证K值，但毕业设计演示场景我仍然建议固定为3档，因为三档的用户解释成本最低。

4.4 前端图表与联调问题

Echarts图表不显示的排查经验，我总结了一个排查顺序：先看Network请求是否返回数据，再看控制台是否有Echarts报错，确认DOM容器的高度是否被设置为0。很多图表"不显示"其实是容器高度为0，因为父级div没有设置高度。每个图表容器显式设置height值，问题即可解决。

折线图x轴刻度显示不全的问题，我最终用了axisLabel的interval: 0和rotate: 30组合解决。如果标签还是重叠，就对x轴数据做抽样展示，而不是强制全部显示。

4.5 答辩与文档经验

答辩演示时最容易翻车的点是数据是新采集的，结果和论文截图对不上。我的建议是提前用同一组关键词和固定日期采集数据，并把关键图表截图存档。真正演示的时候即使现场采集失败，也可以切到存档的数据集，保证答辩流程完整。

论文写作方面，重点不是贴代码，而是讲清楚"为什么这么设计"。我在论文里特别写了技术选型的对比小节，比如为什么用Selenium而不是requests、为什么用聚类而不是分类、为什么用Echarts而不是Highcharts。这些对比内容不需要很长的篇幅，但要有理有据，评委看到的是你的思考过程。

文档结构上，建议按照"选题背景-系统需求分析-系统设计-系统实现-系统测试-总结展望"的顺序来写，把数据仓库的ER图、爬虫流程图、系统部署结构图放上去。图不一定要精美，但必须规范完整。

5. 系统的扩展方向与个人经验小结

这套系统做完主体功能之后，我还顺手补了两个扩展点，个人觉得对综合作品质量和答辩效果都有帮助。

第一个扩展是词云图。我把采集到的商品标题做成词云展示，利用jieba分词提取高频词，填充进Echarts的WordCloud组件中。"手机壳"的高频词会集中在"苹果""硅胶""透明""防摔"等词汇上，一眼就能看出该类商品的核心卖点。词云图虽然实现简单，但视觉冲击力强，放在大屏的角落在演示时很亮眼。

第二个扩展是增加了数据采集的历史趋势折线。通过定时任务每天采集一次商品数据，观察一周内商品价格和销量的变化。这在毕设周期内可能数据不够完整，但你可以提前跑几天积累数据，答辩时展示"系统具备持续采集能力"这个特性，比只展示一次采集结果更有说服力。

就我个人实际操作中的体会而言，这类数据采集加可视化系统最难的不是单个技术点，而是把各模块串起来并且保证整体稳定性。技术层面只要按"爬取-清洗-存储-分析-展示"这条主线走，每个环节做好产物输出，整体完成度就会很高。前期规划时宁可多花几天把架构图画清楚，也不要急着把代码跑起来。代码出问题了随时能改，架构定错了返工成本特别高。

如果你正打算做这个题目，我的建议是先跑通最小闭环：爬一个关键词、清洗入库、做一个最简单的柱状图。有了这个最小闭环，后续的每一个技术点都是在这个基础上做加法。压力最大的是第一周爬虫部分，这个卡点过了之后，后面基本是顺水推舟。

最后再分享一个小技巧：所有模型文件、向量器、标准化器的保存命名规范要提前设计好，我用的统一规则是模型类型加业务名称加时间戳，比如kmeans_price_model.pkl、tfidf_vectorizer.pkl。规范命名能让你在模型迭代和文档写作时省出大量时间，不至于每次都要四处找文件。

这篇内容到这里基本结束，但不代表这个项目的终点。后面可以考虑的方向还有：接入更多的数据源做对比分析、引入消息队列实现分布式采集、把可视化大屏整合进移动端。每个方向都是独立的扩展课题，也都是很好的论文素材。希望这篇实操拆解对正在做选题规划的你有点实际的帮助。