元素的 media 属性到底该如何使用？核心结论是：它确实能够“按条件”下载 CSS 文件，但仅控制浏览器是否下载该文件，而样式最终是否生效，则不在其职责范围内。许多开发者希望通过它实现响应式加载，然而其实际运行逻辑远比想象中复杂。

link 的 media 属性确实能实现“条件加载”CSS 文件，但样式是否生效并不由其控制——它只决定浏览器是否下载该文件。若想借助它实现响应式设计，必须明确其职责边界。

为什么常被误用？

常见误区在于，开发者往往这样写：，并期望手机端只加载 mobile.css，桌面端只加载 desktop.css。但实际表现会揭示三个问题： - 浏览器（尤其是 Chromium 系）可能会预加载所有带 media 的 CSS，即便条件不匹配，也会发出请求，导致带宽被无谓消耗。 - media 仅在页面初始渲染时判断一次，后续无论横竖屏切换、窗口缩放还是方向改变，都不会重新加载或卸载文件。 - 多个 link 加载的 CSS 之间并无自动隔离。例如，.header 同时在 mobile.css 和 desktop.css 中定义了规则，最终生效哪个取决于加载顺序与选择器权重——旧样式很容易残留，调试难度大增。

哪些场景下可以用？

它的真正用武之地是那些“完全隔离、互不干扰”的资源场景。例如： - 打印样式表：，仅在用户点击打印时下载该文件，且绝不参与屏幕渲染。 - 高分辨率专属资源：，只让 Retina 屏设备加载高清图标或字体，普通屏设备不额外下载。 - 横竖屏专属布局：，仅在横屏时拉取，避免竖屏设备下载无用样式。 这些场景的共同特点是：样式逻辑完全独立、没有重叠，media 的“加载开关”功能才能有效发挥作用。

怎么写才不容易出错？

关键不在于语法是否正确，而在于断点设计与路径管理： - 断点必须互斥。例如使用 (max-width: 767px) 和 (min-width: 768px)，避免出现空隙或重叠，否则某些宽度下两个文件可能同时加载或均不加载，导致效果混乱。 - 路径要绝对或明确。若 mobile.css 位于 /css/ 目录下，href 必须写成 /css/mobile.css。相对路径容易因页面层级不同而出错，且失败时不会报错，调试起来十分棘手。 - 兼容性的坑：IE9 及以下版本会忽略 media 并加载所有 CSS。若需兼容老浏览器，需使用 JS 检测后动态 document.write 或插入 link。 - 别指望动态修改：通过 JS 修改 link.media 来实时切换样式风险极高。旧 CSS 不会卸载，新 CSS 可能尚未加载完，容易导致页面白屏或错乱，得不偿失。

什么时候该放弃？

当你需要频繁响应视口变化（例如用户拖拽浏览器窗口）、希望移动端用户不下载桌面端的大图或 CSS，又或者团队协作维护多套样式表成本过高时，link 的 media 就不再是最优选择。 此时更稳妥的做法是：将所有规则收进一个 CSS 文件，用 @media 包裹，并配合 。这种方式更稳定、可预测、易于调试。而 link media 更适合作为“辅助加载”手段，而非响应式方案的核心。