企业官网建设流程全解析

1. 项目概述：这个系统到底解决什么问题

先说结论：这套电商农产品销售预测系统，本质上是一条完整的「数据采集 → 数据清洗 → 特征工程 → 机器学习建模 → 可视化展示」流水线。标题里那串关键词“大数据爬虫 + Python + 机器学习”不是堆技术名词，而是三个层层递进的环节：爬虫负责把电商平台上的农产品销售数据抓下来，Python 负责中间所有的数据处理和业务逻辑编排，机器学习则负责从历史数据里找出“什么因素在影响销量”的规律，并以此预测未来一段时间的销售走势。

这类项目在毕业设计里出现频率很高，原因是它覆盖面广但又不空洞：爬虫涉及网络请求、解析、反爬应对，机器学习涉及回归/时序建模、特征工程、模型评估，后端还要做 API 接口，前端还能接可视化大屏——每一个模块都有足够的深度可以挖，组合起来又是一个完整的闭环，答辩时讲起来非常有层次感。

对想参考这套方案的人来说，它的价值不在于“我用了 XGBoost 所以很高级”，而在于它完整展示了从零到一搭建一个数据应用的全过程。你拿去改一改，换一个垂直领域（比如服装、数码、生鲜），整个架构依然成立。这就是“精品源码”四个字真正的意义：不是代码写得多么花哨，而是工程结构清晰、模块解耦、逻辑可复用。

我个人建议，拿到这类项目后不要急着跑起来，先花半天把三样东西理清楚：数据从哪来、预测什么、预测给谁用。这三件事想明白了，后面所有的代码都是在落实这三句话。下面我就按这个思路，把整个系统的设计和实现逐层拆开讲。

2. 系统整体架构与设计思路拆解

2.1 分层架构：为什么把系统拆成四层

这套系统在设计上采用了经典的分层架构，自然划分成四个层级：数据采集层、数据存储层、算法建模层、业务展示层。每一层都有明确的职责边界，层与层之间通过标准化的数据格式通信，而不是互相调用内部方法。

• 数据采集层：负责从目标电商平台抓取农产品的商品标题、价格、销量、评论数、上架时间、店铺评分、产地等原始字段。
• 数据存储层：把采集到的非结构化数据清洗、去重、转换后写入 MySQL 或 SQLite，同时把一些中间结果缓存到 CSV/Parquet 文件中。
• 算法建模层：从数据库读取历史销量数据，做特征工程，训练销量预测模型，输出未来 N 天的预测值。
• 业务展示层：通过 Flask/FastAPI 提供后端接口，前端页面以图表形式展示历史趋势、预测结果、特征重要性排名等信息。

这么拆的好处，用大白话说就是“各管各的，坏了不牵连”。爬虫那边被封了 IP，不影响你已经存好的历史数据；模型训练速度慢，不影响前端页面展示已经算好的结果。对毕设来说，这意味着你可以分模块写、分模块调试、分模块讲，答辩的时候思路清楚，不会被一句话问倒。

2.2 技术选型：为什么用 Python 而不是 Java 或 Node.js

选 Python 做这个项目基本没有悬念，原因有三条。

第一，爬虫生态成熟。requests、Scrapy、BeautifulSoup、lxml 这些库用起来非常顺手，写一个能跑的单页爬虫只需要几十行代码。Java 也有 HttpClient 和 Jsoup，但代码量明显更多，对于毕设这种时间有限的项目，Python 的开发效率占了绝对优势。

第二，机器学习生态无可替代。scikit-learn、XGBoost、LightGBM、TensorFlow/PyTorch，这些库的 Python 接口是最全的，资料也最多。你遇到任何一个模型报错，搜索引擎里几乎都能找到现成的解决方案。用其他语言做机器学习不是不行，但调试成本和学习成本都会高很多。

第三，Python 胶水语言的特性让前后端衔接非常自然。你可以用 pandas 做数据处理，用 joblib 保存模型，再用 Flask 写一个 /predict 接口，整个过程都在同一个语言环境里完成，不需要跨语言通信。

