企业官网建设流程全解析

打开毕设选题文档那几天，我其实特别焦虑。学校给的题目列表翻来覆去都是图书管理系统、商城系统、某某管理系统，要么就是网上已经被写烂了的电影推荐、用户画像。后来我换了个思路，不去纠结"系统"本身，而是想找一个有真实业务场景、有数据可挖、还能把整个数据链路串起来的题目。最后锁定了"基于Python的京东教辅书销售数据分析系统"。

这个项目本质上就是用Python爬取京东教辅类商品的公开销售数据，经过清洗和分析之后，通过Web界面把销量、价格、评价、出版社等维度的规律展示出来。它特别适合计算机、大数据、电商相关专业的毕业设计，因为技术栈覆盖了爬虫、数据库、pandas数据处理、可视化、Flask Web开发，几乎所有高校课程里学过的核心点都包含了。而且教辅书这个细分方向比泛泛的"电商数据分析"更有辨识度，答辩时能讲的东西也多。

如果你也正在纠结毕设选题，或者想找一个难度适中、能自己完整做下来又不容易撞题的方向，这篇文章就从我的实际项目出发，聊聊整个系统的设计和实现过程，包括踩过的坑和答辩时被问到的问题。

1. 为什么会选"京东教辅书销售数据分析"当题目

1.1 选题背后的业务逻辑

教辅书是电商平台里非常特殊的一个类目。它既有普通商品的通用属性（价格、评价、店铺），又有很强的教育行业特征：年级、科目、教材版本、出版社、出版年份。这些属性组合起来，能做的分析维度非常丰富。

举个简单的例子，每年的开学季前后，小学奥数、中考真题、高考模拟卷这类商品的搜索量和销量会出现明显的脉冲式变化。如果只做全品类电商分析，这种规律会被平均掉；但如果聚焦教辅书，就能看到清晰的周期性。这种"细分领域里能说出具体业务洞察"的项目，写论文、做答辩都比泛泛的"电商数据分析"更有说服力。

我当时定下这个题目后，先在京东上随便搜了几个关键词，确认数据是可获取的：商品标题、价格、评价数、店铺、出版信息这些都展示在页面上，而且数量足够做统计分析。数据是真实业务数据，这一点对毕设的含金量非常重要。

1.2 毕设选题的三条冷门经验

我给正在选题的同学提三条建议，都是实际经验。

第一条，看数据可得性。不要选一个东拼西凑都凑不到1000条真实数据的题目。哪怕数据再漂亮，一旦答辩老师要求你现场演示原始数据，拿不出来就很尴尬。京东、淘宝这类电商平台的数据量天然充足，教辅书搜索页一页几十个商品，翻几十页就能攒下几千条。

第二条，看技术栈完整性。毕设不是工作，不需要用到分布式、大数据引擎那种重型技术，但一定要能串联起来。爬虫采集、数据清洗、数据分析、可视化展示，这四件事覆盖了本科阶段最核心的课程内容。如果这个项目还能带一个Web界面用来展示结果，演示效果和评分都会明显提升。

第三条，看差异化。如果你要做数据分析方向，别选"某电商平台销售数据分析"这种大而空的题目，一定要加一个细分场景。"教辅书"、"宠物用品"、"户外装备"，只要加上限定词，论文的同类研究对比部分就好写得多，答辩时也不容易跟其他同学撞题。

我见过太多人直接去下载网上的"免费python源码大全"，跑通之后换皮交上去。结果答辩时老师问一句"这个图表数据怎么来的"就答不上来。数据链路自己亲手跑通的痛苦和价值，是换皮项目完全无法替代的。

2. 系统总体设计与技术选型：先把数据链路搭通

2.1 四层架构：从采集到展示谁管谁

本系统的整体架构分成四层：

• 数据采集层：用Python写爬虫，从京东搜索页和商品详情页采集教辅书信息。
• 数据存储层：采集结果统一存到MySQL，维护商品信息表、用户表、采集记录表。
• 数据处理与分析层：用pandas做数据清洗、特征提取和指标计算，用jieba做评价关键词提取。
• 可视化与Web展示层：Flask提供后端接口，前端用ECharts渲染图表，页面采用Dashboard布局。

架构一句话概括就是：爬虫往MySQL里喂数据，pandas从MySQL里取数据算指标，Flask把指标以JSON形式返给前端，前端把JSON画成图表。这四层之间通过标准SQL和JSON接口解耦，哪一层出问题都能单独排查。

