Python动漫影视数据可视化毕设：爬虫清洗分析与ECharts实战

“基于Python的动漫影视数据分析和可视化”这个毕设题，我前后带过好几届学生做，自己也完整复现过一套。说实话，这题在近两年大数据方向的毕业设计里非常讨巧：动漫影视数据源丰富、分析维度直观、可视化效果好，而且技术栈标准，从数据采集到前端展示一条线走完，答辩时讲起来也容易出彩。但正因为它“看起来简单”，很多人在实际动手时反而踩了一堆坑——数据爬不下来、清洗逻辑混乱、图表组件加载不出来、部署到服务器上接口报错。这篇文章我会把整套项目的设计思路、技术选型、核心代码逻辑、实操步骤和常见问题全部拆开讲清楚，给准备做类似题目的同学一份能直接照着抄的作业。

这套系统本质上是一个完整的数据分析流水线：先用爬虫从公开数据源抓取动漫影视的基础信息、评分、热度、标签等数据，然后用Pandas做清洗和聚合，再按主题维度（类型分布、季度趋势、口碑排行、发布时间规律等）计算指标，最后通过Flask提供后端接口、前端使用ECharts渲染成交互式可视化页面。整个过程覆盖了“数据获取—数据清洗—数据分析—数据可视化—系统集成”的完整链路，也正好对应了大数据专业培养方案里最核心的几个能力点。

内容会有点长，但每一步都会有对应的代码和参数说明，包括我在实操中踩过的坑。

1. 选题拆解：动漫影视数据可视化毕设到底在做什么

1.1 题目定位与核心需求解析

先把这个题目拆开来看。“基于Python的动漫影视数据分析和可视化设计与实现”其实包含三个层次的要求：数据层面，要有真实可信的数据集做支撑，不能是随便编的假数据；分析层面，要对数据做统计计算、趋势分析、关联对比，而不是简单查个表；展示层面，要以图表或大屏的形式让分析结果能看得见、能交互。这三个层次递进，也正好对应了毕设论文里“数据采集—数据预处理—数据分析—可视化设计—系统实现”的章节结构。

很多同学在开题时容易犯一个错误——把题目想窄了，以为做一个静态的图表展示页面就行。实际上“数据分析”这四个字才是核心，可视化只是分析结果的表达形式。你在答辩时讲“我统计了不同类型动漫的平均评分”，这只是描述；你要能讲清楚“为什么存在类型差异、哪个时间段的番剧质量更高、评分和热度之间有没有关系”，这才叫分析。所以系统设计时，一定要在数据分析层面设计出真正有意义的分析主题，而不是把原始表格换个图表样式就完事。

另外，题目里还有“设计与实现”这个词，这意味着你不仅要有分析结果，还要有一个可运行的软件系统。这里我建议采用经典的“后端接口+前端页面”架构，后端专注数据处理和指标计算，前端专注图形展示和数据交互，双方通过JSON格式接口通信。这样做的好处是分工清晰、代码量适中，而且答辩展示时可以先用接口工具演示数据处理过程，再切到系统页面展示可视化效果，讲解节奏好控制。

1.2 目标用户与应用场景分析

这类系统适合谁来用？分析阶段，最直接的参考对象是动漫内容平台的运营人员，他们需要了解当前哪些题材受欢迎、用户评分与播放热度的关系、不同季度番剧的供给变化；其次是一般的动漫爱好者，可以用这套系统的数据来辅助追番决策——某个高分冷门作品值不值得看、哪个工作室出品的作品平均质量更高、历史上哪个年份是“神仙打架”的年份。所以在系统功能设计时，可以考虑设置“总分总”的浏览逻辑：总览页展示宏观统计指标和排行榜，分类页展示不同维度的详细分析，搜索页让用户按作品名或标签快速定位信息。

我见过有些同学把系统做得非常复杂，搞了五六个角色权限、复杂的用户系统，反而把数据分析这个主菜给冲淡了。记住，毕设项目的评价核心是“数据分析深度”和“系统完成度”，不是用户管理的复杂度。角色权限这类内容点到为止就行，如果论文篇幅不够，多放几张分析图表，多写几个分析结论的解读，比堆功能更有价值。

1.3 与同类毕设题目的差异化策略

动漫影视数据可视化这个方向每年都要被做烂了，要想拿高分，差异化策略很重要。我建议从三个角度做区分。

