Tailwind CSS v4的Oxide引擎是Rust重写的全新底层，非v3升级；@tailwind指令因引擎彻底移除PostCSS链而静默失效，仅支持@import "tailwindcss"；增量构建达192µs依赖变更感知快照机制，不依赖构建工具。
Tailwind CSS v4 的 Oxide 引擎不是 v3 的“升级版”，而是用 Rust 重写的全新底层——它不兼容 v3 的构建链路，也不接受旧写法，强行混用只会导致样式静默丢失。
为什么 @tailwind 指令在 v4 中完全失效
v3 依赖 PostCSS 插件逐条解析 @tailwind base、@tailwind components 等指令，靠 JS AST 遍历+字符串拼接生成 CSS；v4 的 Oxide 引擎根本没实现这套逻辑，它只识别 @import "tailwindcss" 这一条原生语句，并将其当作模块加载指令直接交由 Lightning CSS 处理。
常见错误现象：
-
@tailwind写法不会报错，但base层样式（如*, ::before, ::after重置）彻底不生效 - CI 构建成功，生产环境首页白屏或排版崩坏，排查时发现
preflight样式缺失 - 仍保留
postcss.config.js中的tailwindcss()插件，会与 v4 的 Vite 插件冲突，导致重复处理或静默跳过
增量构建为何能压进微秒级：Oxide 的变更感知快照机制
v3 的 JIT 引擎每次保存都要重新扫描所有 content 路径、正则提取类名、哈希查重，哪怕只改一个空格也得重跑整套流程；Oxide 则在首次构建后固化每个源文件的 AST 和类名引用关系到内存索引中，后续仅比对 mtime 和内容 hash。
立即学习“前端免费学习笔记（深入）”；
实测关键点：
- 无新增类名的保存：v3 耗时 35ms → v4 仅 192µs（注意单位是微秒）
- 新增一个
text-lg：v3 需 44ms → v4 只需 5ms - 这个速度不依赖你用没用 Vite，是 Oxide 自身内存模型决定的，Webpack 用户也能直接受益
v4 的自动内容检测如何绕过 content 字段
v3 必须手动维护 content: ["./src/**/*.{js,jsx,ts,tsx,vue}"]，漏配路径就丢样式；v4 的 Vite 插件启动时直接劫持 ESM 模块图，从 import './style.css' 开始，顺着 import 链自动追踪所有可能含类名的文件。
它能识别：
-
.vue文件的<template>块和<script setup>中的字符串字面量 -
.mdx里的 JSX 标签（如<div className="bg-blue-500">） - Astro 组件中的
frontmatter和<style>标签内联类名
如果你还在 tailwind.config.js 里留着 content 字段，它会被完全忽略——删掉更干净。
Oxide 引擎对浏览器兼容性的实际影响
v4 默认输出原生 CSS 特性（比如 :has()、嵌套语法、OKLCH 颜色函数），不再通过 PostCSS 插件做降级转换。这意味着：
- 开发时样式更接近最终效果，调试成本降低
- 目标浏览器必须支持 CSS Nesting、
:has()等特性（Chrome 119+、Firefox 120+、Safari 17.4+） - 若需兼容旧版 Safari（
Oxide 不提供 polyfill，也不模拟老语法——它假设你已站在现代 CSS 的地基上开工。
