媒体查询本身不阻止css下载，但@import中的媒体查询会阻塞；link media仅控制应用时机，文件仍并行下载（print等例外）。常见未请求实为路径错误或@import嵌套所致。
媒体查询会阻止CSS文件下载吗
不会，但有前提：@import 规则里的媒体查询才真正“阻塞”下载；而 <link media="..."> 中的媒体查询只是告诉浏览器“先别应用”，文件本身仍会并行下载（除非是 print 或不匹配的 screen 类型且浏览器做了优化）。
常见错误现象：network 面板里看到某个 CSS 文件没发起请求，就以为是媒体查询“屏蔽”了它——其实更可能是路径写错、服务器返回 404，或者用了 @import 嵌套在不匹配的查询块里。
-
<link rel="stylesheet" href="mobile.css" media="(max-width: 768px)">：文件照常下载，只是不生效 -
@import url("print.css") print;：多数浏览器会延迟加载，直到打印上下文触发 - chrome 对
not all、only screen等语法更激进地跳过下载，safari 则倾向预取
CSS媒体查询写在HTML里还是单独文件中更高效
优先写在单独 CSS 文件中，用 <link> 引入并配 media 属性；避免把媒体查询逻辑揉进 HTML 的 <style></style> 标签或内联 style 属性里。
原因很实际：浏览器对 <link> 有预加载扫描（preload scanner），能提前发现并行抓取资源；而 <style></style> 里的媒体查询要等 HTML 解析到那行才开始处理，还无法被 http/2 推送或 CDN 缓存复用。
立即学习“前端免费学习笔记（深入）”；
- 移动端首屏关键 CSS 可以内联，但媒体查询部分建议抽离——否则响应式切换时得重排整个样式表
- 不要用 JavaScript 动态插入
<link media="...">，时机难控，容易造成 FOUC 或重复加载 - webpack/Vite 等构建工具默认把
@media合并进同一文件，这不是问题；真要拆包，靠splitChunks按内容而不是媒体类型切
多个媒体查询合并成一个文件会影响渲染性能吗
几乎不影响首次渲染，但可能拖慢后续响应式切换的样式重计算速度。
浏览器解析 CSS 时，媒体查询条件本身不耗时；但当窗口 resize 或设备旋转时，它得重新评估所有 @media 块是否匹配，并批量重应用规则。块越多、嵌套越深（比如 @media (prefers-color-scheme: dark) { @media (hover: hover) { ... } }），重计算开销越明显。
- 把高频切换的查询（如
prefers-reduced-motion、prefers-color-scheme）单独成文件，利用media属性做懒加载 - 避免在单个 CSS 文件里写几十个零散
@media (min-width: ...) { ... }，合并为区间式写法更易维护，也减少匹配遍历次数 - 注意：CSSOM 构建阶段，未匹配的媒体查询仍会进入样式表对象，只是规则不激活——内存占用微增，但可忽略
如何验证媒体查询是否真的影响了页面加载性能
别只看 Lighthouse 的“Eliminate render-blocking resources”建议；重点查 network 面板的 Initiator 列和 Waterfall 时间轴，再配合 Rendering 面板的强制媒体查询模拟。
- 在 chrome devtools 的
Rendering>Emulate CSS Media中切换print/screen，观察对应<link media="print">文件是否发起请求 - 用
performance.mark()+performance.measure()包裹window.matchMedia().addEventListener()回调，测响应式切换延迟 - 真实弱网下测试：用
throttle模拟 3G，看mobile.css（media="(max-width: 480px)"）是否在桌面模式下仍被下载——如果没被下载，说明浏览器做了优化；如果下了，说明你用的是@import或写法触发了预加载
最常被忽略的一点：服务端 User-Agent 检测和客户端媒体查询双管齐下时，CSS 文件可能被重复加载（比如后端吐了 mobile.css，前端又通过 <link media="(max-width: 768px)"> 再拉一遍），这种冗余比媒体查询本身更伤性能。