uni-app中城市三级联动搜索需用input监听输入+uni.request动态获取数据并更新picker的range，而非依赖picker自身；watch需deep: true或改用computed；请求要防抖、加标识、禁用交互；ios点不动多因z-index或touch遮挡。
uni-app里怎么用picker实现城市三级联动搜索
不能直接靠picker自己完成“搜索+级联”，它只负责选择，不带过滤和动态加载逻辑。真要搜着选，得自己搭一层输入框 + 下拉列表 + 异步数据流。
常见错误是把picker当搜索框用，输几个字就期望自动跳转到对应省市区——它根本不响应input事件，也没filter属性。
- 正确做法：用
input组件监听用户输入，触发uni.request查接口（比如传关键词"北京"，后端返回含“北京”的省/市/区数组） - 拿到结果后，手动构造
columns结构塞进picker的range，再showPicker = true唤出选择器 - 注意兼容性：
picker在App端支持多列联动，但H5端默认是单列滚动，得用mode="multiSelector"并配range-key才生效
uni-app中watch监听级联字段为什么总延迟或失效
因为watch对深层对象属性（比如form.province）默认不深度监听，改了值但没触发回调，看起来像“卡住”了。
典型场景：选完省份后，想自动清空已选的城市和区，但watch: { 'form.province'() {...} }没反应。
- 必须显式加
deep: true，且监听目标要是响应式数据（定义在data()里，别放const外面） - 更稳妥的做法是用
computed生成依赖链：比如cityList依赖selectedProvince，areaList依赖selectedCity，UI层直接绑定计算属性，比watch更可靠 - 小程序平台（尤其是微信）对
watch嵌套层级敏感，超过2层可能丢变更，建议拆成平级字段：provinceCode、cityCode、areaCode
uni-app请求级联数据时uni.request怎么避免重复发包和状态错乱
用户快速连输“上海”“上海市”“上海市浦东新区”，如果每次input都发请求，不仅浪费流量，还容易出现后发先回、覆盖前一次结果的问题。
这不是uni-app特有，但它的onPullDownRefresh或onReachBottom里也常踩这个坑。
- 加防抖：
clearTimeout(this.timer)+this.timer = setTimeout(..., 300)，300ms内只认最后一次输入 - 存请求标识：
this.requestId = Date.now()，每次响应回来先比对response.id === this.requestId，不等就丢弃 - 禁用按钮或加
loading态：提交中禁用picker和input，防止用户狂点 - H5端特别注意：
uni.request在某些安卓WebView里会缓存GET请求，加个时间戳参数?t=<code>Date.now()绕过
为什么picker在iOS上点不动，或者点了没反应
大概率是z-index遮挡或touch事件被父容器吞了，不是数据问题。iOS对position: fixed和transform组合特别敏感。
常见于用了自定义导航栏（custom模式）或弹窗组件里嵌picker的场景。
- 检查父元素有没有
overflow: hidden或pointer-events: none，哪怕只是临时加的class也要排查 - 给
picker加style="z-index: 9999;"（H5有效，App端无效，但能帮定位是否z轴问题） - 换用
mode="selector"试试：如果能点开，说明是multiSelector在iOS渲染异常；确认是否漏写了range-key（比如range-key="name"），缺了它iOS直接不响应 - 真不行就放弃
picker，用scroll-view手写三级列表，虽然麻烦点，但可控性强，尤其要支持搜索高亮时
级联搜索最麻烦的从来不是“怎么连三级”，而是“怎么让用户觉得没在等、没点错、没选串”。数据结构、防抖节流、平台差异、touch穿透——这些地方一松劲，体验就断层。