当然，Python 也有短板，主要就是运行效率。但在这个场景里，训练数据量撑死几万条，模型也就几秒钟的训练时间，性能瓶颈完全可以忽略。我相信有人会问：“大数据场景用 Python 会不会太慢？”这里要澄清一下：项目名里的“大数据”更多是教学意义上的“相对海量的数据”，不是真正意义上的 TB 级分布式大数据。真到了那个量级，你会需要 Spark 或 Flink，但那是另一个故事了。对这个项目而言，Python 单机处理完全够用，而且更容易讲清楚思路。

2.3 核心链路：数据如何一步步变成预测结果

整个系统的核心链路可以概括为六个步骤，每一步的产出是下一步的输入，形成一个单向数据流：

1. 爬虫定时抓取各电商平台的农产品商品页数据，保留原始 JSON/HTML；
2. 数据清洗脚本对原始数据进行去重、缺失值补齐、格式统一，输出标准化表格；
3. 基于标准化表格做特征工程，构造历史销量序列、价格变化率、评论情感分、促销标记等特征；
4. 按时间顺序划分训练集和测试集，防止未来数据泄露到训练过程中；
5. 训练多个候选模型（线性回归、随机森林、XGBoost），用 RMSE 和 MAPE 做对比评估，选出最优模型；
6. 将最优模型序列化保存，后端接口接收商品 ID 和预测天数，返回预测销量和置信区间。

这里尤其要注意第 4 步。很多新手做时间序列预测时容易犯一个错误：随机打乱数据再划分训练集和测试集。这在普通分类任务里没问题，但在销售预测里是致命的——因为时间序列数据有先后依赖关系，用未来数据训练、过去数据测试，得到的评估指标会虚高得离谱，但一上线就现原形。正确的做法是严格按照时间顺序切分，比如前 80% 的时间做训练，后 20% 的时间做验证。

3. 爬虫模块：从零抓取电商农产品数据的完整方案

3.1 爬虫选型：requests + BeautifulSoup 还是 Scrapy

这个项目里的爬虫模块，我的建议是：单页抓取用 requests + BeautifulSoup，如果后续要扩展到多个分类甚至多个平台，再上 Scrapy。为什么从 requests 开始？因为它足够轻量，调试方便，每一步都能看到中间结果，对初学者非常友好。

一个完整的 requests 爬虫逻辑模板大概长这样：

import requests from bs4 import BeautifulSoup import time import random headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36", "Referer": "https://www.example.com/", "Accept-Language": "zh-CN,zh;q=0.9" } def fetch_page(url, retries=3): for i in range(retries): try: resp = requests.get(url, headers=headers, timeout=10) if resp.status_code == 200: return resp.text except Exception as e: print(f"[WARN] 第{i+1}次请求失败: {e}") time.sleep(2 ** i) # 指数退避 return None def parse_product(html): soup = BeautifulSoup(html, "lxml") items = [] for tag in soup.select(".product-item"): title = tag.select_one(".title").get_text(strip=True) price = float(tag.select_one(".price").get_text(strip=True).replace("¥", "")) sales = tag.select_one(".sales").get_text(strip=True) items.append({"title": title, "price": price, "sales": sales}) return items

这段代码里有几个细节值得展开说一下：

• time.sleep(2 ** i)是指数退避重试，第一次失败等 2 秒，第二次等 4 秒，第三次等 8 秒。这比固定等待更聪明，既能应对临时网络抖动，又不至于在服务端已经封锁的情况下白白浪费时间。
• resp.status_code == 200只是最基本的校验。真实场景里，很多反爬策略会返回 200 但内容是一个验证码页面。更稳妥的做法是检查返回内容里是否包含预期关键词，比如if "product-item" not in resp.text: 触发告警或切换代理。
• headers 里的 Referer 字段容易被忽略，但有些平台会校验这个字段来判断请求是否来自站内跳转。补上 Referer 能显著降低被拦截的概率。

