css houdini 是一组运行时注入浏览器渲染管线的 javascript api，必须在客户端执行，依赖原生引擎支持，无法通过构建工具转译或服务端预编译。
CSS Houdini 不是能被构建工具处理的“语法”或“特性”，它是一组运行时注入浏览器渲染管线的 JavaScript API。 构建工具（如 Webpack、Vite、PostCSS）在打包阶段就结束了，而 Houdini 的核心能力——比如 CSS.registerProperty()、registerPaint()、registerLayout()——必须在浏览器环境里执行，且依赖底层渲染引擎的原生支持。你没法在构建时“转译出一个 Paint Worklet”，就像你没法用 Babel 把 WebGLRenderingContext 编译成 IE8 兼容代码一样。
为什么 @property 不能靠 PostCSS 或 Babel 补全
PostCSS 可以识别 @property 规则并删掉它，但删掉不等于 polyfill。真正的问题在于：
-
@property告诉浏览器：“这个自定义属性有类型、能插值、可动画”，而旧浏览器压根没有接收和理解这条指令的代码路径 - 即使你用 css-vars-ponyfill 把
var(--gap)替换成12px，它仍然无法让transition: --gap生效——因为旧引擎根本不认识--gap是个可过渡的量 - Babel 对 CSS 零作用；PostCSS 插件（如
postcss-custom-properties）只做静态替换，不提供运行时注册、类型校验、插值调度这些引擎级行为
Paint API 为什么 build-time 无解
registerPaint('wave-border', ...) 是一个典型的 Worklet 注册调用，它必须满足三个 runtime 条件：
- 脚本必须通过
addModule()加载到专用的 Paint Worklet 线程（不是普通 JS 线程） - 浏览器需启用
paint-worklet功能（Chrome/Edge ≥ 85，Firefox/Safari 仍不支持） - CSS 中的
paint(wave-border)要在样式计算阶段被识别，并触发 Worklet 线程绘制回调
构建工具连 Worklet 线程都碰不到，更别说把 Canvas 绘图逻辑“编译”进 CSS 文件里了。你看到的任何“build-time Paint 模拟”，本质都是降级为 SVG 或 background-image，跟 Houdini 无关。
Layout API 和 Typed OM 为什么 SSR 场景下必然失败
服务端渲染（SSR）环境里没有 DOM，也没有 CSSOM，更没有 layout/paint 渲染上下文：
-
CSS.layoutWorklet.addModule()会直接报ReferenceError: CSS is not defined -
CSS.supports('layout-api')在 Node.js 里永远返回false - Typed OM 的
CSSStyleValue.parse()依赖浏览器 CSS 解析器，Node.js 中无对应实现
这意味着：所有 Houdini API 都只能在客户端初始化，且首次渲染必有延迟。你没法把它“提前提取”或“预编译”进 HTML —— 它本身就是运行时契约。
真正容易被忽略的一点是：Houdini 的每个 API 都绑定在特定渲染阶段（解析 / 布局 / 绘制 / 动画），而这些阶段之间有强耦合和内存隔离。试图用构建工具“模拟”其中一环，等于在发动机没启动时去调试排气管温度——位置对不上，时机也错不了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
