前端出图技术演进：从 HTML 表格到 WebGPU
选技术之前，先看全貌。
很多人第一次接触前端可视化，直接就扎进某个框架的文档里，慢慢啃配置，最后做出来一个能跑的图表。但过几个月遇到性能瓶颈，或者需要支持更复杂的交互，才发现当初选的工具根本不合适。
前端出图技术的演进，其实是一条非常清晰的脉络。理解这条脉络，选型时就不会慌乱。
时间线
先看一条时间线，感受一下这些技术出现的节奏：
| |
这条时间线背后，有三条演进主线。
三条演进主线
渲染模式：从保留到即时再到 GPU
浏览器图形渲染经历了三种模式。
SVG 代表保留模式。浏览器维护一棵图形 DOM 树，每个元素可被查询、操作、绑定事件。这种模式的优点是直观，用起来像操作普通 HTML 元素一样。但代价是节点数膨胀后，布局与重绘的开销会越来越大。
Canvas 代表即时模式。开发者向画布下达绘制指令，图形即时变为位图像素。系统不保留图形状态，这换来了高吞吐量，但失去了元素级交互。你需要自己追踪鼠标位置、处理点击事件，或者用第三方库帮你封装一层对象模型。
WebGL 和 WebGPU 则将渲染交给 GPU 的可编程着色器管线，实现大规模并行计算。这开启了百万级数据点与真 3D 可视化的可能，但代价是开发复杂度的指数级上升。
flowchart TD
A[保留模式<br/>SVG] --> B[即时模式<br/>Canvas]
B --> C[GPU 并行<br/>WebGL/WebGPU]
style A fill:#FF9800,color:#fff
style B fill:#2196F3,color:#fff
style C fill:#4CAF50,color:#fff图表生产：从手工绘制到配置驱动再到代码即图表
早期的图表靠 HTML 表格、CSS 定位手工拼凑。那时候做一个柱状图，得用表格单元格模拟柱子的高度，用 background-color 上色。工作量大，调整也麻烦。
随后 Chart.js、ECharts、Highcharts 等库引入配置驱动范式。传入一个 JSON 配置对象，库自动渲染出图。这种模式大大降低了使用门槛，但配置维度多、文档厚，熟悉成本不低。
与此同时，Graphviz、PlantUML、Mermaid 开创了图表即代码范式。用文本描述图表，由引擎自动布局并输出 SVG。这让图表可以被版本管理、可以被 diff、可以被 AI 生成。在技术文档和架构图中，这种范式越来越流行。
flowchart TD
A[手工绘制<br/>HTML 表格拼图] --> B[配置驱动<br/>Chart.js/ECharts]
B --> C[图表即代码<br/>Mermaid/PlantUML]
style A fill:#FF9800,color:#fff
style B fill:#2196F3,color:#fff
style C fill:#9C27B0,color:#fff动效：从装饰到数据叙事
早期 Web 动画多为 Flash 插件或 GIF。那时候动效主要是为了"酷炫"，让页面看起来不那么朴素。
SVG 的 SMIL 动画和 CSS 动画让声明式动效成为可能。不需要 JavaScript，一行 CSS 就能让元素动起来。
GSAP 提供了专业级时序编排能力。复杂的时间轴、缓动函数、动画链，这些在数据可视化的过渡动画里特别重要。
Lottie 打通了设计师与开发的协作链路。设计师在 After Effects 里做动画，导出 JSON，开发集成到项目中。这解决了"设计师做的动效还原度不高"的痛点。
现代数据可视化中，动效承担着"感知性能优化"与"数据叙事"的核心职责。用过渡掩盖加载延迟，用动画传达数据变化的因果关系。动效不再是装饰，而是信息传递的一部分。
为什么要理解这条脉络
知道这些历史有什么用？
第一个用处，是选型时有坐标系。你要做的是静态技术文档图，还是需要百万数据点的实时监控？是给设计师用的高保真原型工具，还是给开发者用的自动化报表？不同的需求对应不同时代的最佳实践。
第二个用处，是理解工具的局限性。SVG 看起来方便，但节点数超过阈值就会卡顿。Canvas 性能好，但交互要自己造轮子。WebGL 强大，但开发门槛高。知道为什么存在这些权衡，你才知道什么时候该用哪个。
第三个用处，是看到趋势的方向。从手工到配置再到代码，从保留到即时再到 GPU，从装饰到叙事。这些趋势还会继续演进，理解过去才能更好地预判未来。
下一步
了解全貌后，就可以开始学习具体技术了。每一代技术都有其适用场景，没有万能银弹。根据需求选型，理解权衡，这才是理性的做法。
接下来会深入每个技术方向，从基础概念到实战案例，帮你建立完整的前端可视化知识体系。