canvas适合2d图形、动画和图像处理，但不擅长大规模图元、高频重绘、复杂交互和跨设备一致性；webgl绕过cpu直接调度gpu，专为高性能高吞吐量图形设计，适用于图元超20k、高频更新及样式规律性强的场景，二者非替代关系而是分层协作——canvas负责交互层，webgl负责数据呈现层。
Canvas 绘图 API 适合快速实现 2D 图形、动画和图像处理，但它的局限性很明确：不擅长处理大规模图元、高频重绘、复杂交互和跨设备一致性。WebGL 不是 Canvas 的“升级版”，而是另一条技术路径——它绕过 CPU 主线程，直接调度 GPU，专为高性能、高吞吐量图形而生。选型不能只看“3D 还是 2D”，关键得看你的数据规模、刷新频率、交互粒度和维护成本。
Canvas 的硬伤：不是性能不够，而是模型不对
Canvas 是即时模式（Immediate Mode）绘图系统：你画完就没了，没有对象概念，也没有内置的命中检测或事件绑定。所有交互逻辑（比如点击某个圆）必须手动实现坐标计算和几何判断。当图元超过 2k，尤其每帧都要重算位置+重绘时，CPU 压力会迅速上升；若叠加 CSS 动画或大量 DOM 更新，主线程容易卡顿。它也不支持矢量缩放保真——放大后就是像素块，无法像 SVG 那样响应式清晰。
- 图元数 > 5k 且需每秒重绘 ≥10 次 → Canvas 开始吃力
- 需要单点编辑、拖拽、右键菜单等细粒度交互 → Canvas 要自己写一整套交互层
- 导出高清图或适配高 DPI 屏幕 → Canvas 输出依赖 canvas.toDataURL()，易模糊、无语义
WebGL 的适用边界：别为了 3D 而用 WebGL
WebGL 的优势不在“能画 3D”，而在“能批量调度 GPU”。它真正胜出的场景是：图元数量大（20k+）、更新频率高（如粒子系统、实时拓扑连线、热力网格）、样式变化规律性强（比如按数值映射颜色、大小）。这时，用着色器一次性处理成千上万个顶点，比 Canvas 逐个调用 fillRect 快一个数量级。但它不解决交互问题——点击拾取仍需额外计算，且调试成本高、兼容性略弱（老 IE/部分国产内核不支持）。
用户要生成可打印的中文字帖/练习纸、导出多页 A4 PDF 报告，或把 SVG 设计稿零误差还原到 Canvas 时使用。本技能是「Canvas 内容工厂闭环」的总控，编排：网格渲染引擎(13 种教育网格+拼音标注) → 多页 PDF 导出(A4 合成) → SVG 精准复刻(坐标误差<0.001px)。触发词：生成字帖、练习纸、导出 PDF、SVG 转 Canvas、印刷级还原、A4 报告、米字格田字格。
- 用 WebGL 前先确认：你是否在反复绘制相似结构？能否把状态抽象为 uniform / attribute？
- 如果只是画几个旋转立方体，Canvas 2D + requestAnimationFrame 更轻量、更可控
- 已有 Canvas 渲染逻辑？别硬迁——WebGL 不是 Canvas 的替代品，而是不同问题的解法
折中方案：Canvas + WebGL 混合使用
真实项目里，纯 WebGL 或纯 Canvas 很少。常见做法是分层渲染：UI 层（按钮、文字、图例）用 Canvas 2D 或 SVG，保证可访问性和开发效率；数据密集层（轨迹线、散点云、动态网格）用 WebGL 加速。OpenLayers 就是典型例子——底图用 Canvas 渲染，海量矢量点用 WebGL Vector Layer 提升帧率。这种组合既规避了 Canvas 的性能瓶颈，又避免了 WebGL 全栈重写。
- Canvas 负责“人机交互层”：标注、弹窗、控制面板
- WebGL 负责“数据呈现层”：每帧上万点、持续动画、视角变换
- 共享数据结构（如 GeoJSON 坐标数组），避免重复解析和内存拷贝
选型 checklist：三句话定方向
不必纠结“哪个更先进”，只需回答三个问题：
- 你每帧要画多少个独立图形？＜2k → Canvas；＞5k 且持续刷新 → WebGL
- 用户是否要对每个图形单独操作？是 → SVG 或 Canvas + 自建交互；否 → WebGL 更省事
- 团队有没有人熟悉 GLSL 或矩阵变换？没有 → Canvas 更安全；有 → WebGL 可控性反而更高
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
