企业官网建设流程全解析

简介：这份代码包提供了一个基于Python的电影数据分析与可视化系统完整实现，面向具备Python与Django基础、希望掌握Web开发与数据分析全流程的开发者，也可作为毕业设计或课程设计参考。系统涵盖用户登录、爬虫采集电影数据、按偏好展示TOP10电影、按片名/导演/演员模糊搜索，以及年代、产地、类型分布饼图柱状图和评价词云等可视化分析模块。资源共42个文件，包含8个核心Python文件、11个Django模板页面、8个CSV数据文件，另有SQLite数据库、CSS样式、说明文档等，压缩包约299.78MB，目录结构清晰。目前已有1040人下载学习。借助源码、数据与配套txt/docx说明，读者能快速搭建运行环境，理清Django项目分层、爬虫数据入库及ECharts图表交互的完整链路，针对关键模块的排错与本地化调整也能节省大量时间。

1. 电影数据分析与可视化系统：不是画几张图那么简单

“电影数据分析与可视化系统”这个标题，很容易让人误以为把 IMDb 或 TMDB 的榜单拉下来，画几张柱状图和折线图就算完工。真正做过一轮的人会发现，它其实是横跨数据获取、清洗、加工建模、图表设计和前端渲染的一条完整链路，任何一环偷懒，最后展示出来的结论就站不住脚。这套系统要解决的核心问题，是把“哪些电影更受欢迎、票房和评分到底什么关系、类型和年份怎样影响口碑”这类模糊问题，变成能随时刷新、可以交互验证的明确结果。既然标题带“代码分享”，下面我会把每一步用到的最小实现、关键参数和踩坑记录直接贴出来，适合独立开发者、数据分析初学者，也适合想给团队搭建内部数据看板的工程师照着从零到一跑通。

2. 数据底座：把公开数据源变成能分析的结构化表

2.1 数据源选型：为什么先用 IMDb 官方数据集而不是自己写抓取脚本

做电影数据分析，第一步不是写代码，而是选数据源。常见做法是先看 IMDb 官方发布的 dataset 文件，它以 gzip 压缩的 TSV 形式提供 title.basics、title.ratings、title.principals 等表格，每一行是一部电影或剧集的元数据，字段用 tab 分隔，缺失值统一记成\N。我一般先用它打底，原因有三个：第一，数据量足以覆盖绝大多数分析场景，不需要自己写抓取脚本去对抗页面结构和限流；第二，schema 稳定，title.basics 里的 tconst 是全局唯一 ID，可以直接和 ratings 表做 join；第三，年份、类型、片长都是规整字段，清洗成本比从网页上抠数据低一个数量级。

这里要泼一盆冷水：IMDb 官方数据集没有票房字段，只有评分、投票数、类型、年份、片长这些内容侧数据。如果你的系统一定要分析票房回报率，就得走 TMDB API 或 The Numbers 这类专门收录票房的数据源，再按 tconst 或电影名做关联。这个坑我一开始就踩过：费了半天劲把 basics 和 ratings 清洗完，才发现票房根本不在里面，等于返工。所以选型阶段先列清楚业务指标，再决定数据源，别让数据源决定指标。对于标题里的“电影数据分析”，我建议的起步组合是：IMDb 的 title.basics 与 title.ratings 做核心分析，TMDB API 按需补充票房和海报。下面先讲 IMDb 这条主链路。

2.2 用 requests + pandas 跑通下载与分块读取

数据文件在 IMDb 官方接口页面公布，每个 TSV 打包成 gz 压缩包，先下载到本地再处理。下面是我常用的下载脚本，注意带本地缓存，避免每次重跑都重新拉全量文件。

import shutil from pathlib import Path import requests DATA_DIR = Path("./movie_data") DATA_DIR.mkdir(exist_ok=True) # IMDb 官方数据托管地址，如页面调整请以官网为准 BASE_URL = "https://datasets.imdb.com/" FILES = { "title.basics.tsv.gz": BASE_URL + "title.basics.tsv.gz", "title.ratings.tsv.gz": BASE_URL + "title.ratings.tsv.gz", } def download_once(fname: str, url: str) -> Path: target = DATA_DIR / fname if target.exists(): print(f"{fname} 已存在，跳过下载") return target tmp = target.with_suffix(".tmp") with requests.get(url, stream=True, timeout=(10, 120)) as r: r.raise_for_status() with open(tmp, "wb") as f: shutil.copyfileobj(r.raw, f) tmp.rename(target) return target if __name__ == "__main__": for name, url in FILES.items(): download_once(name, url)

