多条件筛选本质是表单控件联动与数据过滤逻辑的结合，需用data-filter-key统一管理输入控件，配合debounce、空值跳过、every()实现AND过滤，并用DocumentFragment高效渲染。

多条件筛选不是靠一个 HTML 标签就能搞定的，它本质是「表单控件联动 + 数据过滤逻辑」，HTML 本身只负责承载交互元素，真正起作用的是 JavaScript 对数据的判断和渲染。

怎么用 input 和 select 搭建筛选入口

用户看到的“多条件”，其实就是多个可操作的 DOM 元素：比如 做关键词搜索， 做分类下拉， 做多选标签。关键点在于给每个控件加统一的监听逻辑，而不是各自写一堆 onclick 或 onchange。

实操建议：

• 所有筛选控件加上 data-filter-key 属性，例如 data-filter-key="category"、data-filter-key="status"，方便 JS 统一读取
• 避免用 id 硬编码绑定事件，改用事件委托（监听父容器），否则新增筛选项时要反复补 JS
• 文本输入框建议加 debounce（比如 300ms 延迟触发），防止每敲一个字就重刷列表

filter() 怎么写才能支持 AND 逻辑（全部条件同时满足）

很多人误以为“多条件”就是把每个条件单独 filter() 串起来，结果发现越筛越空——那是因为没处理「空值跳过」。真实场景中，用户可能只填了两个条件，第三个下拉保持默认（比如 “全部”），这个条件就不该参与过滤。

实操建议：

• 把所有控件当前值收集为一个对象，例如 { category: "js", status: "", keyword: "use" }
• 遍历这个对象，对每个有实际值（非空字符串、非 null、非 undefined）的字段做判断，跳过空值
• 用一个 every() 包裹所有有效条件，确保数据必须同时满足它们，而不是用多次 filter() 嵌套
• 字符串匹配建议统一转小写，避免 "React" 和 "react" 不匹配

示例片段：

DeepBI DHTML 页面生成器

生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

下载

const filters = { category, status, keyword };
const isValid = (item) => Object.entries(filters).every(([key, value]) => {
  if (!value) return true; // 空值不参与判断
  if (key === 'keyword') return item.title.toLowerCase().includes(value.toLowerCase());
  return item[key] === value;
});

为什么 DOM 渲染慢？别直接 innerHTML = "" 然后循环 +=

当筛选后要刷新列表时，常见错误是清空容器再拼接字符串：el.innerHTML = ""; data.forEach(... el.innerHTML +=

...)

。这会触发多次 DOM 重排，尤其数据量超 50 条就明显卡顿。

实操建议：

• 用 document.createDocumentFragment() 批量创建节点，最后一次性 append 到 DOM
• 或者用 el.replaceChildren(...frag)（现代浏览器支持），比 innerHTML 更安全、更高效
• 如果列表很长（>200 条），考虑虚拟滚动，但普通筛选场景没必要提前上
• 记得在无结果时显示

  暂无匹配项

  ，而不是留一片空白

移动端点击 select 下拉卡顿？换 details/summary 或自定义弹层

原生 在 iOS 上唤起系统选择器，关闭后页面常有延迟，且无法自定义样式或添加搜索。这不是 bug，是 Safari 的限制。

实操建议：

• 简单场景可用
  分类

  ...
  模拟下拉，兼容性好、零 JS
• 需要搜索或分组，就用
  + aria-expanded 手写，配合 focusin/focusout 控制显隐
• 别用第三方 UI 库的 select 组件来“省事”，很多会在内部强行绑定 click 和 touchstart，反而增加冲突概率

最易被忽略的其实是「条件重置」逻辑：用户点了“清除筛选”，不仅要清空表单值，还得同步把 filters 对象还原成初始状态，并重新跑一遍全量数据渲染——否则下次筛选会带着上次残留的隐藏条件。