多条件筛选分页必须先筛选后分页，前端筛选+前端分页适用于≤1000行且数据已全量加载的场景，需串行执行筛选、重算页数、渲染；前端筛选+后端分页更稳妥，由服务端完成筛选与分页；禁用display:none模拟分页；筛选时页码须自动重置为第一页。
多条件筛选结果分页不能简单套用纯前端分页逻辑——筛选后数据量不确定，直接切片容易漏页或错页。必须先执行筛选，再基于筛选结果做分页，否则页码和总页数会失真。
前端筛选 + 前端分页：适用于 ≤ 1000 行原始数据
这是最轻量的实现方式，但前提是所有原始数据已加载在页面中（如 JSON 数组或完整 <tbody>）。关键点在于：筛选和分页必须串行，不能并行维护两套状态。<ul>
<li>先用 <code>filter() 或 DOM 遍历生成筛选后的数组/节点列表，例如 const filteredRows = allData.filter(item => !name || item.name.includes(name))
filteredRows 数组做分页切片：const pageData = filteredRows.slice((currentPage - 1) * pageSize, currentPage * pageSize)
input 或 change 事件）都需重新执行筛选 → 重算总页数 → 渲染当前页 → 更新页码控件allData.length 当作总条数；正确总条数是 filteredRows.length
前端筛选 + 后端分页：适合动态、大数据或权限敏感场景
用户在前端填筛选条件，但不本地过滤，而是把所有非空条件作为参数发给后端，由服务端完成「筛选 + 分页」两个动作。这是生产环境更稳妥的选择。
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 请求 URL 示例：
/api/users?page=2&limit=10&name=张&status=active&dept=tech - 后端收到后，先拼接 WHERE 条件（注意 SQL 注入防护），再加
LIMIT和OFFSET，同时用COUNT(*)算出该条件下的真实总条数 - 前端只负责传参、收响应、渲染表格和分页控件；页码按钮点击时，保留原有筛选参数，仅更新
page值重发请求 - 切忌把筛选参数存在 JS 变量里靠前端拼 URL——容易丢失、难调试；推荐统一用
URLSearchParams管理
display: none 分页在筛选后失效，别这么干
有人试图在筛选后对 <tr> 批量设 <code>style.display = 'none'，再用“显示第 n 行到第 m 行”来模拟分页。这会导致严重问题：
立即学习“前端免费学习笔记（深入）”；
- 隐藏行仍存在于 DOM 中，浏览器仍要计算布局、触发重排，滚动卡顿明显
- 筛选后隐藏的行和分页需要显示的行无交集，
querySelectorAll('tr:not([style*="none"])')不可靠 - 键盘导航（如 Tab）、屏幕阅读器行为混乱，可访问性崩坏
- 真正该做的，是每次筛选+分页后，用
innerHTML或replaceChildren()替换<tbody> 内容，保持 DOM 干净<p>最容易被忽略的一点：筛选条件变更时，页码必须自动重置为第一页。否则用户在第 5 页筛选，结果新条件只匹配 3 条数据，却还显示“第 5 页”，体验断裂。这个逻辑必须硬编码进筛选事件处理函数里，不能依赖用户手动点“首页”。</p> </tbody>
