简介这是一份基于Python的猫眼电影数据分析可视化系统的毕业设计文档面向计算机相关专业学生、数据分析初学者及电影行业数据研究者提供从数据获取到可视化展示的完整设计思路。系统方案覆盖数据爬虫采集、Pandas清洗、Matplotlib与Echarts可视化、Flask Web展示等完整流程并结合电影评分、票房趋势、类型分布等维度给出分析思路。压缩包内为1个docx文档大小约3.31MB内容含中英文摘要、目录、绪论、国内外研究现状、系统设计与实现说明层次清晰便于直接阅读和二次修改。目前已有381人学习下载。文档还体现了代码可维护性与系统扩展性设计可作为课程设计、毕业设计或入门电影数据分析项目的整体参考帮助读者快速理解数据采集、清洗、分析到可视化展示的落地方法也能支撑后续功能扩展与论文撰写。1. 猫眼电影数据分析可视化为什么“评分最高”不等于“值得看”很多人启动这个项目时第一反应是把猫眼的评分排行榜抓下来画个条形图然后收工。这个思路没错但它浪费了猫眼数据里最有价值的部分评论和票房。评分是结果评论是过程票房是最终校验。基于 Python 猫眼电影数据分析可视化系统的设计与实现核心不是“做一个好看的图表”而是把“抓数据—清洗—分析—展示”串成一条可复现的链路让你能从同一份数据里解释“为什么一部 9.5 分的文艺片票房不如 6.8 分的商业片”这类问题。这套方案适合三类人拿 Python 练手全流程的初级开发者、需要课程设计或毕业设计选题的学生、以及想用数据修正观影直觉的产品向从业者。我下面讲的是我自己反复做过的那套路线参数和坑都是实际撞出来的。2. 数据从哪来猫眼榜单与评论的抓取选型和反爬参数一个数据分析系统里爬虫决定瓶颈。数据没抓好后面所有清洗分析都是空中楼阁。猫眼的网页端是服务端渲染加部分接口动态加载移动端页面用了一批 ajax 接口两套路线都能走。我的建议是榜单走网页端 HTML 解析评论走移动端 JSON 接口不要只套一个方案打天下。2.1 为什么是 requests HTML 解析而不是 Selenium第一直觉通常是 Selenium 打开浏览器模拟点击这样最“省脑子”。但猫眼榜单页的 HTML 本来就是请求一次就能拿全的用 Selenium 反而有三个坏处启动浏览器耗时翻倍、内存占用高、更容易触发风控。实际做的时候requests 一个 GET 请求带上头两秒就能拿到整个页面。我一般先把页面源码拉到本地然后用浏览器开发者工具定位电影信息所在区块。猫眼网页版榜单页的结构里每部电影都包在dd标签中里面依次是排名、片名、主演、上映时间、评分。解析用 BeautifulSoup 或正则都可以我偏爱先用find_all(dd)把整个小方块切出来再逐块拆字段。这样出错时可以单独打印一块来调试不用把整个页面结构都背下来。核心请求代码是这么写的import requests import time import random def fetch_maoyan_board(page0): headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0 Safari/537.36, Referer: https://www.maoyan.com/board/1, Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/avif,*/*;q0.8, } url fhttps://www.maoyan.com/board/{page 1} resp requests.get(url, headersheaders, timeout10) resp.raise_for_status() return resp.text逻辑说明这里模拟的是普通浏览器访问User-Agent和Referer缺一不可Referer填榜单页是因为服务端会校验请求来源。page从 0 开始对应页面上board/1第一页timeout10是给每个请求的硬上限避免某个页面卡住把整个爬取流程拖死。拿到resp.text之后先存一份 HTML 到本地再去解析这样就算解析逻辑写错了也不用重新请求减少一次反爬暴露。参数说明timeout和sleep是两个容易忽略的地方。timeout设置过大任务失败时你会发现脚本已经卡了一分钟设置过小网络抖动又会误杀。本地网络环境 10 秒足够。请求频率方面单页爬取不觉得但后面爬评论时几十个请求连着打出去没有休眠几乎必被封。2.2 榜单页解析正则与 BeautifulSoup 的取舍榜单页结构规整解析方式我推荐 BeautifulSoup 切成块再用正则收尾。find_all(dd)拿到的每一块里面只有一部电影的完整信息字段抽取逻辑清晰单块出错不影响其他数据。这里给出能直接跑的解析函数from bs4 import BeautifulSoup import re def parse_board(html): soup BeautifulSoup(html, html.parser) movies [] for dd in soup.find_all(dd): try: title_tag dd.select_one(.name a) star_tag dd.select_one(.star) time_tag dd.select_one(.releasetime) score_tag dd.select_one(.score) if not title_tag: continue movies.append({ name: title_tag.get_text(stripTrue), actors: star_tag.get_text(stripTrue).replace(主演, ), release_date: re.search( r(\d{4}-\d{2}-\d{2}), time_tag.get_text() ).group(1), score: float(score_tag.get_text(stripTrue)), }) except (AttributeError, ValueError): continue return movies逻辑说明.select_one(.name a)按 CSS 选择器定位片名链接比连续多个find()更紧凑。stripTrue会把文本两端的换行和空格全部去掉避免入库时字段前后带空白。上映时间用正则提取因为页面上有的写“2024-05-01 上映”有的写“2024-12-05 中国内地上映”只取日期部分后面转日期类型才不会报错。参数说明星变量里的“主演”前缀有的页面有、有的没有这里直接 replace 成空串宁可少一个字也不留前缀。评分转 float 时捕获ValueError遇到“暂无评分”这类占位文本直接跳过这一条因为这种片子在分析里没有价值留在数据里反而污染均值。为什么不直接在一个正则里配全因为页面结构稍微调整就会让一个超长正则整体失配分块拆字段挂一个还有其它字段能用。2.3 评论接口从详情页拿 movieId再请求 JSON榜单数据只有几十条做评论情感分析远远不够。猫眼评论是动态加载的接口返回 JSON关键参数是movieId。在浏览器里打开任意一部电影的详情页地址栏 URL 里/films/后面那一串数字就是它。拿到后直接请求评论接口def fetch_comments(movie_id, limit15): url fhttps://m.maoyan.com/mmdb/comments/v2/movie/{movie_id}.json params { _v_: yes, offset: 0, limit: limit, type: 2, movieId: movie_id, } headers { User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 17_5 like Mac OS X) AppleWebKit/605.1.15, Referer: fhttps://m.maoyan.com/films/{movie_id}, } resp requests.get(url, paramsparams, headersheaders, timeout10) data resp.json() return [c[content] for c in data.get(cmts, [])]逻辑说明这里用的是移动端评论接口请求参数比网页端少UA 也要换成 iPhone 的不然服务端会拒绝。offset是分页偏移每页返回条数由limit控制。type2代表全部短评type1是好评type3是差评如果你只想对比正负情绪把三个 type 各抓一组比全量抓下来再筛选体验好得多。参数说明limit千万别一次给 100实测猫眼这个接口对单页数量有上限超过会静默返回空数组不报错但让你白白浪费一个请求。我一般固定 15 条一页翻页时offset 15。另外评论接口偶尔会要求追加token参数这个 token 在详情页的第一次请求返回文本里遇到全部返回空cmts时回详情页源码里搜token就能找到。这种临时参数经常变代码里把它做成函数参数兜底别写死。到这里榜单和评论两条数据通道就有了。加上time.sleep(random.uniform(1, 3))控制节奏能连续跑几百个请求不断线。下一步就是把拿到的结果清洗入库这一环节做得越扎实后面分析阶段就越省心。3. 清洗与存储把脏数据变成一张能直接分析的表从页面和接口拿到的数据直接进分析阶段一定会翻车。重复的电影名、缺失的评分、同片不同名、评论里的标签符号这些问题不清理干净后面画出来的图自己都不敢信。这一节讲我固定用的清洗顺序和入库策略。3.1 四个必做的清洗动作第一个是去重。榜单每个月都在变你如果分几天爬同一部电影会出现多次直接按name去重保留第一次抓到的记录。第二个是评分补全页面里的“暂无评分”是占位符要先转成NaN而不是直接强转 float否则会抛ValueError中断整个流程。第三个是评论去噪短评里常有“#喜剧#”“某人”这类短标签情感分析和词频统计都会被干扰先替换掉。第四个是日期统一上映时间统一成YYYY-MM-DD票房字段里的“万”字去掉再转数值。import pandas as pd df_movies pd.read_csv(movies_raw.csv) df_movies[score] pd.to_numeric(df_movies[score], errorscoerce) df_movies df_movies.dropna(subset[score]) df_movies df_movies.drop_duplicates(subset[name]) df_comments pd.read_csv(comments_raw.csv) df_comments[content] df_comments[content].str.replace( r#[\u4e00-\u9fa5]#, , regexTrue ) df_comments[content] df_comments[content].str.replace( r[\u4e00-\u9fa5a-zA-Z0-9], , regexTrue )逻辑说明pd.to_numeric(errorscoerce)会把“暂无评分”这类非数字文本直接转成NaN比先判断再替换少写两行。dropna(subset[score])把没有评分的电影剔掉因为它们进不了评分分布分析。评论里的#标签#和某人用正则一次剥掉词频统计时才不会出现“#喜剧#”这种带符号的词条。注意这里用的是str.replace配正则不是普通字符串替换所以regexTrue必须带上。参数说明去重只看name在榜单数据里够用但如果你爬了不同上映地区的数据片名会重复这时要用name release_date组合去重。评论去重则按movie_id content组合因为不同用户可能发完全一样的短评文本单字段去重会把这些有效样本误删。3.2 入库SQLite 建表与写入项目要叫“系统”数据就不能一直躺在 CSV 里。分析阶段的数据量撑死几十万条SQLite 完全够用而且没有服务端部署成本。MySQL 的安装、账号、权限配置对本地分析项目来说是额外负担我一般只在多人协作或数据规模真的到千万级才换。下面是建表脚本import sqlite3 conn sqlite3.connect(maoyan.db) cursor conn.cursor() cursor.execute( CREATE TABLE IF NOT EXISTS movies ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL UNIQUE, actors TEXT, release_date TEXT, score REAL ) ) cursor.execute( CREATE TABLE IF NOT EXISTS comments ( id INTEGER PRIMARY KEY AUTOINCREMENT, movie_id TEXT, content TEXT, sentiment REAL, created_at TEXT DEFAULT CURRENT_TIMESTAMP, UNIQUE(movie_id, content) ) ) df_movies.to_sql(movies, conn, if_existsappend, indexFalse) df_comments.to_sql(comments, conn, if_existsappend, indexFalse) conn.commit() conn.close()逻辑说明两张表的唯一约束是关键。movies.name唯一防止重复录入同一部影片comments表上的UNIQUE(movie_id, content)是兜底防重就算爬虫脚本重复执行三次同一条评论也只入库一次。to_sql的if_existsappend适合增量写入全量重建时才用replace。参数说明created_at字段用DEFAULT CURRENT_TIMESTAMP自动记录入库时间方便排查“这批数据是不是上次跑任务留下的”。sentiment字段我一开始就预留了虽然入库时还是None但建表时留好列位后面情感分析结果可以直接UPDATE回表不用改表结构。这是建表的一个习惯为下一步分析预留字段。3.3 增量写入幂等上传不刷重复数据系统的数据价值在于持续更新。固定做法是每天跑一次增量任务只爬新上榜的电影和新增评论然后INSERT OR IGNORE。幂等写入的好处是任务重复执行也不会把表撑爆def incremental_load(df_new, table): with sqlite3.connect(maoyan.db) as conn: df_new.to_sql(tmp_table, conn, if_existsreplace, indexFalse) conn.execute(BEGIN) conn.execute(fINSERT OR IGNORE INTO {table} SELECT * FROM tmp_table) conn.execute(DROP TABLE tmp_table) conn.commit()逻辑说明先写入临时表再插入目标表是规避 Pandas 与 SQLite 类型映射差异的通用做法尤其是日期字符串容易在直插时变成数字。INSERT OR IGNORE依赖建表时的UNIQUE约束来做去重比先查一遍再插入的方式少一次全表扫描几十万条数据下快一个量级。参数说明函数里的临时表名固定为tmp_table如果两个增量任务并发执行会互相覆盖本地场景无所谓部署到服务器做定时任务时要注意串行。BEGIN手动开启事务让整个插入要么全成、要么全不成防止中途报错留下半批数据。4. 分析什么才能说明问题评分、票房与评论情绪的联动分析设计上最容易犯的错是“为了有图而画图”。拿着评分画一张柱状图然后就没有然后了。数据可视化系统的价值在于你能从中发现联系。猫眼数据里至少有三种联动值得做评分分布形态、评分与票房的背离、评论情绪与口碑的落差。4.1 评分分布均值会骗人分布不会第一件要确认的事情不是平均分而是分布形态。猫眼评分整体偏高8 分以上扎堆均值 8.2 看着挺好但直方图一看7.5 分以下是断崖式下跌。用 Pandas 把评分切成区间看集中趋势才有体感。import pandas as pd bins [0, 2.5, 5, 6.5, 7.5, 8.5, 9.9] labels [极差, 较差, 及格, 中等, 优秀, 神作] df_movies[score_seg] pd.cut( df_movies[score], binsbins, labelslabels, rightFalse ) seg_count df_movies.groupby(score_seg, observedFalse).size() print(seg_count)逻辑说明pd.cut把连续分数离散化成六个档位groupby之后size()得到每档影片数量。为什么下界从 2.5 开始猫眼几乎没有低于 2.5 分的影片区间拉得太开图表上会有大片空白区间观感差且信息密度低。rightFalse表示区间左闭右开避免 7.5 分同时落进“中等”和“优秀”两档。参数说明档位边界是按业务经验调的不是固定规则。你拿到自己的数据后先跑一下df_movies[score].describe()看分位数把分位数作为切分点更合理。比如你的数据里 6 分以下占比特别高就把“较差”下界改成 4“及格”下界改成 6这样每档都有足够样本画出来的堆叠图才有区分度。4.2 评分与票房背离找到“值得看但不卖座”的电影票房字段在猫眼榜单里有单位“万”清洗时先去掉。分析主题通常是“评分前十”和“票房前十”两个榜单的重合度。重合超过七成说明市场健康重合度低说明口碑与观众选择背离这本身就是可输出的结论。具体的分组聚合逻辑如下df_movies[boxoffice] ( df_movies[boxoffice_raw] .str.replace(万, , regexFalse) .str.replace(亿, 0000, regexFalse) .astype(float) ) top_score df_movies.nlargest(10, score)[name].tolist() top_box df_movies.nlargest(10, boxoffice)[name].tolist() overlap set(top_score) set(top_box) print(f评分榜与票房榜重合 {len(overlap)} 部) print(f评分高但票房未进前十: {set(top_score) - set(top_box)})逻辑说明这个分析的两个nlargest就是取前 10 名然后用集合运算求出交集和差集。评分高但票房未进前十这个集合就是“口碑好但市场不买账”的样本是整套系统里最适合展开成结论的部分。票房单位转换里亿被替换成0000是因为 1 亿等于 1 万万这样字符串就能直接转成以万为单位的数字。参数说明nlargest默认按降序取前 N 条如果数据里有NaN会报错要确保这步之前已经dropna。票房和评分的 Top 榜单在项目里每次都同时算因为单独算一个榜看不出任何关联只有并排放才有对照意义。4.3 评论情感用 snownlp 打分趋势可信、单条别信影评情感分析轻量做法用snownlp。它不用训练装完就能跑缺点是底座语料偏商品评论对反讽、玩梗、借代这些影评常用写法判断很不稳定。所以我的原则是单条评论的分数不用只用来做分组统计趋势。from snownlp import SnowNLP def sentiment_batch(comment_list): scores [] for c in comment_list: try: scores.append(SnowNLP(c).sentiments) except Exception: scores.append(0.5) return scores df_comments[sentiment] sentiment_batch(df_comments[content].tolist()) senti_stat ( df_comments.groupby(movie_id)[sentiment] .agg([mean, std, count]) .reset_index() )逻辑说明单条评论返回 0~1 之间的分数0.5 是中性线。batch 函数里拿 try 包住整条是因为个别评论里的 emoji 或生僻符号会让SnowNLP直接抛异常给 0.5 中性分比中断任务强得多。groupby(movie_id)算出的mean是影片平均情感倾向std是标准差均值中性但标准差极大说明评论两极分化严重这种片子的“争议性”本身就是分析结论。参数说明snownlp在影评上的单条准确率通常只有六成左右所以这个指标只适合横向比较比如“这部文艺片情感分 0.72那部喜剧情感分 0.55”而不是拿着单条 0.83 去判断某条评论是夸是骂。要更高精度可以把评论文本收集起来换大模型 API 做批量判断代价是成本和耗时上升。分析产出最后汇总成一张宽表方便可视化阶段直接读取。宽表字段包含片名、评分、票房、情感均值、情感标准差。前端接口只需要查这张表不需要在请求里跑 Pandas 计算响应时间从秒级降到毫秒级。5. 避坑手册抓取与展示阶段最容易踩的四个坑这部分每一个都是真实翻过车的按“现象 → 原因 → 解决”写你在自己机器上改几个参数就能躲开。5.1 现象爬着爬着突然 403后续所有请求全部被拒原因基本是请求频率太高或请求头太素。猫眼的限流策略是 IP 加 User-Agent 双维度同一个 UA 高频访问会先返回 403再过一会儿连 IP 都进黑名单换 UA 也没用。解决把每两个请求之间的休眠拉长我固定用time.sleep(random.uniform(1, 3))24 小时跑一次增量。UA 一定要用完整浏览器默认值不要带python-requests/x.x.x特征。爬评论这种几十个请求的批量任务中间一定要加随机抖动固定 2 秒休眠比不睡更容易触发模式识别。如果改完仍然 403就先停一小时本机 IP 不会永久进黑名单是半小时到三小时自动解封。5.2 现象上映时间字段解析完全是“无”页面里明明有原因正则写得太乐观只匹配了2024-05-01这一种格式而页面有的是“2024-5-1 上映”有的是“2024年5月1日中国内地上映”还有的是“2024-05-01 00:00:00”。一旦失配group(1)抛AttributeError被 except 吞掉这条记录直接跳过所以字段全是空。解决先把一小块页面文本打印出来看一眼原始格式别急着写正则。下面这个表达式覆盖了三种常见写法release_match re.search(r(\d{4}[-年/]\d{1,2}[-月/]\d{1,2}), time_text) if release_match: release_str release_match.group(1).replace(年, -).replace(月, -).replace(/, -)逻辑说明正则先放宽到兼容-、年、/三种分隔符取出2024-05-01、2024年5月1日、2024/5/1三种写法再用三个 replace 统一成2024-5-1最后用pd.to_datetime转标准格式。这里不要试图写一个超长正则一步到位分隔符一多正则的维护成本会指数上升。5.3 现象CSV 用 Excel 打开后中文全乱码记事本打开却正常原因Pandas 的to_csv默认编码是utf-8Excel 在中文 Windows 上默认用gbk解码解码错位就是乱码。记事本能正常显示是因为系统会把没有 BOM 的文件自动按系统默认编码尝试反而避开了这个坑。解决写文件时统一指定encodingutf-8-sig它会往文件头写入 BOMExcel 打开时就能识别。后续再读这个文件时read_csv不指定编码也能正常读因为utf-8-sig对 Python 来说是 UTF-8 的超集。这条建议适用于所有给非技术同事交付 CSV 的场景尤其是对方打开文件只看几眼就下结论乱码会直接让人觉得数据是坏的。5.4 现象ECharts 图表数字和数据库里的对不上原因通常是两类。一是后端把数值以字符串拼进了 JSON前端取到的是8.5ECharts 数值轴画图时解析异常导致整条柱状图偏移或消失。二是分析阶段把缺失值NaN直接填充成了空字符串前端拿到空字符串后ECharts 把该条数据连同时间轴错位处理了。还有一个常被忽略的点评论表里同一条评论被抓了两次计数虚高图表看起来就很怪。解决后端接口返回前统一强转类型数值字段用int()或float()缺失值保留null而不是空字符串前端拿到 JSON 后先console.log打印一遍字段类型再交给图表。评论计数这一块SQL 里用COUNT(DISTINCT content)而不是COUNT(*)结合建表时的UNIQUE(movie_id, content)约束数字才对得上。6. 让系统真正可看Flask 接口与 ECharts 大屏的轻量落地最后一段路是可视化。系统走到这里数据链路已经完整关键是职责分离后端只出 JSON前端只负责画图两边不抢活。我用的轻量方案是 Flask 读 SQLite 出统计接口ECharts 渲染大屏整个服务端代码不到 200 行。6.1 后端两个通用接口Flask 接口这块最有复用价值的是“读库出 JSON”的通用封装。分析阶段已经生成了统计宽表接口层不需要任何计算逻辑只做查询和序列化from flask import Flask, jsonify import sqlite3 import pandas as pd app Flask(__name__) def load_query(sql): with sqlite3.connect(maoyan.db) as conn: df pd.read_sql(sql, conn) return df.to_dict(orientrecords) app.route(/api/score_seg) def api_score_seg(): data load_query( SELECT score_seg, COUNT(*) as cnt FROM movies GROUP BY score_seg ) for item in data: item[cnt] int(item[cnt]) return jsonify({data: data})逻辑说明to_dict(orientrecords)把 DataFrame 转成列表套字典正好是前端要的 JSON 结构。cnt强转int是因为 SQLite 返回的可能是 long 型直接jsonify在部分环境下报TypeError。两个接口函数结构完全一样只是 SQL 不同新增图表时复制函数改 SQL 即可不用碰前端代码。参数说明jsonify默认会把中文转成\uXXXX的 Unicode 转义序列浏览器能解析但调试时看不出内容。想直接看中文在app Flask(__name__)之后加一行app.json.ensure_ascii False。另外pd.read_sql需要sqlite3.Connection对象用with包住保证连接关闭避免长时间运行后出现database is locked。6.2 前端大屏的布局与交互大屏图表布局我推荐CSS Grid而不是 flex。Grid 能精准控制每个区块的宽高比缩放窗口时图表不会挤成一团。交互上最值得花时间的是图表的联动比如点击评分分布柱状图里的某一档下面的榜单表格同步过滤出该档位的电影。这个用 ECharts 的dispatchAction就能实现chart.on(click, function (params) { fetch(/api/movies_by_seg?seg${params.name}) .then(res res.json()) .then(data { tableData data.data; renderTable(tableData); }); });逻辑说明chart.on(click)是 ECharts 提供的原生点击事件params.name拿到的就是柱状图横轴档位名。前端拿到它之后请求新接口把表格数据替换成对应档位影片列表。这个联动逻辑是整套系统里最有“系统感”的部分比单纯堆十个不相关的图表更有说服力。数据量大的折线图记得加dataZoom组件不然 200 天的票房曲线挤在 1000 像素宽度里锯齿会盖过趋势。6.3 交付前的五个自检问题我每次交付这类系统前都会拿五个问题过一遍新增数据后接口返回有没有更新评论情感列有没有大量 0.5 的占位接口返回的字段是不是字符串和数字分得清大屏在 1440 和 1920 两种分辨率下图表是否错位数据库里有没有残留的乱码记录。五个问题都通过再交给使用者。这套系统的价值不在于图表多炫而在于你能用同一套代码换数据源——把猫眼的字段映射抽成一个字典换豆瓣、换淘票票清洗和分析链路完全不用重写。我自己从第一个版本到现在每次回看都会发现当初某个清洗步骤是多此一举或不够彻底这也是做数据系统的常态先跑通再优化。希望这篇笔记对猫眼数据抓取、分析和可视化这几个环节的处理能帮到你少走点我走过的弯路。本文还有配套的精品资源点击获取
