link标签的media属性需写为合法媒体类型或媒体查询（如screen、(min-width:768px)），空格分隔多条件，and不可省略或替换，且仅当匹配当前视口时才下载应用样式表。
link 标签里怎么写 media 属性才生效
只有 link 标签的 media 属性匹配当前视口时，浏览器才会下载并应用对应样式表。它不是“加载后判断”，而是“先判断再加载”，所以能节省带宽。
常见错误是把媒体查询写成 CSS 内部语法，比如 media="(min-width: 768px) and (max-width: 1024px)" 看起来对，但实际必须确保 HTML 中的 link 标签没有被其他逻辑（如 JS 动态移除、preload 干扰）打断加载流程。
-
media值必须是有效的媒体类型或媒体查询，例如screen、print、(min-width: 768px) - 多个条件用空格分隔，不是逗号；
and是关键字，不能省略或写成&& - 不支持嵌套括号或自定义函数，比如
(width > 768px)是无效的 - 移动端 Safari 对
link[media]的懒加载行为较激进，首次渲染可能延迟，建议关键断点仍用内联@media
多个 link 标签同时存在时，浏览器怎么选
浏览器不会“合并”或“优先级排序”多个 link[media]，而是对每个标签独立判断：匹配则加载并应用，不匹配则跳过（不下载、不解析）。
这意味着你可以安全地并列写多个响应式样式表，只要它们的 media 条件互斥或有重叠都 OK —— 重叠时，后加载的样式会自然层叠覆盖（取决于 CSS 选择器权重和顺序），和普通样式表规则一致。
- 注意断点边界要对齐，比如
767px和768px必须无缝衔接，否则某些宽度下所有media都不匹配，样式丢失 - 不要依赖
media="not all"或media="none"来“禁用”某个 link —— 它们只是让该资源完全不加载，无法用于切换逻辑 - 服务端无法通过
link[media]检测用户设备，这个判断纯客户端执行
为什么有时 media 匹配了但样式没生效
最常见原因是 CSS 本身的选择器权重不够，或者被后续加载的样式覆盖。因为 link[media] 只控制“是否加载”，不改变 CSS 的层叠顺序 —— 它在 HTML 中的位置决定了它的层叠优先级。
- 如果
desktop.css在mobile.css后面引入，即使只在桌面匹配，它也会覆盖 mobile.css 中相同选择器的声明 -
!important不解决根本问题，反而会让维护变困难；优先检查选择器特异性（比如.header nav avsa） - 使用 Chrome DevTools 的 “Rendering” → “Emulate CSS Media” 可强制触发不同
media，验证是否真加载了对应文件 - 某些构建工具（如 Vite、Webpack）会对
link标签做预处理，可能剥离media属性，需检查最终输出的 HTML
media 查询里的 width 是指什么宽度
是浏览器窗口的 innerWidth，即 CSS 像素宽度（viewport 宽度），不是设备物理像素，也不是 screen.width。
这意味着它受 viewport meta 标签影响极大：
- 没有这行 meta，移动端 Safari 会以 980px 宽度渲染，导致
(min-width: 768px)在 iPad 上也匹配不到 tablet.css -
width=device-width让innerWidth接近设备逻辑宽度（比如 iPhone 14 Pro 是 393px），而非默认缩放后的宽度 - 不要混用
device-width和width：CSS 媒体查询里只能用width（表示视口），device-width是旧式媒体特性，现代开发中已不推荐
断点设计应基于内容而非设备型号，768px 不代表“iPad”，而是“当容器窄到这个程