3.2 反爬对抗：不是硬碰硬，而是想办法礼貌地拿数据

写爬虫绕不开反爬，但很多人的应对方式过于激进，比如疯狂换 IP、高频请求、绕过登录验证——这些做法不仅容易触发更严厉的封锁，而且有合规风险。我的建议是，把反爬应对当成“如何在规则内把数据拿全”的问题来解，而不是“如何攻破对方防线”。

常用的温和对抗方案有这几种：

• 控制请求频率：在两次请求之间加随机延时，让请求节奏接近人工操作。比如time.sleep(random.uniform(1.5, 3.5))，既不像固定 2 秒那么容易被识别，又能保证单位时间内的抓取量。
• 请求头伪装：随机切换 User-Agent，甚至可以维护一个 UA 池，每次请求随机取一个。浏览器的真实 UA 通常在Mozilla/5.0 ... Chrome/xxx这样的格式，可以提前收集十来个常用 UA。
• 代理 IP 池：当单 IP 请求频率触顶时，使用代理池轮换 IP。付费代理质量更稳定，但毕设阶段用免费代理池（比如从公开代理源爬一些高匿名代理）也足够演示。
• 接口优先：很多电商平台的数据其实是通过内部 API 接口返回 JSON 的，直接在页面上搜索api关键字找到数据接口，请求接口拿 JSON 远比解析 HTML 简单高效。这个问题你可以在浏览器开发者工具里点开 Network 面板，刷新页面后筛选 XHR 请求，很容易找到真正的数据来源。

这里我想多说一句：如果你是毕设用途，建议优先选择那些提供了开放数据或者无严苛反爬政策的平台，比如一些地方政府开放的农产品批发价格数据、某电商平台的免费榜单接口。数据来源的合规性，不仅是技术问题，也是你在答辩时面对老师提问的底气。

3.3 并发设计：单线程、多线程还是协程

爬虫抓取农产品数据，如果只抓几百条，单线程绰绰有余。但如果要抓几十个品类、每个品类几十页，单线程的速度就会变得非常感人。这时候就需要考虑并发。网上关于“爬虫并发设计到底哪个好”的讨论很多，我的结论很明确：IO 密集型任务用协程，计算密集型任务用多进程，混合场景用多线程做兜底。

电商爬虫是典型的 IO 密集型任务——绝大多数时间都花在网络等待上，CPU 基本闲着。这种情况下，使用asyncio + aiohttp的协程方案，单进程可以同时发起几十上百个请求，效率远高于多线程（因为线程切换有额外开销）。下面是一个简单的协程爬虫片段：

import asyncio import aiohttp async def fetch(session, url): try: async with session.get(url, timeout=10) as resp: return await resp.text() except Exception as e: print(f"[ERROR] {url}: {e}") return None async def main(urls): async with aiohttp.ClientSession() as session: tasks = [fetch(session, url) for url in urls] return await asyncio.gather(*tasks) if __name__ == "__main__": urls = [f"https://example.com/page/{i}" for i in range(1, 51)] htmls = asyncio.run(main(urls))

使用协程时有一个注意点：你仍然要控制并发上限，否则服务器会因为瞬时请求过多而直接封掉你的 IP。常见的做法是用asyncio.Semaphore限制同时进行的请求数，比如sem = asyncio.Semaphore(10)，在fetch函数里先async with sem:获取信号量再发请求。

3.4 数据清洗与存储：脏数据不处理，后面模型再好也白搭

爬虫拿到原始数据后，千万别急着灌进数据库。电商平台的数据质量参差不齐，常见的问题包括：

• 销量字段带“万+”后缀，比如3.2万+，需要转换成整数 32000；
• 价格字段混入“¥”符号和空格，需要提取数字部分；
• 同一件商品在多个页面重复出现，需要按商品 ID 或标题去重；
• 部分字段缺失，比如评论数为空，需要用默认值或均值填充；
• 商品标题含有各种营销修饰词（“爆款”“限时秒杀”），对建模可能是噪声，需要文本清洗。

