优先选customExport：它支持关联数据、动态列、字段重命名、类型转换和流式导出；quickExport仅适用于单表、字段固定、下游要求标准格式的简单场景。

导出功能选 quickExport 还是 customExport？看数据结构和下游要求

直接结论：quickexport 适合单表、字段固定、下游只认标准格式（如 excel 表头必须是中文）的场景；customexport 是唯一能处理关联数据、动态列、条件过滤、字段重命名或类型转换的入口。

很多人一上来就用 quickExport，结果发现导出的 CSV 里时间戳是毫秒数字、关联的用户昵称变成 undefined、或者导出 Excel 后所有数字被 Excel 自动转成科学计数法——这些都不是 bug，是模式选错了。

• quickExport 内部不做字段映射，直接序列化原始响应体，连空值都原样透出
• customExport 强制要求传 columns 配置，哪怕只改一个字段名也得显式声明
• 如果后端返回的是嵌套对象（比如 user: { name: '张三', profile: { avatar: 'xxx.jpg' } }），quickExport 会把整个 profile 对象转成字符串塞进一格里

customExport 的 columns 配置怎么写才不丢数据

核心原则：列定义必须覆盖所有要导出的字段，且每个 key 必须对应数据项中的可访问路径（支持点号和方括号语法）。

常见错误是写成 { key: 'user.name', title: '姓名' }，但实际数据结构是 { userInfo: { name: '张三' } }，导致该列全为空。

• 路径必须精确匹配，区分大小写，user.Name 和 user.name 是两个字段
• 支持简单表达式，如 key: 'status === 1 ? "启用" : "停用"'，但别写复杂逻辑，容易在批量导出时卡住主线程
• 需要拼接字段时用函数形式：key: row => `${row.firstName} ${row.lastName}`，而不是字符串模板
• 导出日期字段务必加格式化，否则默认输出 2024-05-22T08:12:34.000Z，Excel 打开可能识别失败

导出大文件时 quickExport 反而更慢？内存和流处理差异

表面看 quickExport 少了配置解析环节，应该更快，但实际导出万级数据时，它会先把全部响应 JSON 一次性加载进内存再转 CSV，而 customExport 默认启用流式分块（尤其配合后端 Content-Disposition: attachment; filename="data.csv" 响应头时）。

• 前端内存峰值：使用 quickExport 导出 5 万行 × 20 列，Chrome 中 JS 堆内存可能飙升到 800MB+；customExport 控制在 120MB 内（前提是后端支持分页流）
• quickExport 不支持中断或进度回调，用户点击后只能干等，超时或报错也不提示具体哪一行出问题
• 如果后端返回的是压缩响应（Content-Encoding: gzip），quickExport 会先解压再处理，而 customExport 可跳过解压直接 pipe 到下载流（需服务端配合）

导出 Excel 时中文乱码、数字变科学计数法，跟导出模式有关吗

有关，但不是模式本身的问题，而是两种模式对 MIME 类型和 BOM 头的默认处理不同。

quickExport 默认用 text/csv;charset=utf-8，不加 BOM；customExport 在检测到 .xlsx 后缀时会自动调用 SheetJS，并插入 UTF-8 BOM —— 这个细节决定了 Excel 能否正确识别中文。

• 如果强制用 quickExport 导出 .csv 给 Windows 用户，必须手动加 BOM，否则 Excel 打开就是乱码：new Blob(['\ufeff' + csvString], ...)
• 数字列显示为 1.23E+10 是 Excel 自动格式化行为，customExport 可通过 type: 'string' 显式声明列类型来规避，quickExport 没这个能力
• 不要依赖前端生成 .xlsx 文件处理超大数据，10 万行以上建议后端直出，前端导出只是兜底方案

真正容易被忽略的点：导出前没校验字段值是否含换行符或双引号，会导致 CSV 解析错位——无论用哪个模式，只要原始数据里有 "姓名\n地址"，就得提前清洗，没有银弹。