能，但必须满足显式import、路径合法、不触发边界重载三个条件；Turbopack的CSS HMR依赖模块图标记，绕过构建系统或跨RSC边界会导致全页刷新。
能，但必须满足三个硬性条件：显式 import、文件路径合法、不触发边界重载。 Turbopack 的 CSS HMR 不是“自动生效”的魔法，它依赖精确的模块图标记和受限的更新边界。一旦踩中任意一个隐性限制，就会退化为全页刷新，所谓“极速”就无从谈起。
为什么 import './styles.css' 是唯一合法入口
Turbopack 只对被 JS 模块 import 的 CSS 文件建立构建链路。它不扫描 /public 目录，也不解析 HTML 中的 —— 这些写法完全绕过构建系统，自然无法参与 HMR。
- ✅ 正确：在
app/layout.tsx顶部写import '../styles/global.css' - ❌ 错误：把
global.css放进public/，再在app/layout.tsx里用dangerouslySetInnerHTML注入 - ⚠️ 注意：
page.tsx旁放同名page.module.css不会自动加载，仍需手动import
.module.css 和全局 CSS 的 HMR 行为差异
后缀决定作用域，也影响 HMR 粒度。Turbopack 对 .module.css 做哈希类名 + 导出对象处理，更新时只通知使用了该 CSS 模块的组件；而全局 CSS（如 globals.css）一旦修改，所有 import 它的 layout 或 page 都会被标记为“需重载”，容易引发连锁反应。
- 修改
Button.module.css→ 通常只触发热更新Button.tsx及其子组件 - 修改
app/globals.css→ 若被app/layout.tsx和多个page.tsx共同 import，可能退化为整页刷新 - 不支持
.module.sass：只有.module.css被识别为模块化，.module.scss会被当普通 SCSS 处理（无哈希、无导出）
哪些操作会让 CSS HMR 卡住或 fallback 到 full reload
终端出现 [turbopack] rebuilding (full) 就是明确信号：某处破坏了增量缓存链路。常见诱因不是 CSS 写法本身，而是它所处的 React 组件上下文。
- 在
app/loading.tsx或app/error.tsx中importCSS → 这两个文件属于 RSC 边界，Turbopack 当前对它们的 HMR 支持有限 - 在
use client组件内用import()动态加载 CSS → Turbopack 不支持动态 CSS 导入的 HMR - CSS 文件里用了
url('./image.png')且该图片路径未被 Turbopack 显式识别为资源 → 构建图中断，缓存失效 - 存在未声明的全局变量（如直接写
window.xxx）或eval→ Turbo 引擎拒绝缓存含不可控副作用的模块
PostCSS 和 Sass 的热更新要额外注意什么
Turbopack 内置 PostCSS 和 Dart Sass，但它们的配置生效方式和 Webpack 截然不同：没有 loader 链，也没有插件注册点，一切依赖约定式配置文件和语法兼容性。
- PostCSS：只要根目录有
postcss.config.js，Turbopack 自动启用autoprefixer和postcss-preset-env，无需额外配置 - Sass：
@import '../vars.scss'必须用相对路径，不支持@import '@/styles/vars'这类别名写法 - 不要装
sass-loader或node-sass：Turbopack 完全忽略这些包，装了反而可能干扰依赖解析 - 慎用
@use ... with：当前版本（2026 年中）仅支持基础@use，传参块会报错或静默失败
真正卡住 HMR 的往往不是 CSS 本身，而是它被挂载的位置、导入的方式、以及周边组件是否跨了 RSC 边界。验证方法很简单：先删掉所有 use client，纯服务端组件里 import CSS，改保存看终端日志——如果还是 (full)，就说明问题出在 CSS 文件的路径、引用方式或 PostCSS/Sass 语法上。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
