想象你走进一家餐厅，菜单上的美食照片拍得很漂亮，但你只能隔着屏幕看，既不能把菜端起来凑近观察食材，也不能把照片放大看摆盘细节，更不能勾选“只要辣的菜”来筛选。传统静态图表就是这样的“照片菜单”——数据被定格成一张 PNG，信息再多也只能一次性呈现。而 Plotly 要做的，是为你开一家“透明厨房里的活餐厅”：每张图表都是一道活菜，你可以悬停看原料、放大看细节、筛选口味、甚至观看一道菜从生到熟的完整过程。这套交互式可视化框架，正在改变 AI 从业者展示数据洞察的方式——从“给你看一张图”变成“请你来探索这组数据”。

岗位关联

对 AI 从业者而言，掌握 Plotly 交互式可视化，意味着你能把模型分析结果从静态报告升级为可探索、可筛选、可分享的交互式 Web 应用，这是 AI 工程化落地中“最后一公里”展示能力的关键加分项。

目录
  1. 可视化演示
  2. 起源与定位：从照片菜单到透明厨房
  3. 核心交互能力：食客的四样权利
  4. 双语言生态：同一份菜谱两种做法
  5. 数据到部署：后厨一条龙动线
  6. Dash框架：把明星菜品开成连锁品牌
  7. 选型应用：开哪种餐饮业态
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示Plotly的交互式散点图（悬停/缩放）、40+图表类型画廊（散点/柱状/饼图/3D）以及从Python数据到Web渲染的完整架构流水线。

本节配有交互动效（进入视口后自动加载，约 3KB）。

交互式散点图演示 悬停高亮数据点并显示数值tooltip 缩放动画展示交互式视图变换 hover → tooltip | zoom → scale Plotly原生支持缩放/平移/悬停/选择等交互

起源与定位：从照片菜单到透明厨房

你的手机相册里存满了美食照片——它们忠实记录了一道菜的最终模样，但你没法把照片里的菜端起来、翻过来看看里面的夹心。传统静态图表就是这样的“照片菜单”：数据被 Matplotlib 定格成一张 PNG，信息再丰富也只能一次性摊开。Plotly 的诞生，就是要开一家“透明厨房”——把图表变成一道道活菜，你可以凑近看、伸手碰，甚至围观这道菜如何被烹饪出来。

Plotly 是一个基于 D3.js 与 WebGL 构建的声明式交互可视化框架。D3.js 擅长把数据绑定到网页元素上，WebGL 则调用 GPU 高效渲染海量图形——这两项技术构成了透明厨房的炉灶与锅具。而“声明式”的意思是：你只需要告诉后厨“我要一盘宫保鸡丁，微辣”，而不是一步一步指挥“先切鸡丁、再热油、再下花生”。你描述目标，框架负责执行。

声明式 API 的核心映射关系可以写成：

跟命令式“一步步画图”相比，声明式让可视化从“亲自颠勺”变成“下订单”。你不需要关心坐标轴怎么画、刻度怎么排、图例放哪里——Plotly 这座透明厨房会自动把一切安排妥当。这正是它上手门槛低、但表达力依然强大的根本原因。

V=f(D,L)\mathcal{V} = f(\mathcal{D}, \mathcal{L})
  1. D 数据集输入的数据集合，通常是 Pandas DataFrame，相当于餐厅采购的“食材清单”
    D={d1,d2,…,dn}\mathcal{D} = \{d_1, d_2, \dots, d_n\}
  2. L 布局配置标题、坐标轴范围、颜色主题、图例位置等描述性配置，相当于“口味偏好与摆盘要求”
    L={l1,l2,…,lm}\mathcal{L} = \{l_1, l_2, \dots, l_m\}
  3. f 映射函数Plotly 内部将数据编码为视觉属性（坐标位置、颜色、大小）的自动转换器，相当于“掌勺大厨”
    f:D×L→Vf: \mathcal{D} \times \mathcal{L} \rightarrow \mathcal{V}
  4. V 可视化对象最终生成的交互式 Figure 对象，可以被显示、导出或嵌入网页，相当于“端上桌的活菜”
    V=Figure(data,layout)\mathcal{V} = \text{Figure}(\text{data}, \text{layout})

核心交互能力：食客的四样权利

