小数据（≤1000行）可前端实时过滤，大数据必须后端分页查询；筛选参数需防抖合并、URLSearchParams序列化；渲染前清空tbody，新行须带data-*属性；滚动与焦点需手动恢复；推荐用AbortController+loading状态保障同步。
多条件筛选配合动态加载，必须分清「前端过滤」和「后端拉取」的边界
小数据（≤1000 行）可全量加载后用 JS 实时过滤；大数据必须由后端接收参数、校验、拼 SQL、分页返回。混用会导致空结果、漏行、重复请求或 UI 卡死。关键判断点是：你第一次渲染表格时，数据是静态写死的，还是通过 fetch 或 axios 拿的？前者走前端 filter，后者必须走后端 query 参数透传。
动态加载时，筛选条件怎么安全传给后端
用户改一个输入框，不意味着立刻发请求——得防抖 + 合并参数。常见错误是每个 input 单独绑 change 事件，一改就发一次请求，后端压力大、响应乱序、UI 显示错乱。
- 所有筛选字段（
filter-name、filter-dept、filter-status）统一监听input事件，但只触发一次防抖回调 - 在防抖回调里收集非空值，构造成对象：
{ name: "张", dept: "技术部", status: "active" } - 用
URLSearchParams序列化，避免手动拼?和&：new URLSearchParams(params).toString()→"name=%E5%BC%A0&dept=%E6%8A%80%E6%9C%AF%E9%83%A8" - fetch 地址用
/api/list?${searchParams}，后端直接解析为结构化参数，别用 GET 路径嵌参数（如/api/list/name/张），不通用且难扩展
渲染新数据前，必须清理旧状态
动态加载不是简单 innerHTML +=，尤其带筛选时，旧 DOM 可能残留 display:none 或 class="hidden"，导致新数据被隐藏或样式错乱。
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 每次 fetch 成功后，先清空 tbody：
document.querySelector('tbody').innerHTML = ''，别用removeChild遍历删 - 新数据渲染用
document.createElement('tr')+append()，或批量拼字符串后insertAdjacentHTML('beforeend', html)，避免重绘整个 table - 如果原表格用了
data-*属性做前端过滤（如data-price="999"），新插入的行也必须带上，否则后续再切回前端过滤会失效 - 保留“无数据”提示区域的显隐逻辑：若
response.items.length === 0，显示no-result元素，而不是留空 tbody
筛选条件变更后，滚动位置和焦点容易丢失
用户正在看第 5 页，点了“部门=市场部”，页面刷新式重载，他得手动滚回去——这不是体验问题，是 DOM 替换没处理副作用。
立即学习“前端免费学习笔记（深入）”；
- 用
scrollIntoView({ behavior: 'auto' })在新内容插入后定位到 tbody 顶部，比window.scrollTo(0,0)更精准 - 如果筛选框有 autofocus 需求，不要写
autofocus属性（只在首次加载生效），而是在 fetch 完成后手动input.focus() - 避免在渲染过程中操作
document.activeElement，尤其当用户正编辑某个 input 时，强制 focus 会打断输入流 - 后端返回的每条数据建议带唯一
id字段，前端渲染时设为tr.dataset.id，方便后续做局部更新（比如某行状态异步变更）
AbortController 控制请求生命周期，再加个 loading 状态锁住按钮，比硬调时间戳靠谱得多。 
