原生picker无法修改上下蒙层颜色，因蒙层由原生控件绘制，uni-app无js干预权限；须用scroll-view手动模拟滚动，并严格统一item_height、防抖处理、nexttick更新及三端差异化适配。
为什么原生picker无法改上下蒙层颜色
uni-app 的 picker 和 picker-view 组件在微信小程序、iOS App 等端侧，**不支持修改指示器上下蒙层（遮罩）的背景色或透明度**。这不是配置遗漏，而是底层渲染限制——蒙层由原生控件绘制，uni-app 无 JS 层干预权限。试图用 CSS 覆盖 .uni-picker__mask 或伪元素，真机上完全无效。
用 scroll-view + 手动滚动逻辑替代 picker-view
要真正控制样式（比如深色主题下蒙层变半透黑、选中线粗细/颜色、文字高亮），必须放弃 picker-view，改用 scroll-view 模拟滚动。核心是：固定每项高度、计算 scrollTop、监听滑动结束而非实时 change。
-
ITEM_HEIGHT必须与 CSS 中.mp-item的行高严格一致（如34px），否则滚动错位 - 每列
scrollTop=current[index] * ITEM_HEIGHT，且需在onScrollEnd中四舍五入取整，避免 iOS 滑动惯性导致小数偏移 - 不要在
@scroll里频繁setData，只在@scrollend触发一次校准和回填 - 所有
range数据必须是纯字符串数组（如["北京", "上海"]），含对象会触发 iOS 渲染白屏
三端适配的关键坑点
H5、微信小程序、App 端对滚动模拟的容忍度差异极大，稍不注意就卡顿或错位：
- 安卓真机：单列超过 200 项时
scroll-view渲染极慢，必须截断并加"更多…"占位项，点击后动态加载 - iOS 微信：
scroll-with-animation在快速滑动时易丢帧，建议关闭动画（:scroll-with-animation="false"），靠视觉惯性补偿 - H5 端：
scroll-view不支持scroll-top动态设置？得用this.$nextTick(() => this.scrollTop = xxx)才能生效 - 所有端：禁止在滚动回调里发起异步请求（如按需拉市区列表），必须提前加载完整树形数据，运行时只做数组过滤
防抖 + nextTick 是滚动同步的底线
用户快速滑动时，iOS 微信会高频触发 @scrollend，若每次都在回调里直接 setData 更新 current 和显示文本，UI 会明显滞后甚至回弹异常。
- 加 100ms 防抖：用
clearTimeout(this.timer)+this.timer = setTimeout(...) - 滚动定位必须等 DOM 更新完成：H5 和部分小程序需
this.$nextTick(() => { this.current = newIndex; this.$forceUpdate(); }) - 别用
v-model绑定scroll-view，它不兼容手动scrollTop控制
样式可定制，但滚动逻辑必须亲手掐住节奏——真机上没“差不多”，只有“对”或“卡死”。