在透明厨房里，食客天然拥有四种“上手权”：把菜端近闻一闻——悬停查看详情；捏住照片放大——缩放查看细节；从菜单里勾选“只要辣的”——筛选联动；回放烹饪过程——动画过渡。这些操作不是锦上添花的点缀，而是“交互式可视化”这一概念的核心定义。Plotly 把这四样权利内置到了每一张图表里，不需要你额外写任何前端代码。

悬停是最基础的交互：鼠标滑过数据点时，自动浮现该点的所有字段值，就像用餐时服务员报出这道菜的原料与热量。缩放与平移则让你在宏观总览和微观细节之间自由切换——当数据点密集到难以分辨时，框选放大局部区域是数据分析的刚需。筛选联动常见于多子图场景：点击图例中某个类别，所有关联子图同步隐藏或高亮该类别数据，相当于对全桌菜品按口味一键分区。动画过渡则为数据变化过程提供了时间维度，让“趋势”不再是静态线条，而是肉眼可见的演变。

缩放与平移的底层本质上是一个坐标仿射变换：

这四样“权利”让图表从“一张纸”变成了“一个可探索的空间”。对于 AI 从业者来说，这意味着你的模型结果不再需要反复截图给业务方看——他们自己就能在图表上放大、筛选、悬停，从数据中独立发现问题，这比任何口头解说都更有说服力。

p′=T(p)=s⋅R⋅p+t\mathbf{p}' = \mathbf{T}(\mathbf{p}) = s \cdot \mathbf{R} \cdot \mathbf{p} + \mathbf{t}
  1. p 原始坐标数据点在画布上的初始位置，相当于菜品在桌面上的原始摆放
    p=(x,y)⊤\mathbf{p} = (x, y)^\top
  2. s 缩放因子滚轮放大缩小的比例系数，等于把整桌菜等比例放大或缩小
    s>0s > 0
  3. R 旋转变换在常规缩放中通常为单位矩阵，某些 3D 场景下用于视角旋转
    R=(cos⁡θ−sin⁡θsin⁡θcos⁡θ)\mathbf{R} = \begin{pmatrix} \cos\theta & -\sin\theta \\ \sin\theta & \cos\theta \end{pmatrix}
  4. t 平移向量拖拽图表时的位移偏移量，相当于把整桌菜从桌中央挪到窗边
    t=(tx,ty)⊤\mathbf{t} = (t_x, t_y)^\top
  5. p' 变换后坐标经过缩放旋转平移后的新位置，用户看到的最终画面
    p′=(x′,y′)⊤\mathbf{p}' = (x', y')^\top

双语言生态：同一份菜谱两种做法

一家餐饮集团，中餐主厨和西餐主厨语言完全不通，但他们都能做出同一道招牌菜——因为总厨研发部下发了一份标准化的图文菜谱。Plotly 也做了同样的事：Python 端（plotly.py）负责数据分析和图形对象构建，JavaScript 端（plotly.js）负责浏览器渲染与交互监听。两边语言不通，却共享同一份“标准菜谱”——图形对象 JSON Schema。

使用 Python 时，你面对的是数据分析师熟悉的世界：Pandas 取数、DataFrame 切片、一行代码出图。而当前端团队需要把图表集成到 React 或 Vue 项目里时，可以使用 plotly.js 直接消费 JSON 配置。Python 端构造的每一个 Figure 对象都可以序列化为纯 JSON，前端拿到这份 JSON 就能还原出完全一致的交互式图表。

Python 与 JavaScript 之间的桥梁可以表示为：

这种双语言生态带来的直接收益是选型自由：团队以 Python 为主就选 plotly.py，以前端为主就选 plotly.js，两者数据模型完全一致，切换成本极低。更重要的是，跨团队协作时不再需要“翻译”——数据分析师交付一份 JSON，前端工程师直接渲染上线，这比传统“截图 + 标注”的协作方式高效了一个量级。

