这个开源库有点离谱：让真实 HTML 跑进 WebGL 做流体特效

做创意落地页时，前端经常卡在一个尴尬位置：纯 CSS 动效足够稳，却很难做出流体、折射、火焰、故障艺术这类画面；上 Canvas 或 WebGL，又容易把按钮、文字和表单一起“烘焙”成不可交互的像素。

最近开源的 Canvas UI（ https://canvasui.dev/ ）想把这条断层补起来。它提供一组可复制进项目的 Canvas / WebGL 组件：页面内容仍按普通 HTML 写，特效在其上实时运行。流体、玻璃、粒子、VHS、3D 破碎等效果不再只是视频或截图，而是可以包住现有界面的组件。

它值得关注的点不在“效果多”，而在于它把创意编码收进了熟悉的前端工作流：shadcn 命令把源码放进仓库；React、Vue、Svelte 等框架各有原生版本；效果能力与兼容性边界也没有藏起来。

先说结论：做活动页、作品集、产品首屏或可控范围内的品牌展示，Canvas UI 很值得试；做信息密集型后台、转化关键链路或必须在所有浏览器得到同样视觉效果的页面，应把它当作渐进增强，而不是页面基础设施。

Canvas UI 的两条渲染路径：普通 DOM 始终保底，支持 html-in-canvas 时可将实时 DOM 交给 WebGL 扭曲

它到底是什么：不是“用 Canvas 重写页面”

Canvas UI 是 David Haz（@davidhdev）维护的开源组件库。截至 2026 年 8 月 23 日，官网列出 35 个组件；GitHub 仓库约有 4.2k Star。它的项目定位很明确：在真实、可交互的 HTML 界面上运行流体模拟、着色器和 3D 效果，而不是让你用 Canvas 重新搭一套 UI。官方介绍与仓库 README 都把这一点写在最前面。

这里最容易误解。Canvas UI 不是把整个应用迁到 Canvas，也不是 html2canvas 那种先截图、再处理像素的方案。对于支持 html-in-canvas 的效果，它会让 Canvas 布局并绘制实时 DOM，再把结果作为 WebGL 着色器可采样的纹理；对于不依赖这个实验 API 的组件，它就是常规的 3D / 着色器渲染。官方文档明确说明了这两条路径。

你看到的效果	底层更接近什么	工程含义
Liquid、Glass、VHS、Blaze 等包裹页面内容的效果	html-in-canvas + WebGL，或退化为 WebGL 叠层	DOM 是内容源，完整视觉效果取决于浏览器能力
Particle Object、Glass Object 等对象类效果	Three.js / WebGL 3D 场景	不需要实验性 DOM 绘制能力，现代浏览器路径更一致
非支持浏览器	正常 HTML + 能继续运行的 WebGL 叠层	内容与交互优先保住，效果可能降级

这个设计比“炫技组件库”更实用：当增强能力不存在时，页面不应该只剩一张黑色画布。Canvas UI 的文档承诺在不支持的浏览器中保留普通 HTML，避免抛错；但“保留可用”不等于“保留完全相同的视觉结果”。这正是接入前要先想清楚的边界。

先跑一个最小例子：给首屏加液体效果

Canvas UI 走的是 shadcn registry 分发方式。它不是让你安装一个长期运行的 UI 包，而是把组件源码落到本地目录，之后代码归项目自己维护。

如果项目还没有 components.json，先初始化：

npx shadcn@latest init

然后安装 React 版 Liquid：

npx shadcn@latest add @canvas-ui/liquid-react

官方安装文档说明，组件会被放进 components/canvasui/；Svelte 则是 src/lib/components/canvasui/。把命令末尾的 react 换成 vue、svelte、solid、preact 或 vanilla，即可选择相应框架版本。

在 Next.js / React 页面里，最小使用方式就是包住一段内容：

import { Liquid } from "@/components/canvasui/Liquid";

export default function Hero() {
  return (
    <Liquid
      rainbow
      style={{ height: 480 }}
      distortion={0.35}
      intensity={1.4}
    >
      <section className="hero">
        <p>Creative engineering</p>
        <h1>把鼠标划过来试试</h1>
        <a href="/pricing">查看方案</a>
      </section>
    </Liquid>
  );
}

Liquid 是一个跟随指针的流体模拟。它的源码暴露了模拟网格、染料分辨率、耗散、压力迭代、扭曲强度和色彩混合等参数；换句话说，安装后不是只能调几个“皮肤变量”，而是拿到了可继续改造的实现。

不过在 Next.js 这类带服务端渲染的框架里，要先看组件源码的客户端边界。React 版本带有 "use client"，而且要访问 Canvas / WebGL，因此不要试图把它当作纯服务端组件运行。首屏效果还应给固定或可预测的容器高度，避免客户端初始化后造成布局跳动。

35 个组件，别按名字挑：按页面意图挑

官网列出的组件很容易让人一口气点满。更合理的方式，是先问“我希望用户注意到什么”。

页面意图	可先试的组件	更适合放在哪里	要注意什么
让品牌首屏有即时反馈	Liquid、Ripple、Glass	Hero、产品主视觉	把运动区域限在首屏，别覆盖整站阅读
做游戏、音乐、赛博主题	VHS、Glitch、Glyph Rain	专题页、作品集、互动 demo	文案与表单仍要有清晰的静态对比度
表达“生成”“汇聚”“解构”	Particle Reveal、Particle Scroll、Shatter	发布页的一个核心叙事段落	把动画和滚动节奏一起做真机测试
展示产品素材或模型	Particle Object、Glass Object、Dithered Object	3D 模型、Logo、产品插图	留意模型体积、纹理加载与低端 GPU
只需要一点新鲜感	Magnify、Laser、Decrypt Reveal	单个 CTA、数据卡、标题区域	不要让装饰效果抢走主要操作

