picker不适合多条件下拉筛选，因其H5端退化为不可控的原生select、不支持多列独立筛选、change仅返回索引易混淆，且无法实现搜索/高亮/自定义样式；应改用uni-popup+scroll-view手写弹层，确保状态独立绑定、条件安全合并与三端一致体验。
直接用 picker 做多条件下拉筛选，在 H5 和小程序表现不一致，且无法加搜索、高亮、自定义样式——真要稳定支持多条件过滤，得换 uni-popup 或手写弹层，核心不是“怎么弹”，而是“状态怎么同步”和“条件怎么安全合并”。
为什么 picker 不适合多条件下拉筛选
picker 在小程序里是原生组件，体验好；但到了 H5 端会退化成原生 <select></select>，样式完全不可控，也不能监听滚动、不能插入搜索框、不能高亮关键词。更关键的是：它只支持单列或级联两列，没法同时展示「状态+分类+时间范围」三个独立筛选项。
- 你改不了它的 DOM 结构，
v-html高亮、scroll-view滚动优化都用不上 -
@change只返回索引，没字段名，多组条件一混合就容易串（比如 status 选了第 1 项，category 也选了第 1 项，但你不知道哪个是哪个） - H5 下点开就是系统下拉框，用户根本看不到你的品牌色或图标，体验割裂
用 uni-popup 实现可搜索的多条件弹层
推荐用 uni-popup + scroll-view 手搭弹层，所有渲染逻辑可控，适配三端一致。重点不是“弹出来”，而是让每个筛选项的状态能独立更新、互不干扰。
- 弹层内容必须用
scroll-view包裹并设scroll-y，别用div+overflow: auto，否则 iOS 滚动卡顿明显 - 每个筛选区块（如「订单状态」「商品类目」）用独立
v-model绑定，例如v-model="filterForm.status"，不要绑statusList[0]这种数组索引 - 搜索输入框必须加防抖：
setTimeout清上一次 timer，延迟 300ms 再执行filteredOptions计算，否则快速打字会卡死 - 高亮关键词用
String.prototype.replace()+ 正则，注意大小写忽略：label.replace(new RegExp(`(${search})`, 'ig'), '<em>$1</em>')
onConfirm 里怎么安全合并多组筛选条件
很多人在确认按钮里直接拼对象，结果出现 undefined 覆盖已有值，或者空数组被当成 false 丢弃。关键在初始化和合并逻辑。
- 把筛选表单声明为响应式对象：
filterForm = { status: [], category: [], timeRange: null } - 每个字段初始值必须是
[]或null，**不能是undefined** —— 否则JSON.stringify会删掉该字段，后端收不到空数组语义 - 提交前做显式判断：
if (filterForm.status.length) params.status = filterForm.status，而不是无脑展开{...filterForm} - 如果后端要求字段全量传递（包括空数组），就用
Object.keys(filterForm).reduce(...)手动构造参数，避免漏字段
容易被忽略的兼容细节
鸿蒙、iOS、微信小程序对 position: fixed 和弹层层级处理差异大，一个没注意，菜单就点不中或遮不住背景。
-
uni-popup的type="bottom"在鸿蒙上可能被系统软键盘顶飞，得监听keyboardheight动态调整top - 搜索框
@input在 H5 触发两次（一次 input，一次 compositionend），要用e.detail.value而非$event.target.value - 点击选项后必须手动清空
search输入框，否则下次再点进来还带着上次关键词，用户会困惑 - Android 小程序里
scroll-view滚动到顶部时，scrollTop可能不是 0，要用this.$nextTick(() => { scrollview.scrollTo({ scrollTop: 0 }) })强制归位
