你有没有想过一种可能：网页上的文字仍然可以被选中，链接仍然可以被点击，屏幕阅读器仍然能读到内容，但整个页面却被一层实时流体、火焰或玻璃透镜的特效包裹着？
2026年10月，一个叫Canvas UI的开源组件库发布了35个组件，首次把这个想象变成了可以在生产环境使用的技术方案。它的作者是React Bits的创造者David Haz，而它依赖的核心API------HTML-in-Canvas------正在Chrome 148到150的源试用中接受检验。
一、先搞懂一件事：HTML-in-Canvas不是"把HTML画成图片"
在讲Canvas UI之前，必须先理解它背后的底层API。
过去要在Canvas里渲染HTML，开发者只能用html2canvas这样的库。它的原理是把DOM"截图"成一张位图，然后绘制到Canvas上。代价是：文字不可选中、链接不可点击、无障碍树完全丢失。本质上，你得到了一张"看起来像网页的图片"。
HTML-in-Canvas API走的是一条完全不同的路。
它的核心机制是：在Canvas内部布局实时DOM，通过drawElementImage捕获元素内容，将其上传为纹理，再用着色器进行变形处理 。关键区别在于------文本仍然可以选择，链接依旧能够点击，内容也会保留在无障碍树中。
换句话说，DOM还是那个DOM，只是它的渲染结果被"喂"给了GPU管线。你写的HTML、CSS、JavaScript一切照常运行，但GPU可以在它上面叠加任意着色器效果。
这个API目前处于Chrome 148到150的源试用阶段，需要在Chrome中启用canvas-draw-element标志才能体验完整效果。
二、Canvas UI提供了什么？
Canvas UI是基于HTML-in-Canvas API构建的首个开源UI组件库。
它提供了35个组件，包括：
- 指针驱动的流体效果：鼠标划过时，页面内容像液体一样流动变形
- 火焰效果：文字和图片被真实的火焰着色器包裹
- 玻璃透镜：局部区域产生真实的玻璃折射和放大效果
- ASCII滤镜：把DOM内容实时转换为ASCII字符画
- VHS颗粒：模拟老式录像带的噪点和色彩偏移
- 粒子显现：内容以粒子聚合的方式出现
每种效果都提供两个后端实现：使用GLSL的WebGL版本，以及通过vgpu使用WGSL的WebGPU版本。
WebGPU版本利用了现代GPU的计算着色器能力，在支持WebGPU的浏览器上可以获得更低的延迟和更高的帧率。WebGL版本则保证了更广泛的兼容性------目前WebGPU的浏览器覆盖率还在逐步提升，WebGL仍然是更稳妥的选择。
三、怎么用？一行命令，源码直接进你的项目
Canvas UI的分发方式非常特别。
它不以npm包的形式发布，而是通过一个兼容shadcn的注册表，以源码形式分发。
bash
npx shadcn@latest add @canvas-ui/liquid-react这意味着代码会被直接复制到你的项目仓库里。你可以随意修改、定制、优化，不受任何包管理器的约束。
它支持React、Solid、Preact、Vue和Svelte，同时也有无依赖的原生TypeScript版本。
如果你想切换到WebGPU版本，只需要把已安装的文件替换为注册表中带有-webgpu后缀的版本，同时添加vgpu和@webgpu/types依赖即可。
四、一个聪明的降级策略
Canvas UI在兼容性上的处理值得单独提一下。
html-in-canvas特效在不支持该API的环境中会回退为普通GPU叠加层 ，或者保持被包裹内容的原样渲染。而3D对象组件则可以在所有环境中运行，因为它们不依赖HTML-in-Canvas的DOM捕获能力。
这意味着你可以放心地在生产环境中渐进式采用。Chrome用户看到完整的流体和玻璃效果，Safari和Firefox用户看到的是普通但功能完整的页面。没有白屏，没有报错，没有降级到"不可用"。
五、但浏览器垄断的争议也随之而来
Canvas UI的发布也引发了一个值得思考的问题。
HTML-in-Canvas目前只有Chrome（和基于Chromium的Brave）原生支持。Safari和Firefox的立场尚未明确。有开发者在讨论中担忧：如果这种"GPU增强DOM"的能力只有Chrome支持，会不会进一步加剧Web平台的碎片化？
这是一个真实的风险。但换个角度看，HTML-in-Canvas的设计本身是渐进增强的------它在不支持的浏览器上不会破坏任何东西。Chrome先走一步，其他厂商可以观察实际使用情况再决定是否跟进。这比"强制所有浏览器同时实现"的路径要务实得多。
另外值得注意的是，社区已经在开发HTML-in-Canvas polyfill，目标是在Safari、Firefox、iOS等所有浏览器中实现WICG API。虽然polyfill的性能无法和原生实现相比，但它至少保证了"能力可访问性"。
六、实际应用场景
品牌落地页：鼠标划过时，页面内容产生流体变形，视觉冲击力远超传统CSS动画。
产品展示：用玻璃透镜效果局部放大产品细节，用粒子显现效果做产品参数的渐进披露。
创意作品集：ASCII滤镜和VHS颗粒给数字内容增加独特的质感，不需要设计师手绘素材。
数据可视化：在图表上叠加火焰或流体效果，让数据展示不再枯燥。
游戏化界面：粒子显现效果可以用来做"解锁新功能"的视觉反馈，比传统的弹窗动画更有沉浸感。
七、这对前端开发者意味着什么？
第一，Web的视觉天花板正在被GPU重新定义。
过去前端做特效，要么用CSS animation（有限），要么用Canvas 2D重写整个界面（失去DOM的所有能力），要么用WebGL从头写渲染管线（成本极高）。HTML-in-Canvas+Canvas UI提供了一条新的路：保留DOM的语义和可访问性，同时叠加GPU级的视觉效果。
第二，可访问性和视觉创新不再是对立的。
html2canvas方案最大的问题就是"截图即失联"------无障碍树完全丢失。HTML-in-Canvas的设计从一开始就把可访问性作为一等公民。Canvas UI的组件在实现特效时，文本仍然可以被屏幕阅读器读取，键盘焦点仍然可以正常移动。
第三，shadcn注册表模式正在成为新的分发标准。
Canvas UI选择通过shadcn注册表分发源码，而不是发布npm包。这意味着你可以完全拥有这些代码，随意修改，不受上游更新节奏的约束。这种"源码优先"的分发模式，正在被越来越多的前端工具采用。
写在最后
2026年10月，Canvas UI发布了35个基于HTML-in-Canvas API的组件。
它们让GPU特效可以运行在真实的、可交互的、可访问的DOM内容 上------而不是一张截图。文字可以选中，链接可以点击，屏幕阅读器可以读取。同时，流体、火焰、玻璃透镜、ASCII滤镜、VHS颗粒这些过去需要从零写着色器的效果，现在只需要一行npx shadcn add。
HTML-in-Canvas API还在源试用阶段，Chrome独占支持的情况也引发了浏览器碎片化的讨论。但渐进增强的设计和社区polyfill的推进，让这条路至少是"安全可走"的。
Web的视觉天花板，正在被重新定义。
参考链接：