media属性仅在link标签中实现物理隔离，@import不支持延迟加载；正确写法是base.css无media，mobile.css用max-width:768px，desktop.css用min-width:79px，严格互补且避免only screen。
media属性只在link标签中生效，@import不支持物理隔离
直接用 @import 加媒体查询（比如 @import url("mobile.css") screen and (max-width: 768px)）看似能分设备加载，但实际所有被 import 的 CSS 都会在初始渲染时下载并解析——浏览器根本不按媒体条件延迟加载。这违背“物理隔离”本意，也浪费带宽。
真正能实现文件级隔离的，只有 <link> 标签的 media 属性：
- 浏览器会根据
media值决定是否下载该资源（现代浏览器基本都支持） - 匹配失败时，对应 CSS 文件不会发起 HTTP 请求
- 多个
<link media="...">可共存，互不影响
如何正确写 link 标签实现设备样式物理分离
关键不是“怎么写媒体查询”，而是“怎么组织 link 标签顺序和属性”。常见错误是把所有 media 写成互斥条件，结果桌面端漏样式、移动端没兜底。
推荐写法（以移动优先为例）：
立即学习“前端免费学习笔记（深入）”；
<link rel="stylesheet" href="base.css"> <link rel="stylesheet" href="mobile.css" media="screen and (max-width: 768px)"> <link rel="stylesheet" href="desktop.css" media="screen and (min-width: 769px)">
注意点：
-
base.css必须包含通用重置、基础排版、无障碍等不依赖设备的规则 - 两个 media 查询必须严格互补（
max-width: 768px和min-width: 769px中间不能有空隙） - 不要用
only screen——only在旧版 iOS Safari 有兼容问题，且现代浏览器已无需它 - 如果要支持打印样式，单独加一行
<link rel="stylesheet" href="print.css" media="print">
响应式断点与文件拆分的实际取舍
拆成三个文件（mobile / tablet / desktop）听起来合理，但容易引发维护负担和加载不确定性。多数项目真正需要的是「两档物理隔离」：
- 移动端（含小屏平板）：用
max-width: 1024px覆盖绝大多数手持设备 - 桌面端（含大屏平板）：用
min-width: 1025px，同时保证鼠标悬停、宽屏布局等特性可用 - 避免为 iPad Pro（12.9″）单独建
tablet.css——它的 viewport 宽度常超 1024px，又没鼠标，混在 desktop.css 里反而更难测试
如果你的 base.css 已经用 CSS 自定义属性 + @media 写了大部分响应逻辑，那物理拆分就意义不大；只有当某套样式体积大（>100KB）、规则完全不重叠、且明确只在某类设备运行时，才值得单独抽离文件。
验证是否真做到了物理隔离
别信文档，看 Network 面板：
- 在 Chrome DevTools 的 Device Toolbar 中切换 iPhone SE / MacBook Pro
- F5 刷新，观察 Network → Filter 输入
css，确认只有匹配media的文件被请求 - 特别留意：如果
mobile.css在桌面模式下也出现在列表里，说明它被其他地方（比如 JS 动态插入、或另一个无 media 的 link）引入了 - 禁用 JavaScript 后再测一次——有些框架（如 Next.js）会在客户端补全样式，掩盖服务端真实加载行为
最隐蔽的坑是构建工具自动注入 link 标签。比如 Vite 或 Webpack 的 HTML 插件可能把所有 CSS 当作 rel="stylesheet" 无条件插入，覆盖你手写的 media 属性。这时得查构建配置里是否有 inject: false 或手动控制 <link> 输出的开关。
