简介：一套面向计算机专业毕业生与课程设计学习者的完整项目包，围绕豆瓣电影数据爬取、清洗分析与可视化呈现展开，采用Flask搭建后端、ECharts完成图表渲染、pandas承担数据处理，数据保存到MySQL，适合作为毕业设计或大型课程作业的参考实现。压缩包共1054个文件、约30.07MB，以688个py源码为主体，辅以html、js、css等前端页面与样式，另有sql建表脚本、csv样本数据、docx论文及运行依赖配置，工程结构完整，可对照梳理爬虫、接口与视图的组织方式。目前已有256人学习下载。项目把爬取、清洗、入库、接口输出到多角度动态图表逐层拆开，读者可据此理解数据从目标站点到可视化页面的完整链路，复用其图表配置与处理思路；配套论文便于对齐需求分析与系统设计的写作口径。

1. 选题落地：把“电影评分排序”做成一条能答辩的完整链路

选题报上去的时候，导师只问了一句：除了把评分排个序，这套系统还能回答什么问题。这句话卡住过不少人。python毕业设计里挑豆瓣电影数据分析与可视化方向的人很多，能把“数据从哪来、怎么洗、洗完给谁用”讲完整的却不多。这份基于 Flask + ECharts + 爬虫 + pandas 的完整方案，覆盖的正是这条完整链路：爬虫只负责取原始条目，pandas 把质量较差的数据整理成规整宽表，MySQL 负责存储，Flask 把聚合结果转成 JSON，ECharts 在前端画成能筛选、能联动的六张图。

它适合两类人：一类是要交毕设或课程设计，需要一套既跑得通、也讲得清的结构；另一类是想拿现成骨架改成自己垂类数据分析项目的开发者，把数据源换掉、把指标口径改掉，剩下的接口和图表层基本可以复用。下面按采集、清洗、建模、接口、图表的顺序拆开讲，末尾给一份答辩前能直接照着走的验收表。

2. 采集层设计：条目字段拆解与可中断的断点续爬

采集层最容易犯的错误，是把它当成“一次性脚本”来写：写个 for 循环一页页刷，中途断掉以后从头再来，跑第二遍又开始怀疑数据到底有没有重复。真正要交付的系统里，爬虫应当被视为一个有状态、可恢复、幂等的任务，这也是后面所有分析能站得住的前提。

2.1 字段拆解：一次抓取要拿到哪些列

目标站点通常分成列表页和详情页两层。列表页按分页给出条目卡片，能直接拿到条目 id、标题、评分、评价人数、一句话简介；详情页才有时长、制片国家、类型标签、导演、主演和完整简介。我的做法是先用列表页把所有 id 扫一遍，形成一张“待抓清单”，再按清单去补详情页，而不是在列表页里边翻边抓详情，那样一旦超时，你无法判断哪一条已经抓过。

字段设计上建议按“分析能用到”倒推，别贪多。下面这张表是我这套系统实际入库的字段域，多一列都会在清洗阶段变成负担：

评分人数在页面上是“123456人评价”这种带单位的字符串，年份经常混在“1994 / 美国 / 犯罪 剧情”这样的一行里，类型标签是多个<span>。这些拆解工作一律放在解析函数里做，但只做“结构拆分”，不做“语义修正”。像“美国 / 法国”这种多国联合制片的，原样存成字符串，交给后面的清洗层决定怎么切。这条边界一旦模糊，爬虫就会越来越难维护。

2.2 请求节流、失败重试与断点续爬

请求层我一般固定这么几个参数：超时 8 秒、最多重试 3 次、每次失败后指数退避、每次成功请求之间随机停 2 到 4 秒。别小看这个随机间隔，固定sleep(1)的请求节奏在时序上是完全均匀的，很容易被识别成机器行为。下面的骨架把会话复用、重试和断点都放进去了：