清洗这一步用 pandas 非常方便。核心代码大概是：

import pandas as pd import re df = pd.read_csv("raw_products.csv") # 清洗销量字段："3.2万+" -> 32000 def parse_sales(s): if isinstance(s, str): if "万" in s: return int(float(re.sub(r"[^\d.]", "", s)) * 10000) return int(re.sub(r"\D", "", s)) return 0 df["sales_num"] = df["sales"].apply(parse_sales) # 清洗价格字段："¥29.9" -> 29.9 df["price_num"] = df["price"].apply(lambda s: float(re.sub(r"[^\d.]", "", s)) if isinstance(s, str) else 0.0) # 去重 df = df.drop_duplicates(subset=["product_id"]) # 删除销量、价格合理范围之外的数据（如销量<0、价格>100000） df = df[(df["sales_num"] >= 0) & (df["price_num"] > 0) & (df["price_num"] < 100000)] df.to_csv("cleaned_products.csv", index=False)

清洗完成后，数据写入 MySQL 表或者直接用 CSV 存起来都行。毕设阶段如果没有特殊要求，我倾向于存 CSV/Parquet，因为读写快、不依赖数据库环境。但如果你要展示“大数据存储”能力，就上 MySQL：建一张product_info表、一张daily_sales表，通过外键关联。答辩时可以说“采用 MySQL 关系型数据库存储清洗后的结构化数据，支持多表关联查询”，这个表述比“我用 CSV 存了一下”要专业得多。

4. 特征工程与机器学习建模：预测的核心环节

4.1 预测目标定义：是回归问题还是时间序列问题

拿到清洗后的数据，第一步不是急着训练模型，而是先定义清楚：你要预测什么？

通常有两种选择。第一种是预测未来某一天的销量，这是一个回归问题，输入是过去 N 天的特征，输出是一个具体数值。第二种是预测未来 N 天的销量走势曲线，这是一个时间序列问题。对毕设来说，我建议做前者——实现简单、评估清晰，而且答辩时更容易讲清楚。

假设我们按“过去 7 天预测未来 1 天”的方法构造样本，那核心特征可以包括：

• 历史销量特征：过去 1/3/7/14/30 天的平均销量、最大值、最小值、标准差；
• 时间特征：星期几、是否节假日、是否电商大促日（双 11、618）、月份；
• 价格特征：当前价格、近 7 天价格变化率、价格相对于历史均价的偏离度；
• 外部特征：商品好评率、评论数、店铺评分、商品所属二级类目。

这里的“窗口滑移”是一个必须理解的概念。假设有 100 天的日销量数据，窗口宽度为 30 天，那么可以构造出100 - 30 + 1 = 71个样本。对每个样本，我们用前 30 天的数据生成特征，把第 31 天的销量作为标签。这样每行样本就是一个独立的训练实例。

4.2 算法选型：线性回归、随机森林还是 XGBoost

建模阶段最忌讳的是“一步到位直接上深度学习”。在数据量只有几千条、特征几十个的规模下，深度学习不仅容易过拟合，而且训练耗时、调参复杂。做毕设最稳妥的组合是：线性回归做基线，随机森林做对比，XGBoost 或 LightGBM 做最终选型。

• 线性回归的优势是可解释性极强。你能直接看到每个特征的系数，答辩时可以说“价格每上涨 1 元，预期销量下降约 X 件”这类结论，非常有说服力。
• 随机森林的优势是能捕捉非线性关系，而且几乎不需要特征缩放，对异常值鲁棒。它的feature_importances_属性可以直接输出特征重要性排名。
• XGBoost 在表格数据上通常表现最好，训练速度也比随机森林快（得益于梯度提升和直方图近似），但调参相对复杂。核心超参数包括learning_rate、max_depth、n_estimators、subsample。

以 XGBoost 为例，一个基础训练流程如下：

