应采用服务端识别设备并注入html.pc/html.mobile类，再配合独立CSS文件实现物理分离，而非仅依赖@media查询，因其无法解决DOM结构差异、权重冲突及SSR错配问题。
怎么让同一份 CSS 在 PC 和手机上走不同样式路径
靠 @media 做响应式是常见做法，但真要彻底分离 PC 与移动端样式（比如完全不同的布局结构、组件实现），硬塞进一个文件里维护成本高、调试混乱。更稳妥的方式是「物理分离」：用不同入口或条件加载不同样式表。
- PC 端加载
style.pc.css，移动端加载style.mobile.css，通过 JS 或服务端判断设备类型后动态插入<link> - 如果用构建工具（如 Webpack/Vite），可在入口 JS 中根据
navigator.userAgent或服务端透出的环境变量决定 import 哪个 CSS 文件 - 注意：纯客户端判断有缺陷——SSR 场景下首次渲染可能错配，且 UA 可伪造；更稳的做法是服务端识别设备并注入 class 到
标签，再用html.pc .header/html.mobile .header这类选择器做样式隔离
为什么不能只靠 max-width 媒体查询做彻底分离
因为 @media (max-width: 768px) 这类规则本质是“叠加”而非“替换”。一旦 PC 样式写在前面，移动端样式写在后面，就容易出现权重冲突、意外继承、伪类状态错乱等问题，尤其在复杂组件中调试成本陡增。
- 例如：PC 版
.modal是居中浮层，移动端想改成全屏覆盖，但若共用类名，transform: translate(-50%, -50%)和width: 100vw; height: 100vh会互相干扰 - 媒体查询无法解决 HTML 结构差异——比如 PC 用
<aside></aside>做侧边栏，移动端直接删掉该节点，CSS 再怎么写也盖不住 DOM 缺失 - 打包时所有媒体查询样式仍会打进同一个 CSS 文件，白屏时间长、首屏关键 CSS 提取困难
link[rel="stylesheet"] 的 media 属性能替代 JS 加载吗
可以，但仅限简单场景。HTML 原生支持 <link media="screen and (min-width: 769px)" href="pc.css">，浏览器会按条件下载对应资源。
- 优点：无需 JS，语义清晰，兼容性好（IE9+）
- 缺点：不支持运行时切换（比如用户手动切“桌面版”按钮）、无法配合 SSR 做服务端精准下发、部分低版本 Android WebView 对
media属性解析不准 - 更重要的是：它只是“不应用”，不代表“不下载”——Chrome 会预加载所有
<link>，即使media不匹配，带宽和解析开销仍在
移动端样式被 PC 样式覆盖的典型错误现象
最常出现在开发者写了 PC 专用样式后，忘了给移动端加足够强的选择器权重，或者漏写了 !important（虽然不推荐，但在强覆盖场景有时不得不加）。
立即学习“前端免费学习笔记（深入）”；
- 错误示例：
.btn { padding: 12px; } @media (max-width: 768px) { .btn { padding: 8px; } }—— 看似合理，但如果 PC 样式来自第三方库且用了.btn.primary:hover这种高权重要求，移动端规则就可能失效 - 更隐蔽的问题：CSS 自定义属性（
--color-primary）在 PC 文件里定义，在移动端文件里没重置，导致颜色/间距沿用 PC 值 - 检查方法：打开移动端 DevTools，选中元素，看右侧 Styles 面板里哪些规则被划掉（strikethrough），点开被划掉的规则，看“Computed”里最终生效值从哪来
