如果这学期你也在为课程设计选题发愁看到“基于Python爱奇艺影视数据可视化分析系统”这种题目第一反应大概率是又是老一套的爬虫数据库浏览器图表都快烂大街了。说实话我一开始也这么想但当我真的把整套源码、数据库文件、文档铺开一行一行跑通之后才发现这类项目能成为高频选题是有原因的——它把Python数据采集、数据清洗、数据存储、前后端交互和可视化表达全串在了一条线上是非常典型的全流程练手项目。这套系统做的事情用一句话讲清楚从爱奇艺这类视频平台采集公开的影视数据整理干净后落进数据库再用Web页面把热度、类型、地区、评分、年份等维度以图表形式展示出来。它不是一个只能截图交差的空壳而是能真正运行、看到数据、甚至部署到服务器上的完整项目。如果你正在做课程设计、毕业设计或者想用Python练一把“数据分析闭环”这篇文章应该能帮你少走不少弯路。我会从需求分析、技术选型、采集层实现、数据库设计、可视化搭建、项目复现和踩坑记录七个方面把这个系统拆开揉碎讲清楚。1. 先说清楚这套影视数据分析系统到底在分析什么1.1 爱奇艺平台上有哪些值得分析的数据很多同学拿到项目第一件事就是看代码我觉得应该反过来先看数据。爱奇艺影视信息里常见的公开字段有这些影视名称、类型标签剧情、喜剧、动作、爱情、悬疑、动画等、主演、导演、地区/国家、上映年份、评分、热度值、集数、上线时间、简介。光这些字段就能支撑起五六种不同角度的分析。举几个可以直接落地的分析方向类型分布用饼图/环形图看平台内容结构到底哪个类型占大头热度排行统计当前热度值前20的作品用横向条形图展示直观看出谁是热门年份产量趋势按上映年份统计电影/剧集数量生成柱状图或者面积图能看出内容供给的涨跌地区分布把国产、欧美、日韩、港台等地区的数据做成占比图评分分布用直方图看评分集中区间判断平台内容整体质量热度与评分关系用散点图看高热度作品是否真的高评分这个角度比较有意思也适合写进设计说明书作为“分析亮点”。说白了这套系统的价值不是“爬了数据然后画两张图”而是让数据回答具体问题。答辩或者写文档的时候能说清楚“我为什么选这个图表类型、这个图能说明什么”比堆十个图表有用得多。1.2 系统的最终效果与功能清单我复现这个项目之后把功能整理成了一份清单你可以对照检查自己手里那套源码缺了哪块顶部数字卡片展示影视总量、覆盖类型数、平均评分、最高热度四个核心指标热度趋势图以折线图展示每日Top20热度的整体变化或者某一部剧的时间序列热度类型分布图环形图标注每个类型下的作品数量和占比地区分布图柱状图或者地图看内容来源地区评分分布图直方图展示评分区间人数/作品数热门榜单表格可排序的影视列表按热度降序展示片名、类型、年份、评分等筛选器按类型、年份范围、地区作者筛选筛选后图表联动刷新。如果你的目标只是交一份课程设计做到上面这些已经超过平均水平了。如果还想加点分可以加一个“评分Top10”榜单和“热度异动提醒”的小模块后面我会在扩展方向里细说。2. 技术方案选型为什么是requests SQLite Flask ECharts2.1 爬虫框架自己写requests比Scrapy更适合这个场景我在很多项目里都碰到过一个选择到底用Scrapy还是自己写requests这个项目我推荐后者原因很实际。Scrapy确实强大下载中间件、爬虫中间件、Item Pipeline、调度器、去重队列都是现成的适合大规模、多域名、需要增量爬取的场景。但放到这个影视分析系统里学习成本和代码复杂度反而不划算。数据量也就是几千到几万条采集频率不会太高用requests加一个重试函数脚本两百行内就能写得明明白白。有人可能会问如果对方平台是“前端渲染 复杂反爬”怎么办那我会考虑Playwright这种浏览器自动化方案但代价是内存占用高、环境依赖重、部署麻烦。这个项目如果页面里能直接拿到JSON数据接口requests就完全够用。你先用浏览器开发者工具切到Network面板刷新榜单页面找到返回影视列表的XHR请求看看它的响应结构八成比你想的要干净。2.2 数据库SQLite足够用但要注意并发写课程设计和中小型个人项目数据量基本在几万条以内SQLite是性价比最高的选择。整个数据库就是一个单文件拷贝到任何一台机器都能打开不需要安装MySQL服务也不需要配置账号密码。这对答辩演示非常友好。但SQLite也有脾气最典型的就是并发写时容易报database is locked。Web服务如果同时有多个进程写同一个SQLite文件就会出现这个问题。我的处理办法是分层采集脚本负责写库可视化服务只负责读库两边互不干扰写操作尽量集中在同一个进程里配合conn.execute(PRAGMA journal_modeWAL)能减少读写锁冲突。如果后面数据量真的上了百万级或者要部署到公网给多人同时用再迁移到MySQL也不迟。迁移时要注意修改pymysql/mysql-connector连接方式SQL语句本身不需要大改。2.3 可视化展示ECharts Flask是快速交付的组合可视化部分我接触过几种方案。直接用Excel或者Power BI做静态图表演示效果不够“系统”用Vue ECharts做前后端分离工程化能力强但对一个课程设计来说又偏重了用Flask Jinja2模板渲染页面加上ECharts在前端画图是最平衡的方案。这里有个小建议后端不要直接把数据塞进HTML模板而是提供JSON接口前端用fetch动态获取。比如/api/type_distribution返回[{name: 剧情, value: 120}, ...]页面加载后请求这个接口再渲染图表。这样做的好处是前后端职责清晰后续要换Vue或者做App端对接接口可以无缝复用。3. 爱奇艺数据采集的实现细节与反爬处理3.1 爱奇艺数据源的两种拿法我在实现采集层时一般会优先找JSON接口。打开浏览器开发者工具切到Network - XHR刷新影视榜单页面能看到不少返回JSON数据的请求里面通常直接包含片名、评分、类型、热度值等字段。相比解析HTMLJSON处理起来要省太多事字段层级清楚也不需要跟标签嵌套较劲。如果找不到JSON接口或者接口需要的签名参数太复杂那就退一步用页面解析。用requests拿HTML再用BeautifulSoup按CSS选择器定位影视卡片把标题、评分、类型这些字段从一个一个节点里抠出来。这条路代码会更脆只要页面结构一改选择器就要跟着改。所以我始终建议优先找结构化数据接口。需要提醒一句只采集页面公开展示的榜单和影视信息不要碰会员专属内容、非公开数据也不要短时间内高频猛抓。这个系统是学习研究用途保持合理礼貌的请求频率是基本底线。3.2 Header伪装、Cookie管理与请求间隔很多新手写爬虫直接requests.get(url)拿回来一堆code: 401或者验证页其实是没带请求头。浏览器在发请求时会自动带上User-Agent、Referer、Accept等字段服务端靠这些判断你是真人还是脚本。我们伪造一个正常的浏览器请求头请求成功率会高非常多。如果目标接口需要登录状态需要从浏览器里把Cookie复制出来加进requests的cookies参数。不同浏览器的Cookie可能包含一些加密标识直接复制整体字符串是最省事的方式。请求间隔也是重点。我在采集脚本里习惯加一个随机延时代码大概长这样import random import time import requests 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, Referer: https://www.iqiyi.com/, Accept: application/json, text/plain, */*, } def safe_get(url, paramsNone, cookiesNone, retries3): for attempt in range(retries): try: time.sleep(random.uniform(0.5, 1.5)) resp requests.get( url, headersHEADERS, paramsparams, cookiescookies, timeout10 ) resp.raise_for_status() return resp.json() except Exception as e: print(f请求失败第{attempt 1}次重试{e}) time.sleep(2) return None这个safe_get函数在一个项目里被复用了无数次。随机0.5到1.5秒的间隔既不会太慢也能明显降低被封概率。重试逻辑更是必备——网络波动在长任务采集中太常见了。3.3 字段清洗从JSON里抽数据并统一格式拿到JSON之后不能直接往数据库里塞一定得清洗。这块是最容易被低估的环节也是最影响图表展现质量的环节。常见的脏数据情况有这几种热度值是字符串比如“1.2亿”、“8500万”需要转成统一的数字某些字段缺失评分是空值年份是“”一个影视同时属于多个类型字段长成“剧情,爱情”或者“剧情/爱情”年份可能是一串日期“2023-08-10”需要抽出4位年份。处理热度值的时候写一个专门函数比较稳妥import re def clean_hot(value): if not value: return 0.0 match re.search(r([\d.])\s*(万|亿)?, str(value)) if not match: return 0.0 num float(match.group(1)) unit match.group(2) if unit 万: num * 10000 elif unit 亿: num * 100000000 return num另外类型字段建议拆开存。比如“剧情,爱情”如果直接作为一个字符串存进category字段后面做“类型分布”时会很被动——要么只能用LIKE %剧情%模糊搜索要么统计出来的类别权重失真。我的习惯是建一张movie_category关联表一部影视可以对应多个类型统计时拆成多行参与聚合。这一点在数据库设计阶段就要想好。3.4 断点续采与日志设计采集脚本如果一次要跑几万条数据很容易在中途因为网络波动、服务端限流而中断。如果没有断点续采每次都要从头跑那就是纯浪费时间。我在脚本里加了两个简单机制第一把采集进度写到本地文件比如progress.json每次成功处理一页就更新last_page第二失败时记录日志loguru是很好用的选择。import json PROGRESS_FILE progress.json def save_progress(page): with open(PROGRESS_FILE, w, encodingutf-8) as f: json.dump({last_page: page}, f) def load_progress(): try: with open(PROGRESS_FILE, r, encodingutf-8) as f: return json.load(f).get(last_page, 1) except FileNotFoundError: return 1 start_page load_progress() for page in range(start_page, total_pages 1): data safe_get(url, params{page: page, page_size: 20}) if data is None: break # 解析、清洗、入库 save_progress(page)别看代码简单实际采集中救过我好几次。断点续采看起来是个“很小的功能”但写入文档和代码注释里会让整个项目的完整度上一个大台阶。4. 数据库设计与数据落库的实操4.1 三张核心表影视信息、类型关联、热度历史数据库结构会直接影响后续可视化的复杂度。我在这个项目里用的是三张核心表。第一张是影视基础信息表movie_infoCREATE TABLE IF NOT EXISTS movie_info ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, category TEXT, area TEXT, year INTEGER, score REAL, hot_value REAL, actors TEXT, director TEXT, description TEXT, url TEXT, updated_at TEXT, UNIQUE(title, year) );第二张是影视类型关联表movie_category解决一部影视多个类型的问题CREATE TABLE IF NOT EXISTS movie_category ( id INTEGER PRIMARY KEY AUTOINCREMENT, movie_id INTEGER, category TEXT, UNIQUE(movie_id, category) );第三张是热度历史表movie_hot_history用来记录同一部影视在不同日期的热度值这是做趋势图的数据基础CREATE TABLE IF NOT EXISTS movie_hot_history ( id INTEGER PRIMARY KEY AUTOINCREMENT, movie_id INTEGER, hot_value REAL, collect_date TEXT, UNIQUE(movie_id, collect_date) );如果你手里那套源码只有一张大宽表也能跑但扩展性差很多。加一张热度历史表收获的不只是存储能力更是“趋势分析”这个可视化维度。答辩时告诉老师“我这个系统能观察影视热度随时间的走势”比只说“我能爬数据画饼图”高级不少。4.2 去重与增量更新逻辑影视数据的重复采集是个绕不开的问题。榜单每天都会变同一部电影可能连续好几天在榜如果每次采集都全量插入数据库很快都是重复数据。我的做法是双保险。第一层是数据库层面的唯一约束比如UNIQUE(title, year)让数据库帮忙挡掉完全重复的记录。第二层是采集入库时的显式去重用INSERT OR IGNORE或者先查后插。def save_movies(conn, movies): sql INSERT OR IGNORE INTO movie_info (title, category, area, year, score, hot_value, actors, director, description, url, updated_at) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) conn.executemany(sql, movies) conn.commit()这个方案有个小瑕疵如果同一部影视的评分或者热度变了INSERT OR IGNORE不会更新已有行。所以对于每天变化的字段我会额外执行一次更新逻辑或者干脆先把当天热度写入movie_hot_history保留历史数据而不是覆盖原表。4.3 批量写入的工具选择与效率对比Python写SQLite有三种常见方式我实际对比过差别挺明显单条execute循环插入一万条数据大概要十几秒甚至几十秒主要原因是一条一条地提交事务开销太大executemany批量参数化一万条基本是在几百毫秒到一两秒内完成推荐日常使用pandas.to_sql写起来最短但字段类型和索引控制不如原生SQL灵活数据量大时内存占用也高。我建议在采集入库这个场景里直接用executemany它兼顾了代码简洁和执行速度。另外大批量写入前可以手动管理事务conn.execute(BEGIN) try: conn.executemany(insert_sql, data_list) conn.commit() except Exception: conn.rollback() raise finally: conn.close()事务提交的一个小技巧是把一批数据放在同一个事务里而不是每条一个事务。执行效率会有数量级的提升在课程设计文档里写出这个优化点也很加分。5. 可视化大屏的核心实现图表怎么选、接口怎么出、前端怎么接5.1 先想清楚看板维度不是堆图表而是回答业务问题做可视化最容易犯的毛病是“什么都往上放”结果页面满满当当但每个图表都很单薄。我的经验是反过来先写问题再选图表。比如“爱奇艺内容集中在哪些类型” —— 环形图“近几年影视上线数量是怎么变化的” —— 面积图“当前热度前20的作品有哪些” —— 横向条形图“热度高就一定评分高吗” —— 散点图“总分结构怎么快速掌握” —— 顶部指标卡。想清楚这五个问题之后看板的结构就变得很自然顶部是核心指标中间是趋势和分类下方是排名和关系再配一个表格做明细查询。这样出来的看板逻辑是通顺的。5.2 Flask接口设计返回JSON而不是HTML片段后端接口设计我习惯统一返回格式方便前端处理。一个简单封装如下from flask import Flask, jsonify, request import sqlite3 app Flask(__name__) DB_PATH iqiyi.db def query_db(sql, args()): conn sqlite3.connect(DB_PATH) conn.row_factory sqlite3.Row cur conn.execute(sql, args) rows [dict(row) for row in cur.fetchall()] conn.close() return rows app.route(/api/type_distribution) def type_distribution(): rows query_db( SELECT category, COUNT(*) AS value FROM movie_category GROUP BY category ORDER BY value DESC LIMIT 8 ) return jsonify({code: 0, data: rows}) app.route(/api/hot_top) def hot_top(): limit request.args.get(limit, 20, typeint) rows query_db( SELECT title, category, score, hot_value, year FROM movie_info ORDER BY hot_value DESC LIMIT ? , (limit,)) return jsonify({code: 0, data: rows}) if __name__ __main__: app.run(debugTrue)接口的路径设计最好按资源命名/api/type_distribution、/api/hot_top、/api/year_trend前端一看就知道是什么数据。返回结构统一成{code: 0, data: [...]}的好处是前端能统一处理错误和成功状态不需要每个接口单独判断。5.3 前端ECharts动态渲染fetch拿到数据再setOption前端这块我用最简单的原生HTML加JavaScript演示效果反而比过度封装更容易理解。!DOCTYPE html html langzh-CN head meta charsetUTF-8 title爱奇艺影视数据分析系统/title script srchttps://cdn.jsdelivr.net/npm/echarts5/dist/echarts.min.js/script /head body div idtypeChart stylewidth:100%;height:360px;/div script const chart echarts.init(document.getElementById(typeChart)); fetch(/api/type_distribution) .then(res res.json()) .then(res { chart.setOption({ tooltip: { trigger: item }, legend: { bottom: 0 }, series: [{ name: 类型分布, type: pie, radius: [40%, 70%], data: res.data }] }); }) .catch(err console.error(err)); /script /body /html需要注意如果答辩环境是学校机房外网CDN可能加载不出来。稳妥做法是把echarts.min.js文件下载到本地static/js目录然后用url_for(static, filenamejs/echarts.min.js)引入。这一点看着小但真的很影响现场演示效果。5.4 图表配置的几个细节ECharts的配置项很多但常用的关键细节就那么几个我直接列出来tooltip饼图用trigger: item折线图和柱状图用trigger: axis前者显示单项后者显示坐标轴对比legend如果类型太多设type: scroll否则图例挤成一团看不清dataZoom折线图数据点多时建议加dataZoom让用户拖拽查看区间resize窗口改变时记得给每个图表实例绑定window.addEventListener(resize, () chart.resize())不然大屏缩小到笔记本上会错位颜色主题同一个页面里的图表尽量用同一套色板推荐直接内置echarts.graphic.LinearGradient做渐变效果或者在init时指定dark主题。这些细节是“外行看热闹、内行看门道”的地方把它们写进设计文档里老师一眼就能看出来你是真的把可视化工具吃透了。6. 项目源码的目录结构与复现步骤6.1 拿到源码包后先看什么如果你拿到的是“源码数据库文档”的完整包我建议不要急着跑python app.py。先花十分钟把目录结构捋清楚。一个规范的项目通常长这样iqiyi_analysis/ ├── app.py # Flask入口 ├── spider.py # 爬虫采集脚本 ├── init_db.py # 建库建表脚本 ├── requirements.txt # 依赖列表 ├── config.py # 配置项 ├── iqiyi.db # SQLite数据库文件 ├── static/ │ ├── css/ │ ├── js/ │ └── echarts.min.js └── templates/ └── index.htmlREADME或者运行文档里通常会写启动步骤先看它。如果没有再按上面这个顺序猜先看requirements.txt再看init_db.py最后看app.py的入口逻辑。6.2 环境准备Python版本、依赖安装、数据库初始化环境这块我踩过不少坑主要坑点是Python版本太高导致某些旧依赖装不上。建议直接用Python 3.9或3.10兼容性和稳定性都比较稳。# 创建虚拟环境 python -m venv venv # Windows激活 venv\Scripts\activate # Linux/macOS激活 source venv/bin/activate # 安装依赖 pip install -r requirements.txt依赖装好之后数据库有两种初始化方式如果包里带了现成的iqiyi.db直接放在根目录即可如果没有运行python init_db.py或者直接运行爬虫脚本让代码里自动建表。建议把init_db.py跑一遍这样你对表结构有确切印象后面排查问题会方便很多。6.3 启动系统从爬虫到可视化启动顺序一般分两步# 第一步采集数据入库 python spider.py # 第二步启动可视化服务 python app.py然后浏览器打开http://127.0.0.1:5000就能看到看板。如果数据库已经带好了数据可以直接跳过第一步但我还是建议至少跑一次爬虫看看数据是怎么从接口进到数据库的。只有完整理解了数据流答辩被问到底层细节时才不会慌。6.4 部署到公网需要考虑的事课程设计如果要在机房或云服务器上演示部署不能太随意。本地app.run(debugTrue)只适合开发正式一点的方式是用 gunicorn 启动gunicorn -w 2 -b 0.0.0.0:5000 app:app外部再套一层Nginx做反向代理处理静态资源和端口转发。当然如果你的需求只是局域网里演示gunicorn这步已经够用。部署时还要注意数据库路径别写死成C:/Users/...尽量用os.path.dirname(__file__)拼接成绝对路径避免换一台机器就找不到数据库。7. 我在实操中踩过的坑和后续扩展建议7.1 页面白屏但接口有数据排查JSON字段名我遇到过最典型的可视化翻车场景是这样的Flask接口在浏览器里直接访问返回的数据好好的但页面打开就是一片空白控制台报错Cannot read properties of undefined (reading map)。查到最后发现接口返回的字段名是Data而前端写的是data。原因通常是SQLite的cursor返回dict时保留了SQL里的大小写别名两边没对齐。从那以后我给自己定了个规矩接口返回字段统一改成小写且只用AS name、AS value这种简单别名前后端各看一遍再联调。7.2 采集几万条数据内存溢出最开始写采集脚本时我是把所有页面的数据先存入一个大列表最后一口气写入数据库。数据量到几万条的时候内存直接飙到几百MB运行中途还被系统杀掉。后来改成“每页一清洗、每N条一入库”列表存够500条就立刻写库并清空。再配合生成器逐页处理内存就稳住了。这不算什么高深优化但对项目稳定运行非常关键。7.3 数据库连接未释放Flask每来一个请求就新建SQLite连接用完如果不关闭在Windows上经常出现“文件被占用”的提示连带着爬虫脚本也写不进数据。处理方式就是在公共查询函数里用短连接函数开头连接、函数结束关闭。代码里写成def query_db(sql, args()): conn sqlite3.connect(DB_PATH) try: conn.row_factory sqlite3.Row cur conn.execute(sql, args) return [dict(row) for row in cur.fetchall()] finally: conn.close()这样每个连接的生命周期可控不会积压连接对象。只要你手里那套源码也有类似的连接管理问题可以照这个思路改。7.4 后续可以这样扩展这个项目跑通之后我建议再往下面几个方向扩一扩定时采集用APScheduler或者系统crontab每天早上跑一次爬虫把热度历史写入movie_hot_history一周后你就有真正的“趋势图”了评论情感分析如果能拿到影视评论的公开文本用简单情感词典或者大模型接口做正负面判断看观众口碑和评分的吻合度推荐功能基于用户点击行为做一个“相似类型高评分”的推荐列表哪怕只是规则推荐演示效果也远超纯看板换MySQLRedis把数据库迁到MySQL后端加一层Redis缓存热门接口的查询结果前端再换成Vue基本就是一个可上线的数据产品雏形。最后再分享一个做这类项目的小心得不要被“源码数据库文档”这个包装吓到拿到任何现成项目先别急着改代码把数据流跑通把每张表、每个接口、每个图表之间的关系在纸上画出来再动手优化。这个系统本质上是一根完整的链条——从数据采集到清洗入库从接口查询到前端图表每一环都值得你亲手敲一遍。把链条打通了答辩和面试都不怕被问细节。 
长河君 · 2026/9/24 19:41:45 · 阅读 1.2k Python影视数据可视化分析系统：从爬虫到ECharts大屏的全流程实践
如果这学期你也在为课程设计选题发愁看到“基于Python爱奇艺影视数据可视化分析系统”这种题目第一反应大概率是又是老一套的爬虫数据库浏览器图表都快烂大街了。说实话我一开始也这么想但当我真的把整套源码、数据库文件、文档铺开一行一行跑通之后才发现这类项目能成为高频选题是有原因的——它把Python数据采集、数据清洗、数据存储、前后端交互和可视化表达全串在了一条线上是非常典型的全流程练手项目。这套系统做的事情用一句话讲清楚从爱奇艺这类视频平台采集公开的影视数据整理干净后落进数据库再用Web页面把热度、类型、地区、评分、年份等维度以图表形式展示出来。它不是一个只能截图交差的空壳而是能真正运行、看到数据、甚至部署到服务器上的完整项目。如果你正在做课程设计、毕业设计或者想用Python练一把“数据分析闭环”这篇文章应该能帮你少走不少弯路。我会从需求分析、技术选型、采集层实现、数据库设计、可视化搭建、项目复现和踩坑记录七个方面把这个系统拆开揉碎讲清楚。1. 先说清楚这套影视数据分析系统到底在分析什么1.1 爱奇艺平台上有哪些值得分析的数据很多同学拿到项目第一件事就是看代码我觉得应该反过来先看数据。爱奇艺影视信息里常见的公开字段有这些影视名称、类型标签剧情、喜剧、动作、爱情、悬疑、动画等、主演、导演、地区/国家、上映年份、评分、热度值、集数、上线时间、简介。光这些字段就能支撑起五六种不同角度的分析。举几个可以直接落地的分析方向类型分布用饼图/环形图看平台内容结构到底哪个类型占大头热度排行统计当前热度值前20的作品用横向条形图展示直观看出谁是热门年份产量趋势按上映年份统计电影/剧集数量生成柱状图或者面积图能看出内容供给的涨跌地区分布把国产、欧美、日韩、港台等地区的数据做成占比图评分分布用直方图看评分集中区间判断平台内容整体质量热度与评分关系用散点图看高热度作品是否真的高评分这个角度比较有意思也适合写进设计说明书作为“分析亮点”。说白了这套系统的价值不是“爬了数据然后画两张图”而是让数据回答具体问题。答辩或者写文档的时候能说清楚“我为什么选这个图表类型、这个图能说明什么”比堆十个图表有用得多。1.2 系统的最终效果与功能清单我复现这个项目之后把功能整理成了一份清单你可以对照检查自己手里那套源码缺了哪块顶部数字卡片展示影视总量、覆盖类型数、平均评分、最高热度四个核心指标热度趋势图以折线图展示每日Top20热度的整体变化或者某一部剧的时间序列热度类型分布图环形图标注每个类型下的作品数量和占比地区分布图柱状图或者地图看内容来源地区评分分布图直方图展示评分区间人数/作品数热门榜单表格可排序的影视列表按热度降序展示片名、类型、年份、评分等筛选器按类型、年份范围、地区作者筛选筛选后图表联动刷新。如果你的目标只是交一份课程设计做到上面这些已经超过平均水平了。如果还想加点分可以加一个“评分Top10”榜单和“热度异动提醒”的小模块后面我会在扩展方向里细说。2. 技术方案选型为什么是requests SQLite Flask ECharts2.1 爬虫框架自己写requests比Scrapy更适合这个场景我在很多项目里都碰到过一个选择到底用Scrapy还是自己写requests这个项目我推荐后者原因很实际。Scrapy确实强大下载中间件、爬虫中间件、Item Pipeline、调度器、去重队列都是现成的适合大规模、多域名、需要增量爬取的场景。但放到这个影视分析系统里学习成本和代码复杂度反而不划算。数据量也就是几千到几万条采集频率不会太高用requests加一个重试函数脚本两百行内就能写得明明白白。有人可能会问如果对方平台是“前端渲染 复杂反爬”怎么办那我会考虑Playwright这种浏览器自动化方案但代价是内存占用高、环境依赖重、部署麻烦。这个项目如果页面里能直接拿到JSON数据接口requests就完全够用。你先用浏览器开发者工具切到Network面板刷新榜单页面找到返回影视列表的XHR请求看看它的响应结构八成比你想的要干净。2.2 数据库SQLite足够用但要注意并发写课程设计和中小型个人项目数据量基本在几万条以内SQLite是性价比最高的选择。整个数据库就是一个单文件拷贝到任何一台机器都能打开不需要安装MySQL服务也不需要配置账号密码。这对答辩演示非常友好。但SQLite也有脾气最典型的就是并发写时容易报database is locked。Web服务如果同时有多个进程写同一个SQLite文件就会出现这个问题。我的处理办法是分层采集脚本负责写库可视化服务只负责读库两边互不干扰写操作尽量集中在同一个进程里配合conn.execute(PRAGMA journal_modeWAL)能减少读写锁冲突。如果后面数据量真的上了百万级或者要部署到公网给多人同时用再迁移到MySQL也不迟。迁移时要注意修改pymysql/mysql-connector连接方式SQL语句本身不需要大改。2.3 可视化展示ECharts Flask是快速交付的组合可视化部分我接触过几种方案。直接用Excel或者Power BI做静态图表演示效果不够“系统”用Vue ECharts做前后端分离工程化能力强但对一个课程设计来说又偏重了用Flask Jinja2模板渲染页面加上ECharts在前端画图是最平衡的方案。这里有个小建议后端不要直接把数据塞进HTML模板而是提供JSON接口前端用fetch动态获取。比如/api/type_distribution返回[{name: 剧情, value: 120}, ...]页面加载后请求这个接口再渲染图表。这样做的好处是前后端职责清晰后续要换Vue或者做App端对接接口可以无缝复用。3. 爱奇艺数据采集的实现细节与反爬处理3.1 爱奇艺数据源的两种拿法我在实现采集层时一般会优先找JSON接口。打开浏览器开发者工具切到Network - XHR刷新影视榜单页面能看到不少返回JSON数据的请求里面通常直接包含片名、评分、类型、热度值等字段。相比解析HTMLJSON处理起来要省太多事字段层级清楚也不需要跟标签嵌套较劲。如果找不到JSON接口或者接口需要的签名参数太复杂那就退一步用页面解析。用requests拿HTML再用BeautifulSoup按CSS选择器定位影视卡片把标题、评分、类型这些字段从一个一个节点里抠出来。这条路代码会更脆只要页面结构一改选择器就要跟着改。所以我始终建议优先找结构化数据接口。需要提醒一句只采集页面公开展示的榜单和影视信息不要碰会员专属内容、非公开数据也不要短时间内高频猛抓。这个系统是学习研究用途保持合理礼貌的请求频率是基本底线。3.2 Header伪装、Cookie管理与请求间隔很多新手写爬虫直接requests.get(url)拿回来一堆code: 401或者验证页其实是没带请求头。浏览器在发请求时会自动带上User-Agent、Referer、Accept等字段服务端靠这些判断你是真人还是脚本。我们伪造一个正常的浏览器请求头请求成功率会高非常多。如果目标接口需要登录状态需要从浏览器里把Cookie复制出来加进requests的cookies参数。不同浏览器的Cookie可能包含一些加密标识直接复制整体字符串是最省事的方式。请求间隔也是重点。我在采集脚本里习惯加一个随机延时代码大概长这样import random import time import requests 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, Referer: https://www.iqiyi.com/, Accept: application/json, text/plain, */*, } def safe_get(url, paramsNone, cookiesNone, retries3): for attempt in range(retries): try: time.sleep(random.uniform(0.5, 1.5)) resp requests.get( url, headersHEADERS, paramsparams, cookiescookies, timeout10 ) resp.raise_for_status() return resp.json() except Exception as e: print(f请求失败第{attempt 1}次重试{e}) time.sleep(2) return None这个safe_get函数在一个项目里被复用了无数次。随机0.5到1.5秒的间隔既不会太慢也能明显降低被封概率。重试逻辑更是必备——网络波动在长任务采集中太常见了。3.3 字段清洗从JSON里抽数据并统一格式拿到JSON之后不能直接往数据库里塞一定得清洗。这块是最容易被低估的环节也是最影响图表展现质量的环节。常见的脏数据情况有这几种热度值是字符串比如“1.2亿”、“8500万”需要转成统一的数字某些字段缺失评分是空值年份是“”一个影视同时属于多个类型字段长成“剧情,爱情”或者“剧情/爱情”年份可能是一串日期“2023-08-10”需要抽出4位年份。处理热度值的时候写一个专门函数比较稳妥import re def clean_hot(value): if not value: return 0.0 match re.search(r([\d.])\s*(万|亿)?, str(value)) if not match: return 0.0 num float(match.group(1)) unit match.group(2) if unit 万: num * 10000 elif unit 亿: num * 100000000 return num另外类型字段建议拆开存。比如“剧情,爱情”如果直接作为一个字符串存进category字段后面做“类型分布”时会很被动——要么只能用LIKE %剧情%模糊搜索要么统计出来的类别权重失真。我的习惯是建一张movie_category关联表一部影视可以对应多个类型统计时拆成多行参与聚合。这一点在数据库设计阶段就要想好。3.4 断点续采与日志设计采集脚本如果一次要跑几万条数据很容易在中途因为网络波动、服务端限流而中断。如果没有断点续采每次都要从头跑那就是纯浪费时间。我在脚本里加了两个简单机制第一把采集进度写到本地文件比如progress.json每次成功处理一页就更新last_page第二失败时记录日志loguru是很好用的选择。import json PROGRESS_FILE progress.json def save_progress(page): with open(PROGRESS_FILE, w, encodingutf-8) as f: json.dump({last_page: page}, f) def load_progress(): try: with open(PROGRESS_FILE, r, encodingutf-8) as f: return json.load(f).get(last_page, 1) except FileNotFoundError: return 1 start_page load_progress() for page in range(start_page, total_pages 1): data safe_get(url, params{page: page, page_size: 20}) if data is None: break # 解析、清洗、入库 save_progress(page)别看代码简单实际采集中救过我好几次。断点续采看起来是个“很小的功能”但写入文档和代码注释里会让整个项目的完整度上一个大台阶。4. 数据库设计与数据落库的实操4.1 三张核心表影视信息、类型关联、热度历史数据库结构会直接影响后续可视化的复杂度。我在这个项目里用的是三张核心表。第一张是影视基础信息表movie_infoCREATE TABLE IF NOT EXISTS movie_info ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, category TEXT, area TEXT, year INTEGER, score REAL, hot_value REAL, actors TEXT, director TEXT, description TEXT, url TEXT, updated_at TEXT, UNIQUE(title, year) );第二张是影视类型关联表movie_category解决一部影视多个类型的问题CREATE TABLE IF NOT EXISTS movie_category ( id INTEGER PRIMARY KEY AUTOINCREMENT, movie_id INTEGER, category TEXT, UNIQUE(movie_id, category) );第三张是热度历史表movie_hot_history用来记录同一部影视在不同日期的热度值这是做趋势图的数据基础CREATE TABLE IF NOT EXISTS movie_hot_history ( id INTEGER PRIMARY KEY AUTOINCREMENT, movie_id INTEGER, hot_value REAL, collect_date TEXT, UNIQUE(movie_id, collect_date) );如果你手里那套源码只有一张大宽表也能跑但扩展性差很多。加一张热度历史表收获的不只是存储能力更是“趋势分析”这个可视化维度。答辩时告诉老师“我这个系统能观察影视热度随时间的走势”比只说“我能爬数据画饼图”高级不少。4.2 去重与增量更新逻辑影视数据的重复采集是个绕不开的问题。榜单每天都会变同一部电影可能连续好几天在榜如果每次采集都全量插入数据库很快都是重复数据。我的做法是双保险。第一层是数据库层面的唯一约束比如UNIQUE(title, year)让数据库帮忙挡掉完全重复的记录。第二层是采集入库时的显式去重用INSERT OR IGNORE或者先查后插。def save_movies(conn, movies): sql INSERT OR IGNORE INTO movie_info (title, category, area, year, score, hot_value, actors, director, description, url, updated_at) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) conn.executemany(sql, movies) conn.commit()这个方案有个小瑕疵如果同一部影视的评分或者热度变了INSERT OR IGNORE不会更新已有行。所以对于每天变化的字段我会额外执行一次更新逻辑或者干脆先把当天热度写入movie_hot_history保留历史数据而不是覆盖原表。4.3 批量写入的工具选择与效率对比Python写SQLite有三种常见方式我实际对比过差别挺明显单条execute循环插入一万条数据大概要十几秒甚至几十秒主要原因是一条一条地提交事务开销太大executemany批量参数化一万条基本是在几百毫秒到一两秒内完成推荐日常使用pandas.to_sql写起来最短但字段类型和索引控制不如原生SQL灵活数据量大时内存占用也高。我建议在采集入库这个场景里直接用executemany它兼顾了代码简洁和执行速度。另外大批量写入前可以手动管理事务conn.execute(BEGIN) try: conn.executemany(insert_sql, data_list) conn.commit() except Exception: conn.rollback() raise finally: conn.close()事务提交的一个小技巧是把一批数据放在同一个事务里而不是每条一个事务。执行效率会有数量级的提升在课程设计文档里写出这个优化点也很加分。5. 可视化大屏的核心实现图表怎么选、接口怎么出、前端怎么接5.1 先想清楚看板维度不是堆图表而是回答业务问题做可视化最容易犯的毛病是“什么都往上放”结果页面满满当当但每个图表都很单薄。我的经验是反过来先写问题再选图表。比如“爱奇艺内容集中在哪些类型” —— 环形图“近几年影视上线数量是怎么变化的” —— 面积图“当前热度前20的作品有哪些” —— 横向条形图“热度高就一定评分高吗” —— 散点图“总分结构怎么快速掌握” —— 顶部指标卡。想清楚这五个问题之后看板的结构就变得很自然顶部是核心指标中间是趋势和分类下方是排名和关系再配一个表格做明细查询。这样出来的看板逻辑是通顺的。5.2 Flask接口设计返回JSON而不是HTML片段后端接口设计我习惯统一返回格式方便前端处理。一个简单封装如下from flask import Flask, jsonify, request import sqlite3 app Flask(__name__) DB_PATH iqiyi.db def query_db(sql, args()): conn sqlite3.connect(DB_PATH) conn.row_factory sqlite3.Row cur conn.execute(sql, args) rows [dict(row) for row in cur.fetchall()] conn.close() return rows app.route(/api/type_distribution) def type_distribution(): rows query_db( SELECT category, COUNT(*) AS value FROM movie_category GROUP BY category ORDER BY value DESC LIMIT 8 ) return jsonify({code: 0, data: rows}) app.route(/api/hot_top) def hot_top(): limit request.args.get(limit, 20, typeint) rows query_db( SELECT title, category, score, hot_value, year FROM movie_info ORDER BY hot_value DESC LIMIT ? , (limit,)) return jsonify({code: 0, data: rows}) if __name__ __main__: app.run(debugTrue)接口的路径设计最好按资源命名/api/type_distribution、/api/hot_top、/api/year_trend前端一看就知道是什么数据。返回结构统一成{code: 0, data: [...]}的好处是前端能统一处理错误和成功状态不需要每个接口单独判断。5.3 前端ECharts动态渲染fetch拿到数据再setOption前端这块我用最简单的原生HTML加JavaScript演示效果反而比过度封装更容易理解。!DOCTYPE html html langzh-CN head meta charsetUTF-8 title爱奇艺影视数据分析系统/title script srchttps://cdn.jsdelivr.net/npm/echarts5/dist/echarts.min.js/script /head body div idtypeChart stylewidth:100%;height:360px;/div script const chart echarts.init(document.getElementById(typeChart)); fetch(/api/type_distribution) .then(res res.json()) .then(res { chart.setOption({ tooltip: { trigger: item }, legend: { bottom: 0 }, series: [{ name: 类型分布, type: pie, radius: [40%, 70%], data: res.data }] }); }) .catch(err console.error(err)); /script /body /html需要注意如果答辩环境是学校机房外网CDN可能加载不出来。稳妥做法是把echarts.min.js文件下载到本地static/js目录然后用url_for(static, filenamejs/echarts.min.js)引入。这一点看着小但真的很影响现场演示效果。5.4 图表配置的几个细节ECharts的配置项很多但常用的关键细节就那么几个我直接列出来tooltip饼图用trigger: item折线图和柱状图用trigger: axis前者显示单项后者显示坐标轴对比legend如果类型太多设type: scroll否则图例挤成一团看不清dataZoom折线图数据点多时建议加dataZoom让用户拖拽查看区间resize窗口改变时记得给每个图表实例绑定window.addEventListener(resize, () chart.resize())不然大屏缩小到笔记本上会错位颜色主题同一个页面里的图表尽量用同一套色板推荐直接内置echarts.graphic.LinearGradient做渐变效果或者在init时指定dark主题。这些细节是“外行看热闹、内行看门道”的地方把它们写进设计文档里老师一眼就能看出来你是真的把可视化工具吃透了。6. 项目源码的目录结构与复现步骤6.1 拿到源码包后先看什么如果你拿到的是“源码数据库文档”的完整包我建议不要急着跑python app.py。先花十分钟把目录结构捋清楚。一个规范的项目通常长这样iqiyi_analysis/ ├── app.py # Flask入口 ├── spider.py # 爬虫采集脚本 ├── init_db.py # 建库建表脚本 ├── requirements.txt # 依赖列表 ├── config.py # 配置项 ├── iqiyi.db # SQLite数据库文件 ├── static/ │ ├── css/ │ ├── js/ │ └── echarts.min.js └── templates/ └── index.htmlREADME或者运行文档里通常会写启动步骤先看它。如果没有再按上面这个顺序猜先看requirements.txt再看init_db.py最后看app.py的入口逻辑。6.2 环境准备Python版本、依赖安装、数据库初始化环境这块我踩过不少坑主要坑点是Python版本太高导致某些旧依赖装不上。建议直接用Python 3.9或3.10兼容性和稳定性都比较稳。# 创建虚拟环境 python -m venv venv # Windows激活 venv\Scripts\activate # Linux/macOS激活 source venv/bin/activate # 安装依赖 pip install -r requirements.txt依赖装好之后数据库有两种初始化方式如果包里带了现成的iqiyi.db直接放在根目录即可如果没有运行python init_db.py或者直接运行爬虫脚本让代码里自动建表。建议把init_db.py跑一遍这样你对表结构有确切印象后面排查问题会方便很多。6.3 启动系统从爬虫到可视化启动顺序一般分两步# 第一步采集数据入库 python spider.py # 第二步启动可视化服务 python app.py然后浏览器打开http://127.0.0.1:5000就能看到看板。如果数据库已经带好了数据可以直接跳过第一步但我还是建议至少跑一次爬虫看看数据是怎么从接口进到数据库的。只有完整理解了数据流答辩被问到底层细节时才不会慌。6.4 部署到公网需要考虑的事课程设计如果要在机房或云服务器上演示部署不能太随意。本地app.run(debugTrue)只适合开发正式一点的方式是用 gunicorn 启动gunicorn -w 2 -b 0.0.0.0:5000 app:app外部再套一层Nginx做反向代理处理静态资源和端口转发。当然如果你的需求只是局域网里演示gunicorn这步已经够用。部署时还要注意数据库路径别写死成C:/Users/...尽量用os.path.dirname(__file__)拼接成绝对路径避免换一台机器就找不到数据库。7. 我在实操中踩过的坑和后续扩展建议7.1 页面白屏但接口有数据排查JSON字段名我遇到过最典型的可视化翻车场景是这样的Flask接口在浏览器里直接访问返回的数据好好的但页面打开就是一片空白控制台报错Cannot read properties of undefined (reading map)。查到最后发现接口返回的字段名是Data而前端写的是data。原因通常是SQLite的cursor返回dict时保留了SQL里的大小写别名两边没对齐。从那以后我给自己定了个规矩接口返回字段统一改成小写且只用AS name、AS value这种简单别名前后端各看一遍再联调。7.2 采集几万条数据内存溢出最开始写采集脚本时我是把所有页面的数据先存入一个大列表最后一口气写入数据库。数据量到几万条的时候内存直接飙到几百MB运行中途还被系统杀掉。后来改成“每页一清洗、每N条一入库”列表存够500条就立刻写库并清空。再配合生成器逐页处理内存就稳住了。这不算什么高深优化但对项目稳定运行非常关键。7.3 数据库连接未释放Flask每来一个请求就新建SQLite连接用完如果不关闭在Windows上经常出现“文件被占用”的提示连带着爬虫脚本也写不进数据。处理方式就是在公共查询函数里用短连接函数开头连接、函数结束关闭。代码里写成def query_db(sql, args()): conn sqlite3.connect(DB_PATH) try: conn.row_factory sqlite3.Row cur conn.execute(sql, args) return [dict(row) for row in cur.fetchall()] finally: conn.close()这样每个连接的生命周期可控不会积压连接对象。只要你手里那套源码也有类似的连接管理问题可以照这个思路改。7.4 后续可以这样扩展这个项目跑通之后我建议再往下面几个方向扩一扩定时采集用APScheduler或者系统crontab每天早上跑一次爬虫把热度历史写入movie_hot_history一周后你就有真正的“趋势图”了评论情感分析如果能拿到影视评论的公开文本用简单情感词典或者大模型接口做正负面判断看观众口碑和评分的吻合度推荐功能基于用户点击行为做一个“相似类型高评分”的推荐列表哪怕只是规则推荐演示效果也远超纯看板换MySQLRedis把数据库迁到MySQL后端加一层Redis缓存热门接口的查询结果前端再换成Vue基本就是一个可上线的数据产品雏形。最后再分享一个做这类项目的小心得不要被“源码数据库文档”这个包装吓到拿到任何现成项目先别急着改代码把数据流跑通把每张表、每个接口、每个图表之间的关系在纸上画出来再动手优化。这个系统本质上是一根完整的链条——从数据采集到清洗入库从接口查询到前端图表每一环都值得你亲手敲一遍。把链条打通了答辩和面试都不怕被问细节。