应按语义边界拆分公共CSS：组件级、布局级、主题级可独立，reset与typography合并为base.css；禁用@import，改用构建合并或link引入；CSS变量按模块作用域定义；PostCSS中需禁用cssnano的mergeLonghand等破坏复用的操作。
公共 CSS 文件该拆到多细？
拆太碎会导致 HTTP 请求激增，尤其在 HTTP/1.1 环境下；拆太粗又会让每个页面加载大量无用样式，拖慢首屏渲染。关键不是“要不要拆”，而是按 语义边界 拆：组件级（如 button.css）、布局级（如 grid.css）、主题级（如 dark-theme.css）可以独立，但 reset.css 和 typography.css 建议合并为 base.css——它们几乎被所有页面共用，且体积小、无条件逻辑。
如何避免 @import 引发的阻塞和顺序陷阱？
@import 会阻塞后续 CSS 解析，且导入顺序直接影响优先级，极易引发意料外的样式覆盖。生产环境应禁用 @import，改用构建时合并或 <link rel="stylesheet"> 显式声明。若必须动态引入（如插件场景），用 CSSStyleSheet.insertRule() 或 document.styleSheets[0].addRule() 替代，避免 DOM 渲染卡顿。
CSS 变量（custom properties）怎么用才不伤复用性？
把变量定义在 :root 是常见做法，但容易导致命名污染和维护困难。更稳妥的方式是按模块作用域定义：
:root {
--color-primary: #007bff;
}
.card {
--card-padding: 1rem;
--card-border-radius: 4px;
}
.card-header {
background-color: var(--color-primary);
padding: var(--card-padding);
}
这样既保持继承链清晰，又避免全局变量爆炸。注意：var(--missing) 不报错但会回退到初始值，调试时需检查 computed styles 而非 declaration 面板。
立即学习“前端免费学习笔记（深入）”；
PostCSS 插件链里哪些操作会破坏公共样式复用？
以下操作在「公共样式」上下文中风险较高：
-
postcss-preset-env的stage: 3启用nesting时，嵌套规则可能被错误提升到全局作用域 -
cssnano默认开启mergeLonghand，会把margin-top: 1em; margin-bottom: 1em合并为margin: 1em 0，若下游项目依赖单边 margin 的 specificity，可能出问题 -
postcss-import若未配置resolve，可能误将 node_modules 中同名文件优先引入，覆盖预期的本地variables.css
建议在公共样式构建流程中锁定插件版本，并对 cssnano 关闭 mergeLonghand 和 normalizeWhitespace，保留原始可读性和可预测性。
真正难的不是写多少公共样式，而是每次修改 base.css 或 variables.css 时，能否快速确认影响范围——没有自动化分析手段，靠人肉 grep 或浏览器 devtools 查找，迟早出错。