import xgboost as xgb from sklearn.model_selection import TimeSeriesSplit from sklearn.metrics import mean_squared_error, mean_absolute_percentage_error model = xgb.XGBRegressor( n_estimators=500, learning_rate=0.05, max_depth=5, subsample=0.8, colsample_bytree=0.8, random_state=42 ) # 时间序列交叉验证：严格按时间顺序切分，不允许未来数据进入训练 tscv = TimeSeriesSplit(n_splits=5) for train_idx, valid_idx in tscv.split(X): X_train, X_valid = X.iloc[train_idx], X.iloc[valid_idx] y_train, y_valid = y.iloc[train_idx], y.iloc[valid_idx] model.fit(X_train, y_train, eval_set=[(X_valid, y_valid)], verbose=False) y_pred = model.predict(X_valid) rmse = mean_squared_error(y_valid, y_pred) ** 0.5 mape = mean_absolute_percentage_error(y_valid, y_pred) print(f"RMSE: {rmse:.4f}, MAPE: {mape:.4%}")

评估指标这里单独说一下。RMSE 的量纲和销量一致（比如“日均销量误差约 12 件”），便于直观理解，但对异常值敏感；MAPE 是百分比误差，更直观（“预测误差约为 8.5%”），但在销量接近 0 时会出现极端值。建议两个指标都算，答辩时一起展示，显得更专业。

4.3 特征重要性分析：让模型告诉你什么在影响销量

很多同学做完模型就结束了，忽略了特征重要性分析这一步。其实这一步的“答辩价值”非常大，因为它是连接“机器学习”和“业务理解”的桥梁。

以 XGBoost 为例，训练后直接打印特征重要性：

importance = model.feature_importances_ feat_names = X.columns.tolist() for name, imp in sorted(zip(feat_names, importance), key=lambda x: x[1], reverse=True)[:10]: print(f"{name}: {imp:.4f}")

通常你会看到历史销量特征（如近 7 天平均销量）重要性排名靠前，节假日特征在农产品场景下也很显著——比如中秋节前后大闸蟹销量激增、春节前水果礼盒销量上涨。这些结论放到论文里，就是“基于数据驱动发现农产品销售的季节性和事件性规律”，比单纯写“我用了 XGBoost 模型”要扎实太多。

还有一个可选操作是画 SHAP 值图。SHAP 能告诉你每个特征对预测结果的正负影响方向，比如“价格变化率上升会显著拉低销量预测值”。但注意，SHAP 库可能需要额外安装，做不做取决于你时间够不够。如果时间紧迫，用自带的feature_importances_就够了。

5. 系统集成：从模型到可用的预测服务

5.1 模型持久化与后端接口封装

模型训练好之后，不可能每次预测都重新训练一遍，所以要序列化保存。最简单的方案是用 joblib 或 pickle 把模型存成文件，后端启动时加载到内存，然后对接收到的请求做实时预测。

import joblib # 训练结束后保存 joblib.dump(model, "sales_model.pkl") joblib.dump(feature_columns, "feature_columns.pkl") # 预测时加载 loaded_model = joblib.load("sales_model.pkl") loaded_cols = joblib.load("feature_columns.pkl")

后端接口用 Flask 写非常简洁：

from flask import Flask, request, jsonify app = Flask(__name__) model = joblib.load("sales_model.pkl") @app.route("/predict", methods=["POST"]) def predict(): data = request.get_json() features = data["features"] # 特征列表，顺序与训练时一致 pred = model.predict([features])[0] return jsonify({"predicted_sales": round(pred, 2)}) if __name__ == "__main__": app.run(host="0.0.0.0", port=5000)

这里有一个“货不对板”很容易踩的坑：预测时传入的特征顺序必须和训练时完全一致。如果训练时的特征顺序是[price, avg_sales_7d, is_holiday]，预测时传成[avg_sales_7d, is_holiday, price]，模型不会报错，但预测结果完全是错的。所以我在保存模型的时候，顺手把feature_columns列表也一起保存，预测前先检查一下特征名是否匹配。

5.2 前端可视化：历史趋势、预测曲线与数据大屏