Python Figure→to_dict()JSON→plotly.jsWeb 交互图\text{Python Figure} \xrightarrow{\text{to\_dict()}} \text{JSON} \xrightarrow{\text{plotly.js}} \text{Web 交互图}
  1. Python Figure用 plotly.express 或 graph_objects 构造的图形对象，相当于后厨准备好的“半成品菜”
    fig=px.scatter(df,x="col1",y="col2")\text{fig} = \text{px.scatter}(\text{df}, x=\text{"col1"}, y=\text{"col2"})
  2. to\_dict() 序列化把 Figure 对象转换为纯 Python 字典，进而输出为 JSON——把半成品菜装进标准餐盒
    fig_dict=fig.to_dict()\text{fig\_dict} = \text{fig.to\_dict()}
  3. JSON 桥接一种语言无关的数据交换格式，中餐主厨和西餐主厨都认识这份“图文菜谱”
    JSON={"data":[… ],"layout":{… }}\text{JSON} = \{ \text{"data"}: [\dots], \text{"layout"}: \{\dots\} \}
  4. plotly.js 渲染前端拿到 JSON 后，用 D3 绑定 DOM、WebGL 绘制图形、事件系统绑定交互
    plotly.js: JSON→SVG/WebGL→交互事件\text{plotly.js: JSON} \rightarrow \text{SVG/WebGL} \rightarrow \text{交互事件}

数据到部署：后厨一条龙动线

透明厨房最让人舒适的是动线设计：买菜、洗切、烹饪、上桌，各环节无缝衔接，食客不用等太久。传统数据可视化流程最痛的一点是“断档”——数据分析师在 Jupyter 里画好图，要交给前端团队重新用 ECharts 或 Highcharts 实现一遍，等于同一道菜做了两次。Plotly 试图打通这条全链路，让从数据到 Web 展示一气呵成。

在 Plotly 的世界里，数据分析与可视化部署共享同一条流水线。你在 Jupyter Notebook 里完成数据清洗、特征分析、模型评估，顺手用同一套 DataFrame 画出交互式图表；之后将图表导出为自包含的 HTML 文件，这个文件内嵌了全部数据与 plotly.js 运行时，可以直接用浏览器打开、微信发送、邮件附件；再进一步，你还能把图表嵌入 Flask、FastAPI 等服务端渲染的页面中，让图表成为 Web 应用的一部分。

这条部署链路可以表示为：

这条动线的意义在于“一次分析，到处展示”。你不需要在 Python 画一遍、前端再画一遍——同一份 Figure 既能出现在 Jupyter 报告里，也能出现在生产环境的数据大屏上。对于经常要给业务方做数据汇报的 AI 工程师来说，这节省的不仅是时间，更是沟通中因“图表不一致”而产生的误解成本。

Data→plotFigure→write_htmlHTML→embedWeb\text{Data} \xrightarrow{\text{plot}} \text{Figure} \xrightarrow{\text{write\_html}} \text{HTML} \xrightarrow{\text{embed}} \text{Web}
  1. Data 原始数据经过清洗和特征工程之后、可供绘图的数据集，相当于洗净切好的“备菜”
    Data={(x1,y1,c1),(x2,y2,c2),… }\text{Data} = \{(x_1, y_1, c_1), (x_2, y_2, c_2), \dots \}
  2. plot 绘图调用 plotly 的绘图函数生成 Figure 对象，相当于掌勺烹饪
    Figure=px.scatter(Data,color="类目")\text{Figure} = \text{px.scatter}(\text{Data}, \text{color}=\text{"类目"})
  3. write\_html 导出将 Figure 连同数据与运行库打包为一个独立 HTML 文件，相当于“连锅带菜一起打包外送”
    HTML=fig.write_html("chart.html")\text{HTML} = \text{fig.write\_html}(\text{"chart.html"})
  4. embed 嵌入将 HTML 片段嵌入已有 Web 页面或由服务端动态渲染注入
    Web=HTML+页面容器/服务端模板\text{Web} = \text{HTML} + \text{页面容器/服务端模板}

Dash框架：把明星菜品开成连锁品牌

单张交互图表是一道好菜，能招待好一桌客人。但若想把“数据看板”做成可复制的连锁品牌——让多个图表、多个控件、多个页面协同工作，并让不懂 Python 的业务人员也能自助使用——你就需要一套标准化的品牌运营方案。Dash 就是 Plotly 官方给出的答案。

Dash 是一个基于 Flask 的 Python Web 框架，它将 Plotly 图表封装成语义化的组件，并提供了“回调”机制让图表与控件之间可以互相驱动。比如页面左侧放一个下拉菜单选择“部门”，右侧折线图就自动切换为该部门的业绩趋势。在 Dash 中，布局用 Python 代码声明式编写，交互逻辑用回调函数描述，全部打包成一个 Flask 应用，直接部署到任意服务器上。

