turbopack 不会重复解析未改动的 css 模块，因其将解析、@import 展开等操作标记为可缓存函数，文件 mtime 和内容 hash 不变时直接复用 ast；tailwind v4 的 oxide 引擎同步固化类名引用快照，二者原生协同实现函数级增量复用。
因为 Turbopack 的增量计算模型和 Tailwind CSS v4 的 Oxide 引擎在底层完全对齐：两者都基于 Rust、都支持函数级缓存、都按需处理变更，不是“叠加优化”，而是原生协同。
为什么 Turbopack 不会重复解析未改动的 CSS 模块
Turbopack 把每个 CSS 文件的解析、@import 解析、嵌套展开、前缀补全等操作都标记为可缓存函数。比如 parseCss("globals.css") 返回 AST 后，就固化进内存缓存；只要文件 mtime 和内容 hash 不变，后续所有构建都直接复用。Tailwind v4 的 Oxide 引擎本身也做同样的事——它把每个源文件的类名引用关系建模为快照索引，不重新 AST 遍历。
- Webpack/Vite 在每次 HMR 时仍要重跑 PostCSS 插件链，哪怕只改了一行 JS
- Turbopack + Oxide 组合下，改
Button.tsx只触发 JS 层重编译，globals.css的解析结果直接复用 - 若你误配了
content路径（如漏掉.tsx），Turbopack 仍会缓存一个“空类名集”的错误结果，导致样式静默丢失——缓存越快，错得越隐蔽
@import 'tailwindcss' 在 Turbopack 中如何避免路径解析失败
Turbopack 严格遵循 Node.js 的 exports 字段规范，而旧版 Webpack 是宽松 fallback 模式。当你写 @import 'tw-animate-css'，Turbopack 会查找该包 package.json 中 "exports": { ".": { "style": "./dist/tw-animate.css" } }，而不是退回到 main 或 style 字段。
- 常见错误：
tw-animate-css包没声明exports.style，或声明了但路径指向不存在的文件 → 直接报Module not found - 本地
next dev可能不报错，是因为开发服务器走的是内存 FS + 简化 resolver；next build才启用完整 exports 解析 - 绕过方式：不用
@import，改用@layer base手动引入其 CSS 内容，或在 Docker 构建阶段提前cp node_modules/tw-animate-css/dist/tw-animate.css ./src/lib/再@import './lib/tw-animate.css'
动态类名在 Turbopack + Tailwind v4 下为何更难被识别
Turbopack 的模块图劫持能力比 Vite 更激进：它从 import './style.css' 开始，顺着 ESM 依赖链自动发现含类名的文件。但这个机制只抓静态 import，不执行 JS —— 动态拼接类名（如 className={`text-${size}`}）依然无法被 AST 分析捕获。
- Oxide 引擎的“变更感知快照”只加速已有类名的增量更新，不扩展识别能力
- 如果你用
safelist写正则/^text-[0-9]+$/，Turbopack 会缓存这个正则匹配逻辑；但若正则太宽（如/^text-/），它会缓存并生成大量冗余规则，体积反弹 - 真正安全的做法是：把动态分支收敛到组件级，用
@apply封装后，确保该组件文件路径在content列表中
最易被忽略的一点：Turbopack 的“快”建立在强一致性假设上——它默认所有 CSS @import 都是纯声明式、无副作用、无条件逻辑。一旦你混入 @import 条件加载（如通过构建环境变量控制）、或用插件注入运行时 CSS，整个缓存链就可能失效，且错误不会立刻暴露，而是延迟到生产构建才爆发。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
