link标签的media属性是唯一被所有现代浏览器稳定支持的条件引入方式，其他方法如@import带媒体条件基本不可靠；它通过media="(max-width: 768px)"等控制样式是否应用但不阻止下载，且移动端link须置于PC端之前以避免旧WebView误用；@import不支持媒体查询条件，会无条件加载文件；单CSS文件+移动优先@media才是推荐方案，仅在需物理分离DOM或样式逻辑时才考虑服务端UA识别或构建时环境变量分离。
link 标签的 media 属性是唯一被所有现代浏览器稳定支持的条件引入方式，其他方法（如 @import 带媒体条件）基本不可靠。
用 link 的 media 属性加载不同 CSS 文件
直接在 <head> 里写多个 <link rel="stylesheet">，靠 media 控制是否生效：
-
media="(max-width: 768px)"匹配手机，media="(min-width: 769px)"匹配桌面，两者必须严丝合缝——不能都写768px，否则宽度恰好为 768px 的设备会同时匹配两个规则 -
media只决定样式是否“应用”，不阻止下载：Network 面板里能看到两个 CSS 都发起了请求，哪怕当前视口只满足其中一个条件 - 移动端的
<link>必须放在 PC 端之前，某些旧版 WebView（如 Android 4.4 内置）会优先解析后一个，导致小屏下误用 desktop.css - 媒体类型可省略：
media="(min-width: 769px)"和media="screen and (min-width: 769px)"效果一致，前者更简洁
@import 不支持媒体查询条件
下面这行代码会被忽略或报错，且仍会无条件加载文件：
@import url("mobile.css") screen and (max-width: 768px);原因很简单：@import 是 CSS 规则，不是 HTML 标签，它不参与媒体条件判断。浏览器一旦解析到 @import，就会立即发起请求，不管后面跟没跟 screen and ...。
立即学习“前端免费学习笔记（深入）”；
- 即使语法看似合法，实际行为是：文件照下，但样式不生效；或者干脆被当作无效语句跳过
- 无法用于响应式拆分，也不推荐用于任何生产环境的条件加载场景
单 CSS 文件 + 移动优先的 @media 才是默认推荐方案
绝大多数项目不该拆成多个 CSS 文件。把基础样式（手机）直接写在最前面，PC 增强部分用 @media (min-width: 769px) 包裹：
/* mobile-first 基础样式 */
.header { padding: 12px; }
.nav a { display: block; }
<p>/<em> desktop-only 增强 </em>/
@media (min-width: 769px) {
.header { padding: 24px 40px; }
.nav a { display: inline-block; margin-right: 20px; }
}- 首屏关键 CSS 更容易提取和内联，避免 FOUC 或白屏延迟
- 避免因选择器权重、声明顺序或重复定义引发的小屏样式覆盖失败问题
- 折叠屏横屏时宽度可能突然跳变，
min-width比max-width更稳定
需要物理分离 DOM 或样式逻辑时，别只靠 @media
如果移动端要删侧边栏、PC 端要加悬浮菜单，或者组件渲染结构完全不同，纯 CSS 媒体查询解决不了——它只能控制显示/隐藏，不能删节点、也不能绕过权重冲突。
- 服务端识别 UA 注入
<html class="mobile">或<html class="desktop">，再用.mobile .sidebar { display: none; }隔离样式 - 构建时按环境变量
import不同 CSS，比如process.env.TARGET === 'mobile' ? './mobile.css' : './desktop.css' - 客户端 JS 判断
navigator.userAgent可能首次渲染错配，SSR 场景下尤其危险
真正麻烦的从来不是怎么写断点，而是当设计师说“这个按钮在 iPad 上要右对齐、在 Mac 上要居中、在 iPhone 上要隐藏”时，你得立刻判断：这是纯样式差异，还是 DOM 结构已经不同。后者必须跳出 CSS 媒体查询的边界去处理。