2.2 为什么是Python + Flask + MySQL + ECharts

这个组合是经过对比后才确定的，不是随便选的。

Python本身不用多说，爬虫和数据分析生态最强。Flask选择它的原因很简单：够轻。毕设项目不需要多用户、权限体系、后台管理那些重型功能，Flask写一个路由就是一个接口，前后端分离也方便。如果用Django，框架自带的东西很多但学习成本更高，在答辩时如果被问到"里面的权限中间件怎么实现的"，反而容易露怯。

MySQL存结构化商品数据非常合适。教辅商品信息本质上是关系型数据，字段固定，表之间有明确关联。MongoDB这类NoSQL虽然在爬虫项目里也常见，但对毕设而言，学生和老师更熟悉MySQL，SQL查询写起来也直观。为了后续分析的方便，我将每个商品做成一行记录，字段包括sku、标题、店铺、出版社、价格、评价数、好评率、采集时间等。

pyecharts是Python生成ECharts图表的库，核心价值在于，我可以在Python端直接生成图表的option配置，传给前端渲染，不用手写大量JavaScript。这在毕设开发阶段能节约非常多时间。

2.3 数据库表设计：字段不要拍脑袋，要想到后面怎么分析

表设计是最容易偷懒但最不能偷懒的一环。我最初只是把"页面上看到什么就存什么"，结果后期做分析时发现，出版社信息在列表页根本没有，必须进详情页二次采集，流程被打乱了。所以，表设计一定要先从分析需求反推。

建表SQL如下：

