应以uni.getSystemInfoSync().windowWidth为依据动态适配：windowWidth
直接用 uni.getSystemInfoSync().windowWidth 判断设备宽度，比 UA 检测或 model 字符串匹配更可靠——iPad 的 windowWidth 通常 ≥768px，但要注意 mini 和 Pro 型号差异，不能只写死 768。
如何用 windowWidth 动态区分 iPad 类型
不同 iPad 屏幕物理尺寸接近，但逻辑分辨率差异大（如 iPad mini 是 768×1024，iPad Pro 12.9 是 1024×1366），windowWidth 才是布局决策的真实依据。关键不是“是不是 iPad”，而是“当前可用宽度是否支持分栏”。
windowWidth ：按手机处理（即使真机是 iPad，也可能在分屏/缩放模式下）768 ：视为标准 iPad 模式，适合双栏（如左导航 + 右内容）-
windowWidth >= 1024：倾向 PC 级宽屏逻辑，可启用三栏或浮动面板 - 避免用
res.model.includes('iPad')，因为某些 iPadOS 模拟器或折叠设备返回值不可靠
pages.json 中 leftWindow / rightWindow 的生效条件
leftWindow 和 rightWindow 不是“只要写了就显示”，它们依赖 matchMedia 配置和实际窗口尺寸。H5 和 App 端行为一致，但小程序端不支持这些配置项。
- 必须显式设置
"matchMedia": {"minWidth": 768}，否则默认不触发 -
minWidth单位是 px，不是 rpx，且基于浏览器视口或 native 窗口的windowWidth - 若同时配置了
leftWindow和rightWindow，它们会并排渲染，总宽度可能超出屏幕——需手动用style.width控制，例如"width": "280px"或"width": "calc(100vw - 400px)" - 隐藏 tabBar：用 CSS 选择器
.uni-app--showleftwindow + .uni-tabbar-bottom，而不是 media query
响应式类名 + CSS 媒体查询的混合用法
uni-app 支持媒体查询（H5、App 端），但小程序端不支持。所以不能只靠 @media，得配合动态 class 切换。
- 在
App.vue的onLaunch和onShow中调用uni.getSystemInfoSync()，把windowWidth存入全局状态（如uni.$appState或 Vuex） - 组件中用
:class="['container', widthClass]"，其中widthClass是 computed 返回的'sm'/'md'/'lg' - CSS 里仍可写
@media (min-width: 768px)作为 H5/App 的兜底样式，但核心布局逻辑必须由 class 控制 - 别忘了监听窗口变化：
uni.onWindowResize，尤其在 iPad 分屏拖动时会频繁触发
rpx 在 iPad 上的缩放陷阱
rpx 按照设计稿 750px 宽度换算，但在 iPad 上，750rpx 可能撑不满屏幕（比如 windowWidth=834 时，1rpx≈1.11px），导致留白或错位。
- 纯文字/图标类元素继续用
rpx没问题，它保证视觉比例一致 - 需要“占满可用宽度”的容器，改用
%或vw，例如width: 100%或max-width: 1200px - 字体大小慎用
rpx，iPad 上容易过小；建议用rem或em配合根字号动态调整 - 图片资源优先用矢量（SVG）或提供
@2x版本，rpx不解决像素密度问题
真正难的不是判断 iPad，而是同一套组件在 768px、1024px、1366px 下如何保持交互合理——比如抽屉菜单在窄屏是 overlay，在宽屏就得变成常驻侧边栏，这个切换点必须和 leftWindow 的 matchMedia 对齐，否则用户会看到两个导航同时存在。
