前端项目中高效实现Excel导入导出的实战经验

西门毓琳发布于 2026-03-08 10:07:17 交互阅读 2,795

原创

本文链接：https://www.jztheme.com/blog/interaction/32090.html

西门毓琳

赞 2 收藏反馈

导入导出这事儿，我折腾过好几轮

做前端这几年，但凡碰上数据管理类的项目，十有八九要搞导入导出。用户总想把表格数据导成 Excel，或者从本地 Excel 上传一批数据进来。刚开始我都是现查现用，后来发现不同方案差别真不小——有的写起来省事但限制多，有的灵活但容易踩坑。今天就聊聊我用过的几种主流方案，说说我为什么现在基本只用其中一种。

谁更灵活？谁更省事？

目前主流的前端导入导出方案，无非这三类：

纯前端方案：比如 SheetJS (xlsx) + FileSaver.js
后端兜底方案：前端只传文件，后端解析/生成，返回下载链接
混合方案：小数据走前端，大数据走后端

我一开始图快，直接上纯前端。毕竟不用动后端接口，改完就能上线。但后来发现，这玩意儿在数据量一大时直接卡死页面，用户浏览器风扇狂转，体验极差。所以现在我的选型逻辑很明确：1000 行以内用前端，超过就扔给后端。

核心代码就这几行（但坑不少）

先看导出。用 SheetJS 导出 Excel，代码确实简洁：

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

function exportToExcel(data, filename = 'data.xlsx') {
  const ws = XLSX.utils.json_to_sheet(data);
  const wb = XLSX.utils.book_new();
  XLSX.utils.book_append_sheet(wb, ws, 'Sheet1');
  const wbout = XLSX.write(wb, { bookType: 'xlsx', type: 'array' });
  saveAs(new Blob([wbout], { type: 'application/octet-stream' }), filename);
}

看起来人畜无害对吧？但这里有几个坑我踩过好几次：

中文乱码：如果用户系统语言不是 UTF-8，某些浏览器会乱码。解决办法是在 Blob 里加 { type: 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;charset=utf-8' }，但也不是 100% 稳。
样式全无：导出的 Excel 是纯数据，没有边框、颜色、列宽。如果产品要求“和页面表格长得一样”，这方案直接废掉。
大数据卡顿：实测超过 5000 行，Chrome 会明显卡顿，Safari 更惨。这时候你只能跟产品说“我们技术上做不到”，但人家才不管。

再看导入，用 SheetJS 读取用户上传的 Excel：

function handleFileUpload(file) {
  const reader = new FileReader();
  reader.onload = (e) => {
    const data = new Uint8Array(e.target.result);
    const workbook = XLSX.read(data, { type: 'array' });
    const sheetName = workbook.SheetNames[0];
    const worksheet = workbook.Sheets[sheetName];
    const jsonData = XLSX.utils.sheet_to_json(worksheet);
    console.log(jsonData); // 这就是解析后的数据
  };
  reader.readAsArrayBuffer(file);
}

这个更玄学。Excel 里一个空单元格，可能被解析成 undefined、null、空字符串，甚至直接跳过列。特别是合并单元格，SheetJS 默认不处理，得自己写逻辑补位。有一次我为了对齐一列合并单元格的数据，硬是 debug 了两小时。

后端方案其实没那么麻烦

很多人觉得“让后端搞导入导出太重了”，但其实真没那么复杂。前端只负责上传文件，后端用 pandas（Python）或 Apache POI（Java）处理，然后返回一个临时下载链接。比如：

// 前端上传
const formData = new FormData();
formData.append('file', fileInput.files[0]);
fetch('/api/import', {
  method: 'POST',
  body: formData
})
.then(res => res.json())
.then(data => {
  if (data.success) {
    alert('导入成功');
  }
});

// 后端导出（伪代码）
// 接收查询参数 → 生成 Excel → 存到临时目录 → 返回 { url: '/temp/export_123.xlsx' }
// 前端拿到 url 直接 window.open(url)

这样做的好处很明显：

数据量再大也不怕，浏览器不卡
能保留完整样式（后端生成时可以套模板）
错误处理更优雅，比如“第 128 行手机号格式错误”直接返回具体位置

坏处也有：得协调后端排期，临时文件要清理，下载链接有时效性。但比起前端方案那些玄学问题，我觉得这些都好解决。而且现在很多 BaaS 平台（比如 Firebase）直接提供文件存储和临时链接，连后端都不用自己写。

我的选型逻辑

现在我接到需求，第一反应是问清楚数据规模和样式要求：

如果是 简单列表导出（比如后台订单列表），且行数 < 1000，我直接上 SheetJS。改完立刻生效，不用等后端联调。
如果是 带复杂格式的报表（比如财务对账单，有合计行、颜色标记），或者数据量可能超 2000 行，我会直接推动用后端方案。哪怕多花半天沟通，也比上线后被用户骂强。
至于混合方案？理论上很美，但实际维护成本高。你要判断数据量、切换逻辑、处理两种错误类型……除非团队有基建支持，否则别轻易尝试。

另外提一嘴，有些团队会用 canvas 或 html-to-excel 库直接把 DOM 转 Excel。这种方案我试过一次就放弃了——样式错乱、分页断裂、兼容性差，属于“看起来快，实则巨坑”。

踩坑提醒：这三点一定注意

不管你选哪种方案，下面三个问题一定会遇到：

文件名编码：后端返回的下载链接，如果文件名含中文，必须用 Content-Disposition: attachment; filename*=UTF-8''xxx.xlsx。否则 Safari 会显示乱码文件名。
大文件上传：前端导入时，如果用户上传 100MB 的 Excel，别直接 readAsArrayBuffer，会爆内存。得用 streaming 分片读取，但 SheetJS 不支持，所以大文件还是乖乖交给后端。
安全校验：别以为 Excel 文件就安全！里面可能嵌入恶意宏或公式（比如 =HYPERLINK("http://evil.com", "Click me")）。后端解析时一定要做内容过滤，前端至少校验文件扩展名和 MIME 类型。