Web特效05——聚焦"浏览器原生的三个API"（Canvas2D / WebGL / WebGPU）
前几篇我们搞懂了渲染管线、坐标系统、像素和顶点、CPU和GPU——这些都是地基。但真要动手在浏览器里画东西，绕不开一个问题：到底该用什么API？MDN上能查到至少三个名字：Canvas2D、WebGL、WebGPU。很多人下意识以为"Canvas2D画2D、WebGL/WebGPU画3D"，其实不是这么回事——三者的真正区别不在2D还是3D，而在抽象层级：Canvas2D是"画笔式"的高层指令，无需理解GPU和shader；WebGL则要自己准备顶点数据、手写着色器，2D、3D通用，只是门槛更高；WebGPU是WebGL的继任者，更底层也更现代，还多了通用计算能力。这篇就把三者摆在一起，讲清楚各自的抽象层级、适用场景，为后面深挖WebGL和WebGPU打好坐标基础。
一、三个名字，一个容易踩的坑
打开MDN搜"Web绘图"，你会撞见三个名字：Canvas2D、WebGL、WebGPU。这三个都是浏览器原生自带的接口，不需要引入任何第三方库，写代码时随手就能拿到手。
但很多人对它们的第一反应是这样的：
Canvas2D 用来画2D的东西，WebGL/WebGPU 用来画3D的东西——挑一个对应自己需求的用就行。
这个念头很自然，也很容易踩坑。因为它把三者放在了错误的坐标轴上。
三者真正的区别，不是"画2D还是画3D"，而是抽象层级——也就是"浏览器帮你做了多少事，你自己又要亲手管多少事"。
-
Canvas2D 是一套"画笔式"的高层API。你调用
ctx.fillRect(...)、ctx.arc(...)这类方法，直接下达"画一个矩形""画一个圆"的指令，背后怎么变成屏幕上的像素，浏览器帮你包办了。你完全不需要知道GPU是什么、shader是什么。 -
WebGL 站在完全不同的抽象层级上。它不是"画笔"，而是把最基础的绘制能力——准备顶点数据、写一段跑在GPU上的着色器（Shader）程序——直接暴露给你。你要自己组织三角形网格、自己写顶点和片元着色器。关键是：WebGL本身对2D、3D一视同仁，你往里面塞2D坐标它就画2D，塞3D坐标它就画3D，"能不能画3D"从来不是Canvas2D和WebGL的分界线。
-
WebGPU 是WebGL的继任者，站在比WebGL更底层、也更现代的位置——接口设计更贴近GPU硬件的真实工作方式，而且不止能画图，还多了一种能力：通用计算（Compute Shader），可以把GPU当成一个并行计算器来用，不只是画东西。
所以真正该画的坐标轴，是一条"抽象层级"的轴：一端是"浏览器帮你包办一切"的Canvas2D，另一端是"你自己动手、掌控更细"的WebGL和WebGPU。越往右走，能做的特效上限越高，但你需要理解的底层知识也越多。
这也是为什么这个系列要先讲坐标系统、像素和顶点、GPU和CPU——这些正是你往"抽象层级"右端走时，绕不开的地基。接下来两节，我们就沿着这条轴，先看Canvas2D这一端长什么样。
二、Canvas2D：画笔式的高层API
想象你要在一张纸上画画。你可以直接拿起笔说"在这里画个圆""把这块涂成蓝色"——不需要关心纸的材质、墨水怎么附着，笔和纸的物理细节都被"笔"这个工具屏蔽掉了。Canvas2D 就是这样一支"笔"。
专业说法是：Canvas2D 提供了一套**立即模式（Immediate Mode）**的绘图API——你调用一条指令，浏览器立刻把对应的像素画出来，不需要你管理任何底层状态。
1. 拿到画布，开始画
用Canvas2D画东西分两步：先拿到一个<canvas>元素的2D上下文，再调用上下文上的方法下达绘图指令。
<canvas id="stage" width="400" height="300"></canvas>
<script>
const canvas = document.getElementById('stage');
const ctx = canvas.getContext('2d');
// 画一个矩形
ctx.fillStyle = '#378ADD';
ctx.fillRect(50, 50, 120, 80);
// 画一个圆
ctx.beginPath();
ctx.arc(280, 90, 40, 0, Math.PI * 2);
ctx.fillStyle = '#D85A30';
ctx.fill();
// 画一条路径（多段直线拼成的折线）
ctx.beginPath();
ctx.moveTo(50, 200);
ctx.lineTo(150, 250);
ctx.lineTo(250, 180);
ctx.strokeStyle = '#1D9E75';
ctx.lineWidth = 3;
ctx.stroke();
</script>
getContext('2d')拿到的这个ctx对象，就是你和画布之间唯一的接口——后面所有的绘制都是在调用它身上的方法。
2. 常用绘图方法速查
| 方法 | 作用 | 常见搭配 |
|---|---|---|
fillRect(x, y, w, h) | 画一个填充矩形 | fillStyle 设置颜色 |
strokeRect(x, y, w, h) | 画一个描边矩形 | strokeStyle、lineWidth |
beginPath() + arc() | 画圆/弧线 | fill() 或 stroke() 收尾 |
moveTo() + lineTo() | 画折线/多边形路径 | 配合 beginPath() 使用 |
drawImage() | 画一张图片/视频帧 | 常用于精灵图、视频特效 |
fillText() | 画文字 | font 设置字体 |
这里有个容易被忽略的细节：
beginPath()不是可选的装饰，而是"告诉画布：我要开始一条新路径了"。忘记调用它，新画的路径会和上一条路径粘在一起，导致图形意外连接。
3. 画一帧背后发生了什么
从调用指令到屏幕上出现像素，Canvas2D帮你处理了整个链路：
flowchart LR
A[调用绘图指令<br/>fillRect/arc/drawImage] --> B[浏览器内部光栅化]
B --> C[canvas像素缓冲区]
C --> D[合成到屏幕]
你只需要停留在最左边这一格——"调用绘图指令"，后面三格浏览器全帮你办了。这也正是Canvas2D"高层"的含义：它把光栅化（Rasterization，也就是把矢量指令变成像素）这一步彻底藏了起来，不像后面要讲的WebGL，需要你自己去面对这个环节。
4. 来个demo案例
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8">
<title>Canvas2D 渐变画笔演示</title>
<style>
body {
font-family: -apple-system, "PingFang SC", "Microsoft YaHei", sans-serif;
background: #f1efe8;
display: flex;
flex-direction: column;
align-items: center;
padding: 40px 20px;
}
h1 {
font-size: 18px;
font-weight: 500;
color: #2c2c2a;
margin: 0 0 20px;
}
.controls {
display: flex;
gap: 12px;
margin-bottom: 16px;
}
button {
padding: 8px 18px;
font-size: 14px;
border: 0.5px solid #b4b2a9;
border-radius: 8px;
background: #ffffff;
cursor: pointer;
}
button:hover {
background: #f1efe8;
}
button:disabled {
opacity: 0.5;
cursor: not-allowed;
}
#stage {
border: 0.5px solid #b4b2a9;
border-radius: 8px;
background: #ffffff;
}
</style>
</head>
<body>
<h1>Canvas2D 渐变画笔演示</h1>
<div class="controls">
<button id="startBtn">开始动画</button>
<button id="resetBtn">重置</button>
</div>
<canvas id="stage" width="640" height="320"></canvas>
<script>
const canvas = document.getElementById('stage');
const ctx = canvas.getContext('2d');
const cssW = canvas.width;
const cssH = canvas.height;
const startBtn = document.getElementById('startBtn');
const resetBtn = document.getElementById('resetBtn');
// 预先算好画笔要走的路径（一条起伏的曲线）
let path = [];
const steps = 400;
for (let i = 0; i <= steps; i++) {
const t = i / steps;
const x = 60 + t * (cssW - 120) + Math.sin(t * Math.PI * 3) * 30;
const y = cssH / 2 + Math.sin(t * Math.PI * 5) * (cssH / 2 - 50) * Math.sin(t * Math.PI);
path.push({ x, y });
}
// 沿途安排几块要被"涂亮"的色块
const blockColors = ['#378ADD', '#D85A30', '#1D9E75', '#EF9F27', '#7F77DD'];
function makeBlockPlan() {
const plan = [];
for (let i = 0; i < 6; i++) {
plan.push({
frame: Math.floor((i + 1) * steps / 7),
x: 40 + Math.random() * (cssW - 120),
y: 30 + Math.random() * (cssH - 100),
size: 28 + Math.random() * 36,
color: blockColors[Math.floor(Math.random() * blockColors.length)]
});
}
return plan;
}
let blockPlan = makeBlockPlan();
let idx = 0;
let running = false;
let finished = false;
let rafId = null;
// 每一帧只往前推进一小段，画笔就会像手绘一样慢慢"长出来"
function drawSegment() {
if (idx >= path.length - 1) {
running = false;
finished = true;
startBtn.disabled = true;
return;
}
const grad = ctx.createLinearGradient(0, 0, cssW, cssH);
grad.addColorStop(0, '#378ADD');
grad.addColorStop(0.5, '#D85A30');
grad.addColorStop(1, '#1D9E75');
const a = path[idx];
const b = path[idx + 1];
ctx.beginPath();
ctx.moveTo(a.x, a.y);
ctx.lineTo(b.x, b.y);
ctx.strokeStyle = grad;
ctx.lineWidth = 4;
ctx.lineCap = 'round';
ctx.lineJoin = 'round';
ctx.stroke();
const block = blockPlan.find(bp => bp.frame === idx);
if (block) {
ctx.fillStyle = block.color + '99';
ctx.fillRect(block.x, block.y, block.size, block.size);
}
idx++;
rafId = requestAnimationFrame(drawSegment);
}
function startDraw() {
if (running || finished) return;
running = true;
startBtn.disabled = true;
drawSegment();
}
function resetCanvas() {
if (rafId) cancelAnimationFrame(rafId);
ctx.clearRect(0, 0, cssW, cssH);
idx = 0;
running = false;
finished = false;
blockPlan = makeBlockPlan();
startBtn.disabled = false;
}
startBtn.addEventListener('click', startDraw);
resetBtn.addEventListener('click', resetCanvas);
</script>
</body>
</html>
什么时候该用它
Canvas2D的优势是简单、直观、上手成本低，很适合：图表绘制、简单的2D游戏、像素级图像处理（读取/修改像素数据）、UI原型验证。但它有一个天花板：所有绘制都跑在CPU上（或者说，浏览器帮你调度到GPU，但你完全无法干预这个过程），当画面里有成千上万个元素需要同时变化时，性能会先掉下来——这也是为什么"做特效"这件事，早晚要往抽象层级的另一端走。
下一节，我们就跨过这条线，看看WebGL把哪些原本被Canvas2D藏起来的东西，重新交还给了你。
三、WebGL：把活儿交给GPU
还是拿画画打比方。Canvas2D像点餐——你对服务员说"给我画个圆"，后厨（浏览器内部）怎么处理，你完全不用管。WebGL则像是直接被请进了后厨：食材（顶点数据）你得自己准备，火候和做法（一段跑在GPU上的小程序）你也得自己写清楚——但换来的是一整支能同时颠勺的厨师团队，而不是一个人埋头慢慢画。这支"厨师团队"，就是GPU里成百上千个可以并行运算的核心。
专业说法是：WebGL提供的是一套**可编程渲染管线（Programmable Rendering Pipeline）**接口。核心工作被拆成两段你自己写的小程序——顶点着色器（Vertex Shader）和片元着色器（Fragment Shader，也叫像素着色器）。这两段代码不是JS，而是专门交给GPU执行的语言：GLSL（OpenGL Shading Language）。
WebGL不负责"画什么"，它只负责：把你准备好的顶点数据，按你写的着色器程序，在GPU上跑一遍。
1. 数据要走一条固定的管线
不管你想画三角形、方块还是复杂模型，数据在WebGL里都要经过同一条管线：
flowchart LR
A[顶点数据<br/>Buffer] --> B[顶点着色器<br/>算出每个顶点的屏幕位置]
B --> C[图元装配+光栅化<br/>顶点连成三角形,拆成像素]
C --> D[片元着色器<br/>算出每个像素的颜色]
D --> E[帧缓冲<br/>最终画面]
顶点着色器管"点在哪"，片元着色器管"这个点是什么颜色"——这两段代码你都得亲手写，浏览器不会替你做任何决定。这也是为什么WebGL比Canvas2D"底层"：Canvas2D帮你把这条管线全藏起来了，WebGL则把它整个摊开在你面前。
2. 一个最简单的三角形，要写多少代码
哪怕只是画一个纯色三角形，WebGL也要经过"写着色器→编译→链接→准备顶点数据→绑定→绘制"这一整套流程：
const canvas = document.getElementById('stage');
const gl = canvas.getContext('webgl');
// 顶点着色器：决定每个顶点画在屏幕的哪个位置
const vertexSrc = `
attribute vec2 aPosition;
void main() {
gl_Position = vec4(aPosition, 0.0, 1.0);
}
`;
// 片元着色器：决定每个像素填什么颜色
const fragmentSrc = `
precision mediump float;
void main() {
gl_FragColor = vec4(0.22, 0.54, 0.86, 1.0); // 一个蓝色
}
`;
function compileShader(gl, type, source) {
const shader = gl.createShader(type);
gl.shaderSource(shader, source);
gl.compileShader(shader);
return shader;
}
const vs = compileShader(gl, gl.VERTEX_SHADER, vertexSrc);
const fs = compileShader(gl, gl.FRAGMENT_SHADER, fragmentSrc);
const program = gl.createProgram();
gl.attachShader(program, vs);
gl.attachShader(program, fs);
gl.linkProgram(program);
gl.useProgram(program);
// 三角形的三个顶点(裁剪空间坐标,范围-1到1)
const vertices = new Float32Array([
0.0, 0.5,
-0.5, -0.5,
0.5, -0.5,
]);
const buffer = gl.createBuffer();
gl.bindBuffer(gl.ARRAY_BUFFER, buffer);
gl.bufferData(gl.ARRAY_BUFFER, vertices, gl.STATIC_DRAW);
const aPosition = gl.getAttribLocation(program, 'aPosition');
gl.enableVertexAttribArray(aPosition);
gl.vertexAttribPointer(aPosition, 2, gl.FLOAT, false, 0, 0);
gl.drawArrays(gl.TRIANGLES, 0, 3);
同样是画一个图形，Canvas2D一行fillRect就搞定，WebGL要走完编译着色器、创建buffer、绑定属性这一整套流程。这也是很多人第一次接触WebGL时的感受——门槛陡然拔高。但换来的是：这三个顶点的位置计算、这个三角形每个像素的颜色计算，理论上可以被GPU的成百上千个核心同时处理，而不是CPU一个一个算。
3. 几个绕不开的新概念
| 概念 | 是什么 |
|---|---|
| Buffer | 存放顶点数据的一块GPU内存 |
| Attribute | 顶点着色器里，从buffer取出的"每个顶点独有"的数据(比如位置) |
| Uniform | 整次绘制里所有顶点/像素共享的数据(比如一个统一的颜色、一个变换矩阵) |
| 裁剪空间坐标(NDC) | WebGL的坐标系统，x/y都被限制在-1到1之间，和屏幕像素坐标不是一回事 |
| Draw Call | 一次"开始绘制"的调用，比如例子里的gl.drawArrays() |
注意这里的坐标系统——WebGL用的是-1到1的裁剪空间坐标，和我们前面讲坐标系统那篇里提到的屏幕像素坐标是两套体系。真正做特效时，两套坐标之间的换算是绕不开的一环。
4. 小结：Canvas2D vs WebGL
| Canvas2D | WebGL | |
|---|---|---|
| 绘制方式 | 调用高层指令(fillRect等) | 提交顶点数据+自己写的着色器程序 |
| 谁在算 | 浏览器内部处理，对你透明 | 显式跑在GPU的并行运算单元上 |
| 用什么语言 | 纯JavaScript | 着色器用GLSL，其余配合用JS |
| 典型场景 | 图表、简单2D游戏、原型验证 | 大量图形元素、粒子特效、3D场景 |
WebGL把"怎么画"这件事的控制权整个交还给了你，代价是你要理解顶点、着色器、buffer这些新概念。下一节我们看WebGPU——它站在比WebGL更底层的位置，接口设计更贴近GPU硬件本身，还多了一种WebGL没有的能力：通用计算。
四、WebGPU：更底层，也更现代
如果说WebGL已经把"怎么画"的控制权交还给了你，WebGPU做的是更进一步的事：把GPU本身的能力，更完整、更贴近硬件真实工作方式地暴露出来。
WebGL诞生于2011年，那时候移动GPU的架构和今天已经很不一样了。这些年GPU硬件本身进化了很多，但WebGL的接口设计一直没跟上——它背后其实还绑定着更老的OpenGL ES设计思路。WebGPU就是浏览器厂商重新设计的一套现代GPU接口，直接对标Vulkan、Metal、DirectX 12这些现代图形API的设计理念。
1. 从"每次都要重新配置"到"提前编译好的管线对象"
WebGL里，你调用gl.drawArrays()之前，浏览器要在背后帮你做大量状态检查和转换工作——你设置了哪个着色器、哪个buffer、哪个纹理，这些状态零散地挂在一个全局上下文上，每次绘制前都要重新校验一遍，这些隐藏的开销你完全看不见,也控制不了。
WebGPU把这些状态提前打包成一个"管线对象"（Pipeline Object）：你一次性把"用哪个着色器、顶点数据长什么样、怎么混合颜色"这些配置都定义清楚，编译成一个固定的管线，之后反复调用这个管线就行，浏览器不用每次都重新校验状态。这在需要频繁切换绘制状态的复杂场景里（比如同一帧要画成百上千个不同材质的物体），性能差距会很明显。
2. 真正的新能力：通用计算（Compute Shader）
WebGL的shader只能干一件事——参与"画图"这个流程，顶点着色器算位置，片元着色器算颜色，输出永远是屏幕上的像素。
WebGPU多了一种独立的着色器类型：Compute Shader（计算着色器）。它不负责画任何东西，纯粹是把GPU当成一个大规模并行计算器来用——比如同时对几十万个粒子做物理模拟、做图像的并行滤镜处理、做机器学习里的矩阵运算。GPU天生擅长"同一段代码，海量数据并行跑"，Compute Shader就是把这个能力单独拆出来，不用再绕道"伪装成画图"去蹭GPU的并行算力。
这也是本节插图想说明的：WebGL能碰到的只是GPU里"渲染管线"这一块，WebGPU则同时打通了渲染管线和通用计算管线——多出来的这块，是做复杂粒子特效、物理模拟类效果时真正的底气所在。
3. WebGL vs WebGPU 速览
| WebGL | WebGPU | |
|---|---|---|
| 设计年代 | 2011年，对标OpenGL ES | 近几年设计，对标Vulkan/Metal/DirectX 12 |
| 状态管理 | 每次绘制前动态校验 | 提前编译成管线对象，复用开销更低 |
| 着色器类型 | 顶点着色器、片元着色器 | 顶点、片元着色器 + 独立的Compute Shader |
| 通用计算能力 | 没有，只能绕道用着色器"伪装"计算 | 原生支持，不依赖绘制流程 |
| 着色器语言 | GLSL | WGSL(WebGPU Shading Language) |
| 浏览器支持 | 几乎所有现代浏览器 | 逐步铺开中,需要留意目标浏览器的支持情况 |
值得一提的是着色器语言也换了一套：WebGL用GLSL，WebGPU用的是专门新设计的WGSL（WebGPU Shading Language），语法风格和GLSL不完全一样，等真正上手写WebGPU代码时会再细讲。
到这里，Canvas2D、WebGL、WebGPU这三个原生API的核心差异都讲完了。下一节我们把它们放在一起，给一份实用的选型对照，收束这条"抽象层级"的主线。
五、三者到底怎么选
前面四节把Canvas2D、WebGL、WebGPU的抽象层级和能力边界都拆开讲了。这一节收个尾，给一份实操层面的选型参考。
1. 先看你要做的事，而不是先纠结技术选型
选型的第一步不是问"WebGL和WebGPU哪个更好"，而是问"我要画的东西，规模和复杂度到什么程度"。
- 画面里的图形元素数量不多（几十到几百个），逻辑以"响应用户操作重绘"为主 → Canvas2D就够了，没必要上GPU编程。
- 需要同时处理成千上万个图形元素，或者要做真正意义上的3D场景、粒子系统、自定义光照/材质效果 → 绕不开WebGL或WebGPU。
- 需要做大规模并行计算（物理模拟、图像批量处理），而不只是"画出来" → 这是WebGPU独有的强项，WebGL做不到。
2. Canvas2D：优先级最高的默认选项
如果你的需求Canvas2D能覆盖，就应该优先选它——不是因为它"简单"，而是因为它开发成本低、调试直观、不用操心兼容性。判断标准很简单：这个效果如果用"画笔在纸上画"的方式能想清楚，Canvas2D大概率能做。
典型场景：数据可视化图表、简单的2D小游戏、图片的像素级处理（滤镜、裁剪）、UI里的小动效。
3. WebGL：目前兼容性最好的GPU编程入口
WebGL的最大优势是几乎所有现代浏览器都支持，包括不少较老的移动设备。如果你的项目需要顾及兼容性，或者社区里现成的库、教程、案例更丰富（比如three.js这类建立在WebGL之上的框架，生态已经非常成熟），WebGL仍然是当前最稳妥的选择。
典型场景：3D产品展示、数据可视化里的大规模点云/图表、需要自定义shader效果的视觉特效、绝大多数"Web 3D"相关的应用场景。
4. WebGPU：面向未来，但要看场合
WebGPU的能力上限更高，尤其是需要用到通用计算（比如粒子数量极大的模拟、GPU加速的图像/视频处理）时，是目前浏览器端唯一的原生选择。但它也有两个现实约束：
- 浏览器支持还在逐步铺开，用之前要确认目标用户的浏览器版本是否覆盖。
- 生态还年轻，社区案例、封装库都不如WebGL/three.js丰富，很多东西要自己动手写。
典型场景：需要大规模并行计算的特效（比如几十万粒子的物理模拟）、追求极致渲染性能的场景、面向新版浏览器用户群体的实验性项目。
5. 一张对照表收尾
| Canvas2D | WebGL | WebGPU | |
|---|---|---|---|
| 上手成本 | 低 | 中高 | 高 |
| 浏览器兼容性 | 好 | 很好(几乎全覆盖) | 逐步铺开中 |
| 图形规模上限 | 几十~几百个元素 | 海量,3D场景 | 海量,3D场景+通用计算 |
| 生态成熟度 | 成熟 | 非常成熟(three.js等) | 还年轻 |
| 通用计算能力 | 无 | 无 | 有 |
| 适合场景 | 图表/简单2D动效/像素处理 | 3D展示/大规模可视化/自定义特效 | 粒子模拟/GPU并行计算/前沿场景 |
一句话总结：能用Canvas2D解决的，别急着上GPU编程；需要GPU编程时，先默认选WebGL图个稳妥；只有当你确实需要通用计算能力、又能接受兼容性代价时，才考虑WebGPU。
六、这只是地基，接下来往哪走
回头看一眼这篇文章走过的路：从"三个名字容易被误解成2D vs 3D"这个坑出发，我们搞清楚了Canvas2D、WebGL、WebGPU真正的区别在于抽象层级——一端是浏览器帮你包办一切的画笔式API，另一端是把顶点、着色器、GPU管线整个摊开给你的底层接口。
Canvas2D用一行fillRect就能画出东西，代价是你摸不到GPU的并行算力；WebGL把控制权交还给你，但你得自己写GLSL着色器、自己管理buffer；WebGPU站得更靠近硬件本身，管线提前编译成对象、状态切换开销更低，还多出了Compute Shader这个通用计算的口子。三者不是三选一的竞争关系，而是同一条抽象层级轴上，由浅入深的三个站点。
这一篇建的是"地图"，接下来要做的是沿着地图往深处走。具体往哪走，是这篇文章里埋下的三条线：
- WebGL的着色器与渲染管线：这篇里那个"画一个三角形"的demo只是冰山一角。顶点着色器和片元着色器具体怎么协作、GLSL的语法长什么样、uniform和attribute怎么配合动画和交互——这些都值得单独拆一整篇细讲。
- WebGPU的管线对象与计算能力：管线对象具体怎么创建、WGSL和GLSL的语法差异、Compute Shader怎么写一个真正的并行计算demo（比如几万个粒子的物理模拟）——这是WebGL天花板之上的部分。
- Three.js：建立在WebGL之上的框架：前面提过，Three.js不是浏览器原生API，而是把WebGL的这些底层细节封装成了Scene、Camera、Mesh这些高层概念。等WebGL的底子打好了，理解Three.js到底帮你省了哪些活，会顺畅很多。
这三条线里，我们打算先从WebGL的着色器开始往下写——毕竟不管是WebGPU还是Three.js，"顶点着色器算位置、片元着色器算颜色"这套底层逻辑都是共通的，越早吃透，后面走得越快。
七、关于八荒启
八荒启是一家专注于交互体验产品与解决方案的品牌，持续探索交互技术在教育教学、产品展示、过程模拟、操作训练和数据可视化等场景中的应用。
我们不仅分享技术实现，也持续创作和沉淀交互动画、数字作品、开发教程、项目案例与行业解决方案，希望通过交互技术，让复杂事物变得更加容易理解、探索、操作和创造。
八荒启，专为交互动画而生
让复杂事物可探索、可操作、可反馈
如果你正在寻找交互作品、学习相关技术，或者希望把一个想法转化为可实际操作的交互项目，欢迎访问八荒启官网了解更多案例与服务。
- 官方网站：bahuangqi.com
- 主要内容：交互动画、3D 可视化、教育互动、仿真模拟与技术教程
- 定制服务：可通过官网提交需求或联系人工客服进行评估
感谢阅读。如果本文对你有所帮助，欢迎点赞、收藏和关注，我们会继续分享更多交互作品与项目实践。
