uni-app中picker原生region模式不支持可控三级联动，应改用multiselector配合三层嵌套数组数据，并在bindchange中手动同步索引、分步懒加载数据以确保兼容性与性能。
uni-app 里 picker 原生组件不支持三级联动，硬套会卡死或选错
uni-app 的 picker 组件在 H5 和小程序平台行为不一致：H5 下 mode="region" 只能两级（省+市），且无法控制第三级（区）是否显示；微信小程序虽默认三级，但数据源固定、不能自定义（比如去掉“市辖区”这类冗余项），更没法对接你自己的行政区划接口。直接写 <picker mode="region"></picker> 看似省事，实际上线后常出现用户选了“北京市→朝阳区”，结果回显成“北京市→北京市→朝阳区”——因为原生 region 模式把直辖市的“市”和“区”叠了两层。
用 mode="multiSelector" + 自定义数据才是可控方案
真正能稳定跑通三级联动的，是放弃 mode="region"，改用 mode="multiSelector" 配合三列数组数据。关键点在于：数据必须提前按「省→市→区」层级拉平为三个独立数组，且每列的索引变化要能联动更新下一级选项。
- 第一列（省）数据格式：
["北京市", "上海市", "广东省"] - 第二列（市）必须是二维数组：
[["北京市"], ["上海市"], ["广州市", "深圳市", "珠海市"]]，索引需与省列对齐 - 第三列（区）是三维数组：
[[["东城区", "西城区"]], [["黄浦区", "徐汇区"]], [["天河区", "福田区"], ["南山区", "宝安区"], ["香洲区"]]] - 每次
@change触发时，只取当前列选中索引，再用它去查下一级数组，不能直接监听 value 数组全量变化，否则 iOS 下容易丢帧
bindchange 里手动同步三级索引，别信 value 初始值
很多人以为给 picker 的 value 属性传个 [0, 0, 1] 就能默认选中“北京→北京→西城区”，其实不行。iOS 微信小程序里 value 只在初始化时生效一次，后续 setData 不会重置滚动位置；H5 下甚至可能完全忽略。真实做法是：在 bindchange 回调里，根据当前 detail.value 数组，重新计算并更新 this.provinceIndex、this.cityIndex、this.districtIndex 三个响应式变量，再用它们驱动下一级数组渲染。
常见错误现象：console.log(detail.value) 打出来是 [0, 1, 0]，但页面上第二列还停在索引 0 —— 因为你没在回调里立刻 this.setData({ cityIndex: 1 })，导致视图未同步。
性能敏感点：区级数据超 200 条时必须做懒加载
像广东、河南这种省份，区县级单位动辄 100+，如果一次性把全部三级数据塞进页面 data，H5 下内存飙升，小程序里首次渲染延迟明显。正确做法是：省级数据始终加载，市级数据在省选择后异步拉取，区级数据在市选择后再拉取，并加 loading 状态防重复触发。注意 uni.request 成功后，必须用 setTimeout(() => { this.setData(...) }, 0) 包一层，否则某些安卓机上 picker 列不会自动刷新。
别碰 picker-view 自己手写滚动逻辑——兼容性坑比收益多，尤其 iOS 15+ 对 touch 事件拦截变严格，容易滑不动或跳项。
