前端导入导出功能实现与性能优化实战经验

我的写法，亲测靠谱

在做数据管理类项目时，导入导出几乎是绕不开的功能。我一开始也照着网上教程瞎搞，结果不是中文乱码，就是大文件直接卡死浏览器。折腾了几个项目后，总算摸出一套自己用着顺手的方案。核心原则就一条：能用现成库就别手写，但得知道它怎么工作的。

现在我导出 Excel 基本都用 SheetJS（也就是 xlsx），配合 FileSaver.js 触发下载。为什么？因为纯前端生成文件，不用走后端，用户点一下就能下，体验好。而且 SheetJS 对中文支持很稳，不像某些方案动不动就变“锟斤拷”。

下面是我常用的导出函数，直接复制就能用：

import * as XLSX from 'xlsx';
import { saveAs } from 'file-saver';

function exportToExcel(data, filename = 'data.xlsx') {
  // data 是数组对象，比如 [{name: '张三', age: 25}, ...]
  const ws = XLSX.utils.json_to_sheet(data);
  const wb = XLSX.utils.book_new();
  XLSX.utils.book_append_sheet(wb, ws, 'Sheet1');
  
  // 生成 ArrayBuffer
  const wbout = XLSX.write(wb, { bookType: 'xlsx', type: 'array' });
  
  // 用 FileSaver 触发下载
  const blob = new Blob([wbout], { type: 'application/octet-stream' });
  saveAs(blob, filename);
}

这个写法的好处是：兼容性好、代码短、不依赖后端。我在三个项目里都这么用，没出过乱码问题。注意两点：一是 type: 'array' 别写成 'binary'，后者在 Safari 里偶尔会出问题；二是文件名最好带后缀，不然有些浏览器会默认存成 .txt。

这几种错误写法，别再踩坑了

我见过太多人把导入导出搞复杂了。最常见的反面教材有这几个：

• 用 JSON.stringify 直接导出 CSV：看起来简单，但一遇到逗号、换行符、引号就崩。比如用户填了个地址“北京市朝阳区，建国路88号”，CSV 里没转义的话，直接变成两列。这种写法只适合 demo，上线必出事。
• 前端生成超大文件用 URL.createObjectURL 不释放：很多人导出后这样写：

  const url = URL.createObjectURL(blob);
      const a = document.createElement('a');
      a.href = url;
      a.download = 'file.xlsx';
      a.click();

  表面上看没问题，但 createObjectURL 会占用内存，如果不调用 URL.revokeObjectURL(url)，多次导出后内存会暴涨，尤其在低配手机上容易卡死。我之前一个项目就因为这个被 QA 投诉“点十次导出页面就卡住”。

• 导入时不做格式校验，直接 JSON.parse：用户上传个 Excel，你读成 JSON 就扔给业务逻辑？万一他传了个空表、或者列名对不上，直接报错。更糟的是，有人用 eval 解析内容（真见过！），安全风险拉满。

还有个隐蔽坑：导出时用 Date 对象。SheetJS 默认会把 Date 转成数字（Excel 的时间戳格式），用户打开看到的是 44562 这种鬼东西。正确做法是提前转成字符串：

// 错误写法
const data = [{ time: new Date() }];

// 正确写法
const data = [{ time: new Date().toLocaleString('zh-CN') }];

实际项目中的坑

去年做后台系统时，客户要求支持 10 万行数据导出。我一开始用上面的方案，结果 Chrome 直接弹“页面无响应”。后来发现，前端生成大文件本质是反模式。超过 1 万行的数据，老老实实让后端生成文件流，前端只负责触发下载和显示进度。

所以现在我的策略是：小数据（<5000 行）前端导出，大数据走后端接口。判断逻辑很简单：

if (data.length > 5000) {
  // 调用后端接口，返回文件 URL
  fetch('/api/export-large', {
    method: 'POST',
    body: JSON.stringify({ filters: currentFilters })
  }).then(res => res.json()).then(data => {
    window.location.href = data.fileUrl; // 或者用 a 标签跳转
  });
} else {
  exportToExcel(data, 'report.xlsx');
}

导入也一样。用户上传 Excel 后，我先用 SheetJS 读取前 100 行做预览和校验，确认格式没问题再提交到后端处理完整数据。这样既避免前端卡死，又能提前拦截错误格式。

另外，样式问题别忽视。默认导出的 Excel 没有边框、字体小，用户总抱怨“看不清”。其实 SheetJS 支持加基础样式，虽然麻烦点，但值得：

const ws = XLSX.utils.json_to_sheet(data);
// 给第一行加粗
const range = XLSX.utils.decode_range(ws['!ref']);
for (let C = range.s.c; C <= range.e.c; ++C) {
  const addr = XLSX.utils.encode_cell({ r: 0, c: C });
  if (!ws[addr]) continue;
  ws[addr].s = { font: { bold: true } };
}

不过要注意，不是所有 Excel 软件都支持样式（比如 WPS 手机版可能忽略），所以别依赖样式做关键信息展示。

导入时的防呆设计

用户上传文件时，总会传错格式。我吃过亏：用户传了 .xls（旧版 Excel），但我的代码只处理 .xlsx，结果静默失败。后来加了两层防护：

1. 前端限制 input 的 accept 属性：

   <input type="file" accept=".xlsx, .xls, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet" />

2. 读取时先判断文件类型，再决定用哪种解析方式：

   function readFile(file) {
         const reader = new FileReader();
         reader.onload = (e) => {
           const data = new Uint8Array(e.target.result);
           const workbook = XLSX.read(data, { type: 'array' });
           // 后续处理...
         };
         reader.readAsArrayBuffer(file);
       }

   这样不管是 .xls 还是 .xlsx 都能处理，SheetJS 内部会自动识别。

还有一点：别信任用户传的列名。曾经有个客户把“手机号”列写成“手机”，另一个写成“联系电话”，导致导入失败。现在我会在导入前让用户手动映射列：

• 读取 Excel 的第一行作为“原始列名”
• 显示一个映射表，让用户选择哪一列对应“姓名”、“手机号”等
• 再按映射关系提取数据

虽然多了一步操作，但大大降低了导入失败率。毕竟，让业务人员改 Excel 模板比改代码容易多了。

最后的小建议

如果你的项目用 Vue 或 React，可以封装成自定义 Hook 或组件。比如我在 React 里写了个 useExport，内部处理 loading 状态、错误提示、大文件降级逻辑，业务组件只要传数据就行。这样团队其他人就不会重复踩坑。

对了，测试时一定要用真实数据。我曾用 mock 数据测试导出正常，结果上线后用户传了个带 emoji 的名字（比如“张三😊”），Excel 打开直接乱码。后来强制在导出前做字符过滤：

function cleanString(str) {
  if (typeof str !== 'string') return str;
  // 移除 emoji 和控制字符
  return str.replace(/[u{10000}-u{10FFFF}u0000-u001F]/gu, '');
}

虽然有点粗暴，但保证了文件可读性。毕竟业务系统不是社交软件，没必要支持 emoji。

以上是我踩坑后的总结，希望对你有帮助。这套方案不是最优的，但在中小型项目里够用、稳定、维护成本低。有更优的实现方式欢迎评论区交流，比如你们怎么处理超大文件导入的？我还在找更好的方案。