不能直接用 CSS 修改 picker 样式，因其在 iOS、Android、H5 和小程序中底层渲染机制不同，原生控件不支持样式覆盖且 mode="selector" 无法控制列宽、字体、高亮等细节；Pad 适配关键在于控制列数、滚动行为与点击热区，需手写基于 scroll-view 的自定义数字选择器。
直接用 picker 组件改样式行不通，必须自定义组件；Pad 适配关键不是加宽，而是控制列数、滚动行为和点击热区。
为什么不能直接 style 改 picker 的数字选择器
uni-app 的 picker 在各端底层渲染机制不同：iOS 和 Android 原生系统控件不支持 CSS 覆盖，H5 端虽能 hack 但样式不稳定，微信小程序里甚至会忽略大部分自定义样式。更关键的是，picker 的 mode="selector" 或 mode="multiSelector" 无法控制单列宽度、字体大小、选中高亮色块形状等细节——尤其在 Pad 上，原生 picker 会撑满全屏或比例失调，根本没法做“自定义风格”。
所以真实路径只有一条：手写一个基于 scroll-view + view 的数字滚动选择器，完全可控。
自定义数字选择器的核心实现要点
核心是模拟滚动惯性 + 视觉居中对齐 + 数值边界约束。不要用 picker-view，它同样受限且不支持 Pad 优化。
- 用
scroll-view的scroll-y+scroll-top控制滚动位置，配合bindscroll实时计算当前选中值 - 每项高度固定（比如
80rpx），总高度设为80rpx × 列数，让“视觉中心线”落在第 n 项中间 - 选中态用
transform: scale(1.1)+font-weight: bold实现，避免阴影或边框（Pad 触控精度低，边框易误触） - 初始值要通过
scroll-top计算偏移量设置，不能靠v-model绑定——否则 Pad 上首次打开会跳动 - 安卓低端机上禁用
scroll-with-animation，否则滚动卡顿明显；iOS 和 H5 可开启
Pad 设备的适配重点不是分辨率，而是交互逻辑
Pad 屏幕宽，但用户习惯用手指点选而非滑动长列表。直接把手机版数字选择器拉宽，会导致单列过长、滚动距离变大、误操作率飙升。
- 检测 Pad 设备用
uni.getSystemInfo判断windowWidth > 768，而不是查 UA 或设备名 - Pad 模式下改为「分页式」：每页显示 5～7 个数字，左右箭头切换，取消惯性滚动，用
button触发翻页 - 列宽从手机的
120rpx改为160rpx，文字大小从28rpx提到36rpx，留足点击热区 - 禁用
scroll-view的 bounce 效果（bounce="false"），Pad 上 bounce 会触发意外回弹 - 如果同时支持横竖屏，监听
uni.onWindowResize动态切换布局模式，而不是只 onload 判一次
容易被忽略的兼容细节
最常踩坑的地方不在样式，而在事件响应链和数值同步时机。
- Pad 上 touchstart/touchend 间隔可能超过 350ms，导致 click 事件失效——必须用
tap事件，且绑定在最外层容器，别套多层view - 修改
scroll-top后，需nextTick再读取实际滚动位置，否则 H5 端读到的是旧值 - 数字范围若含负数（如 -99 到 +99），注意
Math.round()在负数除法时的取整偏差，建议统一用Math.floor((scrollTop + itemHeight / 2) / itemHeight) - 微信小程序真机调试时，
scroll-view在 Pad 模拟器里表现正常，但实机（尤其是 iPadOS 17+）会出现滚动延迟，加style="will-change: scroll-position"可缓解
真正难的不是画出好看样式，而是让每一次滚动、点击、翻页在所有 Pad 型号上都给出确定反馈。做完之后，务必用 iPad Air 4、iPad mini 6、以及 Windows 的 PWA 模式跑一遍真实操作流。
