应以uni.getSystemInfoSync().windowWidth为依据动态适配：windowWidth<768按手机处理，768≤width<1024启用双栏，≥1024启用三栏或浮动面板，并配合matchMedia、动态class及vw/%单位规避rpx缩放问题。
直接用 uni.getSystemInfoSync().windowWidth 判断宽度，比 UA 检测或机型字符串匹配更稳——iPad mini 和 iPad Pro 的 windowWidth 都 ≥768，但真实可用宽度差一倍，布局决策必须基于这个值，而不是“是不是 iPad”。
如何用 windowWidth 动态区分设备类型
关键不是识别设备型号，而是判断当前窗口是否支持分栏。不同 iPad 的逻辑分辨率差异大（如 mini 是 768×1024，Pro 12.9 是 1024×1366），windowWidth 才是真实依据：
-
windowWidth < 768：按手机处理（即使真机是 iPad，也可能在分屏/缩放模式下） -
768 <= windowWidth < 1024：启用双栏（如左导航 + 右内容） -
windowWidth >= 1024：倾向 PC 级宽屏逻辑，可启用三栏、浮动面板或自定义rightWindow
别写死 res.model.includes('iPad')，某些 iPadOS 模拟器或折叠设备返回不可靠；也别只依赖 CSS 媒体查询，小程序端不支持 @media。
pages.json 中 leftWindow / rightWindow 怎么配才生效
leftWindow 和 rightWindow 不是“写了就显示”，它们依赖 matchMedia 配置和实际窗口尺寸：
- 必须显式设置
"matchMedia": {"minWidth": 768}，minWidth单位是 px（不是 rpx），基于 native 窗口的windowWidth - 若同时配置了
leftWindow和rightWindow，它们会并排渲染，总宽度可能溢出屏幕——需手动控制宽度，例如"width": "calc(100vw - 400px)"或固定"width": "280px" - 隐藏 tabBar：用 CSS 选择器
.uni-app--showleftwindow + .uni-tabbar-bottom { display: none; }，比 media query 更可靠且能联动
H5 和 App 端行为一致，但小程序端完全不支持这些配置项，这点容易被忽略。
rpx 在平板上为什么变“虚”或留白严重
rpx 按「屏幕宽度 / 750」等比缩放，只管横向比例，不感知物理尺寸、像素密度或安全区域：
- iPad Pro（1024px 宽）上，750rpx ≈ 75% 屏宽，右侧大片留白
- iPhone 5（320px 宽）上，750rpx 满屏，但字体小得看不清
- 高 DPR 安卓机上，rpx 渲染后边缘发虚，边框糊成一片
- 刘海屏、全面屏底部横条等安全区域，rpx 完全不避让
解决办法是组合使用：rpx 做基础缩放 + uni.getSystemInfoSync() 获取 pixelRatio 和 safeArea + 全局动态 class 控制容器级样式。例如在 App.vue 的 onLaunch 中存入 uni.$appState.windowWidth，组件里用 :class="['container', widthClass]" 切换布局。
横竖屏切换和键盘弹出时布局错乱怎么办
横屏不是“自动适配”，而是要主动监听并响应：
- 用
uni.onWindowResize监听窗口变化，尤其在 iPad 分屏拖动时，windowWidth实时变动，仅靠onLoad一次判断远远不够 - 键盘弹出时，
uni.getSystemInfoSync().windowHeight会骤减，但safeArea.bottom不更新——需结合uni.onKeyboardHeightChanged动态调整表单区域高度 - 横屏布局优先测试，很多 bug 只在
orientation: landscape下暴露，比如 flex 子项换行异常、绝对定位偏移错位
真正麻烦的不是初始适配，而是窗口尺寸在运行时动态变化——分屏、多任务、虚拟键盘、系统横竖屏强制锁定，这些场景下硬编码的宽度或媒体查询都会失效。
