根本原因是iPad分屏时视口宽度被系统动态压缩至320–600px，导致@media (min-width: 768px)无法触发，应改用min-aspect-ratio断点、JavaScript动态校验及弹性布局协同应对。
iPad分屏模式下CSS响应式布局错乱，根本原因不是断点写错了，而是视口宽度被系统动态压缩（常缩到320–600px），而你写的@media (min-width: 768px)根本没机会触发——它等的768px永远不到。
为什么@media (min-width: 768px)在分屏里完全失效
iPad分屏时，系统把App窗口当成一个“窄视口”分配，哪怕设备是12.9英寸，window.innerWidth也可能只有540px。此时@media (min-width: 768px)不会匹配，所有为平板设计的样式都被跳过，页面退化成手机样式，侧边栏消失、网格坍缩、字体过小。
- 分屏不是“设备类型变化”，而是“视口尺寸重定义”，媒体查询只认
innerWidth，不认设备物理尺寸 -
UIRequiresFullScreen: YES（旧版iOS App常见）会强制全屏渲染，导致分屏时触发兼容性缩放，进一步扭曲CSS计算 - 仅靠
device-width或orientation: landscape判断毫无意义——分屏下orientation仍返回portrait，device-width仍是1024
用min-aspect-ratio替代width断点来捕获分屏场景
分屏窗口虽然窄，但宽高比往往仍大于1（比如540×680 → aspect-ratio ≈ 1.26）。比起死守像素值，用宽高比更贴近真实分屏行为。
- 改用
@media (min-aspect-ratio: 1.2/1)代替@media (min-width: 768px)，能覆盖多数分屏窗口（包括Slide Over和Split View） - 避免
@media (orientation: landscape)——它在分屏下几乎不触发，iOS 15+中已被证实不可靠 - 组合使用更稳妥：
@media (min-aspect-ratio: 1.2/1) and (hover: hover)，既过滤纯触屏手机，又确保有悬停能力（iPad + 鼠标/Pencil）才启用侧边栏等复杂布局
必须配合JavaScript动态校验初始状态
CSS媒体查询在分屏窗口首次打开时可能延迟触发，或因快速拖拽错过事件。只靠CSS会漏掉“刚进分屏就横屏”的情况。
立即学习“前端免费学习笔记（深入）”；
- 用
window.matchMedia('(min-aspect-ratio: 1/1)')监听，而非废弃的orientationchange - 在
resize事件中加防抖（如300ms），并手动执行一次matches检查，防止直出页面样式错位 - 把状态挂到
上（如class="is-split-view"），避免框架接管后样式失效 - 首次加载立即运行：
if (matchMedia('(min-aspect-ratio: 1.2/1)').matches) { document.documentElement.classList.add('is-split-view'); }
Flex/Grid容器在分屏下容易撑破布局的硬伤
分屏窗口高度有限，但默认flex-direction: column或grid-template-rows: 1fr会让内容无限拉伸，触发滚动条或溢出。
- 给父容器加
max-height: 100vh和overflow-y: auto，而不是依赖height: 100% - Grid列数别写死：
grid-template-columns: repeat(auto-fit, minmax(280px, 1fr))比repeat(3, 1fr)更适应分屏宽度波动 - 图片/卡片务必设
max-width: 100%和height: auto，否则分屏缩放时会撑破容器 - 慎用
vh单位——分屏下地址栏可能隐藏，100vh实际高于可视区，改用dvh（100dvh）或min(100vh, 100dvh)
最易被忽略的是：分屏不是“另一种屏幕尺寸”，而是“同一页面在不同窗口约束下的实时重排”。你写的每一条flex、grid、font-size规则，都得经受innerWidth在320–1024px之间频繁跳变的考验——靠静态断点兜不住，必须用宽高比+JS校验+弹性容器三者咬合。
