ipad适配需放弃固定宽度断点，转而用hover: hover和pointer: fine等能力检测组合判断真实设备能力，配合javascript动态响应分屏与折叠状态。
纯靠 @media (min-width: 768px) 拦不住 iPad 的真实行为——它可能在分屏里缩成 400px，也可能展开后宽达 1200px 却仍被识别为“手机”，微调必须绕过像素陷阱，直击设备能力。
为什么 @media (min-width: 768px) 在 iPad 上经常失效
这个断点源自 2010 年 iPad 第一代竖屏逻辑像素（1024×768），但今天它已严重失准：同一台 iPad 开启 Slide Over 后 window.innerWidth 可能只剩 540px；启用系统字体放大后，768px 断点提前触发；折叠屏展开后视口超 1200px，但 screen.width 仍返回 810px。本质问题在于：媒体查询匹配的是 CSS 像素宽度，不是设备类型，更不反映是否支持悬停或精细指针。
用 hover 和 pointer 组合精准锁定 iPad 真实能力
iPadOS 15+、iOS 16+ 已稳定支持 hover: hover 和 pointer: fine，这是比宽度靠谱得多的信号。它们能区分出“可悬停 + 可精细操作”的真实平板/桌面环境，自动过滤掉绝大多数触屏手机。
-
@media (min-width: 768px) and (hover: hover)：启用侧边栏、悬停菜单、工具提示等 PC 类交互样式 -
@media (min-width: 768px) and (pointer: fine)：适配 Apple Pencil 或鼠标下的按钮间距、图标尺寸、拖拽反馈 -
@media (min-width: 1024px) and (orientation: landscape) and (display-mode: browser)：专为 iPad 横屏全屏浏览器场景优化主内容区留白和行高
避开 Bootstrap 默认断点与 iPad 视口错位的坑
Bootstrap 的 sm（≥576px）、md（≥768px）断点是按“宽度区间”设计的，而 iPad 的视口宽度浮动极大。直接覆盖 .col-md-6 可能导致分屏下卡片堆叠异常，或横屏时列宽过窄。
- 不要重写整个栅格类，优先加一层 wrapper class：
.ipad-layout .col-md-6，再用媒体查询局部修正 - 对关键容器（如
.container）用max-width限宽：@media (min-width: 768px) and (hover: hover) { .container { max-width: 960px; } }，避免横屏拉伸过度 - 慎用
.d-md-block这类工具类——分屏下md断点可能误触发，改用.d-tablet-block自定义类 + 能力型媒体查询控制
必须配合 JavaScript 动态响应分屏与折叠状态
CSS 媒体查询无法监听分屏开启/关闭、折叠屏展开/收拢这类运行时变化。仅靠静态断点，iPad 用户切出 Slide Over 后布局就卡死在窄屏状态。
- 监听
window.matchMedia("(display-mode: browser)")，在matches === true时补上.in-browser-modeclass - 对
resize事件做节流，检查window.innerWidth是否落在 600–800px 区间（典型 Slide Over 宽度），动态切换布局紧凑模式 - 折叠屏需额外检测
screen.orientation.type和screen.availWidth，不能只信matchMedia
真正难的不是写对一行 @media，而是接受 iPad 不是一个“固定尺寸设备”，而是一组动态能力组合。你得放弃“适配 iPad”这个念头，转而适配“可悬停 + 可精细操作 + 视口 ≥768px + 浏览器全屏”这一串条件——漏掉任意一个，布局就可能在某个用户手上突然崩掉。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
