link标签的media属性控制CSS文件是否参与样式计算，不阻止下载；它仅在页面加载时静态匹配一次，不随窗口变化重载，需配合JS实现动态响应。
link标签的media属性到底控制什么
它只决定标签是否“生效”，不控制CSS文件是否被浏览器下载。哪怕media="print"，现代浏览器仍会并行下载该CSS（除非用rel="preload"等主动干预），只是不把它用于屏幕渲染。
常见错误现象：media="(max-width: 768px)"写在上，但小屏下样式没生效——大概率是媒体查询条件没匹配，或CSS优先级被覆盖，而不是文件没加载。
- 使用场景：响应式站点首屏优化、为打印/语音朗读等辅助设备提供专用样式、避免移动端加载桌面端冗余CSS（需配合HTTP缓存策略）
- 参数差异：
media值支持完整的CSS媒体查询语法，如media="screen and (min-resolution: 2dppx)"或media="all"（默认值） - 兼容性影响：IE9+完全支持；但旧版Safari对复杂查询（如
hover、prefers-color-scheme）支持较晚，建议用matchMedia()做运行时兜底
如何真正延迟加载非关键CSS文件
想让CSS“按需下载”，media本身做不到。必须配合JavaScript动态创建<link>或用rel="preload" + onload切换。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 把非关键CSS的
media设为一个永远不匹配的值，比如media="not all"，再用JS在合适时机改回真实值（如link.media = "all"） - 更可靠的做法：用
<link rel="preload" as="style" href="mobile.css" onload="this.onload=null;this.rel='stylesheet'">，配合media属性一起用 - 注意：动态插入
<link rel="stylesheet">会阻塞渲染，而preload+onload可实现异步加载
和CSS @media规则的区别在哪
<link media>是资源级开关，@media是规则级开关。前者决定“整个文件是否参与样式计算”，后者决定“文件里哪些声明生效”。
容易踩的坑：
- 同一份CSS既用
<link media="screen">引入，又在内部写@media print { ... }——打印样式依然可用，因为文件已加载 - 误以为
<link media="(min-width: 1024px)">能替代@media (min-width: 1024px)——前者在窗口宽度变化时不会重新加载文件，后者实时响应 - 性能影响：大量
<link media>会增加HTML解析开销，而@media规则由CSS引擎统一处理，更轻量
media属性失效的几个典型原因
不是语法错，而是环境或逻辑问题。
- HTML中
<link>写在<body>里：部分浏览器会忽略，必须放在<head>中 - 媒体查询用了未启用的特性，比如
media="(prefers-reduced-motion: reduce)"在旧系统或未开启设置的设备上恒为false - 服务端返回了
Content-Type: text/plain而非text/css，导致浏览器拒绝解析，此时media根本没机会起作用 - 路径错误导致404：浏览器仍会尝试请求，但控制台报
Failed to load resource，样式自然不生效
最常被忽略的一点：媒体查询匹配是静态的——页面加载时计算一次，后续尺寸变化不会触发重加载。要响应式更新，得靠JS监听resize或用matchMedia()主动切换link.media。
