Pad端布局需以uni.getSystemInfoSync().windowWidth≥768为判断依据，手动设阈值、分场景适配；rpx基准设为768，字体起步40rpx，侧边栏替代tabBar，横屏必测。
直接用 uni.getSystemInfoSync() 拿窗口宽度，结合 CSS 媒体查询和条件渲染，就能稳住 Pad 端布局。别信“一套代码全自动适配”的说法——真实项目里，必须手动设阈值、分场景、做降级。
怎么判断是不是 Pad 设备
不能只看 UA 或设备型号，得用运行时真实尺寸：
-
uni.getSystemInfoSync().windowWidth是唯一可靠依据，H5、小程序、App 三端都返回一致的逻辑像素宽度 - Pad 的典型阈值是
windowWidth >= 768 && windowWidth ；PC 端则 ≥1024；移动端默认兜底 - 别在
onLoad里直接赋值this.isTablet，要等onReady后再触发重绘，否则首屏可能闪动或错位 - 如果用 Vue 3 setup 语法，建议封装成
useDeviceType()组合式函数，避免每个页面重复写判断逻辑
Flex 分栏布局为什么比 CSS Grid 更稳妥
Grid 在 H5 没问题，但在微信小程序基础库 grid-template-columns: repeat(auto-fill, minmax(...)) 会直接失效，整块内容塌陷。
- 推荐用 Flex 手动分组：比如 12 条数据分 3 列，就用
Array.from({ length: 3 }, (_, i) => list.filter((_, idx) => idx % 3 === i)) - 外层
display: flex，每列加flex: 1和flex-direction: column，列高自动撑开，不会因某列内容多而拉低其他列 - iOS 微信小程序对
flex-wrap: wrap+ 百分比宽度计算有精度误差，最后一列常被挤到下一行，必须避开 - 列间间距用
gap？旧版小程序不支持，改用margin-right，并用:nth-last-child(1)清除最后一列的 margin
rpx 单位在 Pad 上容易翻车的点
rpx 默认按 750 设计稿等比缩放，但 Pad 屏幕宽常达 1200+ 逻辑像素，750rpx 就会远超实际可视区，导致元素溢出或文字过小。
- 在
pages.json中强制约束 rpx 计算基准："rpxCalcMaxDeviceWidth": 768，让 Pad 设备也按 768 基准换算，而不是按它自己的大宽度 - 字体大小别全用
32rpx，Pad 端建议用40rpx起步，图标至少48rpx - 点击区域不能只靠
padding: 20rpx，要确保物理尺寸 ≥ 44px，可加min-height: 44px保底 - 媒体查询里写
@media (min-width: 768px)没用——uni-app 的 rpx 媒体查询实际作用于设计稿宽度，不是设备逻辑像素，得配合 JS 动态 class 切换
导航与交互在 Pad 上必须改什么
底部 tabBar 在 Pad 上空间浪费严重，且手指操作效率低；侧边栏才是合理选择。
- 在
pages.json中把 Pad 页面的tabBar配置关掉，用custom: true+ 自定义组件替代 - 侧边栏不要用绝对定位硬塞，要用
flex: 0 0 240px固定宽度 + 主内容flex: 1，横屏时也能自适应 - 表单输入框高度至少
80rpx，行高匹配，iOS 键盘弹起时要监听keyboardHeight动态上推内容区 - 手势滑动（如左右切页）必须加
touch-action: pan-y，否则在 Pad Chrome 里容易触发页面滚动干扰
最易忽略的是横屏测试——很多团队只测竖屏 Pad，结果横屏时 media 查询没生效、flex 方向没反转、侧边栏被压扁。上线前务必在真机横屏下跑一遍核心流程。
