断点不触发的根本原因是 viewport 标签未生效，导致视口宽度异常（如 980px），进而使媒体查询失去依据；应通过 document.documentElement.clientWidth 和 window.matchMedia 直接验证真机视口与断点匹配情况。
断点不触发，先查 document.documentElement.clientWidth
在 iPad Safari 中打开控制台，运行：console.log(document.documentElement.clientWidth)
若返回值不是约 768（竖屏）或 1024（横屏），而是 980、1280 或其他远大于设备逻辑宽度的数，说明 viewport 标签根本没生效。这不是媒体查询写错了，是它运行的“地基”塌了。
- 常见干扰源：Next.js 或 UniApp 框架自动生成一条
，你又手动加了一条，后加载的覆盖前一条 -
被 CMS 插件塞到了标签之后，浏览器忽略 - 写了
user-scalable=no，某些 X5 内核 WebView 会降级为桌面渲染模式，视口直接按 980px 处理
@media (min-width: 768px) 在 iPad 横屏下不生效？别信 device-width
device-width 返回的是设备物理宽度（单位 px），且不响应旋转——iPad 竖屏横屏都返回 768，无法区分方向。更关键的是，Safari 已弃用该特性，Chrome 仅作兼容保留，行为不可靠。
- 正确做法：只用
width、min-width、max-width，它们基于当前视口，旋转时自动重匹配 - 横屏失效常因系统字体放大或浏览器缩放导致视口变窄，比如实际
innerWidth只有 912px，@media (min-width: 1024px)就不会触发 - 如需方向判断，必须组合：
@media (min-width: 1024px) and (orientation: landscape)，单独用orientation也不保险（kiosk 模式可能锁死方向）
真机调试时，window.matchMedia 比 DevTools 更可信
Chrome DevTools 的模拟器默认补全 viewport 行为，即使你 HTML 里漏了 viewport，它也会“假装”正常。但真机不会宽容。
- 在 iPad Safari 中执行：
window.matchMedia('(min-width: 768px)').matches，直接看布尔结果，比肉眼观察样式是否生效更准 - 对分屏敏感的场景，加一层检测：
window.matchMedia('(display-mode: browser)')，iPad 的 Slide Over 和 Split View 会返回false - 避免在组件级 SCSS/Less 中分散写
@media，同一断点在多个文件里重复声明，构建后冗余 CSS + resize 时反复重算，容易卡顿
断点数值别抄参数表，从你自己的布局里“找坍塌点”
iPad Pro 12.9 英寸横屏逻辑宽度是 1024px，但 Surface Go 是 834px，安卓平板分屏后可能只剩 540px。硬套 768/1024，等于拿一把尺子量所有人的手，还指望它永远贴合。
- 打开 DevTools → 设备工具栏 → 拖动宽度滑块，盯住你页面的真实变化点：
导航栏文字换行处、卡片从单列变双列处、侧边栏能稳定塞下的最小宽度 - 优先交叉验证能力而非尺寸：
@media (min-width: 768px) and (hover: hover)排除纯触屏手机，@media (min-width: 768px) and (pointer: fine)专为带 Apple Pencil 或鼠标设备启用精细样式 - 安卓 Pad 上慎用 dp 换算：Web 环境无原生 dp 支持，1dp ≈ 1px 的假设在高 DPI 屏上直接崩盘
实际项目里最易被忽略的，是把 viewport 当成“写了就完事”的装饰标签。它一旦失效，后面所有媒体查询都在真空里跑。真机上跑一遍 clientWidth 和 matchMedia，比调十次 CSS 选择器权重更接近问题本质。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