Dash 回调机制的核心模式非常简洁：

Dash 把“交互式图表”升级为“交互式应用”，这是从“给业务方看一张图”到“给业务方一套分析工具”的跨越。AI 团队可以用 Dash 快速搭建模型指标监控后台、AB 实验分析平台、数据质量看板等内部工具，而无需养一支独立的前端团队。连锁品牌的本质是标准化——Dash 把图表、布局、回调三板斧标准化之后，剩下的事情就是批量复制。

Output=f(Input,State)\text{Output} = f(\text{Input}, \text{State})
  1. Input 输入控件用户可操作的交互组件，如下拉菜单、滑块、输入框——相当于连锁门店里的“点餐触摸屏”
    Input=dcc.Dropdown(options,value)\text{Input} = \text{dcc.Dropdown}(\text{options}, \text{value})
  2. State 状态数据回调执行时读取但不会触发回调的附加数据，相当于后厨备好的“固定配料表”
    State={"当前页面":"/dashboard","用户角色":"admin"}\text{State} = \{ \text{"当前页面"}: \text{"/dashboard"} , \text{"用户角色"}: \text{"admin"} \}
  3. f 回调函数由 Python 编写的业务逻辑，负责处理输入、读取状态、计算并返回新内容，相当于“店长决策大脑”
    f:Input×State→Outputf: \text{Input} \times \text{State} \rightarrow \text{Output}
  4. Output 输出组件被更新重绘的目标组件，通常是图表或其他 UI 元素，相当于“送餐窗口更新后的菜品”
    Output=dcc.Graph(figure=新图表)\text{Output} = \text{dcc.Graph}(\text{figure}=\text{新图表})

选型应用：开哪种餐饮业态

开餐厅之前，你得想清楚业态：街角快餐讲究出餐快、客单价低；高端私厨强调菜品精致、单桌服务；精品连锁则看重标准化与规模化。可视化技术栈的选型逻辑完全一样，Plotly 不是万能解，它适合的是那些“重交互、重探索、需要从分析到部署全链路打通”的场景。

与 ECharts 相比，Plotly 的优势在于 Python 生态无缝衔接和科学统计图表种类丰富（如 3D 图、统计分布图），劣势在于纯前端场景下 ECharts 的社区资源与定制灵活性略胜一筹；与 Bokeh 相比，Plotly 的 API 一致性更好、Dash 生态更完善，Bokeh 则在服务端推送和流式数据场景有独特优势。选型的本质是对多个维度做加权打分，找到最适配当前团队与场景的组合。

选型决策的数学模型可以表示为：

选型没有银弹，只有适合与否。如果你的场景是“Python 分析师产出、需要快速分享到 Web 端的交互式图表”，Plotly 几乎是最短路径；如果你的场景是“纯前端大屏、需要高度定制动画效果”，ECharts 可能更顺手。想清楚你的“餐饮业态”，再选你的“后厨方案”——这才是技术选型的正确姿势。

Score=∑i=1nwi⋅si\text{Score} = \sum_{i=1}^{n} w_i \cdot s_i
  1. w\_i 权重第 i 个评估维度的重要程度，权重大小反映团队对这个维度的在意程度——相当于你开店时对“翻台率”和“客单价”的权重分配
    wi∈[0,1],∑i=1nwi=1w_i \in [0, 1], \quad \sum_{i=1}^{n} w_i = 1
  2. s\_i 得分某个框架在第 i 个维度上的表现评分——相当于某个菜系在“出餐速度”维度上的评分
    si∈[0,10]s_i \in [0, 10]
  3. Σ 加权求和把所有维度的得分按权重汇总——相当于综合各维度给出最终开店决策
    Score=w1s1+w2s2+⋯+wnsn\text{Score} = w_1 s_1 + w_2 s_2 + \dots + w_n s_n
  4. Score 总分选型结果的量化度量，总分最高的方案即最优解
    方案最优  ⟺  Scoremax⁡\text{方案最优} \iff \text{Score}_{\max}

AI 应用场景

模型性能监控看板

阶段：模型部署与运维（Model Deployment & Monitoring）

解决的问题：传统方式下，模型上线后的性能指标（准确率、延迟、特征漂移）散落在日志和静态报告中，算法工程师发现问题时往往已经滞后数小时。用 Plotly + Dash 搭建看板后，指标变化以交互式图表实时呈现，支持悬停查看异常点、框选放大时间窗口、按模型版本筛选对比，让监控从“事后翻日志”变为“事中看仪表盘”。