预测结果的展示，我建议至少包含三个页面/组件：

• 历史销量趋势图：用折线图展示过去 90 天的实际销量，让用户看到数据的波动规律；
• 未来销量预测图：用折线图展示未来 7 天的预测销量，可以把真实值和预测值放在同一张图里对比（如果是回测模式）；
• 特征重要性排名图：用横向柱状图展示影响销量的 Top10 特征。

图表开源库选择上，前端用 ECharts 是最合适的。它支持丰富的交互、中文文档完善、开箱即用。如果后端渲染，也可以用 Python 的 pyecharts，它封装了 ECharts 的能力，可以直接在 Python 里生成 HTML。

如果你想让项目看起来更“大数据”，可以再加一个数据大屏：用几块面板展示实时抓取的商品总数、今日销量总和、价格分布直方图、Top10 热销农产品排行。这些面板的数据都从 MySQL 里查，前端定时轮询刷新。做这一步的投入产出比很高，因为视觉效果非常加分，答辩时老师一眼就能看出你的系统是完整的。

5.3 论文结构与答辩 PPT 的映射关系

很多同学代码写完了，论文却不知从何下手。其实论文结构可以直接照着系统模块来写，每一章对应一个模块，整体逻辑非常顺畅：

• 第一章 绪论：研究背景与意义（农产品电商发展趋势、精准预测的价值）、国内外研究现状、论文组织结构；
• 第二章 相关技术介绍：Python、爬虫技术、机器学习算法、Flask、ECharts；
• 第三章 系统需求分析与总体设计：功能需求、非功能需求、系统架构图；
• 第四章 系统详细设计与实现：爬虫模块、数据处理模块、模型训练模块、可视化模块，每个模块放核心代码 + 截图；
• 第五章 系统测试与结果分析：测试环境、功能测试、模型评估指标对比（线性回归 vs 随机森林 vs XGBoost）；
• 第六章 总结与展望。

答辩 PPT 不用担心，按“背景与意义 → 技术栈 → 系统架构 → 核心模块实现 → 实验结果展示 → 总结”这个顺序做 15~20 页就够。每页不要堆文字，多放架构图、流程图、预测效果对比图。老师提问时，只要你能把“为什么选这个模型”“数据怎么处理的”“预测效果如何评估”这三大问题答清楚，基本就稳了。

6. 常见问题与避坑指南

6.1 爬虫被反爬封锁：症状、排查与应对

• 症状一：请求返回 200，但页面内容里没有商品数据，只有验证码框架或空白。排查方法：打印一段响应内容，人工看看到底返回了什么。
• 症状二：请求返回 403 Forbidden 或 418 I'm a teapot。排查方法：先检查是否带了完整 headers，再降低请求频率；如果仍然 403，考虑换代理 IP。
• 症状三：连续请求几个页面之后，后续所有请求都返回 503。排查方法：大概率是触发了 QPS 限制，需要大幅降低并发数并增加随机延时。

一个非常实用的自查方法是：把浏览器的请求头完整复刻到你的代码里。浏览器能正常访问的页面，你的爬虫带上同样的 headers 通常也能正常访问。如果浏览器访问正常、代码访问不行，那就逐项比对 headers 差异。

6.2 预测结果偏差大：先检查特征而不是模型

模型预测效果差，80% 的原因出在特征工程和数据清洗上，而不是模型参数。我见过太多同学一上来就调 XGBoost 的max_depth和learning_rate，调了半天效果纹丝不动，结果发现问题是“销量字段根本没清洗干净，脏数据全进去了”。

优先检查的清单：

• 训练集里有没有销量为 0 的异常样本？这些样本是不是因为数据缺失被错误填充了？
• 时间特征是否编码正确？比如节假日字段是不是只在节假日当天为 1，而不是前后三天都为 1？
• 是否存在未来数据泄露？比如你用了“当天评论数”去预测“当天销量”，这在逻辑上是成立的，但如果评论数本身是事后统计的，就构成了泄露，上线后数据不可得，模型就会失效。
• 训练集和测试集是否严格按时间划分？这是最常见的坑，没有之一。

