应共用一个回调函数统一读取所有筛选值再执行过滤，避免状态覆盖；search事件适用于用户明确提交的确认式筛选，需设type="search"；submit事件最稳妥，须preventDefault并用FormData同步参数。
用 input 事件监听单个输入框，但别各自执行过滤
用户一边输姓名一边选部门时，如果每个 <input> 和 <select></select> 都绑独立的 input 或 change 回调并立刻过滤，会出现状态覆盖：后触发的那个会抹掉前一个还没来得及生效的结果。这不是防抖能解决的，是逻辑错乱。
正确做法是所有筛选控件共用一个回调函数，比如 onFilterChange()：
document.getElementById('filter-name').addEventListener('input', onFilterChange)document.getElementById('filter-dept').addEventListener('change', onFilterChange)document.getElementById('filter-status').addEventListener('change', onFilterChange)
函数体内统一读取全部值：const name = nameInput.value.trim(); const dept = deptSelect.value; const status = statusSelect.value;，再一次性执行过滤逻辑。
什么时候该用 search 事件而不是 input？
search 事件只在用户明确提交时触发（比如在 type="search" 输入框中按回车，或点击搜索图标），适合“确认式”筛选场景——避免输入过程中的频繁重绘、减少 DOM 操作压力，也更符合用户心智模型。
立即学习“前端免费学习笔记（深入）”；
它天然规避了连续输入导致的竞态问题，但代价是无法实时响应。使用时注意：
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 必须把
<input>的type设为"search"，否则不会触发search事件 - 清空操作不会自动触发
search，需额外监听input并判断event.inputType === 'deleteContentBackward'或比对前后值 - 移动端软键盘的「搜索」键才能触发，「回车」键不一定生效，需兼容处理
表单 submit 事件怎么和筛选联动？
如果筛选区域包裹在 <form></form> 标签里，用 submit 事件是最稳妥的显式触发方式，尤其适合需要同步 URL 参数或跳转的场景。
常见错误是没阻止默认行为，导致页面刷新：
- 必须写
event.preventDefault()，否则表单会提交并刷新 - 获取参数别用
form.elements手动遍历，推荐new FormData(form)，它自动忽略空值、支持checkbox多选、兼容file类型（即使不用） - 若要保留筛选状态，记得把
FormData序列化进 URL：history.replaceState(null, '', '?' + new URLSearchParams(formData).toString())
为什么 click 事件不适合做筛选触发器？
除非你明确设计成「点按钮才查」，否则 click 在筛选交互中基本是误用。它不感知输入变化，用户改完内容不点按钮就得不到反馈；而且容易和划词搜索、按钮二次点击等行为冲突。
更隐蔽的问题是：如果按钮被设为 type="button" 却没加 preventDefault()（其实不需要），或者误写成 type="submit" 又没包 <form></form>，会导致意外提交或控制台警告。
真正该监听的是数据源变化本身（input、change、search、submit），不是 UI 上某个按钮的点击动作。