第一是数据源的稀缺性。很多人只会用现成的CSV数据集，或者只爬某一个平台的数据。你可以做多源数据融合，比如把某平台的评分数据和另一平台的热度数据进行关联分析，讨论跨平台数据的口径差异，这个点放在论文里就是创新点。

第二是分析维度的深度。不要只展示“评分TOP10排行榜”，可以结合时间序列做“公映季度的番剧评价波动分析”，结合文本做“作品标签的词频共现分析”，甚至可以对高评分和低评分作品的标题文本做关键词分布对比，这些分析本身就是论文里的核心章节素材。

第三是可视化交互的独特性。很多人的页面就是固定的柱状图+折线图，你可以加入时间轴拖拽、散点图多维度联动的动态筛选、表格和图表的联动刷新，这些交互效果在工作量上体现得非常明显，答辩演示也更有说服力。但注意交互要建立在真实分析需求上，不能为了炫技而炫技。

2. 技术方案与工具选型：为什么是这套Python组合拳

2.1 核心技术栈全景

技术选型是整个项目的地基。我的推荐方案是：Python 3.9+ 作为主语言，Requests + BeautifulSoup4 或 Scrapy 做数据采集，Pandas + NumPy 做数据处理，Flask 提供后端服务，前端原生HTML + CSS + JavaScript，图表渲染用 ECharts，数据存储用 SQLite 或 MySQL 二选一。

为什么用Python？因为数据处理生态太成熟了。Pandas的DataFrame结构处理表格数据非常顺手，groupby、merge、apply、pivot_table这些方法几乎覆盖了所有数据分析的需求；可视化方面，虽然Matplotlib能画图，但交互性和美观度远不如ECharts，所以后端只负责提供数据，图表渲染完全交给ECharts，这个分工在现代Web开发里是非常成熟的做法。

选Flask而不是Django，原因是Flask足够轻量，适合单机部署的小型数据可视化系统。Django自带Admin后台和ORM，功能强但学习成本高，对于毕设这种体量的项目有点杀鸡用牛刀。Flask的路由装饰器写起来直观，两三天就能上手，后续如果要加接口也方便。SQLite和MySQL之间我建议绝大多数人选SQLite，因为它是文件型数据库，不需要单独安装数据库服务，部署时拷走文件就行，对答辩演示非常友好。项目如果数据量超过几十万条，再考虑MySQL也不迟。

这里还要提醒一点：技术选型千万别追求“新”和“多”。我之前见过有人往毕设里塞了Django + Scrapy + ClickHouse + Redis + Docker，结果是每个技术都只用了皮毛，反而主线的数据分析做得非常单薄。毕设的技术栈要的是“能完整走通闭环”，不是“名字听起来炫”。

2.2 采集工具选择与反爬应对思路

数据采集这块，Requests + BeautifulSoup4的组合最灵活，但是要考虑目标站点的反爬策略。分几种情况聊一下。如果只是静态HTML渲染的页面，直接在请求头里带上基本的User-Agent就能拿到数据；如果是Ajax动态加载的页面，比如很多平台的榜单数据是通过JSON接口异步加载的，需要用开发者工具去找到真实的接口地址，直接请求接口拿JSON；如果遇到请求频率被封的情况，可以控制爬取间隔、使用Session保持会话、设置Referer头。深度的网站，用Playwright或Selenium这种浏览器自动化工具基本都能解决，但会明显降低爬取效率，建议在实在找不到接口或者页面极其复杂时才使用。

写爬虫时有个非常重要的合规意识：爬取公开数据用于学习研究本身是没问题的，但要注意控制请求频率，不要对目标站点造成访问压力；采集到的数据也不要再大规模对外传播。我在实操时会自己控制一个爬取间隔在1到3秒之间，一个几千条数据规模的数据集，爬完也就一到两小时，完全够用。

2.3 开发环境与依赖管理

为了不让自己在环境配置上浪费太多时间，我强烈建议用Anaconda创建独立的虚拟环境。可以手动用pip安装，但用conda创建虚拟环境的好处是不同项目之间的依赖不会互相干扰，日后的复现也方便。

conda create -n anime_viz python=3.9 conda activate anime_viz pip install pandas numpy flask requests beautifulsoup4 lxml pip install pyecharts # 如果要用Python生成图表配置（可选）

