移动端CSS引入最稳妥方式是link标签配合media属性，需搭配viewport元标签，使用明确像素断点（如max-width:480px），避免device-width，确保互斥覆盖且支持all回退。
移动端 CSS 引入方式：link 标签 + media 属性最稳妥
直接在 <head> 里用 <link> 加载样式，并通过 media 属性控制加载时机，是移动端响应式最可靠的方式。它比在 CSS 里写 @media 更早介入渲染流程，能避免「闪屏」或「先大屏后缩放」问题。
常见错误是把 media 写成 screen and (max-width: 768px) 却没加 viewport 元标签，导致移动端根本不会触发该断点——因为默认视口宽度远大于 768px。
-
<meta name="viewport" content="width=device-width, initial-scale=1">必须存在，否则media查询基于桌面视口计算 -
media值推荐用screen and (max-width: 480px)、screen and (min-width: 768px)这类明确像素值，避免用handheld（已废弃）或模糊的only screen - 多个
<link>可共存，浏览器只下载并应用匹配的那一个，未匹配的不会请求 CSS 文件（注意：IE9 及以下会预加载所有link，但现代移动端无需考虑）
@media 查询写在 CSS 文件里 vs 外链 link 的区别
写在 CSS 文件里的 @media 是「条件应用」，文件本身总会被下载；而 <link media="..."> 是「条件加载」，不匹配时整个文件不会发起 HTTP 请求。这对首屏性能影响显著。
例如你有三套样式：desktop.css、tablet.css、mobile.css，用外链方式可这样组织：
立即学习“前端免费学习笔记（深入）”；
<link rel="stylesheet" href="desktop.css" media="screen and (min-width: 1024px)"> <link rel="stylesheet" href="tablet.css" media="screen and (min-width: 768px) and (max-width: 1023px)"> <link rel="stylesheet" href="mobile.css" media="screen and (max-width: 767px)">
注意：媒体查询条件必须互斥且覆盖完整，否则可能漏掉某类设备；也别用 max-device-width，它依赖物理分辨率，在高 DPR 屏幕（如 iPhone）上极易误判。
media 属性中常用且安全的断点值怎么选
不要硬套「iPhone 6 宽度是 375px」这种说法。实际应以内容承载能力为依据，而非设备型号。主流做法是采用渐进式断点，从移动优先出发：
-
max-width: 480px：窄屏手机（小屏 Android / 竖屏 iPhone） -
min-width: 481px和max-width: 767px：宽屏手机 / 小平板竖屏 -
min-width: 768px：平板及以上（iPad 竖屏起始） - 避免使用
device-width或orientation做主断点，它们触发不稳定，且横竖屏切换时容易造成样式抖动
如果项目需支持微信内置浏览器或某些安卓 WebView，建议在 media 中加上 all 回退项：<link rel="stylesheet" href="base.css" media="all">，确保基础样式始终生效。
Chrome DevTools 模拟时 media 不生效？检查这三点
调试时发现 <link media="..."> 没加载，不是代码写错，大概率是环境问题：
- DevTools 的 device toolbar 开启后，页面宽度是模拟的，但
media查询仍以window.innerWidth为准——所以要手动调整窗口宽度，或勾选「Disable cache」再刷新 - 部分旧版 Chrome（≤80）对
media动态变更支持不全，改完 HTML 后务必硬刷新（Ctrl+Shift+R），不能仅靠 F5 - 如果用了
rel="preload"提前加载某个 CSS，又同时写了media，可能导致预加载与媒体条件冲突，此时应改用rel="stylesheet"并依赖原生 media 控制
真机测试永远比模拟器可靠，特别是涉及 DPR、缩放、输入法弹出等场景——这些都会间接影响视口宽度计算，而这是 media 查询的根本依据。
