媒体查询本身不能按需加载CSS文件，真正实现按需加载需通过HTML的link[media]属性、JavaScript动态插入或服务端条件渲染；CSS内部@media仅控制样式生效时机，不阻止文件下载。
媒体查询不能直接按需加载CSS文件
浏览器的 @media 查询只是「条件渲染规则」，它不会阻止CSS文件下载——哪怕你把样式写在 @media (max-width: 480px) { ... } 里，整个CSS文件依然会在页面初始时被请求、解析、构建CSSOM。这是最常见的误解源头。
真正能实现「按需加载」的，是HTML层面的资源分发逻辑，不是CSS内部的媒体查询。
-
<link rel="stylesheet">标签加media属性，可让浏览器延迟加载非匹配媒体的样式表（如media="print"或media="(min-width: 768px)"） - 现代浏览器对
media属性值为不匹配当前环境的<link>，会将其设为disabled状态，跳过解析，但**仍会发起HTTP请求**（除非用onload+remove()手动清理） - 若想彻底避免请求，必须用JS动态插入
<link>，或服务端根据UA/屏幕宽度做条件渲染
用 media 属性做轻量级分流
适合多终端共用一套构建流程、不想改打包逻辑的场景。关键在把「大而全」的响应式CSS拆成语义明确的几份，并用 media 控制初始加载时机。
例如：
立即学习“前端免费学习笔记（深入）”；
<link rel="stylesheet" href="base.css"> <link rel="stylesheet" href="mobile.css" media="(max-width: 767px)"> <link rel="stylesheet" href="desktop.css" media="(min-width: 768px)">
- 所有
<link>都会被HTML parser发现并预加载，但只有匹配media的才会触发CSS解析和渲染阻塞 -
mobile.css在桌面端仍会下载（Chrome DevTools Network面板可见），但不会影响首次渲染（FOUC风险低） - 务必确保
base.css包含通用重置、字体、基础布局，避免拆分后出现样式断裂 - 不要对同一选择器在多个文件里重复定义——没有层叠顺序保障，容易因加载时序导致意外交互
动态加载需要JS介入
想真正只加载当前设备所需的CSS，必须绕过HTML初始解析阶段，用脚本控制请求时机。这不是“优化”，而是「资源调度」。
- 用
matchMedia()检测当前断点，再调用document.createElement('link')插入对应CSS - 记得设置
link.rel = 'stylesheet'和link.href，否则无效 - 插入后可监听
link.onload做后续操作（比如移除占位样式），但注意IE不支持onload，需用onreadystatechange - 如果用户旋转屏幕或缩放窗口，
matchMedia().addEventListener('change')可触发切换，但频繁切换CSS文件易引发重排，建议仅用于差异极大的主题（如深色/浅色模式）而非常规响应式断点
构建时分离比运行时更可靠
Webpack/Vite等工具能通过配置，在打包阶段就产出不同入口对应的CSS，再由HTML模板按需引入。这比JS动态加载更稳定，也更容易配合HTTP缓存。
- Vite中可用
import('./mobile.css')动态导入，配合if (isMobile)判断，生成独立chunk - Webpack中用
MiniCssExtractPlugin+ 多入口（entry: { mobile: './src/mobile.js', desktop: './src/desktop.js' }），输出不同CSS文件 - 服务端渲染（如Next.js、Nuxt）可在getServerSideProps中读取
user-agent或accept-encoding，决定注入哪组<link> - 注意：移动端CSS体积小 ≠ 加载快——若CDN未开启Brotli压缩、或未启用HTTP/2多路复用，小文件反而因TCP握手开销显得更慢
真正卡顿的往往不是CSS本身，而是没意识到CSS文件即使被 media 屏蔽，仍参与关键渲染路径的资源发现与预加载。拆得越细，越要盯住Network面板里每个 .css 请求的状态码、大小、传输时间——而不是只看DOM里有没有那行 <link>。