如果你电脑上连Anaconda都懒得装，直接用Python自带的venv也一样，命令区别很小。核心是把依赖库列表导出来，写一个requirements.txt放在项目里，这既是规范，也是论文目录里可以写一笔的工程实践。

pip freeze > requirements.txt

3. 数据采集与预处理：拿数据是最脏最累的活

3.1 数据源分析与字段设计

在做采集之前，先在草稿纸上明确你要“最终拿到一张什么样的表”，这个意识非常重要。我的建议是数据表设计下面几个核心字段：

这张表里的字段是为了支撑后续的分析主题设计的，比如按类型分析需要category，按时间趋势分析需要year和quarter，口碑维度需要rating和rating_count，制作质量分析需要studio和tags。如果一开始没想清楚分析维度，后边清洗时才发现缺字段，再去补爬一遍就很浪费时间。

字段设计有一个容易忽略的细节：评分人数这个字段非常有价值。因为两个作品评分同为9.0时，一个几十万人评分，一个两万人评分，含金量完全不同。后续分析时可以把评分人数作为一个参考权重来引入，这也是一个比较聪明的分析思路。

3.2 爬虫代码实现与字段清洗

以某个典型动漫数据站的页面为例，先说思路：先用Requests请求列表页拿到作品详情页的链接集合，再对每个详情页发起请求解析出字段。这个流程比较稳，因为列表页数据不全，详情页数据才完整。

import requests from bs4 import BeautifulSoup import pandas as pd HEADERS = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36", "Accept-Language": "zh-CN,zh;q=0.9" } session = requests.Session() session.headers.update(HEADERS) def get_html(url): resp = session.get(url, timeout=10) resp.encoding = "utf-8" return resp.text def parse_detail(html): soup = BeautifulSoup(html, "lxml") title = soup.select_one("h1.title").get_text(strip=True) rating = float(soup.select_one("span.rating-number").get_text(strip=True)) ... return { "title": title, "rating": rating }

爬取过程中容易出现两类问题。第一类是HTML结构变化，昨天还能直接匹配到的CSS选择器，今天页面改版就选不到了，所以代码里一定要写健壮的默认值try...except，字段解析不到就给NaN，先保证整个流程能跑完。第二类是编码乱码问题，有些站点的响应头里没有明确charset，需要手动设定resp.encoding = "utf-8"或“gbk”。乱码这块可以在数据清洗阶段统一处理，先用charset检测库，不行就手动试。

3.3 清洗去重与标准化处理

数据爬下来之后，清洗这一步的质量直接决定后面分析的可靠程度。第一步是去重，同一部作品可能在多个月度榜单里重复出现，要按title字段做去重保留最新记录，可以使用Pandas的drop_duplicates；第二步是约束范围，比如过滤掉评分人数过少的样本（例如少于100人评分的作品，稳定性和参考价值都偏低），设置rating范围在0到10之间；第三步是处理缺失值，tags为空的可以用“未知”填充，rating缺失的直接删掉行；第四步是类型归一化，把“热血/战斗/动作”这类表达统一映射到规范标签，这个映射关系在分析时非常重要。

df = df.drop_duplicates(subset=["title"]) df = df[df["rating_count"] >= 100] df["tags"] = df["tags"].fillna("未知") df["rating"] = pd.to_numeric(df["rating"], errors="coerce") df = df.dropna(subset=["rating"])

清洗完之后，把数据存成CSV文件而不是直接存数据库，这有什么好处？CSV文件在论文答辩时可以作为“数据样本展示”直接截进论文，而且文本格式方便用Excel打开给导师看，还方便后续反复导入。我当时在项目里设置了一个data/目录，原始数据、清洗后数据、分析结果数据分开放，结构非常清晰。

4. 数据分析维度与可视化设计：到底展示什么才有含金量

4.1 基础统计分析与排行榜体系

分析维度是整个系统的灵魂，我建议按“宏观总览—维度分析—关联探索”三层设计。

第一层是宏观总览，主要展示以下几个指标：动漫作品总数、参与制作的制作公司数量、平均评分、最高评分和最低评分。这些指标以数值卡片的形式放在页面的头部，让用户一眼就能对数据集有个总体印象。

第二层是排行榜体系：评分TOP10、热度TOP10、评分人数TOP10、冷门高分榜（可以设定评分大于8.5但评分人数低于5000的作品）。排行榜用条形图展示效果最好，如果作品名太长，可以考虑用横向条形图来避免文字重叠。