这也是 Canvas UI 的正确打开方式：它更像视觉叙事的积木，不是给每个卡片都加一层滤镜。 官网首页还把社区视频与开发者评价集中在一起，足以说明它在创意编码圈的传播度；第三方工具收录站 Superpowered Design 的项目页则用“在交互 HTML 上叠加实时 WebGL 效果”概括它的用途。前者是官方展示，后者只是社区介绍，不应把它当作兼容性或性能承诺。

为什么它能跨框架：一套引擎，六层薄封装

Canvas UI 支持 React、Solid、Preact、Vue、Svelte 和无框架 TypeScript。它并非为每个框架维护一套不同效果：仓库结构中，每个组件以 TypeScript / WebGL 的核心引擎为主，再加不同框架的薄包装层；组件之间也尽量独立。仓库的开发说明给出了对应目录结构。

这带来两个实际好处：

• 团队换框架时，效果的参数语义大体不变；文档也会随你选择的框架切换示例。
• 因为源码复制进项目，设计系统可以直接改默认色、交互阈值、无障碍策略和资源加载，不必等上游开放某个 prop。

但“源码在手”也意味着升级不再自动发生。官方建议重新执行安装命令获取最新组件，或者由团队维护自己的副本。官网 FAQ 说得很诚实：这避免了依赖在背后变化，也把后续合并更新的责任交回项目。

生产前最重要的一页：Chrome 实验能力不是 Web 标准

完整的“把 live DOM 当纹理实时扭曲”依赖 html-in-canvas。官方文档将它标为 Chrome 的实验能力：本地开发需要开启 chrome://flags/#canvas-draw-element；线上若要让普通 Chrome 访客走完整路径，需要为自己的域名申请 Chrome Origin Trial 并以 meta 或 HTTP header 提供 token。官网自己能直接演示，是因为它运行在 Origin Trial token 下。

因此，这不是“装完组件，所有人都能看到同样的玻璃折射”。更准确的支持模型如下：

访问环境	HTML-in-Canvas 类组件	对发布者的要求
Chrome + 本地 flag / 合法 Origin Trial	完整效果	处理 flag 或为自己的域名申请并配置 Trial token
其他浏览器	普通 HTML 保底，部分 WebGL 叠层继续运行	必须接受效果降级，并测试可读性与操作
现代浏览器上的 3D 对象组件	完整 3D 效果	仍需评估 WebGL、资源体积和设备性能

这里有三条不应该省：

1. 先做无特效页面。 标题、按钮、输入框、焦点状态和关键图片必须在普通 DOM 下完整成立；特效只能增强，不能承担信息。
2. 尊重减少动态效果偏好。 官网称组件会识别 prefers-reduced-motion，但接入后仍要用系统设置和真实设备验证，尤其是自行改过源码的组件。
3. 测低端设备和长页面。 官方说明效果在 GPU 上执行、组件挂载时初始化、离屏暂停、卸载清理。它们是好的设计方向，不是你的 LCP、内存和耗电预算已经自动达标；首页全屏动效尤其要用目标机型做性能剖析。

版权和“开源”也要看清

Canvas UI 使用 MIT + Commons Clause。官方的解释是：个人项目和商业项目可以免费使用组件，但不能把组件本身或其移植版单独转售、再分发或打包售卖。

这对绝大多数把它嵌进官网、SaaS 或客户项目的团队通常不是问题；但如果你在做模板市场、组件市场、二次分发 SDK，或要把源代码放进可被客户下载的产品包，就应该让法务按完整许可证核对，而不是只看“MIT”三个字。

上线前的 6 个问题

问题	答案决定什么
不开特效，这个区域是否仍能读懂、点击、完成转化？	决定能否作为渐进增强接入
目标用户有多少使用 Chrome，是否能接受浏览器间视觉差异？	决定是否投入 Origin Trial 与兼容测试
效果是在一个段落，还是覆盖全页？	决定 GPU 预算、滚动与可读性风险
是否有 prefers-reduced-motion、键盘操作和焦点的回归测试？	决定可访问性底线
组件源码进仓后，谁负责升级与安全审查？	决定长期维护成本
这个效果是否在讲产品，而不是替产品抢镜？	决定它是视觉叙事还是噪声

Canvas UI 让前端把“这个效果做起来很麻烦”变成一次可读、可改的组件安装，这很有价值。更好的用法不是把所有页面都变成特效展台，而是在用户需要被吸引、被解释或被引导操作的一个瞬间，让视觉和内容往同一个方向发力。

如果你的项目正在做品牌首屏或互动专题，建议先选一个小范围：用 Liquid 或 Particle Reveal 包住一段真实内容，准备一条没有特效的保底路径，再在 Chrome、Safari、Firefox 和手机上分别检查点击、滚动、减少动态效果与性能。值得测试；是否大面积采用，等真实用户与设备数据给答案。

对 Canvas UI 这类开源项目感兴趣的话，也可以到 云栈社区 找更多前端同好一起交流实际落地经验。