后端必须接收标准query参数，前端用FormData采集最稳；需过滤空值、校验数值与日期格式；防抖控制请求频率；URL同步和localStorage缓存保障条件持久化。
后端必须接收标准 query 参数，前端 FormData 是最稳的采集方式
HTML 本身不处理筛选逻辑，所有条件最终要变成 URL 查询参数（如 ?status=active&dept=tech&score_min=70）发给后端。手动拼字符串或遍历 document.querySelectorAll('[name]') 极易出错——比如漏掉 disabled 控件、搞错 checkbox 多选逻辑、忽略空值。直接用 new FormData(form) 能自动跳过未选中的 checkbox、合并同名项、丢弃 disabled 字段，且与后端接收名严格对齐。
常见错误：
- 把
form换成div，再用 JS 硬捞name，结果加个动态渲染的筛选项就断掉 - 给输入框起名带方括号，如
name="brand[]"，FormData不识别，后端收不到数组 - 价格区间写成一个
input再切分，而不是两个独立字段price_min和price_max，导致后端无法做数值范围校验
前端提交前必须过滤空值，否则后端 SQL 会出错
用户没填的字段，不能传 "" 或 "undefined" 给后端。比如 score_min= 这种空值，后端若直接拼进 SQL 的 WHERE score >= ?，就会查出全表或报错。正确做法是在提交前清理：
- 用
Array.from(formData.entries())转成键值对数组，再.filter(([k, v]) => v !== "" && v != null) - 数值类字段（如
score_min）额外用parseFloat(v)判断是否有效数字，避免传入"abc" - 日期字段（
start_date）检查是否为合法 ISO 格式，否则后端解析失败
别依赖后端兜底——前端传错一个空字符串，可能让整个查询退化成全表扫描。
立即学习“前端免费学习笔记（深入）”；
防抖不是可选项，是防止请求雪崩的底线
用户在多个输入框里快速修改时，如果不加控制，每敲一个字都触发一次请求，后端瞬间收到十几条重复、无效的筛选请求。尤其移动端网络延迟高，更容易堆积竞态请求。
必须用防抖（debounce），不是节流（throttle）：
- 监听
input或change事件，但回调函数不立即执行请求 - 每次触发重置定时器，比如设为 300ms，只有用户停顿超过该时间才真正发请求
- 防抖函数内统一读取所有字段值，避免多次读取造成状态不一致（比如 A 框刚改完、B 框还没更新）
注意：搜索按钮点击不需要防抖，但要禁用按钮防止重复提交；失去焦点（blur）可作为兜底触发点，避免用户输完不点按钮就走人。
URL 同步和 localStorage 缓存是用户体验分水岭
用户筛选完刷新页面，筛选条件消失，这是最伤体验的一点。纯靠后端分页 + 条件查询，前端必须主动把当前条件同步到 URL 或本地存储：
- 每次成功请求后，用
history.replaceState()把参数写进 URL，如/list?dept=tech&role=dev - 页面加载时优先从 URL
searchParams读取初始条件，并自动填充表单、触发首次筛选 - localStorage 存一份最近一次完整条件对象（非字符串），用于“返回上一页”或意外刷新后恢复
容易被忽略的是：多选 checkbox 的值在 URL 中会变成重复参数（如 ?brand=apple&brand=samsung），后端必须支持解析同名多值，前端用 formData.getAll('brand') 读取，别只用 get()。
