做创意落地页时，前端经常卡在一个尴尬位置：纯 CSS 动效足够稳，却很难做出流体、折射、火焰、故障艺术这类画面；上 Canvas 或 WebGL，又容易把按钮、文字和表单一起“烘焙”成不可交互的像素。
最近开源的 Canvas UI 想把这条断层补起来。它提供一组可复制进项目的 Canvas / WebGL 组件：页面内容仍按普通 HTML 写，特效在其上实时运行。流体、玻璃、粒子、VHS、3D 破碎等效果不再只是视频或截图，而是可以包住现有界面的组件。
它值得关注的点不在“效果多”，而在于它把创意编码收进了熟悉的前端工作流：shadcn 命令把源码放进仓库；React、Vue、Svelte 等框架各有原生版本；效果能力与兼容性边界也没有藏起来。
先说结论：做活动页、作品集、产品首屏或可控范围内的品牌展示，Canvas UI 很值得试；做信息密集型后台、转化关键链路或必须在所有浏览器得到同样视觉效果的页面，应把它当作渐进增强，而不是页面基础设施。
它到底是什么：不是“用 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 是一个跟随指针的流体模拟。它的源码暴露了模拟网格、染料分辨率、耗散、压力迭代、扭曲强度和色彩混合等参数；换句话说，安装后不是只能调几个“皮肤变量”，而是拿到了可继续改造的实现。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、资源体积和设备性能 |
这里有三条不应该省：
- 先做无特效页面。 标题、按钮、输入框、焦点状态和关键图片必须在普通 DOM 下完整成立；特效只能增强，不能承担信息。
- 尊重减少动态效果偏好。 官网称组件会识别
prefers-reduced-motion，但接入后仍要用系统设置和真实设备验证，尤其是自行改过源码的组件。 - 测低端设备和长页面。 官方说明效果在 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 官网与组件演示
- 官方文档
- 安装指南
- GitHub：DavidHDev/canvas-ui
- Liquid 组件源码与参数说明
- 社区介绍：Superpowered Design（非官方资料）