link的media属性仅控制CSS文件是否下载，不控制样式是否生效；常因误以为能实现响应式加载而被滥用，实际存在预加载、不响应动态变化、样式无隔离三类问题。
link 的 media 属性确实能“按条件加载”CSS 文件，但它不控制样式是否生效——只控制浏览器要不要下载那个文件。想靠它做响应式，必须清楚它管什么、不管什么。
为什么常被误用？
很多人写 ，以为手机一访问就只加载 mobile.css、桌面就只加载 desktop.css。实际会遇到三类问题：
- 浏览器可能预加载所有带
media的 CSS（尤其 Chromium 系），即使不匹配也发请求，浪费带宽 -
media只在页面初始渲染时判断一次，横竖屏切换、缩放、窗口 resize 都不会重新加载或卸载 - 多个
link加载的 CSS 之间没有自动隔离，.header在mobile.css和desktop.css里都定义了，层叠优先级取决于加载顺序和选择器权重，容易残留旧样式
哪些场景下可以用？
它真正适合的是“完全隔离、互不干扰”的资源，比如：
-
print：打印样式表—— 打印时才下载，且不参与屏幕渲染 - 高分辨率专用资源：
—— 只给 Retina 屏加载高清图标或字体 - 横竖屏专属布局：
—— 仅横屏时拉取，避免竖屏设备多下一份
这些场景下，样式逻辑独立、无重叠，media 的“加载开关”作用才真正可控。
怎么写才不容易出错？
关键不是语法对不对，而是断点设计和路径管理：
- 断点必须互斥：比如用
(max-width: 767px)和(min-width: 768px)，别留空隙或重叠，否则某些宽度下两个都加载或都不加载 - 路径要绝对或明确：如果
mobile.css在/css/目录下，href必须写成/css/mobile.css，相对路径易因页面层级出错，失败也不报错 - IE9 及以下会忽略
media并加载所有 CSS —— 如果还要兼容，得用 JS 检测后动态document.write或插入link - 不要指望改
link.media能实时切换样式：JS 修改后，旧 CSS 不会卸载，新 CSS 可能还没加载完，页面直接白屏或错乱
什么时候该放弃？
当你需要频繁响应视口变化（比如拖拽浏览器窗口）、或希望移动端用户不下载桌面端大图/CSS、或团队协作维护多套样式表成本太高时，link 的 media 就不是最优解。
这时候，把所有规则收进一个 CSS 文件，用 @media 包裹，配合 ，才是更稳定、可预测、易调试的做法。而 link media 更像是“辅助加载”，不是响应式主干。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
