先说结论：这个标题描述的现象是真实存在的，但它并不是什么“新黑科技”，反而是一种非常古老思路的现代翻版。它的核心逻辑其实特别朴素：拿代码当画笔，让浏览器当画布，一帧一帧把画面“画”出来，而不是像视频生成模型那样直接吐出一段MP4文件。
我最初看到这类说法时，也以为是什么新出的视频生成框架又玩出了花，结果扒开一看，好家伙，底层全是Canvas、requestAnimationFrame、甚至是SVG动画的老三样。但有意思的是，这套“老技术”在特定场景下（比如实时数据可视化、交互式广告、动态海报）反而比真视频更实用、更轻量、更可控。
这篇文章，我就从这几个角度把这件事拆开揉碎讲清楚：它到底是怎么实现的、为什么有人要这么干、以及你自己上手时最容易踩的坑。
1. 内容整体设计与思路拆解
1.1 先搞清楚“不生成视频”到底是什么意思
大多数人对“生成视频”的认知，是输入一句提示词，然后模型吐出一段.mp4或者.webm文件。这个过程，本质是模型在内部通过扩散或自回归的方式，预测出一堆像素帧，再编码成视频流。这是一种数据生成的思路。
但“Opus 5.5”这类项目走的是另一条路：它不直接产生视频文件，而是生成一段可执行的代码。你把这代码丢给浏览器，浏览器里的JavaScript引擎会按照代码里的逻辑，在每一帧刷新时重新计算并绘制画面。换句话说，视频的“内容”不是预先决定的，而是实时计算出来的。
这两者最根本的区别在于：
- 真视频：信息是静态的、预先存储的。你看到的就是录下来的，改了也没用。
- 代码绘制：信息是动态的、程序化的。画面的每一个像素都可以是数学函数、物理模拟、随机噪声的结果。同一个代码，每次运行可能画面都不同，甚至可以响应鼠标交互。
所以说“它不生成视频”这个描述，技术上算准确，但容易让人误会。它其实是在用一种更底层、更繁琐、但也更灵活的方式“制造”视频效果。
1.2 为什么有人会选择“用代码画视频”而不是直接生成视频
这个问题，凡是自己动手试过的人，应该都有切身体会。
第一个原因是可控性。视频生成模型现在的确很强，但它的输出是个“黑盒”。你告诉它“画一只猫在桌上走”，它给你产出一段很惊艳的镜头，但你想让那只猫在第三秒的时候停下来回头看一眼，对不起，做不到。你得重新生成，或者后期剪辑。而代码绘制不同，你写了一段moveCat(3, 'turnHead')，它就一定在第三秒回头，精确到帧，绝不妥协。
第二个原因是交互性。真视频是单向的，你只能看。但代码画的视频，可以是一个“活”的东西。比如一个动态海报，用户鼠标滑过的时候，云彩飘动方向改变；或者一个数据大屏，图表随实时数据跳动。这些本质都是“视频”，但它们是活的，是响应的。
第三个原因是体积和性能。一个10秒的4K视频，哪怕压缩得很狠，也要几兆到几十兆。但一段能画出这个画面的代码，可能只有几KB到几十KB。对于做网页、做H5小广告、做线上邀请函的人来说，这差别非常大。加载一个几十KB的脚本和加载一个几十MB的视频，用户体感完全不同。
第四个原因，说出来有点扎心，但很真实：有些画面效果，压根不是拍拍出来的，而是算出来的。比如粒子汇聚成文字、流体扰动、音乐可视化波形，这些你用摄像机拍不出来，用生成模型也经常翻车，但用代码写，精准又高效。
1.3 核心思路的本质：程序化动画与逐帧渲染
如果你打算自己动手做类似的事，心里要清楚，你面对的核心不是“视频技术”，而是**“图形学基础”和“动画调度”**这两件事。
图形学基础解决的是“画面怎么画”。你说到底是用Canvas的2D API去画形状、填颜色，还是用WebGL去操作GPU搞粒子系统，或者干脆用SVG的路径变化模拟动画，这决定了你的画面风格和性能上限。
动画调度解决的是“画面怎么动”。你可以简单粗暴地用setTimeout每隔16毫秒画一帧，也可以用requestAnimationFrame让浏览器帮你安排好绘制时机，还可以用CSS动画配合onanimationiteration事件去实现特定节奏的画面切换。选哪个，取决于你想要的帧率稳定性、CPU占用率，以及代码的复杂程度。
我当时自己做的一个数据可视化的动态图表项目，就属于这类思路。一个实时刷新的折线图，数据每秒来一条新记录，画面要像心电图一样平滑滚动。用真视频方案，我得预先渲染，完全没法用；后来改成Canvas每帧重绘，代码量几十行，效果反而很灵动。
2. 核心细节解析与实操要点
2.1 常用的实现方式与选型对比
如果你也想做点“用代码画视频”的东西，先看看自己适合哪条路。下面我列一下主流的玩法，都是我自己实际会比较过的。
| 实现方式 | 核心原理 | 适用场景 | 上手难度 | 性能上限 |
|---|---|---|---|---|
| Canvas 2D | 用路径、图形、像素操作逐帧绘制 | 图表、海报、简单的动画元素 | 低 | 中等 |
| WebGL | 调用GPU做大规模并行计算的渲染 | 粒子系统、3D场景、大量物体运动 | 高 | 非常高 |
| SVG + CSS动画 | 通过改变矢量图形的形状、位置、透明度形成动画 | 图标动画、界面过渡、矢量风格视觉 | 低 | 低（复杂时性能下降快） |
| CSS 逐帧动画 | 利用steps()实现类似GIF的逐帧切换 | 像素风格、序列帧动画 | 极低 | 低 |
| WebCodecs API | 直接编码视频帧，属于浏览器底层能力 | 视频合成、实时流处理 | 极高 | 高 |
对于大多数人来说，Canvas 2D + requestAnimationFrame是最友好的起点。它没有复杂的数学门槛，也适合描述“如何从零画出一个动态画面”的过程。
2.2 Canvas 2D动态绘制的核心概念
Canvas 2D说白了就是给你一张画布，然后让你用JavaScript画。每画一帧，你需要做三步：
- 清空上一帧：用
ctx.clearRect()把画布擦干净。 - 计算本帧状态：根据当前时间、用户操作、数据变化，算出每个元素的坐标、大小、颜色。
- 画出来：用
fillRect()、arc()、drawImage()这些API把元素画到画布上。
听起来简单，但细节里全是经验。
第一个坑是坐标计算。动画里最常用到的就是三角函数，比如物体绕圈，就必须用cos和sin去算x和y。很多人写不出好看动画，不是因为不会API，而是不知道怎么把数学式子用上去。
第二个坑是坐标系参照。Canvas默认原点是左上角，x往右y往下。但很多视觉设计习惯用中心点。所以画之前我一般会先做一次坐标系变换，ctx.translate(width/2, height/2)，把原点移到画布中心，再进行绘制。这一步看似无关紧要，但对后期调试帮助巨大。
第三个坑是性能。每一帧都重新画全部元素，是很浪费的。我已经习惯的做法是：背景这种不怎么变化的，单独画在一层离屏Canvas上，然后每一帧只用ctx.drawImage()把那层canvas贴上去，再画动态元素。这一招能省掉不少绘图开销。
2.3 requestAnimationFrame与帧率控制
帧率控制是所有动画的命根子。你以为是60fps跑满，实际上浏览器在标签页切到后台时，会直接把这个函数停掉以节省资源。所以如果你负责的是大屏展示或线上活动页面，一定要自己设计一个“暂停恢复”的逻辑，否则用户切个标签页回来，画面就乱了。
控制帧率的另一个技巧是时间差插值。别直接在每一帧里把物体位移固定成5像素，那在帧率波动时画面会一卡一卡。正确做法是记录时间戳，算出上一帧和这一帧之间的时间差，然后把位移乘以它。这样无论帧率是30还是60，物体移动的速度是一致的。
我自己写动画时，很少直接使用setInterval(16.7)去卡帧率，因为浏览器的实际刷新周期没那么精确。requestAnimationFrame是最贴合显示器的方案，代码基本长这个样子：
let lastTime = 0; function animate(time) { const delta = (time - lastTime) / 1000; lastTime = time; // 核心绘制逻辑 drawFrame(delta); requestAnimationFrame(animate); } requestAnimationFrame(animate);delta就是这帧距离上一帧过了多少秒。所有运动速度都用“每秒多少像素”去定义，然后乘以delta，就是你这一帧该移动的距离。这是我见过最简单的防卡顿套路，新手上路建议直接抄。
2.4 数据的表示与动画的揉合
很多代码动画，光有画面是不够的，得和数据结合。比如让一排柱状图随着音乐节奏跳动，或者让热力图的颜色浓度跟着数值变化。
这类场景的通用思路是：先用一套逻辑把数据整理成“标准化”的中间量，再把这个中间量映射到画面的坐标、颜色、透明度上。
举个例子，你要画一个随温度变化的太阳。温度最高是35℃，最低是10℃，你可以先把温度归一化成0到1的数值（(当前温度-10)/(35-10)），然后把这个0到1之间的数映射成颜色。0对应蓝色，1对应红色，中间渐变。Canvas里可以用HSL颜色模型，ctx.fillStyle =hsl(${230 - 230 * t}, 80%, 60%)``，这样颜色过渡就特别自然。
这背后依赖的，其实就是数学里的线性插值。如果数值不是线性变化的，也可以用smoothstep或者缓动函数。理解了“数据–中间量–视觉映射”这三层架构，你会突然感觉自己能做的东西多了很多。
3. 实操过程与核心环节实现
3.1 一个最小可用的例子：飘动的粒子背景
说了这么多理论，上点真东西。我给你一个最经典的入门Demo：粒子在画布里飘动，相互靠近时自动连线，像星云又像蛛网。这个效果可以用来做网页背景、直播间氛围，甚至动态海报。
先看核心代码结构：
const canvas = document.getElementById('starfield'); const ctx = canvas.getContext('2d'); const particles = []; const COUNT = 80; // 初始化粒子位置 for (let i = 0; i < COUNT; i++) { particles.push({ x: Math.random() * canvas.width, y: Math.random() * canvas.height, vx: (Math.random() - 0.5) * 0.5, vy: (Math.random() - 0.5) * 0.5, r: Math.random() * 2 + 1 }); } function draw() { ctx.clearRect(0, 0, canvas.width, canvas.height); // 更新坐标 for (let p of particles) { p.x += p.vx; p.y += p.vy; // 碰到边缘反弹 if (p.x < 0 || p.x > canvas.width) p.vx *= -1; if (p.y < 0 || p.y > canvas.height) p.vy *= -1; } // 画粒子 for (let p of particles) { ctx.beginPath(); ctx.arc(p.x, p.y, p.r, 0, Math.PI * 2); ctx.fillStyle = 'rgba(255,255,255,0.8)'; ctx.fill(); } // 连线 for (let i = 0; i < particles.length; i++) { for (let j = i + 1; j < particles.length; j++) { const dx = particles[i].x - particles[j].x; const dy = particles[i].y - particles[j].y; const dist = Math.sqrt(dx * dx + dy * dy); if (dist < 120) { ctx.strokeStyle = `rgba(255,255,255,${1 - dist / 120})`; ctx.lineWidth = 0.6; ctx.beginPath(); ctx.moveTo(particles[i].x, particles[i].y); ctx.lineTo(particles[j].x, particles[j].y); ctx.stroke(); } } } requestAnimationFrame(draw); } draw();这个Demo跑起来之后，你就得到了一个持续变化的动态背景。它没有视频文件，也没有任何外部资源，完全是代码实时算出来的。
3.2 参数调整经验与调试技巧
初期你可能会遇到几个问题，我都踩过：
- 粒子不动：检查
vx和vy的值，可能是被设成了0，或者更新坐标的代码没执行。 - 线太密或太稀：调
dist判断值，120是比较中庸的。数值越大线越多，场面越满。 - 画面卡顿：把数组里粒子数量降下来，或者把计算线段的双重循环优化一下。80个粒子的双重循环是可控的，但如果你加到500个，计算量就变成500*500/2次循环，肉眼可见地掉帧。
- 背景不是想要的颜色：在
fillStyle上调整alpha通道，或者把clearRect换成填充全屏矩形。
调这些参数，我建议直接用Chrome开发者工具的Performance面板，能看到具体哪一行代码耗时最多，比盲猜效率高太多了。
3.3 进阶：如何把“代码动画”导出成真视频
有一些场景下，的确需要把这段动画录下来，当作视频素材去用。这不是不行，只是要绕一个小弯路。
我的办法是用canvas.captureStream(60)拿到画布的媒体流，再用MediaRecorder去录制。代码很简单：
const stream = canvas.captureStream(60); const recorder = new MediaRecorder(stream, { mimeType: 'video/webm' }); recorder.start(); // 设定录制时长 setTimeout(() => { recorder.stop(); }, 10000); recorder.ondataavailable = (e) => { const blob = new Blob([e.data], { type: 'video/webm' }); const url = URL.createObjectURL(blob); const a = document.createElement('a'); a.href = url; a.download = 'output.webm'; a.click(); };这样就把“代码画的视频”落成了真视频文件。输出的是.webm格式，用Chrome、Edge都能直接打开，如果需要.mp4，可以再转一下封装格式。录制期间别切Tab页，否则浏览器为了省电会降低帧率，录出来的素材会一顿一顿的。
3.4 事后复盘：这套方案的性能边界与适用边界
使用这套方案时，你需要清醒知道它“哪里好使，哪里不好使”。
它特别适合的是：
- 背景氛围动画（靠纯数学模拟视觉效果）
- 数据可视化大屏
- H5动画场景、动态海报
- 教育类演示（用代码控制精确演示步骤）
它不适合的是：
- 需要真实世界纹理和光影的复杂3D场景
- 需要拟真人物或物理细节的画面
- 需要低端手机也能流畅跑的高负载动画
我调试时踩过最狠的一个坑，是做了个全屏粒子流体模拟，在桌面Chrome上跑得很开心，结果换到一台几年前的Android手机上，帧率直接跌到个位数。后来才发现，问题出在密集的像素级getImageData操作上，手机GPU撑不住。最后只能改成WebGL的GPU方案才解决。所以如果你判断自己的动画会跑在移动端，一开始就考虑性能预算，别先写完再优化。
4. 常见问题与排查技巧实录
4.1 为什么画面会闪烁
这是新手最常遇到的。究其原因，大多是绘制逻辑里每一帧都清空了画布，但新内容又没有完整画完，导致某些区域出现短暂空白。解决办法是：
- 把清屏和绘制放在同一个函数里，保证清完立刻重绘。
- 如果使用离屏Canvas缓存静态背景，注意赋值顺序是否有误。
requestAnimationFrame的回调函数里不要写耗时的同步逻辑，比如大量console.log会拖慢绘制。
4.2 为什么动画不随帧率变化而变
你可能会遇到，代码在不同电脑上跑出来的速度不同。原因在于直接使用了frameCount累加来控制运动，而不是时间差。不同设备的刷新率不同，比如普通屏幕60Hz，高刷屏120Hz，在120Hz屏幕上，画面每秒跳动的次数更多，速度就快了。
解决方式就是我前面提到的：delta时间差统一调度。为了减少读者浪费时间，我再贴一次核心代码段：
let lastTime = performance.now(); function animate(now) { const delta = (now - lastTime) / 1000; lastTime = now; // 注意：delta单位是秒 updatePosition(delta); draw(); requestAnimationFrame(animate); }4.3 常见问题速查表
| 问题现象 | 可能原因 | 排查步骤 |
|---|---|---|
| 画布一片空白 | Canvas坐标超出范围 / 忘记调用绘制函数 | 检查初始化坐标是否在宽高范围内；在绘制函数开头打日志 |
| 文字和图形模糊 | Canvas未适配设备像素比 | 设置canvas.width = clientWidth * devicePixelRatio并缩放上下文 |
| 动画CPU占用过高 | 每帧执行路径计算过重 / 粒子数量过大 | 用Performance面板定位耗时函数；减少粒子数量或拆离线Canvas |
| 鼠标交互无反应 | 事件绑定的元素不对 | 确认监听器挂在canvas上而非document；用canvas.getBoundingClientRect()换算坐标 |
| 切换标签页后动画卡顿 | 浏览器自动暂停requestAnimationFrame | 用visibilitychange事件检测页面可见性，回来时重置时间基准 |
这几张表，基本覆盖了我日常开发中遇到的大部分问题。你可以直接当成工具书查阅。
5. 最后想说的话
这套“代码画视频”的方案，说到底不是什么银弹，但它给了我一个很重要的启发：当工具越来越智能时，我们反而容易忘记底层能力的重要性。一个懂Canvas、懂数学映射、懂动画调度的人，做出来的动态效果，仍然比单纯依赖生成模型的人要灵活得多。至少当需求变成“第三秒的时候猫回头”时，你不会只能摇头说重新生成十几次试试。
我个人现在遇到交互性强的动效需求，第一反应依然是拿起代码，而不是去找现成视频素材。这个习惯让我避免了很多卡在“找不到合适素材”的窘境。反而是这类看似原始的逐帧绘制技术，考验的是你对图形学的耐心和理解力，它会要求你把“感觉”翻译成“参数”，把“效果”转化为“逻辑”。这个过程本身，就是很值回票价的。
