v4 的 Oxide 引擎通过 content 驱动的按需生成、@layer 压缩合并、Lightning CSS 严格解析，实现更激进的 tree-shaking；未匹配类不声明、冗余结构被剔除、非法规则直接跳过，产物体积取决于 content 配置精度与语法合法性。
因为 v4 的 Oxide 引擎在生成 CSS 时彻底跳过了“先生成所有可能类、再删没用的”流程，改为“只生成 content 中真实出现过的类”，且不再保留未使用的层结构或冗余选择器。
tree-shaking 更激进：未匹配的工具类根本不会定义
v3 的 JIT 引擎会先构造完整工具类集合（比如所有 text- 变体），再扫描 HTML/JSX 去剔除未用项；v4 的 Oxide 引擎直接把 content 扫描结果当作唯一输入源——没在匹配文件里出现的 bg-red-500，连声明块都不会写进输出 CSS。
- 实测：一个只用了
text-sm和flex的页面，v4 输出中完全找不到text-lg、grid等相关规则 - v3 即使配置了
purge或content，仍可能因正则误匹配或插件干扰残留未用类 - 注意：
content路径漏配（如没覆盖.astro文件）会导致对应类名完全不生成，不是“多余”，而是“缺失”
@layer 结构被压缩：base/components/utilities 不再独立成块
v3 输出中每个 @tailwind base 对应一个独立 @layer base 块，含重置样式、默认字体、表单修复等；v4 的 @import 'tailwindcss' 触发 Oxide 三阶段处理后，这些规则被合并、去重、按实际依赖注入，不再机械保留原始分层。
- 例如
* {}和html {}重置规则会被折叠为更紧凑的选择器组合 - 未启用的插件（如
@tailwindcss/forms）对应的所有@layer components内容直接不参与构建 - 旧项目若手动写了
@layer components { ... }，可能被@theme规则覆盖或忽略，导致结构进一步简化但行为不可预期
Lightning CSS 默认 strict 模式：非法表达式直接跳过，不兜底
v3 的 JS JIT 引擎对 calc(100% - var(--x)) 这类语法错误会宽容处理（跳过或降级），仍输出部分 CSS；v4 的 Lightning CSS 在 strict 模式下遇到非法 calc、无效嵌套或错位 @ 规则，直接中断该规则解析，不生成对应声明。
立即学习“前端免费学习笔记（深入）”；
- 结果是：v4 的产物里没有“半残缺”的样式块，要么完整，要么不存在
- 常见坑：自定义 CSS 中混用
calc()+ 未声明变量，v3 有样式，v4 没这条规则 - 可通过在
tailwind.config.js中加lightningcss: { cssModules: false, drafts: { nesting: true } }放宽限制，但会牺牲精简度
真正影响产物体积的，从来不是“压缩率”，而是“是否生成”。v4 把“生成决策点”从 JS 运行时前移到 Rust 编译期，并绑定到精确的文件级引用关系上——这导致它的 CSS 看起来更薄，但前提是你的 content 配得准、@import 写得干净、calc() 用得合法。任何一环松动，精简就变成缺失。
