应谨慎拆分CSS文件，仅在非首屏必需、主题切换、第三方库三类场景下按语义拆分，并严格控制加载顺序与关键CSS内联。
多个CSS文件在响应式项目里到底要不要拆？
拆不拆，关键看你的构建流程和团队协作方式。没有“必须拆”或“必须合”的铁律，但盲目拆分会显著拖慢首屏渲染——浏览器遇到 <link rel="stylesheet"> 就会阻塞渲染，每个额外的CSS文件都意味着一次HTTP请求（即使启用了HTTP/2，仍存在连接初始化、队列调度等隐性开销）。真要拆，只应在语义明确、加载时机可控的前提下进行，比如把打印样式、暗色模式、第三方组件样式单独抽离。
哪些场景适合拆成多个CSS文件？@media 规则本身不构成拆分理由；响应式逻辑本该写在一个文件里用媒体查询组织。真正值得拆的只有三类：
- 非首屏必需的样式：比如 print.css 仅在 window.matchMedia("print").matches 时动态加载
- 主题切换样式：如 dark-theme.css，配合 prefers-color-scheme 或用户手动切换，用 rel="stylesheet alternate" + JS 控制启用状态
- 第三方UI库样式：像 node_modules/antd/dist/reset.css 这类与业务无关、更新频率不同的资源，独立引入便于缓存分离
拆了之后怎么避免样式冲突和加载顺序问题？
CSS加载顺序直接影响层叠结果，尤其当多个文件里都写了 .btn 这样的通用类名。常见错误是把基础重置（reset.css）放在后面，导致全局样式被覆盖。务必按以下顺序组织 <link> 标签：
- 最前：重置/标准化样式（reset.css 或 normalize.css）
- 中间：基础布局与工具类（base.css、utils.css）
- 最后：页面级或组件级样式（home.css、modal.css）
别依赖 @import 拆分——它会在运行时阻塞解析，且无法并行下载，现代项目一律用构建工具（如PostCSS、Webpack）做真正的条件打包。
移动端下多CSS文件对性能的实际影响有多大？
在3G弱网下，每增加一个CSS文件，首屏时间平均延长300–600ms（实测数据，含DNS+TCP+TLS握手）。更隐蔽的问题是：部分低端Android WebView对并发 <link> 数量敏感，超过4个可能触发串行加载。解决方案不是硬塞进一个文件，而是用构建时提取关键CSS（Critical CSS）内联到HTML <head>，其余异步加载：
const style = document.createElement('link');
style.rel = 'stylesheet';
style.href = 'non-critical.css';
style.media = 'print'; // 先以不阻塞方式加载
style.onload = () => { style.media = 'all'; };
document.head.appendChild(style);
这个技巧绕过了渲染阻塞，又保留了样式文件的可维护性。
@media 规则本身不构成拆分理由；响应式逻辑本该写在一个文件里用媒体查询组织。真正值得拆的只有三类：
- 非首屏必需的样式：比如 print.css 仅在 window.matchMedia("print").matches 时动态加载
- 主题切换样式：如 dark-theme.css，配合 prefers-color-scheme 或用户手动切换，用 rel="stylesheet alternate" + JS 控制启用状态
- 第三方UI库样式：像 node_modules/antd/dist/reset.css 这类与业务无关、更新频率不同的资源，独立引入便于缓存分离
拆了之后怎么避免样式冲突和加载顺序问题？
CSS加载顺序直接影响层叠结果，尤其当多个文件里都写了 .btn 这样的通用类名。常见错误是把基础重置（reset.css）放在后面，导致全局样式被覆盖。务必按以下顺序组织 <link> 标签：
- 最前：重置/标准化样式（reset.css 或 normalize.css）
- 中间：基础布局与工具类（base.css、utils.css）
- 最后：页面级或组件级样式（home.css、modal.css）
别依赖 @import 拆分——它会在运行时阻塞解析，且无法并行下载，现代项目一律用构建工具（如PostCSS、Webpack）做真正的条件打包。
移动端下多CSS文件对性能的实际影响有多大？
在3G弱网下，每增加一个CSS文件，首屏时间平均延长300–600ms（实测数据，含DNS+TCP+TLS握手）。更隐蔽的问题是：部分低端Android WebView对并发 <link> 数量敏感，超过4个可能触发串行加载。解决方案不是硬塞进一个文件，而是用构建时提取关键CSS（Critical CSS）内联到HTML <head>，其余异步加载：
const style = document.createElement('link');
style.rel = 'stylesheet';
style.href = 'non-critical.css';
style.media = 'print'; // 先以不阻塞方式加载
style.onload = () => { style.media = 'all'; };
document.head.appendChild(style);
这个技巧绕过了渲染阻塞，又保留了样式文件的可维护性。
<link> 数量敏感，超过4个可能触发串行加载。解决方案不是硬塞进一个文件，而是用构建时提取关键CSS（Critical CSS）内联到HTML <head>，其余异步加载：
const style = document.createElement('link');
style.rel = 'stylesheet';
style.href = 'non-critical.css';
style.media = 'print'; // 先以不阻塞方式加载
style.onload = () => { style.media = 'all'; };
document.head.appendChild(style);
这个技巧绕过了渲染阻塞，又保留了样式文件的可维护性。
实际项目里，最常被忽略的是构建产物中残留的未使用CSS规则——哪怕只拆了一个文件，如果里面混着大量未调用的选择器，gzip后体积反而比合并后更大。拆之前先跑一遍 PurgeCSS 或 UnCSS，否则只是把问题从体积转移到请求数。
