高清屏断点失效的根本原因是视口缩放失准，导致 media 查询的 width 值基于错误的 CSS 像素；混用 device-width 不可靠且不响应旋转；应优先使用 width/min-width/max-width 及 resolution/DPR 媒体特性，并验证 clientWidth 和 innerWidth 是否匹配设备逻辑宽度。
高清屏断点失效的根本原因不是像素密度，而是视口缩放失准
媒体查询的 width 和 max-width 判断依据是 CSS 像素（viewport width），不是物理像素。iPhone 14 Pro 的物理分辨率为 1170×2556，但其逻辑宽度（CSS 像素）是 390px —— 这个值由 <meta name="viewport"> 决定。如果 viewport 配置错误，比如漏了 initial-scale=1.0，iOS Safari 会自动缩放页面，导致 document.documentElement.clientWidth 返回 980 或 800 这类桌面级数值，所有 @media (max-width: 768px) 都不会触发。
@media 中混用 device-width 是高频陷阱
你可能见过这种写法：@media screen and (device-width: 375px)。它在部分安卓机上看似有效，但实际不可靠：device-width 指设备物理宽度（单位为 px），而媒体查询标准行为基于视口宽度（CSS 像素），且该特性在 Safari 中已被弃用、Chrome 仅作兼容保留。更糟的是，它不响应横竖屏切换 —— iPad 竖屏是 768px，横屏是 1024px，但 device-width 固定返回 768。
- 永远用
width/min-width/max-width，它们基于当前视口，可响应旋转和缩放 - 避免
device-width、device-height、orientation单独使用；如需方向判断，应组合：@media screen and (min-width: 768px) and (orientation: landscape) - 高清屏适配真正该关注的是
resolution或-webkit-device-pixel-ratio，例如：@media (-webkit-device-pixel-ratio: 2)用于加载 @2x 图片
真机调试时必须验证的两个 JS 值
别只信 DevTools 模拟器。在 iOS Safari 或安卓 WebView 中打开控制台，运行这两行：
console.log('clientWidth:', document.documentElement.clientWidth)
console.log('innerWidth:', window.innerWidth)
理想结果应接近设备逻辑宽度（如 iPhone 14 Pro ≈ 390，Pixel 7 ≈ 412）。若两者远大于此（如 980、1280），说明 viewport 标签未生效或被覆盖。常见干扰源包括：
立即学习“前端免费学习笔记（深入）”；
- 框架（Next.js、UniApp）自动生成了一条 viewport，你又手动加了一条，后加载的覆盖前一条
-
<meta>被插件或 CMS 插入到<style>标签之后 - 写了
user-scalable=no导致某些 X5 内核 WebView 降级为桌面渲染模式
选择器权重不足在高清屏上更易暴露
高清屏设备通常伴随更高 DPR（device pixel ratio），但 DPR 不影响 CSS 选择器权重。问题在于：很多项目默认样式用了 !important 锁定颜色、字体等，而媒体查询里只写 .nav a { color: #fff; } —— 在高密度屏幕上，用户更倾向放大文字，此时基础样式中带 !important 的规则更容易压过媒体查询。DevTools 里看到 color 被划掉，就说明这个现象正在发生。
- 检查目标元素的 Styles 面板，确认
color、font-size等是否被更高权重规则覆盖 - 媒体查询内提升特异性：把
.header .logo改成.header > .logo或body .header .logo - 禁用所有
!important，改用结构化类名和明确层级来管理优先级
高清屏本身不破坏媒体查询，破坏它的是 viewport 失准、选择器权重失控、以及对 device-width 的误用。最该盯住的永远是那两个 JS 值：clientWidth 和 innerWidth —— 它们才是媒体查询是否“看见”真实屏幕的直接证据。