import os, json, time, random import requests from bs4 import BeautifulSoup # 目标站点地址集中配置，换数据源时只改这一处 BASE = "https://movie.example.test/top250" CKPT = "checkpoint.json" HEADERS = { "User-Agent": ("Mozilla/5.0 (Windows NT 10.0; Win64; x64) " "AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36"), "Accept-Language": "zh-CN,zh;q=0.9", } session = requests.Session() # 复用连接，减少握手次数 session.headers.update(HEADERS) def load_ckpt(): """断点文件不存在时返回初始状态，保证首次运行也能跑""" if os.path.exists(CKPT): with open(CKPT, encoding="utf-8") as f: return json.load(f) return {"page": 0, "done_ids": []} def save_ckpt(state): """先写临时文件再替换，防止进程被杀时断点文件损坏""" with open(CKPT + ".tmp", "w", encoding="utf-8") as f: json.dump(state, f, ensure_ascii=False) os.replace(CKPT + ".tmp", CKPT) def fetch(url, retry=3): for i in range(retry): try: r = session.get(url, timeout=8) r.encoding = r.apparent_encoding # 页面声明的编码不可靠，用探测结果覆盖 if r.status_code == 200: return r.text if r.status_code in (403, 429): # 被限流时直接放弃本轮，交给上层降速 print("限流状态码:", r.status_code) return None except requests.RequestException as e: print("请求异常:", e) time.sleep(2 ** i + random.random()) # 1s、2s、4s 的指数退避加抖动 return None

session复用的是 TCP 连接和 Cookie，比每次裸调requests.get稳得多；r.apparent_encoding会走一遍编码探测，比直接用r.encoding靠谱；os.replace是原子操作，断点文件不会出现写一半的残废状态。这套写法在几千条量级下，中断重启只需要从state["page"]续上，不用重头再来。

2.3 原始数据落盘：别把清洗逻辑塞进爬虫

解析出来的数据我建议先落成 JSONL，一行一条，文件名带上页码，比如raw/page_003.jsonl。理由很实际：爬虫跑一次要十几分钟，而清洗规则你大概率要改五遍以上。原始层存住，改清洗规则只需要重跑 pandas，不用重新抓一遍。

入库前再加一道校验：movie_id必须存在且是数字，title不能为空，score落在 0 到 10 之间，不满足的记录写进raw/reject.jsonl并附上原因。这一步看起来多余，但答辩时被问到“你的数据质量怎么保证的”，能拿出一个拒收文件，比嘴上说“我做了校验”有力得多。

import json def parse_page(html): soup = BeautifulSoup(html, "html.parser") rows = [] for card in soup.select("div.item"): try: rows.append({ "movie_id": int(card.select_one("em").text), "title": card.select_one(".title").text.strip(), "score": float(card.select_one(".rating_num").text), "rating_count": int(card.select_one(".star span:last-child") .text.replace("人评价", "").replace(",", "")), "summary": (card.select_one(".inq") or {}).get_text(strip=True, default=""), }) except (AttributeError, ValueError) as e: # 单条解析失败不能影响整页，记下来继续 print("跳过异常条目:", e) return rows

card.select_one返回 None 时直接取属性会抛AttributeError，外面套一层 try 保证一条坏数据不会中断整页；rating_count里的千分位逗号和中文单位在解析阶段就清掉，是为了让后面的 dtype 转换少一次失败。真正复杂的清洗，比如多国家拆分、类型多值展开，全部留到下一章。

3. 数据落地：四张表的建模与 pandas 清洗流水线

数据从 JSONL 到能被图表直接消费，中间隔着一层建模决策。很多方案到这里就糊过去了，直接一张大宽表存所有字段，类型标签用逗号拼成字符串，后面做类型分布统计时只能在 Python 里split完再循环计数——数据量一大就彻底不可用。我的做法是维度表和事实表分开，把多值字段拆成桥表。

3.1 四张表的结构与索引设计

四张表各司其职：dim_movie存电影维度和评分快照，movie_genre是电影与类型的多对多桥表，fact_rating_trend记录每部电影按天采集的评分与评价人数变化，fact_comment存短评文本供词云使用。DDL 大致如下：

