导出必须基于筛选后的数据而非原始HTML；应维护可见数据数组，用SheetJS导出Excel，按钮需禁用并加加载态，大数据量建议后端导出且确保前后端筛选逻辑一致。
导出前必须先拿到筛选后的数据，而不是原始 HTML 表格
很多人直接对 <table> 元素调用 <code>document.querySelector('table').outerHTML 导出，结果发现导出的是全部数据——因为 DOM 没变，只是部分 <tr> 被 <code>display: none 隐藏了。导出逻辑必须和筛选逻辑耦合：筛选时应维护一个「当前可见数据数组」，导出时只处理这个数组。
常见错误现象：
• 点击导出，Excel 里全是原始数据
• 筛选后行数变少，但导出文件行数没变
• 导出内容包含被隐藏的敏感字段（比如后台 ID）
- 筛选函数返回的不能只是 DOM 操作结果，必须返回过滤后的纯数据（如
filteredData数组） - 导出函数应接收该数组作为唯一参数，不读取 DOM
- 如果筛选依赖服务端（如分页 + 搜索），导出前需重新请求带相同条件的全量数据（避免前端漏导）
用 SheetJS（xlsx.js）导出为 Excel 最稳，别手写 CSV
手拼 CSV 字符串容易崩：含逗号、换行、中文、双引号的单元格会错位；而浏览器原生 download 属性不支持 Excel 格式。SheetJS 是事实标准，体积小（xlsx.min.js 约 150KB），API 直观。
使用场景：
• 需要保留数字格式（如 123456789 不变成 1.23E+8）
• 列名含中文或特殊符号
• 后续可能加样式或多 sheet
立即学习“前端免费学习笔记（深入）”；
- 引入方式：
<script src="https://cdn.sheetjs.com/xlsx-0.20.3/package/dist/xlsx.min.js"></script></li> <li>核心导出代码（传入筛选后的数组）：<pre class="brush:php;toolbar:false;">const ws = XLSX.utils.json_to_sheet(filteredData);<br>const wb = XLSX.utils.book_new();<br>XLSX.utils.book_append_sheet(wb, ws, "数据");<br>XLSX.writeFile(wb, "筛选结果.xlsx");
- 注意：
json_to_sheet 默认按对象第一个元素的 key 排列列顺序，若需固定列序，传 <code>{header: ['name', 'status', 'amount']}
导出按钮必须禁用 + 加载态，尤其数据量大时
用户点击导出后无反馈，容易连点；而 SheetJS 处理 5000+ 行时在低端设备上可能卡顿 1–2 秒，期间若重复触发会生成多个文件或报错 RangeError: Maximum call stack size exceeded（因大量对象递归序列化）。
- 按钮添加
disabled和 loading 文字：<button id="exportBtn" disabled>导出中...</button> - 导出完成后手动恢复：
btn.disabled = false; btn.textContent = '导出 Excel'; - 超过 1 万行建议提示：“数据量较大，导出需要几秒，请勿关闭页面”
后端导出更可靠，但需同步筛选参数
前端导出受限于内存（Chrome 对单次 Blob 约 500MB 上限）和性能（>5 万行易卡死）。真实业务中，导出应走后端接口，前端只传筛选条件。
关键点：
• 前端筛选条件（如日期范围、状态数组、关键词）必须原样透传给后端
• 接口返回 Content-Disposition: attachment; filename="xxx.xlsx"
• 前端用 fetch + response.blob() 触发下载
- 不要把前端已筛选的数据 POST 给后端再导出——冗余且不安全
- GET 参数长度有限，复杂条件（如多选 ID 列表）改用 POST，但 URL 仍需保持可复现（方便日志追踪）
- 后端导出完成前，前端仍需禁用按钮并显示加载态，防止用户以为失败而重试
最容易被忽略的是：前端筛选 UI 和后端查询逻辑必须严格一致。比如前端用 new Date().toISOString().split('T')[0] 生成日期，后端却按 UTC+8 解析，导出时间就错了一天。