具体案例：某金融风控团队部署了信贷审批模型，利用 Dash 构建监控页面：左侧下拉框选择模型版本，中间大图展示每日 KS 值与 PSI 稳定性指标，右侧表格列出 Top 特征漂移程度。业务方发现某日 KS 值骤降，通过框选放大当天时间窗，再悬停异常点定位到具体特征——原来是新接入的数据源字段分布发生偏移，半小时内完成了问题定位与回滚决策。

数据分析探索式报告

阶段：数据探索与特征分析（EDA）

解决的问题：传统 EDA 过程需要写大量 Matplotlib 代码反复调整视图，每个新视角都要重新运行代码。Plotly 的交互式图表让探索式分析摆脱了“改代码—重跑—看图”的循环，一份带悬停、缩放、筛选的图表就能承载多角度观察。

具体案例：电商数据分析师接到任务研究用户复购行为，她用 plotly.express 画出用户生命周期值与购买频次的散点图，用颜色区分会员等级、大小表示客单价。汇报时老板问“高价值用户集中在哪个地区”，她直接在图例中点击筛选“高价值”类别，并悬停查看每个点的省份字段——五分钟内完成了一个原本需要重新跑数才能回答的追问。

教学与文档中的可交互示例

阶段：知识传递与结果汇报（Presentation）

解决的问题：AI 课程和算法文档中大量使用静态示意图，读者无法直观感受参数变化对模型的影响。用 Plotly 制作可交互的教学图，读者可以拖动滑块改变超参数、点击图例开关不同曲线，从而主动理解算法行为。

具体案例：一位 AI 讲师编写 K 均值聚类教程，用 Plotly 绘制了不同 K 值下的聚类效果图，并加上滑块让读者实时调整簇数，观察轮廓系数的变化。学生从“看老师演示”变成“自己动手探索”，课程反馈中“算法直觉建立快”的评语比例显著提升。

Python 演示

python50 行
"""Plotly 交互式可视化：从模拟数据到可分享的 Web 图表"""import jsonimport plotly.express as pximport pandas as pd  def make_sample_data():    """生成模拟的办公楼能耗监测数据"""    return pd.DataFrame({        "日期": pd.date_range("2024-01-01", periods=60, freq="D"),        "温度": [5 + i * 0.3 + (i % 7) for i in range(60)],        "能耗": [220 + i * 2.5 + (i % 5) * 12 for i in range(60)],        "楼层": [f"{i % 5 + 1}F" for i in range(60)],    })  def build_interactive_chart(df):    """用声明式 API 创建交互式能耗散点图"""    fig = px.scatter(        df,        x="日期",        y="能耗",        color="楼层",        size=[8] * len(df),        hover_data=["温度"],        title="建筑能耗监测（悬停查看温度）",    )    fig.update_layout(dragmode="zoom")    return fig  def export_to_web(fig):    """导出为自包含 HTML 文件，双击即可在浏览器打开"""    fig.write_html("energy_dashboard.html")  def main():    df = make_sample_data()    fig = build_interactive_chart(df)    export_to_web(fig)    summary = {        "数据点": len(df),        "交互模式": fig.layout.dragmode,        "输出文件": "energy_dashboard.html",    }    print(json.dumps(summary, ensure_ascii=False, indent=2))  if __name__ == "__main__":    main()
目的：演示 Plotly 声明式 API 的完整工作流——生成模拟数据、一行代码创建带悬停与缩放的交互式散点图、导出为可在浏览器直接打开的自包含 HTML 文件。
  1. import plotly.express as px引入 Plotly 的高级接口，相当于走进透明厨房时领到的“快速点餐单”
  2. fig = px.scatter(df, x="日期", ...)声明式核心调用：只描述“数据放哪一列、颜色按哪一列”，不写任何绘图循环
  3. hover_data=["温度"]悬停提示配置：鼠标滑过数据点时自动展示这一列的值，就像服务员报出菜品配料
  4. fig.update_layout(dragmode="zoom")开启框选缩放交互模式，让食客能框选放大任意区域
  5. fig.write_html("energy_dashboard.html")导出为自包含 HTML，数据与渲染引擎一并打包，离线也能打开
  6. fig.layout.dragmode读取图表当前的交互配置，验证设置是否生效
  7. if __name__ == "__main__":标准入口守卫，确保脚本被直接运行时才执行主流程