CREATE TABLE dim_movie ( movie_id INT PRIMARY KEY, -- 用站点条目 id 做主键，天然幂等 title VARCHAR(120) NOT NULL, release_year SMALLINT, country VARCHAR(80), duration_min SMALLINT, score DECIMAL(3,1), rating_count INT, director VARCHAR(80), summary VARCHAR(500), crawl_date DATE NOT NULL, KEY idx_year (release_year), KEY idx_score (score) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE movie_genre ( movie_id INT NOT NULL, genre VARCHAR(20) NOT NULL, PRIMARY KEY (movie_id, genre), -- 联合主键顺带解决重复插入 KEY idx_genre (genre), CONSTRAINT fk_genre_movie FOREIGN KEY (movie_id) REFERENCES dim_movie(movie_id) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE fact_rating_trend ( movie_id INT NOT NULL, stat_date DATE NOT NULL, score DECIMAL(3,1), rating_count INT, PRIMARY KEY (movie_id, stat_date) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE fact_comment ( comment_id BIGINT AUTO_INCREMENT PRIMARY KEY, movie_id INT NOT NULL, content VARCHAR(300), vote_count INT DEFAULT 0, KEY idx_movie (movie_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

关键点有三个。movie_id直接做主键而不是自增 id，重跑导入时用INSERT ... ON DUPLICATE KEY UPDATE就能实现幂等，不会像自增主键那样每次重跑都多一份数据。movie_genre用(movie_id, genre)做联合主键，把“一部电影属于多个类型”这件事表达清楚，类型分布统计就变成一句GROUP BY genre。字符集统一utf8mb4，是为了让简介和短评里的表情符号、生僻字不会在入库时被截断。索引只加在会被WHERE和GROUP BY用到的列上，年份和评分这两个最常做筛选的字段必须有。

3.2 pandas 清洗流水线：去重、缺失、类型统一

清洗层我习惯写成四个顺序执行的函数，每个函数只干一件事，中间结果可以单独 print 出来看，出问题能立刻定位到是哪一步弄坏的。顺序是：读入 → 去重 → 类型与缺失处理 → 多值展开。

import pandas as pd def load_raw(path_glob="raw/page_*.jsonl"): df = pd.read_json(path_glob, lines=True, dtype={"movie_id": "Int64"}) return df def drop_dup(df): # 同一部电影可能在多次采集中出现，按 id 保留评分人数最多的一条（信息最全） df = df.sort_values("rating_count", ascending=False) return df.drop_duplicates(subset="movie_id", keep="first") def fix_dtype(df): df["score"] = pd.to_numeric(df["score"], errors="coerce") df["rating_count"] = pd.to_numeric(df["rating_count"], errors="coerce").astype("Int64") df["release_year"] = pd.to_numeric(df["release_year"], errors="coerce") # 年份超出合理范围的一律置空，避免折线图出现 0 年这种脏点 df.loc[~df["release_year"].between(1900, 2025), "release_year"] = pd.NA df["score"] = df["score"].clip(0, 10) return df def fill_missing(df): df["country"] = df["country"].fillna("未知") df["duration_min"] = df["duration_min"].fillna(df["duration_min"].median()) return df def explode_genre(df): # "犯罪 剧情" -> ["犯罪", "剧情"]，再展开成一行一个类型 g = df[["movie_id", "genres"]].copy() g["genres"] = g["genres"].fillna("").str.split() return g.explode("genres").rename(columns={"genres": "genre"}).dropna()

errors="coerce"把无法转换的值变成 NaN 而不是抛异常，这在真实数据里几乎是必须的；clip(0, 10)是给评分设一道物理上合理的边界；时长缺失用中位数填而不是均值，因为电影时长分布右偏，少数三小时以上的长片会把均值拉高。explode那一步是把宽表变成长表的标准操作，展开后movie_genre的每一行就是一个(movie_id, genre)对，直接对应桥表结构。

跑完这四个函数，建议固定输出一份体检报告：总条数、去重后条数、各字段缺失率、评分均值与分位数。这份报告既是数据质量的证据，也是论文里“数据预处理”那一节的素材，比纯文字描述有说服力。

3.3 入库策略：批量写与幂等重跑

入库用 SQLAlchemy 的to_sql最省事，但有两个坑要提前处理。一是method="multi"配合chunksize才能拼成批量 INSERT，默认是一条一条发，几千行要跑好几分钟；二是if_exists="append"在主键冲突时会直接报错，重跑必须先处理冲突。

from sqlalchemy import create_engine, text engine = create_engine( "mysql+pymysql://user:pass@127.0.0.1:3306/movie_db?charset=utf8mb4", pool_pre_ping=True ) def upsert_movie(df): cols = ["movie_id", "title", "release_year", "country", "duration_min", "score", "rating_count", "director", "summary", "crawl_date"] # 先写临时表，再用一条 SQL 合并，避免逐行 UPDATE 的性能问题 df[cols].to_sql("tmp_movie", engine, if_exists="replace", index=False, chunksize=500) with engine.begin() as conn: conn.execute(text(""" INSERT INTO dim_movie (movie_id, title, release_year, country, duration_min, score, rating_count, director, summary, crawl_date) SELECT movie_id, title, release_year, country, duration_min, score, rating_count, director, summary, crawl_date FROM tmp_movie ON DUPLICATE KEY UPDATE score = VALUES(score), rating_count = VALUES(rating_count), crawl_date = VALUES(crawl_date) """))

pool_pre_ping=True会在取连接前先探活，长时间跑批不会因为 MySQL 掐掉空闲连接而报Lost connection。临时表 +INSERT ... SELECT的组合，把“重跑”变成一次集合操作，比在 Python 里判断存在性再决定 insert 还是 update 快一个量级。桥表则简单粗暴：先按movie_id删掉旧记录再整批插入，因为类型标签每次采集都可能变，做增量合并反而容易留下脏数据。

4. 接口与图表：Flask 蓝图划分与六个 ECharts 图表落地

后端这一层的职责很单一：接收前端的筛选参数，拼成聚合 SQL，返回 JSON。真正容易出问题的地方不是 Flask 本身，而是“指标口径”和“图表选型”对不对得上——用饼图去画连续变量、用折线图画无序类别，这类错误在毕设答辩现场一抓一大把。

4.1 蓝图划分与接口约定

我按业务域拆三个蓝图：api/basic管电影维度的筛选与分页，api/stat管各类聚合统计，api/comment管短评与词云。统一返回结构{"code": 0, "msg": "ok", "data": [...]}，前端只判断code，出错时把msg直接弹出来，联调阶段能省掉大量猜谜时间。

参数设计上有个小习惯：所有区间型查询都给默认值，start默认 1980、end默认当前年份，前端不传也能返回完整数据。这样接口用浏览器直接打开就能自测，不依赖前端页面。

from flask import Blueprint, jsonify, request import pandas as pd from sqlalchemy import create_engine stat = Blueprint("stat", __name__, url_prefix="/api/stat") engine = create_engine("mysql+pymysql://user:pass@127.0.0.1:3306/movie_db?charset=utf8mb4") @stat.get("/year_score") def year_score(): start = request.args.get("start", 1980, type=int) end = request.args.get("end", 2025, type=int) sql = """ SELECT release_year AS year, ROUND(AVG(score), 2) AS avg_score, COUNT(*) AS cnt FROM dim_movie WHERE release_year BETWEEN :start AND :end AND score IS NOT NULL GROUP BY release_year ORDER BY year """ df = pd.read_sql(sql, engine, params={"start": start, "end": end}) # NaN 不是合法 JSON，统一转成 None，否则 jsonify 直接 500 records = df.astype(object).where(pd.notnull(df), None).to_dict("records") return jsonify({"code": 0, "msg": "ok", "data": records})

用的是:start命名参数而不是字符串拼接，SQL 注入这条路直接堵死。astype(object)是必要的：pandas 的Int64和float64转成object之后，where才能把 NaN 替换成 None，否则jsonify会抛ValueError: Out of range float values are not JSON compliant，前端表现就是一张空白图加一条 500 报错。这个坑我在好几个项目里都见过，第一次遇到时排查了大半天。

4.2 六个图表的指标口径与聚合 SQL

图表选型的唯一标准是“这组数据的类型和它想表达的关系”。年度趋势是时间序列 + 样本量，用柱线组合图：柱表示当年入库电影数，线表示平均分。类型占比是无序类别构成，用饼图或环形图。评分分布是连续变量的频次，用柱状图并固定分箱间隔 0.5 分。评分与热度是两个连续变量的相关性，用散点图，点大小再映射评价人数。类型雷达图用于横向比较三到五个类型在评分、时长、热度上的综合表现。词云只做展示性补充，别把它当分析结论。

散点图那条 SQL 要注意一点：评价人数跨度可能从几千到上百万，直接映射成点大小会出现“一个大圆盖住半个画布”的情况，通常做法是对rating_count取对数再映射symbolSize。类型占比要先排除“类型”字段为空的记录，否则饼图里会多出一块莫名其妙的“未知”。

-- 类型占比 + 各类型均分，一次查询同时喂饼图和雷达图 SELECT g.genre, COUNT(*) AS cnt, ROUND(AVG(m.score), 2) AS avg_score, ROUND(AVG(m.duration_min), 0) AS avg_duration FROM movie_genre g JOIN dim_movie m ON m.movie_id = g.movie_id WHERE g.genre <> '' AND m.score IS NOT NULL GROUP BY g.genre HAVING cnt >= 10 -- 样本太少的类型不参与排名，避免长尾噪声 ORDER BY cnt DESC;

HAVING cnt >= 10这个阈值不是随便定的：只有一两部电影的类型，均分波动极大，放进排名里会把“纪录片均分最高”这种伪结论顶到前排。答辩时被追问“为什么排除小样本”，这就是现成的回答。

4.3 前端配置与联动：ECharts option 怎么写

前端页面结构建议一个页面一块图表，用一个全局筛选条（年份区间 + 类型多选）驱动所有图表重绘。每个图表封装成renderXxx(params)函数，筛选变化时统一调用一遍。下面这张年度趋势图是最典型的组合图写法：

// 年度评分趋势：柱状表示样本量，折线表示平均分，双 Y 轴 const chart = echarts.init(document.getElementById('yearChart')); function renderYear(start, end) { fetch(`/api/stat/year_score?start=${start}&end=${end}`) .then(r => r.json()) .then(({code, data}) => { if (code !== 0) return; chart.setOption({ tooltip: { trigger: 'axis' }, legend: { data: ['样本数', '平均评分'] }, xAxis: { type: 'category', data: data.map(d => d.year) }, yAxis: [ { type: 'value', name: '平均评分', min: 5, max: 10 }, { type: 'value', name: '样本数' } ], series: [ { name: '样本数', type: 'bar', yAxisIndex: 1, data: data.map(d => d.cnt), itemStyle: { opacity: 0.35 } }, { name: '平均评分', type: 'line', smooth: true, data: data.map(d => d.avg_score), symbolSize: 6 } ] }, true); // notMerge = true，切换筛选时清掉旧系列，避免残影 }); } window.addEventListener('resize', () => chart.resize());

setOption(option, true)里的第二个参数是关键：默认是合并模式，切换年份区间后如果某年没有数据，旧的系列还会留在图上，看起来像“数据错乱”。yAxisIndex: 1把样本量挂到右轴，是为了让均分那条线的波动不被柱子的量级压平。resize监听不能少，否则窗口缩放后图表会按初始尺寸裁切。

主题统一用一套浅色系，六个图表的配色从同一个调色板取值，图例位置固定在右上。这些是观感层面的细节，但它们直接影响答辩时评委的第一印象——同一份数据，配色混乱和配色统一，被追问的概率差很远。

5. 避坑排查：从 403 到 NaN 序列化最容易翻车的五个点

这一节列的是我在同类项目里反复遇到的五个问题，每一个都真实出现过，并且都不是靠“再看一遍文档”能解决的。

第一，跑到三四十页之后全部返回 403 或空列表。现象是前几十页正常，之后突然整批失败，重启也不恢复。原因是请求节奏过于均匀加上 UA 固定，被目标站点识别为自动化流量并做了限时限制。解决办法是把 UA 放进一个列表随机取、间隔改成 2 到 4 秒随机、复用 Session 带上 Cookie，并且遇到 403 立刻停止本轮，隔半小时再续爬，不要硬刚。断点续爬这时候就是救命设计。

第二，中文入库后全是问号。现象是页面解析出来看着正常，入库后查询变???。原因通常是两处：请求端没覆盖r.encoding，页面声明与实际编码不一致；或者连接串漏了charset=utf8mb4，驱动按 latin1 发数据。解决是解析前统一r.encoding = r.apparent_encoding，建表和连接串都显式指定utf8mb4，两边都对齐。

第三，接口返回 500，前端图表一片空白。现象是浏览器控制台看到 500，后端日志里是Out of range float values are not JSON compliant。原因是 pandas 的 NaN、NaT 不是合法 JSON 值，jsonify直接拒绝序列化。解决是在to_dict之前统一df.astype(object).where(pd.notnull(df), None)，或者干脆在 SQL 层用COALESCE给默认值。这个坑几乎每个用 pandas + Flask 的组合都会踩一次。

第四，重跑导入后平均值全错。现象是第二次导入之后，年度均分莫名其妙变了，条数也翻倍。原因是to_sql用了if_exists="append"加自增主键，同一部电影被插了两遍。解决是movie_id做主键 + 唯一约束，改用临时表 +ON DUPLICATE KEY UPDATE合并，桥表按movie_id先删后插。

第五，筛选切换后图表卡顿甚至数据错乱。现象是点了几次筛选，图上出现叠在一起的旧数据，或者动画卡住。原因是setOption用了默认的合并模式，加上单次返回的数据点过多。解决是setOption(option, true)强制不合并，同时在服务端把聚合粒度压到百级以内，别把几万条原始记录直接丢给浏览器去画。

提示：这五条里，第一条和第三条最好在开发第一天就处理好，否则后面每改一次都要重新踩一遍。

6. 验收与答辩：按这张检查表走一遍再交

交付前的最后一件事，我建议不是继续加功能，而是拿一张检查表从零开始跑一遍。很多人栽在“本地能跑、换台机器就跑不起来”上，而这恰恰是评委最容易验证的部分。

我的检查表分四段。第一段是环境：全新的虚拟环境从requirements.txt装依赖，MySQL 用提供的 SQL 脚本建库建表，全程不手工改任何配置。第二段是数据：爬虫冷启动跑十页，中断后重启验证断点生效；清洗脚本连跑两次，核对dim_movie条数不变。第三段是接口：六个接口逐个在浏览器打开，确认code为 0、字段名和前端一致、空数据不报 500。第四段是页面：所有图表在 1366 宽度和手机宽度下各看一遍，筛选切换三次确认无残影。

答辩环节最常被问的三个问题，其实都可以用这套结构直接回答：数据从哪来——采集层的字段表和拒收记录；数据质量怎么保证——清洗四步法和体检报告；系统的价值在哪——不是“能画图”，而是“能回答某年某类型的评分是否显著高于整体”这类具体问题。准备两三个这样的结论，比展示十张图有效。

我自己的教训是第一次做这类系统时，只顾着把图堆满首页，结果被问到“你这张饼图的百分比分母是什么”时当场卡壳。从那以后我每次做数据类项目，都会在写前端之前先把每个图表的指标口径用一句话写在文档里，口径说不清的图直接删掉。希望这套结构能帮到你，少走一遍我绕过的弯路。

本文还有配套的精品资源，点击获取