第三层是分布画像层：不同类型作品的数量占比、不同年份的产出数量变化、评分区间分布直方图。这一层的图我建议不要只是静态展示，要在旁边附上对图表结论的解读文字，这一做法非常体现分析深度。

4.2 让分析结论引导可视化形式选择

图表类型选择不是随意的，每一种图都有它最擅长表达的问题。这里我整理了一个在实操中觉得很实用的对照表：

关于散点图我要多说两句。把x轴设为热度指数、y轴设为评分、点的大小映射评分人数、颜色映射作品类型，这样一个散点图就能同时展现四五个维度的信息，而且在答辩时非常出效果。我实际做的时候用ECharts的scatter加visualMap调色就实现了，代码量不大，但视觉层次感直接上一个台阶。

option = { xAxis: { name: "热度指数" }, yAxis: { name: "评分" }, visualMap: { dimension: 2, min: 0, max: 200000, text: ["高评分人数", "低评分人数"], calculable: true }, series: [{ type: "scatter", encode: { x: 0, y: 1, size: 2, color: 3 }, data: scatterData }] };

4.3 交互联动设计的两个高级方案

基础页面做到图表齐全，最多算合格。要想做出“分析系统”的感觉，必须加入交互。我给你两个立竿见影的方案。

第一个是“点击路由筛选”：在饼图中点击某个类型的扇区，页面下方的所有图表自动切换为该类型的数据，比如只看“热血”类型时的评分分布、季度变化和代表作品。这个效果可以通过ECharts的点击事件绑定到全局数据筛选函数来实现，本质上是前端维护一个currentCategory全局变量，每次点击重新向后端发请求，再把图表重新渲染。代码不算复杂，但演示效果极好，答辩时评委点一下就能明显感觉到你的系统“活”了。

第二个是“时间轴拖拽”：用一个slider控件控制年份范围，用户拖到头尾，时间跨度内的数据全部联动刷新。这其实是有点实时数据分析的感觉了。实际代码思路是监听事件后重新向后端请求year_start和year_end两个参数，后端用Pandas的条件过滤返回数据，前端重新setOption。这种动态交互在毕设答辩现场的效果真的很好。

交互设计的底线是要保证刷新速度。后端只返回过滤后的数据而不是全量数据，前端只用setOption更新而不是重建整个页面，这两个优化做好了，交互基本不会卡顿。

5. 系统架构与核心代码实现：从数据到图表的完整链路

5.1 后端接口结构与Flask实现

整个项目采用Flask提供JSON接口，这里给出核心后端结构。后端代码不需要很复杂，只要把数据处理函数和路由函数分开就行，一个负责计算，一个负责响应HTTP请求。这是工程上的好习惯，也好写进论文。

from flask import Flask, jsonify, request import pandas as pd app = Flask(__name__) df = pd.read_csv("data/cleaned_anime.csv") def compute_category_stats(source_df): return source_df.groupby("category").agg( cnt=("title", "count"), avg_rating=("rating", "mean") ).reset_index() @app.route("/api/category_stats") def api_category_stats(): data = compute_category_stats(df) return jsonify({ "code": 0, "data": data.to_dict(orient="records") })

接口收到前端传过来的参数之后再做过滤。比如在前面的时间轴联动场景里面，浏览器先请求“2010年到2015年之间的评分趋势”，会发这样一个请求：/api/trend?year_start=2010&year_end=2015，后端路由里读出参数，然后用Pandas过滤查询之后返回结果。

@app.route("/api/trend") def api_trend(): start = int(request.args.get("year_start", 2000)) end = int(request.args.get("year_end", 2023)) filtered = df[(df["year"] >= start) & (df["year"] <= end)] result = filtered.groupby("year").agg( cnt=("title", "count"), avg_rating=("rating", "mean") ).reset_index() return jsonify({"code": 0, "data": result.to_dict(orient="records")})

这里有一个常见的坑：JSON序列化时，Pandas的int64、float64类型不能直接被jsonify序列化，会报TypeError。最简单的解决方法是转成Python原生类型，用round、int包装一下。我实际操作时会在最终返回数据前做一个干净的类型处理，避免前端莫名其妙解析出NaN。

5.2 前端页面结构与ECharts渲染