6.3 环境与依赖问题：Python 版本冲突怎么办

这个项目的依赖库不少：requests、beautifulsoup4、pandas、scikit-learn、xgboost、flask、pyecharts……Python 版本不同，某些库的安装方式会有差异。建议新开一个虚拟环境，不要直接装在系统全局 Python 里。

python -m venv sales_env # Windows 下激活 sales_env\Scripts\activate # macOS/Linux 下激活 source sales_env/bin/activate pip install requests beautifulsoup4 lxml pandas scikit-learn xgboost flask pyecharts joblib

安装 xgboost 时如果遇到报错，常见原因是 Python 版本太新（比如 3.12），有些库的预编译 wheel 还没跟上。这种情况直接装 CPU 版本：pip install xgboost默认就是 CPU 版，如果报错就换pip install xgboost==2.0.3等旧版本。另一个方案是先用随机森林扛着，答辩演示效果也没差多少，不必死磕一个库。

6.4 答辩高频提问的预设答案

我根据经验总结了答辩时老师最爱问的六个问题，提前准备答案，现场就不慌：

1. 为什么选这个课题？答：农产品电商存在明显的产销信息不对称问题，精准的销量预测可以帮助农户和商家优化备货、减少损耗。
2. 数据量有多大？数据从哪来？答：通过爬虫从 XX 平台采集了近 X 万条商品数据，时间跨度为 X 个月，每天定时增量抓取。
3. 为什么用 XGBoost 不用深度学习？答：当前数据量为万级、特征维度约 XX 个，XGBoost 在中小规模表格数据上精度高、训练快、可解释性强；深度学习需要更大数据量才能发挥优势。
4. 模型评估指标为什么选 RMSE 和 MAPE？答：RMSE 量纲直观，反映绝对误差水平；MAPE 反映相对误差比例，两者结合能全面评估模型（尤其排除销量量纲差异的干扰）。
5. 预测结果如何落地？答：将模型封装成 API 服务，前端可以按日/周维度查询预测结果，后续可扩展为按品类、按地区细粒度预测。
6. 系统有什么不足？答：当前只用了单机模型，数据量增大后可以考虑引入分布式特征计算；另外预测周期目前是日级别，未来可以细化到小时级。

7. 项目扩展：从毕设到可落地系统的三个方向

如果你做完基础版本还有余力，我建议从以下三个方向里挑一个做扩展，能让项目的含金量上一个台阶。

第一个方向是爬虫升级。把单机版爬虫改造成分布式爬虫，用 Redis 做 URL 去重队列，用 Scrapy-Redis 实现多节点协同抓取。这个扩展能直接把“大数据”属性拉满，论文里可以写“基于 Redis 的分布式爬虫架构设计”。

第二个方向是模型升级。目前做的是回归模型，你可以把它升级成真正的时间序列模型，比如 Prophet 或 LSTM。Prophet 对节假日效应和周期性趋势有内置支持，特别适合农产品这种季节性强、节假日波动大的场景；LSTM 虽然训练成本高，但能捕捉更复杂的时序依赖，可以作为实验对比模型写进论文。

第三个方向是系统完善。加入定时调度框架（APScheduler）让爬虫和模型训练每天自动运行，加入简单的用户登录权限控制，把系统从“演示版”变成“真正可以长时间运行”的后台服务。这个方向虽然技术含量不高，但对工程素养的体现非常明显。

我个人在实际操作中的体会是，这类项目做的过程中，最耗时间的往往不是“看代码”，而是“等数据”。爬虫抓数据可能要跑几个小时，清洗完继续写特征工程又要来回调试，模型训练反而是最快的一环。所以我的建议是：第一天先把爬虫跑起来，让它夜里慢慢抓数据，第二天开始写数据处理和建模代码，第三天做可视化，第四天写论文和 PPT。时间安排合理，整个毕设一点都不慌。