paint api 无法 polyfill，因其运行在渲染管线底层 worklet 线程，不暴露 dom、不支持主线程干预，且依赖 blink 内核原生支持；firefox 和 safari 不识别 background: paint()，直接丢弃该声明而不报错或降级。
没有真正可行的 paint() Polyfill 方案，它在非 Chromium 浏览器中无法被模拟或降级实现。
为什么 paint() 不能 Polyfill？
根本原因在于 Paint API 运行在浏览器渲染管线底层（worklet 线程），不暴露 DOM、不支持 JS 主线程干预，且整个机制依赖 Blink 内核对 CSS.paintWorklet 的原生支持。Firefox 和 Safari 当前（2026 年中）仍未实现该 API，background: paint(myPainter) 在它们中会被当作无效值直接丢弃，不报错、不触发 fallback、也不执行任何 JS 回调。
所有试图用 JS 模拟绘制行为的方案（如监听尺寸变化 + 动态插入 canvas/svg）都违背了 Paint API 的设计前提：它不是“画完再贴上去”，而是参与浏览器原生绘制流程。这类模拟本质是重写整套渲染逻辑，性能、事件响应、缩放一致性全不可控。
@supports (paint-api: true) 不起作用
浏览器根本不识别这个语法。CSS 解析器遇到未知特性检测时，整条 @supports 块会被跳过，就像它不存在一样。你不能靠它来条件加载 JS 替代方案。
- 正确检测方式只有运行时判断：
if ('paintWorklet' in CSS)—— 但 Safari/Firefox 即使返回false，你也无法据此注入等效图形，因为缺失的是底层能力，不是接口暴露问题 - 更现实的做法是 UA 检测 + 构建时分离样式：对非 Chromium 用户，直接编译掉含
paint()的 CSS 规则，并启用备用背景（如 SVG 或 PNG）
实际能做的只有渐进增强和结构兜底
必须接受 paint() 是纯增强项，不是功能必需项。它的降级不是“换一种方式画”，而是“不画，用静态替代”。
- 用
@supports background: paint()包裹规则 —— 注意：这个检测在 Safari/Firefox 中虽不报错，但因不支持该函数，整个块被忽略，天然实现兜底 - 在同选择器下写前置声明：
.bg { background: #f0f0f0; background: paint(wave); }—— 非 Chromium 浏览器会采用第一个有效声明 - 如果需要动态参数（如颜色、幅度），只能通过 JS 同步更新两套逻辑：主页面改
--wave-color的同时，也手动更新备用元素的style.background
最容易被忽略的一点：Paint Worklet 的模块加载失败（比如路径错、MIME 类型不对、file:// 协议）和浏览器不支持，在表现上完全一致——都是背景空白。调试时别花时间查 JS 错误，先确认 'paintWorklet' in CSS 和网络请求是否成功返回 application/javascript。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