前端不建议用任何框架，原生HTML + JavaScript就够。页面结构上建议用左右布局：左侧是筛选面板和数据指标卡，右侧是图表区域。图表区域用CSS Grid来排布，两列布局，高度就设置成视口高度，保证在普通笔记本上打开不出现滚动条，这是演示时的加分解。这里给一个页面骨架：

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>动漫影视数据分析可视化系统</title> <script src="https://cdn.jsdelivr.net/npm/echarts@5"></script> <style> body { margin: 0; font-family: "Microsoft YaHei", sans-serif; background: #f5f7fa; } .header { height: 60px; background: #2d3a4b; color: #fff; line-height: 60px; padding-left: 24px; font-size: 20px; } .layout { display: grid; grid-template-columns: 300px 1fr; } .side { padding: 16px; background: #fff; height: calc(100vh - 60px); overflow: auto; } .right { display: grid; grid-template-columns: 1fr 1fr; gap: 12px; padding: 12px; } .card { background: #fff; border-radius: 8px; padding: 12px; box-shadow: 0 2px 8px rgba(0,0,0,0.06); } .chart { width: 100%; height: 320px; } </style> </head> <body> ... <script> const chart1 = echarts.init(document.getElementById("chart1")); fetch("/api/category_stats") .then(r => r.json()) .then(res => { chart1.setOption({ tooltip: {}, series: [{ type: "pie", data: res.data.map(item => ({ name: item.category, value: item.cnt })) }] }); }); </script> </body> </html>

前端代码的重点就一句话：fetch接口、setOption渲染。剩下的工作都是在配置ECharts的option对象里做文章。如果你不想在HTML里写死图表配置，也可以用pyecharts在Python端生成配置JSON再传给前端，但对于纯毕设项目，我更推荐直接在前端手写option，灵活度更高，控制力更强。

5.3 前后端联调与页面展示顺序

联调是整个开发过程中最容易出问题又最枯燥的阶段。我的调试顺序是这样的：先用curl或者浏览器直接访问接口地址，确认后端返回的JSON结构没问题；再在前端代码里先用Mock数据渲染图表，确认图表显示格式没问题；最后把fetch的真实数据替换Mock数据，这样一旦图表有问题，就能迅速定位是接口问题还是渲染问题。我习惯在浏览器开着开发者工具，切到Network面板看每个请求的返回状态码，这是排查问题最快的方式。

给系统设计的所有页面排一个演示顺序很重要。默认打开的总览页要把最庞大的信息量展示出来：顶部指标卡、中部类型分布和年份趋势、底部排行榜和散点图相关性分析。分类分析和搜索功能放在第二个页面，这样演示时可以说“我们可以从宏观看到整体情况，也能下钻到某一类作品查看细节”，讲故事的逻辑就顺下来了。

6. 毕设实战中的高频坑与排查心得

6.1 爬虫阶段的高频报错与解决方案

爬虫阶段最有代表性的报错是403和503。403通常是请求头不全，缺少User-Agent或Referer，解决方案是补全headers，并且用Session维持会话。503就是访问太频繁被限流了，可以增加sleep间隔、加入随机延迟。更隐蔽的问题是解析时出现NoneType，用BeautifulSoup的select_one方法如果没有匹配到元素会返回None，如果你直接对None调用get_text就会崩。解决办法是给解析写一个通用包装函数。

def safe_text(soup, selector): node = soup.select_one(selector) return node.get_text(strip=True) if node else ""

6.2 清洗处理时最容易被忽视的“脏数据”

清洗阶段典型的坑有三种。第一是评分格式不统一，有的数据源评分是字符串“8.9分”，有的是“8.9/10”，清洗时要统一把“分”和“/10”去掉再转float；第二是年份字符混入空格或换行符，可以先strip再映射到int，避免强转时报错；第三是评分人数包含“万”这种单位，比如“12.5万人评分”，要把这个转为纯数字，用float("12.5") * 10000。如果你不处理就直接to_numeric，这一整列都会变成NaN，后面的分析全废了。

6.3 可视化阶段的黑屏、白屏与分析口径不一致问题

前端图表白屏，90%的情况是数据格式不对。ECharts对数据格式要求比较严格，饼图的data要求是[{name: ..., value: ...}]这样的对象数组，很多人直接把groupby结果传进去，里面是category和cnt两个字段，忘了把字段名改成name和value，结果就是白屏。还有一个常见坑是setOption时的replaceMerge和notMerge参数。如果你反复调用setOption，默认是增量合并，可能导致旧系列没有清除，图表出现叠加错乱，这时在setOption里加一个true参数强制清空再渲染就可以了。

分析口径不一致的问题也很坑。比如饼图上的“类型占比”，有的人按作品数量算，有的人按评分人数加权算，数量占比和加权占比在数字上相去甚远。同一个指标在页面或论文里只能采用一种口径，并且要在图上明确标注口径说明，这既是技术规范，也是答辩时应对提问的准备。提前把这些口径定义写在README文档里，也能省去很多解释成本。

7. 答辩演示与项目扩展思路：怎么把工作量讲出价值

7.1 答辩前必做的三个准备

第一个准备是准备一份脚本化演示流程。很多同学答辩时打开页面想到哪点到哪，结果现场操作混乱。正确的做法是提前写一份演示讲稿：先展示数据总览卡片，然后演示点击类型筛选联动，接着拖拽时间轴看到趋势变化，最后搜索一个作品看详情。每一步之间设计好过渡话术，讲清楚“这个交互解决了什么问题”。把演示过程控制在五分钟到八分钟，节奏非常重要。

第二个准备是提前在脱网环境下测试。答辩现场经常出现网络不稳定的情况，如果前端图表是通过CDN加载的ECharts脚本，一旦网络断掉整个页面就垮了。把ECharts的js文件下载到本地放进static目录，这是最稳妥的做法。同理，数据库如果用的本地SQLite文件，就不用担心数据库连接问题。

第三个准备是准备一批“追问弹药”。评委最爱问的问题方向无非以下几类：数据量有多大？数据来源是什么？如何保证数据准确性？为什么用Flask不用Django？系统可扩展性如何？这些问题都要提前想好答案。特别是数据可靠性这个问题，我的标准回答模板是：通过多源交叉验证、对明显异常值进行过滤、对样本量过小的数据剔除、保留清洗前后数据对比表来证明处理流程的合理性。

7.2 给项目进行低成本高回报的扩展

做完基础系统后，如果时间充裕，我建议从以下几个方向做扩展，每一个都是能在论文里单独成章的：

加入时间维度下的季度番剧对比分析，突出“评价最好的季度”与“数量最多的季度”是否存在错位，这个分析能和社会文化背景产生联动讨论，分析深度一下就出来了。加入制作公司的产出与口碑对比，展示不同公司的作品数量及平均评分差异，可以发现“高产量与高质量往往不兼得”的规律。加入标签关系的共现网络图，如果一个作品有“战斗”和“奇幻”两个标签，网络中这两个节点之间就产生一条边，用ECharts的graph类型渲染，视觉效果非常震撼，开发量却不高。还可以加入文本挖掘维度，对作品简介做分词处理，提取高频关键词，生成词云，展示时能明显增加技术层次。

7.3 从毕设到作品集的思维转变

最后分享一个我反复给学生强调的观点：毕设不只是为了拿学分，它应该是一个能放进作品集的项目案例。如果你后续要找工作或考研复试，这套系统的完整流程就是很好的展示素材。在写项目描述时不要只写“开发了一个可视化系统”，要按“数据采集—数据处理—分析建模—可视化呈现—系统落地”的结构写清楚你做了什么、用了什么工具、产出了什么结果。把分析结论做成独立的分析报告，比如“哪些类型的动漫更容易获得高分”，这部分是可以写进简历里的亮点经历。

我在带项目的过程中，经常看到有人把时间全花在调前端样式上，结果数据分析的思考过程却写不出来。但实际上毕设答辩更看重的是你面对一个实际问题时，能否拆解它、设计解决方案并用代码实现出来。技术本身是工具，分析思路和解决问题的能力才是老师真正想看到的。所以不管你怎么选技术栈、怎么做展示，都一定不要丢了“数据分析”这个魂。

最后再分享一个小技巧：整个系统的部署不要等到最后几天才做。开发到一半就尝试在另一台电脑或虚拟机上跑一遍完整流程，环境差异带来的坑早踩早解决。我就遇到过同学答辩前夜才发现接口在服务器上访问不通，原因是防火墙没放行端口或host配置不对，这种技术含量不高但断送演示效果的错误，确实是可以靠提前彩排完全避免的。