基于Python爬虫与机器学习的电商农产品销量预测系统设计

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 核心链路数据如何一步步变成预测结果整个系统的核心链路可以概括为六个步骤每一步的产出是下一步的输入形成一个单向数据流爬虫定时抓取各电商平台的农产品商品页数据保留原始 JSON/HTML数据清洗脚本对原始数据进行去重、缺失值补齐、格式统一输出标准化表格基于标准化表格做特征工程构造历史销量序列、价格变化率、评论情感分、促销标记等特征按时间顺序划分训练集和测试集防止未来数据泄露到训练过程中训练多个候选模型线性回归、随机森林、XGBoost用 RMSE 和 MAPE 做对比评估选出最优模型将最优模型序列化保存后端接口接收商品 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;q0.9 } def fetch_page(url, retries3): for i in range(retries): try: resp requests.get(url, headersheaders, timeout10) if resp.status_code 200: return resp.text except Exception as e: print(f[WARN] 第{i1}次请求失败: {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(stripTrue) price float(tag.select_one(.price).get_text(stripTrue).replace(¥, )) sales tag.select_one(.sales).get_text(stripTrue) 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, timeout10) 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 [fhttps://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, indexFalse)清洗完成后数据写入 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_estimators500, learning_rate0.05, max_depth5, subsample0.8, colsample_bytree0.8, random_state42 ) # 时间序列交叉验证严格按时间顺序切分不允许未来数据进入训练 tscv TimeSeriesSplit(n_splits5) 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)], verboseFalse) 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(fRMSE: {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), keylambda x: x[1], reverseTrue)[: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(host0.0.0.0, port5000)这里有一个“货不对板”很容易踩的坑预测时传入的特征顺序必须和训练时完全一致。如果训练时的特征顺序是[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 Im 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 xgboost2.0.3等旧版本。另一个方案是先用随机森林扛着答辩演示效果也没差多少不必死磕一个库。6.4 答辩高频提问的预设答案我根据经验总结了答辩时老师最爱问的六个问题提前准备答案现场就不慌为什么选这个课题答农产品电商存在明显的产销信息不对称问题精准的销量预测可以帮助农户和商家优化备货、减少损耗。数据量有多大数据从哪来答通过爬虫从 XX 平台采集了近 X 万条商品数据时间跨度为 X 个月每天定时增量抓取。为什么用 XGBoost 不用深度学习答当前数据量为万级、特征维度约 XX 个XGBoost 在中小规模表格数据上精度高、训练快、可解释性强深度学习需要更大数据量才能发挥优势。模型评估指标为什么选 RMSE 和 MAPE答RMSE 量纲直观反映绝对误差水平MAPE 反映相对误差比例两者结合能全面评估模型尤其排除销量量纲差异的干扰。预测结果如何落地答将模型封装成 API 服务前端可以按日/周维度查询预测结果后续可扩展为按品类、按地区细粒度预测。系统有什么不足答当前只用了单机模型数据量增大后可以考虑引入分布式特征计算另外预测周期目前是日级别未来可以细化到小时级。7. 项目扩展从毕设到可落地系统的三个方向如果你做完基础版本还有余力我建议从以下三个方向里挑一个做扩展能让项目的含金量上一个台阶。第一个方向是爬虫升级。把单机版爬虫改造成分布式爬虫用 Redis 做 URL 去重队列用 Scrapy-Redis 实现多节点协同抓取。这个扩展能直接把“大数据”属性拉满论文里可以写“基于 Redis 的分布式爬虫架构设计”。第二个方向是模型升级。目前做的是回归模型你可以把它升级成真正的时间序列模型比如 Prophet 或 LSTM。Prophet 对节假日效应和周期性趋势有内置支持特别适合农产品这种季节性强、节假日波动大的场景LSTM 虽然训练成本高但能捕捉更复杂的时序依赖可以作为实验对比模型写进论文。第三个方向是系统完善。加入定时调度框架APScheduler让爬虫和模型训练每天自动运行加入简单的用户登录权限控制把系统从“演示版”变成“真正可以长时间运行”的后台服务。这个方向虽然技术含量不高但对工程素养的体现非常明显。我个人在实际操作中的体会是这类项目做的过程中最耗时间的往往不是“看代码”而是“等数据”。爬虫抓数据可能要跑几个小时清洗完继续写特征工程又要来回调试模型训练反而是最快的一环。所以我的建议是第一天先把爬虫跑起来让它夜里慢慢抓数据第二天开始写数据处理和建模代码第三天做可视化第四天写论文和 PPT。时间安排合理整个毕设一点都不慌。