CREATE TABLE book_product ( id INT PRIMARY KEY AUTO_INCREMENT, sku VARCHAR(32) NOT NULL UNIQUE COMMENT '商品SKU', title VARCHAR(255) NOT NULL COMMENT '商品标题', link VARCHAR(255) COMMENT '商品链接', shop VARCHAR(128) COMMENT '店铺名称', publisher VARCHAR(128) COMMENT '出版社', price DECIMAL(10,2) COMMENT '售价', commit_num INT COMMENT '评价数', good_rate DECIMAL(5,2) COMMENT '好评率(%)', publish_date VARCHAR(32) COMMENT '出版时间', grade VARCHAR(16) COMMENT '年级', subject VARCHAR(16) COMMENT '科目', version VARCHAR(32) COMMENT '教材版本', source_keyword VARCHAR(32) COMMENT '来源搜索词', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

注意里面的grade、subject、version三个字段，它们是数据分析的重要维度，是在清洗阶段从标题里拆出来的，采集阶段先置空。sku字段加上唯一索引，这样增量更新时可以用INSERT ... ON DUPLICATE KEY UPDATE，一个语句完成"存在则更新，不存在则插入"。

3. 数据采集：京东教辅书爬虫设计与反爬应对

3.1 明确采集范围和字段优先级

我设定的采集范围是：在京东搜索"教辅书"、"初中教辅"、"高中教辅"、"小学教辅"、"一课一练"、"中考真题"、"高考模拟"等关键词，每个关键词采集前30页左右的商品列表。最终有效数据量控制在3000条以上，这个规模已经足够做各类统计分析了。

字段优先级上，第一优先级是sku、标题、价格、评价数，因为它们是后续分析的基础；第二优先级是店铺、出版信息；第三优先级是好评率、出版时间这类不一定每个页面都有、需要单独处理的字段。

列表页能抓到sku、标题、价格、店铺、评价数。出版信息、好评率、出版时间在详情页或参数页才有，所以我做了一步"详情页补采"：从列表页拿到sku列表，再批量抓取详情页。这个过程会显著增加请求量，一定要控制频率。

3.2 列表页爬虫实现：选择器永远要有容错

京东搜索页的结构会随着改版变化，不要指望一个月前别人博客写的选择器现在还完全有效。我实现时采用了"选择器 + 空值容错"的策略，确保页面结构小改时程序不会直接崩溃。

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 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36", "Accept-Language": "zh-CN,zh;q=0.9" } def fetch_list(keyword, page): url = f"https://search.jd.com/Search?keyword={keyword}&page={page}" resp = requests.get(url, headers=HEADERS, timeout=10) soup = BeautifulSoup(resp.text, "html.parser") lis = soup.select("#J_goodsList li.gl-item") items = [] for li in lis: sku = li.get("data-sku") if not sku: continue title = li.select_one(".p-name em") price = li.select_one(".p-price i") commit = li.select_one(".p-commit a") shop = li.select_one(".p-shop a") items.append({ "sku": sku, "title": title.text.strip() if title else "", "price": price.get("data-price") or price.text if price else None, "commit": commit.text.strip() if commit else "0", "shop": shop.text.strip() if shop else "", "url": f"https://item.jd.com/{sku}.html" }) return items

这里面有几个处理细节值得说清楚。

第一，li.get("data-sku")拿不到sku的直接丢弃，因为后续详情页全靠它。

第二，价格字段优先从>def parse_commit(text): if not text: return 0 text = text.replace("+", "").strip() if "万" in text: return int(float(text.replace("万", "")) * 10000) if not text.isdigit(): return 0 return int(text)

3.3 反爬应对：不是对抗，是克制

京东的反爬机制主要是验证码、IP频率限制、账号风控。作为一个毕设项目，我的原则不是"破解反爬"，而是"让请求频率低到不会被反爬体系注意到"。

实际采用方案：

• 同一关键词翻页之间随机sleep 1.5到3秒，不同关键词切换之间sleep 5到8秒。
• 请求头只设置User-Agent和Accept-Language，伪装真实浏览器但不堆砌多余请求头。
• 连续请求失败超过3次就终止当前关键词采集，记录日志，人工判断后再继续，绝不自动无限重试。
• 采集时间拉长到几小时，分多次运行。

这里要特别说明一下合规问题。京东商品页的搜索结果是公开信息，爬取公开商品信息用于个人学习研究，本身没有越界。但必须控制节奏、不采集用户个人数据、不用于商业用途。论文里也要写"遵守robots协议和数据使用规范"这句话，这是答辩时的基本职业素养。

另外，京东页面有一些地方提供了>from sqlalchemy import create_engine engine = create_engine("mysql+pymysql://root:123456@localhost:3306/jd_books?charset=utf8mb4") df = pd.DataFrame(items) df.to_sql( "book_product", engine, if_exists="append", index=False, method="multi", chunksize=200 )

注意sku设置了唯一索引，但是to_sql遇到重复主键时会整批报错。后来我改用了一条原生SQL做增量更新：先把数据写入临时表，再用INSERT ... ON DUPLICATE KEY UPDATE合并到主表。这个方案在毕设场景下足够稳定，也比"先delete再insert"安全得多，因为不会因为中途失败而把历史数据全删掉。

4. 数据清洗与预处理：脏数据才是数据分析的必修课

4.1 原始数据常见的四个坑

采集完的数据直接分析一定会翻车。我第一批数据跑出来，就发现了四类典型问题。

第一，重复数据。同一个商品会被不同搜索关键词反复采到，比如"初中教辅"和"七年级教辅"会出现大量相同的sku。

第二，缺失值。价格、出版社、好评率都有可能缺失，尤其是第三方店铺的书籍，很多没有标注出版社。

第三，异常值。有一些商品价格是0.01元，明显是商家低价引流或者价格采集失败。还有一些评价数高达几十万，需要确认是不是"刷单"或"爆款"造成的极端值，在统计时不能简单放过。

第四，文本数据里包含了大量营销词，比如"正版包邮""学霸必备""秒杀"。这些词用词云做人气分析时毫无意义，必须在分析前剔除。

4.2 清洗流程：pandas一行一行把数据捋干净

清洗逻辑我用pandas实现，核心代码不长，但每一步背后都有讲究。

import pandas as pd df = pd.read_sql("SELECT * FROM book_product", engine) # 1. 去重：同一个SKU只保留最新采集的一条 df = df.sort_values("update_time", ascending=False).drop_duplicates("sku", keep="first") # 2. 价格转数值，低于1元的视为异常抛弃 df["price"] = pd.to_numeric(df["price"], errors="coerce") df = df[df["price"] >= 1.0] # 3. 评价数转数值，缺失的补0 df["commit_num"] = df["commit_num"].fillna(0).astype(int) # 4. 出版社缺失值：用“未知出版社”填充，而不是直接删行 df["publisher"] = df["publisher"].fillna("未知出版社") # 5. 好评率缺失值：用全样本中位数填充 df["good_rate"] = pd.to_numeric(df["good_rate"], errors="coerce") df["good_rate"] = df["good_rate"].fillna(df["good_rate"].median())

关于好评率的填充，我一开始用的是均值，后来发现好评率分布是左偏的，大量商品集中在95%到100%之间，用均值填充会把缺失值拉得偏低，而中位数更接近常态值。这个细节在论文"数据预处理"章节里写出来，反而是加分项。

4.3 从商品标题里拆出年级、科目、教材版本

教辅书标题的典型格式是"2025版初中数学七年级上册人教版教材同步练习"，这行文本里包含学段、年级、科目、版本四个分析维度。用正则加关键词匹配就能拆出来。

import re def extract_features(title): grade = "" subject = "" version = "" grade_pattern = re.compile(r"(小学|初中|高中)?(一|二|三|四|五|六|七|八|九)年级") m = grade_pattern.search(title) if m: grade = m.group(0) subject_dict = ["语文", "数学", "英语", "物理", "化学", "生物", "历史", "地理", "政治", "科学"] for sub in subject_dict: if sub in title: subject = sub break version_dict = ["人教版", "北师大版", "苏教版", "外研版", "鲁教版", "沪教版", "湘教版", "冀教版", "译林版"] for ver in version_dict: if ver in title: version = ver break return grade, subject, version df[["grade", "subject", "version"]] = df["title"].apply( lambda x: pd.Series(extract_features(str(x))) )

这个模块就是论文里的"特征工程"，也是老师和答辩评委最容易提问的部分。你需要能讲清楚：不是用机器学习模型，而是基于教辅书标题的领域知识，用规则提取特征。这样做的好处是解释性强，坏处是覆盖面有限，有些标题没有明确的"人教版"字样就只能留空。

5. 核心指标设计与数据分析模块：让数字说话

5.1 教辅书业务指标体系怎么定

数据分析不是把图生成出来就完事，而是要先定义"要看什么、为什么看"。我围绕教辅书这个场景设计了六类核心指标。

这里有一个必须解释清楚的地方：京东商品页不会直接展示"销量"字段，公开可见的是"评价数"。所以整个分析中用评价数作为销量热度的近似代理指标。这个近似并不是完全准确，因为很多用户买了之后不给评价，但它在横向比较同一个品类里的商品热度时仍然有参考价值。我建议你在论文里也如实写出这个指标替代逻辑，这比隐藏细节要稳妥得多。

5.2 价格带分析：低价未必高销量

价格带是教辅书分析里最直观的维度。我按"0-20元、20-50元、50-100元、100元以上"把商品分成了四组，统计每个价格带的平均评价数、商品数量和平均好评率。

bins = [0, 20, 50, 100, float("inf")] labels = ["0-20元", "20-50元", "50-100元", "100元以上"] df["price_band"] = pd.cut(df["price"], bins=bins, labels=labels, right=True) result = ( df.groupby("price_band", observed=True) .agg( total=("title", "count"), avg_commit=("commit_num", "mean"), avg_rate=("good_rate", "mean") ) .reset_index() )

跑出来的实际结论很有意思：0-20元的商品数量很多，但平均评价数反而低于20-50元区间。这说明教辅书不是越便宜越好卖，20-50元这个价位段可能是家长和学生更信任的"正版教辅主力价位"。这个洞察写进论文，比单纯贴一张柱状图有价值得多。

5.3 出版社与年级、科目分布分析

出版社分析可以联合年级和科目一起做，形成"交叉分析"。比如在初中数学品类里，哪几个出版社的评价数明显领先；在高考真题品类里，哪些出版社的新品更多。

实现方式是用pandas的groupby加sort_values：

top_publisher = ( df[df["subject"] == "数学"] .groupby("publisher") .agg(total=("title", "count"), avg_commit=("commit_num", "mean")) .sort_values("avg_commit", ascending=False) .head(20) .reset_index() )

这一步生成的表格和图，配合可视化层做一张Top出版社横向条形图，非常直观。另一个值得做的分析是"年级热度分布"：小学、初中、高中三个学段里，哪个年级的商品数量最多、评价数最高。实测结果一定是初中和高中阶段的数据量明显高于小学，尤其是九年级和九年级以下，这与中考、高考的压力直接相关。

5.4 评价关键词分析：可选的加分模块

京东的评价详情文本采集难度大、反爬严格，所以我的系统里做了一个折中方案：不采集具体评价内容，而是通过商品的标题词频和教辅场景关键词做一层"内容热度分析"。

方法很简单：把所有清洗后的标题拼成一个长文本，用jieba分词，过滤停用词和"包邮""正版"等通用营销词，然后统计关键词词频。

import jieba from collections import Counter text = " ".join(df["title"].tolist()) words = jieba.lcut(text) stop_words = {"包邮", "正版", "现货", "新款", "全套", "初中", "高中", "小学"} filtered = [w for w in words if len(w) >= 2 and w not in stop_words] word_freq = Counter(filtered).most_common(30)

这个模块虽然不是严格意义上的情感分析，但能反映出当前教辅市场上"真题""同步""专项训练""思维"等概念的流行度，在答辩展示时是一个很有话题性的图表。

6. 可视化与Web系统实现：让分析结果能演示、能落地

6.1 Dashboard页面规划：不是堆图表，而是讲故事

做毕设系统，最容易犯的错是把一堆图表堆在首页，看起来炫，实际没有逻辑。我的页面规划遵循"总—分—细"的故事线。

• 总览页：核心指标卡片（总商品数、平均价格、平均评价数、Top出版社）+ 价格带分布柱状图 + 年级占比饼图。
• 商品分析页：教辅商品数据表格，支持按年级、科目、出版社筛选排序，用分页降低数据量。
• 价格分析页：价格带与评价数关系图，可以联动选择学段。
• 出版社分析页：出版社榜单横向条形图 + 词云。
• 数据管理页：显示采集状态、数据量统计，预留数据更新的触发按钮。

这样的好处是，答辩演示时你能讲出一条完整逻辑："先看整体盘子有多大，再看价格带和年级分布，然后穿透到出版社和具体商品"。这套叙事比"我这里有一堆图"强太多。

6.2 Flask后端与前端图表对接

后端我用Flask提供JSON数据接口，前端用ECharts渲染。这个前后端分离结构在答辩时容易被问到"你是怎么实现前后端交互的"，所以要非常清楚。

后端路由示例：

from flask import Flask, render_template, jsonify from sqlalchemy import create_engine import pandas as pd app = Flask(__name__) engine = create_engine("mysql+pymysql://root:123456@localhost:3306/jd_books?charset=utf8mb4") @app.route("/") def index(): return render_template("index.html") @app.route("/api/price_band") def price_band(): sql = """ SELECT price_band, COUNT(*) AS total, AVG(commit_num) AS avg_commit FROM book_product GROUP BY price_band """ df = pd.read_sql(sql, engine) return jsonify({ "categories": df["price_band"].tolist(), "total": df["total"].tolist(), "avg_commit": df["avg_commit"].round(1).tolist() })

前端只需要在页面里写一个简单的fetch或者$.getJSON，把接口返回的数据塞进ECharts的option即可。这里我推荐把option的series部分用接口数据动态赋值，避免写死数据，这样筛选功能才能联动。

如果不想前后端分离，也可以直接用pyecharts生成HTML片段嵌入模板：

from pyecharts.charts import Bar from pyecharts import options as opts bar = Bar() bar.add_xaxis(categories) bar.add_yaxis("平均评价数", values) bar_html = bar.render_embed() return render_template("dashboard.html", chart_html=bar_html)

render_embed()返回的是完整的ECharts初始化脚本，放到模板的div中就能显示，开发效率非常高。缺点是图表间的交互联动会比较繁琐，所以我实际用的是前一种"JSON接口+ECharts"的方式。

6.3 关键功能模块：登录、筛选联动、数据明细

系统不能只是一个图表集合，还要有"系统"该有的功能模块。我做了一个轻量的用户登录模块，密码用werkzeug.security的哈希函数处理，不用明文存储。数据库里建一张user表，存用户名和password_hash。

筛选联动是演示时的重点。用户在页面上选择"科目=数学"和"年级=初中"，点击查询，前端通过Ajax请求带参数接口：

fetch(`/api/price_band?subject=${subject}&grade=${grade}`) .then(res => res.json()) .then(data => updateChart(data));

后端拿到筛选条件后，拼SQL时加上WHERE条件，再重新聚合数据返回。这个交互每次能真实地改变图表，而不是前端做假筛选，答辩时很有说服力。

数据明细表格我用的是一个简单的前端表格库，配合后端分页接口。这里注意，表格数据量大的时候千万不要一次性全部加载到页面里，否则浏览器会卡。我在后端接口里加了limit和offset参数，用MySQL的LIMIT实现分页。

7. 系统测试与论文写作：毕设答辩前的最后冲刺

7.1 功能测试与性能测试的实用思路

很多毕设文档里的测试章节都是凑字数，但系统测试其实是最容易拉开差距的地方。我的实际测试分成三块。

第一块是数据采集的稳定性测试。让爬虫从早晨跑到下午，记录每个关键词的采集耗时、成功条数、失败条数、被反爬中断的次数。这部分数据直接写进论文"系统测试"章节，用表格呈现，说服力极强。

第二块是接口响应时间测试。给MySQL的sku字段加了唯一索引后，通过/api/price_band这类接口返回时间一般都在100ms以内。我用浏览器开发者工具测了几个核心接口，记录响应耗时，并和优化前的对比。

第三块是功能边界测试。重点测了筛选条件为空、价格范围不含任何数据、搜索关键词没有结果这几种情况，确保前端不报错、页面有友好提示。这个测试点可以在答辩时主动说出来，展现你的测试思维。

7.2 论文结构：重点写"分析模块"而不是"爬虫"

这个系统相关的论文，我建议章节结构如下：

• 摘要与关键词
• 第一章 绪论：选题背景、国内外研究现状、研究意义
• 第二章 相关技术介绍：Python、Flask、MySQL、爬虫技术、ECharts
• 第三章 需求分析：功能性需求（登录、数据采集、数据分析、可视化）、非功能性需求（数据量、响应时间）
• 第四章 系统设计：总体架构、数据库设计、模块设计
• 第五章 系统实现：采集模块实现、清洗模块实现、分析模块实现、Web展示实现
• 第六章 系统测试：测试环境、测试用例、测试结果
• 第七章 总结与展望

写作时还有一个关键点：把"爬虫"这个词替换成"数据采集"，把"反爬绕过"表述为"访问频率控制"。这能体现你对数据合规的理解。爬虫相关技术可以写实现细节，但不要写如何绕过验证码、如何伪造签名这类内容，一是敏感，二是完全没必要，毕设的数据量靠正常频率就能采够。

7.3 答辩必问问题的应答思路

答辩是所有毕设的最终考试，下面几个问题是我遇到的或同学遇到的，提前准备好答案。

问题一，数据量有多大，数据是真实的吗？回答思路：公开了采集时间范围、采集关键词、有效条数，解释评价数是公开字段，数据真实但仅代表采集时段。

问题二，为什么用评价数代替销量？如实承认这是代理指标，并解释在电商公开数据中评价数是可观测且稳定的热度指标。同时补充，如果后期能拿到订单数据，可以换成真实销量。

问题三，你这个数据清洗最大的困难是什么？回答：价格缺失和好评率缺失的填充策略，以及标题中教材版本提取的规则覆盖不全。这两个具体问题能证明你是真正动手做过。

问题四，如果京东页面改版了，你的爬虫怎么办？回答：修改选择器和解析逻辑，将采集模块设计为可配置，模块化替换。如果时间允许，可以现场演示修改选择器后重新采集。

问题五，你的系统有什么可以改进的地方？回答：可以引入更细粒度的评论情感分析，接入图表间的自动联动，以及把数据采集做成定时任务。注意，说改进点不是承认缺陷，而是展示你在思考边界。

很多同学在答辩前最担心被问倒是"爬虫会不会有问题"，但你只要把合规使用、频率控制、研究目的这三点讲清楚，并且论文中没有教唆性内容，这个环节完全可以平稳通过。

做完整个系统，我最深的感受是，毕设选一个自己真正愿意深挖的细分场景，比选一个听起来高大上但只能靠造数据支撑的题目，省心太多了。你在清洗数据时发现的每一个异常，分析时得出的每一个结论，都会变成论文里的真实素材。如果时间有限，优先把数据分析结果和可视化图表做得漂亮、有业务洞察，演示效果比单纯的系统多几个按钮重要得多。最后再分享一个小技巧，答辩前把爬虫采集、数据清洗、图表展示这一条完整链路在本地跑通，录一段小视频备用，万一现场网络出问题，这段视频能救回大部分印象分。