大型项目中直接@import全局css危险，因样式污染和构建不可控会随文件增长指数级放大；css-in-js适用于高交互、主题切换等场景但有ssr和性能代价；css modules是被低估的折中方案，需正确配置与使用。
大型项目里直接 @import 全局 CSS 为什么越来越危险
因为样式污染和构建不可控会随着文件增长指数级放大。你改一个 button.css，CI 构建时发现 Modal 组件的圆角突然变了——大概率是某个 @import 顺序错位，或者某处用 !important 撑出来的临时修复反向污染了全局。
常见错误现象：Unexpected style override in production only、热更新后样式丢失、css-loader 的 localIdentName 在不同子包里冲突。
- 所有跨包共享的样式必须显式声明作用域，不能依赖“大家都引入了同一个 reset.css”这种默契
-
@import在.css文件里是同步阻塞的，Webpack 不会做 tree-shaking，哪怕只用了一个按钮，也会把整份common.css打进去 - 多人协作时，
@import "utils/mixins.css"这种路径写法在 monorepo 里极易因别名配置不一致导致本地能跑、CI 报Module not found
CSS-in-JS（如 styled-components）在什么场景下真有用
不是“用了就高级”，而是解决特定问题：组件级样式隔离 + 运行时主题切换 + 基于 props 的动态样式生成。比如你有一个 ChartCard 组件，需要根据 size="sm" 或 theme="dark" 实时生成不同 padding 和颜色，这时候 styled-components 的插值语法比写一堆预编译 class 名更直白。
但代价也很实在：服务端渲染时要多一次 extractCritical 步骤；React 18 的 concurrent rendering 下，频繁创建 styled.div 可能触发不必要的 memo 失效；生产环境打包后，class 名哈希值变长，gzip 后体积未必比 BEM 小。
- 适合：高交互组件（表单、图表、弹窗）、需要主题热切换的管理后台、微前端子应用独立样式沙箱
- 不适合：纯静态内容页、SEO 敏感型站点（SSR 注入时机稍有偏差就会闪屏）、已有的 Vue/Angular 项目强行接入（生态割裂成本高）
- 注意
styled-components的shouldForwardProp必须配，否则自定义 prop 会透传成 DOM 属性，控制台刷满Warning: React does not recognize the `variant` prop
CSS Modules 是不是被低估的折中方案
它没解决运行时动态性，但把“模块化”这件事做得足够干净：每个 .module.css 文件天然作用域隔离，类名自动哈希，且支持 :global 显式破圈——该收的收，该放的放，不玄学。
典型误用：把 index.module.css 当成传统 CSS 写，堆 .btn-primary:hover 和 .btn-primary:active，结果发现伪类选择器没生效。原因是 CSS Modules 默认不处理伪类，得写成 &:hover 嵌套在父类里，或者用 :global(.btn-primary):hover。
- 必须配合 Webpack 的
css-loader?modules或 Vite 的css.modules配置，否则import styles from './Button.module.css'会返回空对象 - 与 Sass/Less 混用时，
@use和@forward不能跨 module 边界，变量得提成variables.module.scss单独 import - 动态 className 拼接要小心：
className={`${styles.container} ${isActive ? styles.active : ''}`，别漏掉空格或三元表达式返回undefined
真正影响加载性能的不是“用不用 CSS-in-JS”，而是怎么切分 chunk
再优雅的样式方案，如果所有 CSS 都打进 main.css，首屏照样卡顿。关键在拆分策略：路由级 chunk（loadable-components + extract-css-chunks-webpack-plugin）、组件级异步 CSS（React.lazy 配合 StyleSheetManager）、以及 SSR 时按需注入 critical CSS。
容易被忽略的一点：CSS 的 media 查询不会触发懒加载，但 @supports 会。如果你写 @supports (display: grid) { .grid-layout { display: grid; } }，这个规则仍会进入初始 bundle，除非你用 JS 动态插入 style 标签。
- Webpack 5 的
splitChunks.cacheGroups要为 CSS 单独设规则，不能只靠chunks: 'all'，否则node_modules里的 CSS（比如react-datepicker）可能被错误地塞进 vendor chunk - Vite 用户注意：
build.rollupOptions.output.manualChunks对.css文件无效，得用build.cssCodeSplit控制是否拆分 - CDN 缓存失效链路里，CSS 文件的 hash 变更常被忽略——改了 JS 逻辑但样式依赖的变量没变，hash 却全变了，缓存利用率暴跌
样式方案选型最麻烦的地方不在语法甜不甜，而在团队对“样式即接口”的认知是否一致：要不要让设计师直接改 Button.module.css？能不能接受 SSR 时多一次样式收集？有没有人愿意维护那套 theme.ts 到 variables.scss 的映射表？这些事，代码跑通只是开始。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