常见误区

误区很多人觉得 Plotly 就是把 Matplotlib 的静态图画得更立体、更精致一点，本质上还是“画图库”，交互只是附带效果。

正解交互不是 Plotly 的装饰，而是它的核心设计理念。悬停、缩放、筛选、动画是内置于每一个图表中的一等公民能力；更进一步，Dash 把图表升级为可双向驱动的应用组件。这就像一家“透明厨房”与“普通餐厅”的区别——前者让你参与探索，后者只把菜端上桌。

为何常见：很多人只在 Jupyter 里用过 fig.show()，看到的是一个静态渲染结果，没有在浏览器里真正体验过交互操作，所以容易得出“只是好看一点”的结论。

误区市面上教程几乎全是 Python 示例，导致很多人以为 Plotly 只能用于 Python 环境，前端团队要接入只能靠后端渲染图片或 iframe。

正解Plotly 是双语言生态——Python 端的 plotly.py 和 JavaScript 端的 plotly.js 共享同一套 JSON 数据结构。前端完全可以直接用 plotly.js 消费 JSON 配置来渲染图表，React/Vue 项目都能以 npm 依赖方式接入。

为何常见：教程生态严重偏向 Python 数据分析场景，plotly.js 的文档入口相对隐藏，导致前端开发者被“看起来像 Python 库”的第一印象误导。

误区有人认为 Dash 不过是在 HTML 里嵌了几个 Plotly 图表，和用 `write_html` 导出再粘贴到页面里没本质区别。

正解Dash 是一个完整的 Web 应用框架。它提供组件系统、回调机制、多页面路由、权限管理等全套能力。回调让控件与图表双向驱动，相当于把“展示型菜单”升级为“可点菜、可反馈、可交互的智能餐桌”。write_html 导出的是静态页面，而 Dash 应用是一个有状态的动态系统。

为何常见：初级教程往往先教 write_html 导出，学习者会误以为那就是 Dash 的全部用法。

误区习惯了前端用 CDN 引入 js 库的做法，很多人以为 `write_html` 导出的文件也依赖外网加载资源，断网就白屏。

正解fig.write_html() 默认将 plotly.js 运行库连同全部数据一起内嵌到 HTML 文件中（include_plotlyjs='cdn' 时才会外链），生成的文件是自包含的，邮件发送、U 盘拷贝都能直接双击打开。

为何常见：Web 开发的主流实践是 CDN 引库节省流量，这种习惯性认知被错误迁移到了 Plotly 导出的场景中。

面试题

Q1. Plotly 的“声明式 API”核心含义是什么？

单选题 · easy

  • A.用户描述“要什么结果”，框架自动绘制← 正确答案
  • B.用户手动控制每一步绘制的指令
  • C.所有图表都必须使用 WebGL 渲染
  • D.必须编写 JavaScript 回调才能创建图

答案：A。声明式对应命令式——前者描述目标（“要一盘宫保鸡丁”），后者描述过程（“先切鸡丁再热油”）。Plotly 让用户传入数据和布局配置，框架自动完成绘制映射。B 是命令式特征；C 错在 Plotly 也支持 SVG 渲染；D 错在 Python 端无需写 JS。

Q2. Plotly 图表中鼠标悬停数据点时浮现详情，这个交互叫？

单选题 · easy

  • A.悬停提示（Hover）← 正确答案
  • B.动画过渡帧
  • C.数据筛选器
  • D.坐标缩放器

答案：A。悬停提示是 Plotly 最基础的交互能力，配置 hover_data 指定要展示的字段即可。动画是时序动态效果、筛选是条件过滤、缩放是坐标变换，三者都属于 Plotly 交互体系但与“浮现详情”不是一回事。

Q3. Plotly 缩放与平移操作在底层的本质是什么？

单选题 · mid

  • A.对数据点坐标做仿射变换← 正确答案
  • B.重新读取并过滤后端数据
  • C.切换图表的渲染引擎
  • D.修改数据点的颜色与大小

答案：A。缩放和平移本质是坐标变换 p' = s·p + t，仅改变观测窗口，数据本身不变。B 描述的是服务端筛选场景；C 是引擎切换；D 是视觉映射。仿射变换是图形学的基础机制，WebGL 渲染中也依赖它更新顶点位置。