参数说明：timeout 写成(10, 120)，10 秒是连接超时，120 秒是读取超时。电影数据集压缩包动辄几百 MB，连接超时设短、读取超时设长，可以在断网时快速失败而不是干等。stream=True 配合 shutil.copyfileobj 是按块写盘，不会把整个压缩包读进内存，小内存机器也能跑。最后用 .tmp 后缀先写临时文件再改名，避免下载到一半留下半截文件，下次误判为已下载。

下载完成后，用 pd.read_csv 直接读 gz 可行，Pandas 会自动解压。但 title.basics 解压后有几百万行，一次性读进来会占掉好几个 GB 内存。我一般用分块读取，并且提前声明 dtype，避免 Pandas 对年份这类列做耗时的类型推断。

import pandas as pd def load_basics_with_chunks(path: Path, chunksize=500_000): """分块读取 title.basics，适合内存有限的机器。""" dtype_spec = { "tconst": "string", "titleType": "category", "primaryTitle": "string", "originalTitle": "string", "isAdult": "int8", "startYear": "Int64", # 允许缺失的整数类型 "endYear": "Int64", "runtimeMinutes": "Int64", "genres": "string", } reader = pd.read_csv( path, sep="\t", dtype=dtype_spec, na_values="\\N", chunksize=chunksize, low_memory=False, ) for chunk in reader: yield chunk

逻辑说明：na_values="\\N"是关键，IMDb 用字面量\N表示缺失，不告诉 Pandas 的话 startYear 会被当成字符串，后续没法做时间维度聚合。startYear 用Int64而不是普通 int，是因为这个列有缺失值，普通 int dtype 会直接报错或把缺失值变成异常的负数。titleType 声明成 category，它的枚举值很少，分组统计时的开销比 string 小得多。low_memory=False 是老版本 Pandas 的保险选项，新版本默认行为已改，这里显式写出来是提醒自己处理大文件时不要依赖隐式行为。

读进来之后，通常只保留 titleType == "movie" 的行，因为电视节目、短片、剧集会污染“电影评分和票房”的分析口径。过滤操作放在分块阶段做，能省下一大块内存。

2.3 多值字段与关联键：genres 拆分和 ratings join

title.basics 的 genres 字段是竖线分隔的多值字符串，例如Drama|Romance。分析“类型对评分的影响”时，不能把整串当成一个类别，要拆开。拆的方法有两种：简单场景用 str.split + explode，复杂场景用 MultiLabelBinarizer 做多热编码。先看 explode 的写法。

def explode_genres(df: pd.DataFrame) -> pd.DataFrame: """把 genres 竖线串拆成多行，一部电影可出现在多个类型下。""" return ( df.assign(genres=df["genres"].str.split("|")) .explode("genres") .dropna(subset=["genres"]) ) # 示例：只看电影、年份在 2000 年以后 basics = pd.concat(load_basics_with_chunks(DATA_DIR / "title.basics.tsv.gz")) movies = basics[basics["titleType"].eq("movie")].copy() movies = movies[movies["startYear"].ge(2000)] genres_long = explode_genres(movies[["tconst", "startYear", "genres"]])

参数说明与边界：explode 会把一行从 1 行展开成 N 行，代价是行数膨胀。若一部电影有 3 个类型，总行数就变成原来的 3 倍。数据量大时先做口径过滤再 explode，不要反过来。dropna(subset=["genres"]) 必须放在 explode 之后，因为缺失值在 split 阶段会得到 NaN，explode 会把 NaN 行原样保留，不删的话后续统计会出现一堆无类型记录。如果要做“是否包含某类型”的布尔特征，更省内存的做法是str.get_dummies生成宽表，行数不膨胀但列数膨胀，两种方案按下游用途选。我一般画“各类型平均分”用 explode，做机器学习特征用 get_dummies。

ratings 文件字段是 tconst、averageRating、numVotes，关联时用 inner join 把没有评分的电影丢掉即可。真正要留意的是 numVotes 的分布：很多冷门片只有几十票，平均值容易被个位数投票拉高。后面做分析时，我会先按 numVotes 做一层截断（比如至少 1000 票），否则排行榜前几名永远是只有五个人投过十分的片子。这个截断阈值是业务参数，具体取多少取决于你的场景，但“一定要截断”这件事是确定的。到这里，数据底座已经具备：一张干净的电影主表、一张评分表、一份拆好的类型长表。

3. 指标与分析层：把干净的表变成能回答问题的结论

3.1 核心指标选型：评分中位数比平均值更抗噪，热度要看对数

数据清洗完成后，很多人直接用 groupby 算平均分，这是最容易翻车的地方。平均分对极端值敏感，IMDb 的评分分布又天然右偏，大量电影集中在 4 到 7 分，少数神片高达 9 分以上。如果只算均值，类型和年份间的差异会被极值掩盖。我一般会同时算三组指标：评分中位数 median、投票数的对数log1p(numVotes)、高分片占比（评分 ≥ 8 且票数 ≥ 5000 的占比）。这三组指标在业务上分别对应口碑中枢、热度规模、出片质量，比单个平均分更能解释“为什么某个类型看起来厉害”。尤其是高分片占比，它能把“偶尔出一部神作”和“整体水平稳定”区分开，后者才是类型健康度的真实信号。

年份维度的分析是另一个重灾区。startYear 列里有缺失、有早期默片、还有少量未来年份，数据源偶尔会混入发行预告。直接在图上画时间趋势会看到一两个诡异的尖峰。常规做法是先做口径校验：

def filter_year(df: pd.DataFrame, min_year: int = 1930, max_year: int = None) -> pd.DataFrame: """剪掉明显异常年份，避免时间轴被脏数据拉变形。""" max_year = max_year or pd.Timestamp.now().year return df[df["startYear"].between(min_year, max_year)]

参数说明：max_year 默认取当前年份，是为了挡住未来年份的数据；min_year 按分析目标调整，研究当代电影的话可以再往上提到 1980，年份区间越小，类型分布越接近当前市场结构。这里不是越全越好，是越贴合业务口径越好。

3.2 Pandas 侧的分析操作：先截断再 join，最后用透视表出矩阵

没有数仓环境时，用 Pandas 做同样分析也完全够用。要注意的只有一点：尽量在过滤后的小表上做操作，不要全量 join 再过滤。下面这段代码把评分表和主表关联，然后按类型和年代做透视。

rating = pd.read_csv( DATA_DIR / "title.ratings.tsv.gz", sep="\t", dtype={"tconst": "string", "averageRating": "float32", "numVotes": "int32"}, na_values="\\N", ) # 先截掉低票数，再 join，能减少大量无效关联 rating_cut = rating[rating["numVotes"] >= 1000] df = movies[["tconst", "startYear", "genres"]].merge(rating_cut, on="tconst", how="inner") genres_long = explode_genres(df) pivot = genres_long.pivot_table( index="genres", columns=pd.cut(genres_long["startYear"], bins=[1930, 1980, 2000, 2020, 2030]), values="averageRating", aggfunc="median", )

逻辑说明：pd.cut 把 startYear 切成几个年代桶，作为透视表的列，bin 边界必须和 3.1 里的口径保持一致。这里为了展示用[1930, 1980, 2000, 2020, 2030]，实际项目中按问题域调整。aggfunc="median" 呼应核心指标选型，不使用均值。这段代码的运算成本集中在 explode 上，如果 genres_long 行数过大，可以先对每个类型单独聚合再合并结果，效果一样但内存可控。

有人会问：为什么不在 SQL 里直接算好再拉结果？如果在维护数仓，当然优先 SQL；但在独立开发场景里，Pandas 的优势是每一步都能看到中间结果，方便排查口径问题。我通常是 SQL 和 Pandas 混合用：耗时的大聚合交给 SQL，探索性分析和口径调整交给 Pandas。两条路径算出来的结果应该对得上，对不上就说明其中一条的口径有 bug。

3.3 分析结果落地：把口径和结论一起存下来，给图表层喂文件

分析层容易被忽略的一步是结果落地。很多人直接在 Jupyter 里看一眼图表就结束，等要接可视化系统时，又得重跑一遍。我现在的习惯是：所有中间结果都落成 parquet 或 csv，并带一份 meta.json 记录过滤口径和生成时间。这样可视化端只管读文件，不需要知道底层清洗逻辑。

import json result = { "filter": {"num_votes_min": 1000, "year_range": [1930, 2024]}, "generated_at": pd.Timestamp.now().isoformat(), "pivot_file": "pivot_by_genre_decade.csv", } with open(DATA_DIR / "meta.json", "w", encoding="utf-8") as f: json.dump(result, f, ensure_ascii=False, indent=2) pivot.to_csv(DATA_DIR / "pivot_by_genre_decade.csv")

参数说明：meta.json 里的 filter 字段是我给自己留的“后悔药”，一周之后重看这张透视表，至少能知道它是在什么口径下算出来的。这种习惯在长期维护的数据项目里尤其值钱，比代码注释更可靠，因为它和产物文件放在一起，不会因为代码重构而失联。

分析层到此已经能输出：类型×年代的评分中位数矩阵、高分片占比序列、投票热度分布。下一步是把这些聚合结果变成人一眼能读懂的图。这里有一个重要取舍：直接拿几十万行明细画图，和拿几千行聚合结果画图，性能差一个数量级，可视化层的设计要围绕这个取舍展开。

4. 可视化层实现：从静态图表到可交互仪表盘

4.1 图表选型：数据关系决定图表，靠审美决定的图表都会翻车

可视化系统最忌讳的是把一堆图表堆在页面上。选图之前先明确要回答什么问题：比较类问题用条形图，趋势类问题用折线图，相关性类问题用散点图，分布类问题用直方图或箱线图。下表是我在电影数据分析系统里常用的对应关系。

这些图不是越多越好。我见过不少项目把五六个图表硬塞进一页，用户根本看不出重点。可视化系统的价值在于把口径固定的少量图表做深，而不是把数据全部铺开。比例尺、坐标变换、样本量标注这些细节，比图表的种类更影响使用者的判断。

4.2 用 Plotly 绘制投票数——评分散点图：对数坐标与交互参数

Plotly 的优势是交互逻辑不用自己写：hover 提示、缩放、拖拽都是内置行为。下面这个散点图是系统的核心视图，横轴是投票数对数刻度，纵轴是评分，点的大小映射投票数，颜色映射年代。一张图能同时回答“哪些电影叫好又叫座”和“高分冷门片长什么样”。

import plotly.express as px fig = px.scatter( df_sample, x="numVotes", y="averageRating", size="numVotes", color="startYear", hover_data=["primaryTitle", "genres"], log_x=True, range_x=[10, 3_000_000], range_y=[1, 10], title="电影投票数与评分分布（票数≥1000）", ) fig.update_traces(marker=dict(opacity=0.6, line=dict(width=0))) fig.update_layout( xaxis_title="投票数（对数刻度）", yaxis_title="平均评分", coloraxis_colorbar=dict(title="上映年份"), ) fig.write_html(DATA_DIR / "rating_scatter.html")

参数说明：log_x=True 是关键，投票数从几十到几百万跨越五个数量级，线性坐标下绝大部分点会挤在左侧，图等于白画。range_x 和 range_y 是坐标轴显式范围，不设的话 Plotly 会按数据极值自动扩展，上限可能被《阿凡达》这类超级大片拉得很远，主体群体还是挤成一团。opacity=0.6 给重叠点设置透明通道，几十万点叠在一起时没有透明度等于看到一团黑。hover_data 里放 primaryTitle 和 genres，用户悬停能看到电影名和类型，这是交互分析的基本诉求。但 hover_data 越多，图表文件越大浏览器越卡，只放必要字段。

这里有一个性能边界：直接把几十万行明细丢给 Plotly，生成的 HTML 可能有上百 MB，浏览器直接白屏。工程上的常用做法是先做分桶抽样，把数据量压到一两万点以内，再用 size 和颜色表达信息密度。我在 2.3 节说先过滤再聚合，在可视化层变成先抽样再绘图：

# 按投票数分桶后每桶抽样，保留长尾但控制总量 df_sample = ( df.groupby(pd.cut(df["numVotes"], bins=20)) .apply(lambda x: x.sample(min(len(x), 500)), include_groups=False) .reset_index(drop=True) )

参数说明：pd.cut 把 numVotes 切成 20 个桶，每桶最多抽 500 条，总样本量控制在 10000 以内，同时每个量级的点都保留。include_groups=False 是新版 Pandas 的写法，老版本里这个参数名不同，报错时优先查这个 API 变更。这个抽样不做的话，静态图勉强能出，一加交互控件就卡死。

4.3 用 Dash 把图表装进可查询的仪表盘

单张静态图满足不了“可视化系统”的定位。我一般用 Dash 把散点图、直方图和透视表矩阵包进同一个页面，再放一个年份范围筛选器。Dash 本质是 Python 包装的 React 应用，回调函数负责控件和图表的联动。下面是最小可用的骨架。

from dash import Dash, dcc, html, Input, Output import plotly.express as px app = Dash(__name__) app.layout = html.Div([ dcc.RangeSlider(1930, 2024, step=5, value=[1980, 2024], id="year-slider"), dcc.Graph(id="main-scatter"), ]) @app.callback( Output("main-scatter", "figure"), Input("year-slider", "value"), ) def update_scatter(year_range): mask = df_sample["startYear"].between(*year_range) return px.scatter( df_sample[mask], x="numVotes", y="averageRating", size="numVotes", color="startYear", log_x=True, ) if __name__ == "__main__": app.run_server(debug=True, host="127.0.0.1", port=8050)

逻辑说明：RangeSlider 的 value 是[1980, 2024]这样的二元组，回调函数里用 between(*year_range) 直接过滤，不要手写year_range[0] <= x <= year_range[1]。回调函数的 Input 和 Output 必须和 layout 里的 id 一一对应，Output 在前 Input 在后，顺序写反会导致 Dash 启动报错。这是新手最容易卡住的地方，报错信息通常很长，但核心问题往往是回调签名顺序错了。debug=True 只建议本地开发时开，部署到服务器务必关掉，否则控制台会暴露环境信息，每次报错都会打印完整堆栈。

这一步跑通后，标题里的“可视化系统”就基本成型了：本地起一个服务，浏览器访问 8050 端口，拖动年份滑块能看到散点图实时变化。但到这里只能算能跑，离靠谱还差很远，下面把我踩过的五个高频翻车现场按现象、原因、解决列一遍。

5. 电影数据可视化系统的 5 个常见坑：现象、原因、解决办法

5.1 票房单位不一致导致聚合结果差一个数量级

现象：从 TMDB API 取回票房字段后直接按年份汇总，发现某部电影的票房比上一年的所有电影加起来还高。

原因：TMDB 的 revenue 字段统一以美元为单位，但系统里合并了其它地区数据源时，比如中文网站抓来的内地票房单位是人民币，IMDb 的 rating 表里又没有票房，单位不一致就会被当成同一个字段聚合。固定汇率换算也会埋雷，因为汇率随时间变化。

解决：建表时把 currency 字段单独列出来，所有跨币种聚合前先经过一层换算函数，换算汇率记录在 meta 表里。如果只做趋势对比不追求精确金额，更省事的是用对数归一化把金额缩放到 [0,1] 区间，消除单位影响。排查时先打印df["revenue"].describe()，看到 min 和 max 相差超过 7 个数量级，基本就是混入了不同币种。

5.2 年份列在导入时被自动转成 float

现象：groupby("startYear") 之后，索引突然出现 1987.0、1995.0 这种小数。

原因：IMDb 数据里 startYear 存在缺失值\N，Pandas 默认推断 dtype 时想，这列有缺失值，那就用 float64 吧，于是年份全变成浮点。

解决：read_csv 时显式声明 dtype，把年份列指定为Int64或string，并指定 na_values。我在 2.2 节已写过这个参数，这里再强调一次：不要依赖 Pandas 自动类型推断，大文件清洗时显式声明 dtype 不是可选优化，是必修课。排查时直接看df.dtypes，如果 startYear 显示 float64，就要回到读取那一步改 dtype。

5.3 explode 之后内存翻倍，脚本直接被杀

现象：对几十万行电影表执行 explode_genres 后，内存占用从 2GB 跳到 6GB，进程被 OOM Killer 中断。

原因：explode 把一行拆成多行，结果行数是原来的均摊类型数倍，同时 genres 列被复制多次，内存按行数线性增长。如果在 explode 之后再 join ratings 表，内存会进一步爆炸。

解决：先把分析子集过滤到最小，再 explode；explode 后立刻删掉不再需要的列；内存仍不够就分块处理，每个 chunk 单独聚合再合并结果。排查时用df.memory_usage(deep=True).sum() / 1024**2打出各列内存，看到 genres 列占用异常高，说明拆分时机太早了。不要试图用更大的机器解决问题，先确认数据流里没有无效膨胀。

5.4 出图后坐标轴中文变方块，换台机器就乱码

现象：本地 Jupyter 里画图中文正常，生成 HTML 后浏览器里标题和坐标轴变成方块。

原因：Plotly 生成的 HTML 在浏览器端渲染，字体依赖浏览器环境。本机装了中文字体，服务器或别人浏览器没有；或者字体名没正确传进 layout 的 font 配置。

解决：在 update_layout 里显式指定中文字体，并在 CSS 层把页面的 font-family 也设成同样的字体栈。

fig.update_layout( font=dict(family="Microsoft YaHei, SimHei, Noto Sans CJK SC, sans-serif"), )

参数说明：字体栈按操作系统覆盖，Windows 用微软雅黑，macOS 和 Linux 用 Noto Sans CJK SC。生产环境更稳妥的做法是自托管一个开源字体文件，通过 CSS 引入，完全摆脱用户机器限制。不要图省事只写一个字体名，线上系统最常见的乱码就是字体栈不完整。

5.5 打开仪表盘白屏或拖动滑块时风扇狂转

现象：Dash 页面加载完成后浏览器空白；或拖动年份滑块时极度耗 CPU。

原因：最常见的是把全量明细数据塞进 Plotly 图表，生成的 DOM 节点数量达到几十万个，浏览器渲染不过来。另一种是回调函数把过滤后的数据全量重算，每次都重新读文件重新 join，没有缓存。

解决：4.2 节的抽样方案就是针对这个问题的；同时给回调函数加缓存，避免同一筛选条件下重复计算。简单做法是用 joblib 缓存 DataFrame 子集。

from joblib import Memory memory = Memory("./cache", verbose=0) @memory.cache def load_subset(): return df_sample.copy()

逻辑说明：Memory 会把函数结果按参数存到磁盘，下次相同调用直接读缓存。这个方案对“数据每天更新但图表频繁打开”的场景最合适。核心原则是：图表端永远只拿聚合结果或抽样结果，明细数据留在分析层。如果加了缓存仍然卡，打开浏览器开发者工具的 Performance 面板看主线程占用，通常会发现卡顿来自回调里重复生成 figure 而不是数据查询。

6. 进阶验证：用统计检验给图表结论兜底

可视化系统能出图和出表之后，下一步不是加更多图表，而是验证结论的稳健性。我的习惯是选一个业务上最容易被质疑的结论，用简单的统计检验去戳它。比如“动作片是不是比剧情片更热门”这种说法，直接看票房均值容易被几部超级大片带偏。正确的做法是先定义清楚比较组，再做分组对比。

from scipy.stats import mannwhitneyu action = merged[merged["genres"].str.contains("Action", na=False)]["numVotes"] drama = merged[merged["genres"].str.contains("Drama", na=False)]["numVotes"] stat, p_value = mannwhitneyu(action, drama, alternative="two-sided") print(f"p_value={p_value:.4f}")

参数说明：mannwhitneyu 是秩和检验，不要求数据正态分布，适用于投票数这种严重右偏的变量。这里要注意，同属动作和剧情的电影会同时出现在两个组里，所以两组不是互斥的，结论只能说明包含该类型的电影的票数位置，不能说明谁更赚钱。如果要互斥比较，得先给每部电影指定一个主类型。

这个验证习惯的价值在于：可视化系统最怕的不是图表难看，而是图表给了业务一个错误的确定性。交互式散点图很容易让观者自己“看出”某种规律，而规律是否真实存在需要统计检验兜底。我现在每次给系统加一个分析视图，都会顺带写一个最小检验脚本，放在视图后端，和 meta.json 对齐口径。这样图表上随口说出的结论，至少有一个可复核的数字支撑。

另一个值得做的进阶是给图表加极值标注。散点图里《泰坦尼克号》《阿凡达》这类巨无霸永远在右上角，把坐标轴撑得失去参考意义。与其把整个轴改成对数坐标隐藏差异，不如单独标注这几个点，并在标题里说明剔除方式。这个坑在真实业务里特别常见：大客户或爆款单品会扭曲全局视图，系统要做的是把异常和主体分开呈现，而不是硬塞进同一张图。

最后说一个我自己的教训：第一次把系统交付给业务同事时，我只留了过滤控件，没给任何提示信息。同事随手把年份拖到 1930-1940，看到一堆黑白电影评分极高，立刻来问是不是系统 bug。其实只是那个年代样本量小、投票者偏死忠粉。后来我在所有图表标题和 hover 里都带上了“样本量 n=xxx”字段，这种误读基本消失。可视化系统的专业度，往往体现在你主动暴露数据边界，而不是让用户去猜。希望帮到你。

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