<link media>是唯一原生、零JS、无闪动的按需加载方式，浏览器仅在media匹配时才发起CSS请求，不匹配则完全不下载；多个link断点须互斥，路径需准确，IE9及以下会忽略media属性。
用 <link media> 实现真正按需加载
媒体查询在 @media 规则里只能“开关样式”，不会阻止 CSS 文件下载；想让浏览器只在匹配时才发起请求，必须用 <link> 标签的 media 属性。这是唯一原生、零 JS、无闪动的按需加载方式。
-
media值为真时，浏览器才 fetch 对应的 CSS；为假时，完全不发请求（DevTools Network 面板里看不到） - 多个
<link>的断点必须互斥，否则可能同时触发下载——比如max-width: 768px和min-width: 768px在 768px 视口下会同时命中 - 路径写错（如
href="css/mobile.css"但实际在/assets/css/下）会导致静默失败：404 不报错，也不影响其他样式，极难排查 - IE9 及以下会忽略
media属性，无条件加载所有<link>——若仍需兼容，得回退到 JS 检测 +document.write
screen and (max-width: 768px) 这类写法为什么常出问题
断点值本身没毛病，但实际效果常偏离预期，核心在于它匹配的是视口宽度（viewport width），不是设备像素或物理尺寸。很多开发者误以为“手机就该走 mobile.css”，结果横屏 iPad（视口宽 > 768px）加载了 desktop.css，竖屏安卓小屏手机却因 viewport 缩放或 UA 伪造导致宽度计算异常。
-
max-width: 768px匹配的是当前视口 CSS 像素宽度，和<meta name="viewport">的width设置强相关；漏设或设错会导致所有断点失效 -
screen是媒体类型，不是必需项；写成media="(max-width: 768px)"和media="screen and (max-width: 768px)"效果一致，但后者更明确意图 - 避免用
device-width：已被现代浏览器弃用，且在 iOS Safari 中行为不可靠 - 横竖屏切换时，部分 Android WebView 不触发重载，
orientation查询可能滞后——建议搭配resize事件做降级处理
深色主题、高 DPI 等新场景怎么加 media 条件
现代浏览器支持的媒体特性远不止宽度，prefers-color-scheme 和 resolution 已成标配，但写法稍有差异，容易漏掉括号或逻辑符。
- 深色模式：
media="(prefers-color-scheme: dark)"—— 注意是scheme不是theme，且值必须小写 - Retina 屏：
media="(-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi)"—— 需同时写 WebKit 和标准语法，仅靠前者在 Firefox 中失效 - 组合条件要用
and：media="(max-width: 768px) and (prefers-color-scheme: dark)"，不能用逗号分隔 -
not和only已基本不用：only screen是 IE8 兼容写法，现代项目可直接省略
为什么有时写了 media 却还是加载了不该加载的 CSS
最常见原因是构建工具（如 Webpack、Vite）在打包时把所有 <link> 当作静态资源处理，提前内联或预加载，绕过了浏览器原生的 media 判断逻辑。
立即学习“前端免费学习笔记（深入）”；
- 检查构建产物 HTML：确认
<link>标签是否被插件（如html-webpack-plugin）自动注入了rel="preload"或rel="prefetch"，这些会无视media - Vite 的
build.rollupOptions.output.manualChunks若按入口拆包，可能把多个 CSS 合并进同一 chunk，导致断点失效 - 服务端渲染（SSR）框架如 Next.js，默认会把所有
<link>渲染到首屏 HTML，客户端 hydration 时 media 才生效——首次加载仍会多下一份 - 真正保险的做法：只对关键断点（如移动端基础样式）用
<link media>，其余用单个 CSS 内部@media，平衡性能与可控性
