最可靠方式是html中用的media属性加载css，如
用 <link> 的 media 属性加载不同 CSS 文件最可靠
直接在 HTML 中用 <link rel="stylesheet" href="mobile.css" media="(max-width: 768px)"> 是唯一被所有现代浏览器（包括 iOS Safari、Chrome Android）稳定支持的方式。CSS 里的 @import 不支持媒体查询条件——写 @import url("mobile.css") screen and (max-width: 768px); 会被忽略或报错，且无条件加载文件。
常见错误现象：样式在小屏设备上没生效，但 Network 面板里发现两个 CSS 都下载了——这说明 media 属性只控制“是否应用”，不阻止下载（除非配合 rel="preload" + JS 动态切换）。
- 移动端
<link>必须放在 PC 端之前，避免某些旧版 WebView 优先解析后一个 - 断点别重叠：
max-width: 768px和min-width: 769px才能严丝合缝；写成min-width: 768px会导致 768px 宽度设备同时匹配两个规则 - 媒体类型可省略：
media="(max-width: 768px)"比media="screen and (max-width: 768px)"更简洁，效果一致
@media 写在单个 CSS 文件里才是默认推荐方案
绝大多数项目不该拆 CSS 文件。把移动端基础样式写在前面，PC 增强部分用 @media (min-width: 769px) 包裹，结构清晰、首屏关键 CSS 易提取、维护成本低。
容易踩的坑：有人先写 PC 样式再用 @media (max-width: 768px) 覆盖，结果小屏下因选择器权重或声明顺序出问题；移动优先才是正解。
- 默认样式（手机）直接写，不包
@media - 平板及以上用
@media (min-width: 768px)，桌面用@media (min-width: 1024px)，逐级增强 - 避免用
max-width做主断点——折叠屏横屏时宽度可能突然跳变，min-width更稳定
需要彻底分离 DOM 或样式逻辑时，别只靠 @media
如果移动端要删侧边栏、PC 端要加悬浮菜单，或者组件渲染结构完全不同，纯 CSS 媒体查询解决不了——它只能控制已有元素的显示/隐藏或样式，不能删节点、也不能绕过权重冲突。
这时候得物理分离：服务端识别 UA 注入 html.mobile 或 html.pc 类，再用 html.mobile .header 和 html.pc .header 写隔离样式；或者用构建工具按环境变量 import 不同 CSS。
- SSR 场景下，客户端 JS 判断
navigator.userAgent可能首次渲染错配 -
@media规则全部打进同一个 CSS 文件，白屏时间长，关键 CSS 提取困难 - DOM 差异大时，用媒体查询强行共用类名，后期调试会反复陷入“为什么这个 transform 还在生效”的陷阱
补充：用 prefers-color-scheme 或 hover 辅助判断设备能力
仅靠宽度判断太粗糙。比如 iPad 横屏时宽度超 1024px，但实际是触摸设备；又比如某些 Windows 平板既支持触控又支持鼠标悬停。这时可以叠加其他媒体特性提升准确性。
示例：@media (min-width: 769px) and (hover: hover) 表示“大屏且支持悬停”，适合展示 PC 特有交互；@media (prefers-color-scheme: dark) 可单独加载深色主题变量。
-
hover: hover比pointer: fine兼容性更好（iOS 13.4+ 才支持后者） -
prefers-color-scheme在 iOS Safari、Chrome、Firefox 中均已稳定支持，适合渐进增强 - 别用
orientation做主要断点——横竖屏切换频繁，且折叠屏展开后 orientation 可能不变但宽度剧增
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
