什么是 HTML-in-Canvas？

，里面是文本、按钮、输入框、CSS 样式。你在 canvas 的 paint event 里调用 ctx.drawElementImage(element, x, y)，浏览器就会把这个元素的渲染结果画到 canvas 上。
第三，如果你在 WebGL 里，可以用 texElementImage2D；如果在 WebGPU 里，可以用 copyElementImageToTexture。
这一步才是很多 3D 开发者眼睛一亮的地方。因为 HTML 不只是画到 2D canvas，它还可以成为 texture。texture 意味着它可以贴到 3D 物体上，可以进 shader，可以被 post-processing 处理，可以成为沉浸式场景的一部分。
第四，要同步 transform。
这是最容易被忽略、但最关键的一步。
你看到的 HTML 已经被画到 canvas 里了，但真实 DOM 仍然要知道自己“在屏幕的哪里”。不然用户点击画面上的按钮，浏览器不知道该把这个点击交给哪个真实 DOM 元素；屏幕阅读器、hover、focus、选中文本也会错位。
所以 drawElementImage() 会返回一个 transform。你要把这个 transform 应用到元素的 CSS transform 上。3D 场景里则可以用 getElementTransform() 辅助计算。说白了，视觉位置和真实 DOM 位置必须对齐。
这也是为什么它不是“截一张图塞进 canvas”。截图不会有焦点，不会有输入，不会有可访问性，不会有浏览器查找。HTML-in-Canvas 玩的是活的 DOM。
这和 html2canvas 有什么区别？
很多人会问：这不就是官方版 html2canvas 吗？
不是。
html2canvas 文档自己说得很清楚，它会遍历 DOM，读取元素信息，然后构建一个页面表示。它不是浏览器截图。它能画对多少，取决于它理解多少 CSS、多少布局细节、多少边界情况。
这就像你照着网页临摹一幅画。画得再像，也还是临摹。
HTML-in-Canvas 更接近浏览器自己把那层真实 HTML 渲染结果交给你当素材。它不是第三方库猜浏览器怎么画，而是浏览器平台提供“把 DOM 绘制进 canvas / texture”的能力。
还有一种老办法是 DOM overlay。
比如你在 WebGL canvas 上面盖一个绝对定位的 div，看起来像在 3D 场景里。但它本质上是贴在画面外面的透明贴纸。它可以交互，但它没有真正进入 3D 管线。它不能自然被 shader 处理，不能真实贴在一个旋转的 3D 屏幕上，也很难和复杂后处理融在一起。
DOM overlay 像把字幕贴在电视屏幕外面。
HTML-in-Canvas 是把字幕送进画面信号里。
差别就在这。
它带来的第一个变化：Canvas 应用不用再那么“装瞎”
Canvas 应用有个老问题：用户看得到，浏览器看不懂。
你在 canvas 里画了一个图表，用户看到坐标轴、图例、tooltip、按钮。但对浏览器来说，那可能就是一堆像素。你要想支持无障碍、搜索、复制、翻译、右键、自动填充，就得自己额外维护一套 fallback DOM 或自定义逻辑。
很多团队不是不知道该做，而是成本太高。
结果就是大量 canvas 应用变成“视觉上很强，浏览器能力很弱”。尤其是复杂白板、设计工具、图表工具、游戏 UI、3D 场景，一旦进入 canvas，很多普通网页里默认免费的能力突然都变成工程债。
HTML-in-Canvas 的价值，是让真实 DOM 可以继续存在于浏览器语义系统里，同时又能被画进 canvas。
这对大型 canvas-based 应用很重要。比如官方提到 Google Docs、Miro、Figma 这类重量级 Web 应用。它们不一定会马上把所有 UI 改掉，但某些复杂组件、嵌入式面板、文本区域、可访问内容，未来有机会少写很多自研逻辑。
你以为这只是省几行代码。
不，这是把“可访问性”和“浏览器能力”从补丁变回地基。
第二个变化：3D 和 WebXR 终于能吃上真实 Web UI
做过 WebGL / Three.js / WebXR 的人都知道，3D 里的 UI 很折磨。
你想在 3D 场景里的一个电脑屏幕上放一个网页界面。简单做法是贴一张图片，不能交互。高级一点，用 canvas texture，自己画内容。再高级，用 DOM overlay，让一个 HTML 面板跟着 3D 位置走。但它经常有遮挡、透视、事件、深度关系和真实嵌入感的问题。
所以很多 3D UI 最后都变成手搓。
按钮自己画，输入框自己写，布局自己算，hover 自己做，focus 自己接，事件自己 raycast。写着写着，你不是在做产品，你是在复刻浏览器。
HTML-in-Canvas 的想象空间就在这里：你可以用 HTML / CSS 写 UI，再把它作为 texture 放进 3D 场景。
Three.js r184 已经加了 HTMLTexture。PlayCanvas 也有 HTML-in-Canvas 文档，讲如何把 live HTML / CSS 渲染成 WebGL texture，并保留 hit testing、focus 和 accessibility。
这说明生态已经开始接线了。
对游戏、WebXR、沉浸式官网、3D 产品展示来说，这不是小改动。以前你要在“网页 UI 的成熟能力”和“3D 世界的真实嵌入感”之间选一个。现在至少有机会两个都要。
当然，别激动过头。
3D transform、hit testing、texture 更新、fallback、浏览器兼容，还是工程活。HTML-in-Canvas 不是仙丹，它只是把最底层那堵墙打开了一扇门。
门开了，不等于路铺好了。
第三个变化：AI Agent 更容易读懂“视觉应用”
这个点很多人会忽略，但我觉得很关键。
Google 在 I/O 2026 的语境里，不只是讲 Web UI，还在讲 agentic web。HTML-in-Canvas 官方介绍里也提到，内容如果仍然是 DOM，爬虫和 AI agent 可以更容易索引和读取 2D / 3D 场景里的文本。
这句话背后其实很重。
AI agent 要操作网页，最怕什么？怕界面只有像素，没有语义。
如果一个按钮只是 canvas 上的一块蓝色矩形，agent 要理解它，只能靠视觉识别、坐标推断、截图 OCR。能做，但脆。像让人隔着毛玻璃修电路。
如果那个按钮背后仍是 DOM，里面有真实文本、真实 role、真实 input、真实 form、真实可访问性信息，那 agent 操作它就稳定得多。
这也是为什么我说 HTML-in-Canvas 不是单纯视觉特性。它和 AI 原生 Web 是有关系的。未来的 UI 可能既要被人看，也要被 agent 读；既要能进 GPU 管线，也要保留语义；既要炫，也要能被浏览器工具理解。
很多人以为 AI 时代的 UI 会变成一堆生成出来的炫酷画面。
但真相是，AI 时代更需要结构化 UI。
没有结构，agent 就只能猜。猜得越多，系统越不可靠。
第四个变化：前端分工会重新洗牌
过去前端经常有一种隐形分工：
做业务页面的人在 DOM / CSS / React 里打转。
做创意视觉、游戏、3D、白板、设计工具的人在 Canvas / WebGL / WebGPU 里打转。
两边互相看不上也互相羡慕。DOM 这边觉得 canvas 那边炫但不好维护；canvas 那边觉得 DOM 这边啰嗦但能力成熟。
HTML-in-Canvas 会让这个分界变薄。
未来一个前端工程师可能不能只懂“组件怎么写”，也不能只懂“shader 怎么跑”。更值钱的是你能不能理解 UI 的三层：
语义层：这个界面对用户、浏览器、辅助技术、agent 来说是什么。
交互层：用户如何点击、输入、选中、复制、聚焦。
图形层：它如何被绘制、变形、合成、进入 2D / 3D / GPU 管线。
以前这三层经常绑在一起。DOM 页面三层都交给浏览器。Canvas 应用三层很多要自己写。
HTML-in-Canvas 的意义，是让这三层有机会重新组合。
这才是真正的变化。
但现在别把它吹成生产神技
这里要泼一盆冷水。
HTML-in-Canvas 现在还很早。
Chrome 官方写得很清楚，Chrome 148 到 150 是 origin trial。要本地测试，需要 Chrome Canary 149+，还要打开 chrome://flags/#canvas-draw-element。WICG explainer 也还在持续更新。TAG、Mozilla、WebKit 的相关讨论还没完全收束。
所以别看几个 demo 很炸，就开始喊“前端未来已来，马上重构所有项目”。
这事儿没那么简单。
第一，浏览器兼容是现实问题。你不能指望所有用户立刻支持。
第二，性能不是白送的。HTML-in-Canvas 通过 JS 驱动绘制，滚动、动画、频繁 texture 更新都要评估。把一大坨复杂 DOM 塞进 canvas，不会自动变快。
第三，安全和隐私有限制。跨源 iframe、跨源资源、用户敏感状态，不可能让你随便画进 canvas 再读像素。
第四，工程复杂度还在。特别是 3D 场景里的 transform 同步，想做得稳定，需要框架和引擎继续封装。
所以正确姿势是什么？
如果你是普通业务前端，现在不用焦虑，也不用为了跟风硬学。
如果你做 3D、游戏、WebXR、数据可视化、白板、设计工具、富文档编辑器，建议第一时间跟踪。不是马上上生产，而是做 demo、测边界、看生态封装。
如果你在做 AI 生成 UI 或 agent 可操作界面，那更要关注。因为这类技术会影响未来“界面如何既给人看，也给机器读”。
我真正看重的是什么
我看重的不是 API 名字。
前端这几年不缺新 API。很多 API 出来，热闹两天，然后消失在兼容性、复杂度和真实需求里。
HTML-in-Canvas 真正值得看的，是它背后的方向：浏览器正在承认，Web App 已经不是传统文档页面了。
现在的 Web 上有设计工具、视频编辑器、3D 展厅、AI coding IDE、白板、游戏、数据大屏、沉浸式课程、agent 操作界面。它们既需要 DOM 的语义和浏览器能力，也需要 GPU 的图形能力。
过去我们总在两边来回横跳。
要么在 DOM 里装作自己是原生应用。
要么在 canvas 里装作自己是浏览器。
HTML-in-Canvas 的出现，说明平台层开始补这块拼图。
这才是变革。
不是“Canvas 可以写 HTML 了”。
而是 Web UI 终于开始从二维页面，走向一个更混合的渲染模型：语义是语义，交互是交互，图形是图形，它们可以被组合，而不是被迫绑定在一套技术里。
最后说句实话
很多技术热点都喜欢用一句话把人骗进去：
“这会改变前端。”
大多数时候，这句话是空的。因为真正改变前端的，不是某个 API 多酷，而是它有没有改变开发者做选择的方式。
HTML-in-Canvas 这次有这个苗头。
以前你的选择是：要 DOM，还是要 Canvas？
以后可能变成：哪一层用 DOM，哪一层进 Canvas，哪一层交给 GPU，哪一层保留给浏览器和 AI agent？
这就是从“选阵营”变成“做架构”。
对普通人来说，这不是明天就能变现的新技能。
但对前端开发者来说，这是一个非常好的信号：浏览器平台还在进化，而且进化方向不是让你背更多黑话，而是把过去那些别扭的边界慢慢拆掉。
说白了，HTML-in-Canvas 不是终点。
它只是告诉你：Web UI 的墙，已经开始松了。
墙一松，新的东西就会长出来。