Q4. 以下哪些属于 Plotly 双语言生态的组成部分？

多选题 · mid

  • A.Python 端 plotly.py 库← 正确答案
  • B.JavaScript 端 plotly.js 库← 正确答案
  • C.JSON 格式的图形描述桥接← 正确答案
  • D.SQL 查询接口来直接操作图表

答案：ABC。plotly.py 负责数据分析和图形对象构建，plotly.js 负责浏览器渲染，两者通过 JSON Schema 桥接共享同一套图形描述。SQL 是数据查询语言，与 Plotly 的图表对象无关。

Q5. 关于 fig.write_html() 导出的 HTML 文件，正确说法是？

单选题 · mid

  • A.默认内嵌数据与运行库，可离线打开← 正确答案
  • B.必须部署到服务器才能查看
  • C.只能显示静态图无交互能力
  • D.需要安装 Python 环境才能预览

答案：A。write_html() 默认启用 include_plotlyjs=True，将 plotly.js 运行时与数据一并内嵌，生成自包含 HTML，双击即可离线查看且交互完整。B 混淆了“导出分享”与“服务端部署”；C 与事实不符；D 浏览器无需 Python。

Q6. Dash 回调机制中的三类核心角色是什么？

单选题 · mid

  • A.Input、Output 与 State← 正确答案
  • B.Query、Filter 与 Join
  • C.Open、Save 与 Close
  • D.Start、Stop 与 Restart

答案：A。Dash 回调函数接受输入组件（Input）、可选状态数据（State），返回更新目标（Output）。B 是 SQL 操作；C 是文件操作；D 是运行控制。这三类角色构成了 Dash 交互应用的“点餐-读取-送餐”闭环。

Q7. 关于 Dash 中 State 与 Input 的区别，正确的有？

多选题 · hard

  • A.State 变化不会触发回调执行← 正确答案
  • B.Input 变化会触发回调执行← 正确答案
  • C.State 也可以触发回调执行
  • D.State 仅在回调读取时传递数值← 正确答案

答案：ABD。State 和 Input 的区别是“是否触发”：Input 变化自动触发回调，State 只在回调执行时被动读取当前值，不参与触发。A 与 C 互斥，A 正确则 C 错误。D 描述的是 State 的传值方式。理解这对关系是写高效 Dash 应用的基础。

Q8. 在 Plotly 与 Bokeh 的选型对比中，通常考量的维度是？

单选题 · mid

  • A.生态成熟度与 API 一致性← 正确答案
  • B.厨房菜品数量与口味数量
  • C.计算机 CPU 主频与内存大小
  • D.文档字体数量与排版样式

答案：A。选型维度通常包括生态成熟度、API 一致性、交互能力、部署链路、社区活跃度等。B 是比喻干扰项，菜品数量是比喻说法不是技术维度；C 是硬件指标；D 是无关项。

Q9. 选择 Plotly 作为交互可视化方案的合理理由有哪些？

多选题 · hard

  • A.数据分析到 Web 部署链路较短← 正确答案
  • B.双语言生态覆盖 Python 与 JS← 正确答案
  • C.声明式 API 降低使用门槛← 正确答案
  • D.不支持大数据量高效渲染

答案：ABC。Plotly 的核心优势就是分析到部署全链路打通（write_html/Dash）、双语言共享同一 JSON 模型、声明式 API 大幅降低上手成本。D 说法错误——Plotly 基于 WebGL 恰恰是为了支持大数据量高效渲染。

Q10. Plotly 中 D3.js 与 WebGL 的分工是什么？

单选题 · extreme

  • A.D3 负责数据绑定，WebGL 负责高性能渲染← 正确答案
  • B.D3 负责视频加工，WebGL 负责存储文字
  • C.两者功能完全一致可以任意互换
  • D.D3 运行在服务端，WebGL 运行在浏览器

答案：A。D3.js 擅长将数据绑定到网页 DOM 并管理图形元素；WebGL 调用 GPU 对大量顶点做高效绘制。两者是“组织者与画家”的分工——D3 负责按数据组织元素，WebGL 负责把上百万个点快速画出来。B、C 完全错误；D 错在 D3 是前端库，WebGL 虽运行在浏览器但两者都在客户端。