ExcelJS 实战：前端 Excel 导出导入、样式合并与流式处理

前端要做导出 Excel，十个需求里有八个最后会变成同一句话：能不能带上颜色、合并一下表头、顺便再加个筛选？纯前端能碰 Excel 的库不少，ExcelJS 是我这几年在 JavaScript 项目里用得最顺手的那个——它把 xlsx 当成一个有结构的对象来操作，而不是拼字符串、拼 HTML。浏览器里生成带样式的表格、把用户上传的表格读成干净的业务数组、给几十万行数据做分批落盘，它都能接得住。这篇不打算复述官方 API 文档，而是把我自己在后台系统、数据看板、批量导入这几类场景里踩过的坑和总结下来的写法摊开讲，适合已经会一点 JavaScript、正准备把“导出”和“导入”这两件事做扎实的同学，也适合刚开始接手这类需求、被合并单元格和日期错位折腾过的人。

1. 浏览器里生成一份像样的 Excel，难在哪

1.1 需求从“能下载”升级到“要能看”

早些年做导出，一个 CSV 文件就能交差：text/csv，逗号分隔，a标签一点，任务完成。后来业务方开始拿着别人家的报表截图来找你，说“我们要做成这样”——冻结首行、隔行变色、负数标红、表头两行合并、日期列带筛选箭头、备注列自动换行。这些诉求单独看都不复杂，凑在一起就变成一场对库的考验。CSV 是完全不够用的，它连“颜色”这个概念都没有，更别提合并单元格和条件格式。

中间很多人试过一条捷径：把 HTML<table>直接改后缀成.xls。这招在早期确实能骗过一部分办公软件，打开后还带着 CSS 样式。问题是它本质上是 HTML，不是工作簿格式，稍微新一点的办公套件就会弹“文件格式与扩展名不一致”的警告，WPS 之类还可能直接打不开；更要命的是，这种文件无法被程序再读取解析，做数据回传就彻底断了。短期演示能用，上线就是事故。

再往后就是“后端生成”。让服务端拼 xlsx 传回来，前端只负责下载。这条路稳健，但引入的问题同样明显：一个纯前端项目要为了一个导出按钮去起一个服务，或者去找后端排期；导出的数据结构在前端手里，传到后端再序列化一遍，字段往往还要重新对齐;文件一旦涉及几十万行，服务端也得算内存。很多时候，数据本来就只存在于浏览器内存里，绕一圈纯属浪费。

1.2 几种常见路线的真实差距

ExcelJS 属于最后一类。它的定位很明确：在 JavaScript 环境里把 xlsx 当成一棵对象树来读写，支持样式、公式、合并、数据验证、条件格式、图片、超链接，Node 端和浏览器端共用同一套 API。这也意味着它不是“最轻”的选择——包体积摆在那，但它换来的是一份能真正交付给业务方的文件。

1.3 ExcelJS 解决的具体问题，而不是“通用能力”

我个人把它带来的价值归成三条。第一条是结构与样式分离。你操作的是 Worksheet 和 Cell 对象，写cell.fill、cell.border，而不是在字符串里找位置插标签。第二条是可逆。生成的文件能被同一个库读回来，也能被其他工具解析，做“导出—修改—再导入”的闭环时非常关键。第三条是前后端同构。同一份报表逻辑，白天在浏览器里跑给用户看，晚上在 Node 脚本里跑出来做定时归档，代码几乎不用改，这对维护成本的影响比想象中大。

反过来说，它的短板也得提前认清：包体积不小（完整引入几百 KB 级别），浏览器端的大文件写入会吃内存，流式 API 在浏览器里不是开箱即用。这些后面都会具体讲。

2. 把对象模型吃透，比背 API 有用得多

2.1 Workbook、Worksheet、Cell 的三层职责

用一句话概括：Workbook 是文件，Worksheet 是页签，Cell 是格子。三者之外还有 Row、Column、Style 这些衍生对象，但它们本质上都是对 Cell 的批量视图。

const workbook = new ExcelJS.Workbook(); // 整个文件 workbook.creator = '内部工具'; workbook.created = new Date(); const sheet = workbook.addWorksheet('明细'); // 一个页签 sheet.getCell('A1').value = '编号'; // 一个格子

这里有个容易被忽略的点：workbook.creator、created、modified这些属性会写进文件元信息，在文件属性面板里能看到。做内部工具时我习惯统一填成系统名，而不是默认值，方便后续排查“这份文件是谁导的”。

Worksheet 的命名有硬约束：最长 31 个字符，不能包含: \ / ? * [ ]。这几个字符在 xlsx 的规范里是保留的，写进去会直接抛错。我见过最典型的事故是把时间戳拼进页签名，2024-06-01 12:30里的冒号让整个导出崩在最后一步。稳妥做法是先做一次清洗：

function safeSheetName(raw) { return String(raw) .replace(/[:\\/?*\[\]]/g, '_') .slice(0, 31) || 'Sheet1'; }

2.2 Cell 的 value 是个多态类型，这是最大的认知差

很多人第一次读 Excel 时会被cell.value搞懵：有时候是字符串，有时候是数字，有时候是Date，有时候干脆是一个对象。这不是库的设计问题，而是 xlsx 格式本身就支持这么多内容——富文本、超链接、公式、错误值，都是合法的单元格内容。

写的时候也有对应写法，不能一把梭：

cell.value = '普通文本'; cell.value = 42; cell.value = new Date(2024, 5, 1); cell.value = { formula: 'SUM(B2:B10)', result: 100 }; // 公式必须给 result cell.value = { text: '查看详情', hyperlink: '#' }; // 超链接 cell.value = { richText: [{ font: { bold: true }, text: '总计' }, { text: '：100' }] };

关于公式那条，我要单独强调：只写 formula 不写 result，很多查看器打开时是空白。因为 xlsx 里公式的计算结果是被缓存存储的，库本身不会去算，你必须自己把结果算好填进result。这一点在导出汇总行时几乎必踩。

2.3 样式挂在格子上，而不是行或列

新手常问：“能不能给整行设置背景色？”答案是能，但本质上是遍历这一行的每个格子分别设置。row.eachCell能帮你做到，但要注意它默认只遍历有值的格子，空单元格不会被动到，导致斑马纹在空列处断掉。想覆盖到某一行范围内所有格子，得用下标循环：

function paintRow(sheet, rowNumber, fromCol, toCol, argb) { for (let c = fromCol; c <= toCol; c++) { sheet.getCell(rowNumber, c).fill = { type: 'pattern', pattern: 'solid', fgColor: { argb } }; } }

另外，样式对象是可以复用的，但不要复用同一个对象引用去改属性。比如你写const border = {...}然后给几十个格子赋值cell.border = border，后续如果又去改border.color，所有格子会一起变。要么每次都新建，要么在赋值前深拷贝一次。这个坑我在做“表头统一样式”封装时踩过一次，排查了半天以为是库的缓存问题。

3. 一次完整导出：从空 Workbook 到用户硬盘

3.1 引入方式和打包环境的坑

包管理器安装没什么好说的：npm i exceljs。真正会卡住人的是浏览器环境。ExcelJS 内部依赖了 Node 的一些内置模块（buffer、stream、events），用 Vite 或 webpack 打包时，早期版本会报Buffer is not defined。

最省事的解法是走它自带的浏览器版构建：

<script src="/vendor/exceljs.min.js"></script> <script> // 全局变量 ExcelJS 可用 const wb = new ExcelJS.Workbook(); </script>

如果坚持用 import，就需要补 polyfill：

import { Buffer } from 'buffer'; if (typeof window !== 'undefined' && !window.Buffer) { window.Buffer = Buffer; }

还有一种情况是只做读、不做写，那可以考虑按需引入，减小体积。这部分在第 6 节细讲。

3.2 表头、列宽、冻结、筛选的一次性配置

我习惯把列定义集中在一处，这样列宽、标题、字段名的调整只改一个地方：

const columns = [ { header: '订单号', key: 'orderNo', width: 22 }, { header: '下单时间', key: 'orderTime', width: 20 }, { header: '客户名称', key: 'customer', width: 28 }, { header: '金额', key: 'amount', width: 14 }, { header: '状态', key: 'status', width: 12 }, ]; const sheet = workbook.addWorksheet('订单明细', { views: [{ state: 'frozen', ySplit: 1 }] // 冻结首行 }); sheet.columns = columns; sheet.autoFilter = { from: { row: 1, column: 1 }, to: { row: 1, column: columns.length } };

sheet.columns = columns这一句会顺带把表头写进第一行，也就是header字段自动变成了 A1、B1 的值。列宽单位是“字符宽度”，大约相当于默认字体下一个 ASCII 字符的宽度，中文字符则差不多要占两倍。

冻结窗格用views配，ySplit: 1表示前 1 行固定不动，xSplit同理是前 N 列。这两个组合起来做“首行 + 首列都固定”很实用。

顺便补一个易错点：autoFilter和addTable是两套东西。用autoFilter只加筛选箭头，不加斑马纹；用addTable会生成一个正式的“表格对象”，带主题样式和结构化引用，但两者不能同时对一个区域用，否则打开时会提示文件需要修复。

3.3 样式复用的正确姿势

表头样式我一般写成函数，返回一个新的对象：

function headerStyle() { return { font: { name: '微软雅黑', size: 11, bold: true, color: { argb: 'FFFFFFFF' } }, fill: { type: 'pattern', pattern: 'solid', fgColor: { argb: 'FF2F5597' } }, alignment: { vertical: 'middle', horizontal: 'center', wrapText: true }, border: { top: { style: 'thin', color: { argb: 'FFD9D9D9' } }, left: { style: 'thin', color: { argb: 'FFD9D9D9' } }, bottom: { style: 'thin', color: { argb: 'FFD9D9D9' } }, right: { style: 'thin', color: { argb: 'FFD9D9D9' } }, }, }; } sheet.getRow(1).height = 28; sheet.getRow(1).eachCell({ includeEmpty: true }, (cell) => { Object.assign(cell, headerStyle()); });

argb是八位十六进制，前两位是透明度（FF表示不透明），后六位才是颜色。只写六位比如'2F5597'，某些环境下会被当成非法值处理，表现出来就是“设置了颜色但没生效”。这个细节几乎每个新手都会栽一次。

金额列的数字格式也很关键：

sheet.getColumn('amount').numFmt = '#,##0.00'; sheet.getColumn('orderTime').numFmt = 'yyyy-mm-dd hh:mm';

numFmt只是显示格式，底层值仍然是数字或日期，用户点进单元格看到的还是原值，这点和“把数字转成字符串”有本质区别——后者在 Excel 里会变成左对齐的文本，无法参与求和。

3.4 触发下载：Blob 与 a 标签的那些细节

async function downloadWorkbook(workbook, filename) { const buffer = await workbook.xlsx.writeBuffer(); const blob = new Blob([buffer], { type: 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet', }); const url = URL.createObjectURL(blob); const link = document.createElement('a'); link.href = url; link.download = filename; link.style.display = 'none'; document.body.appendChild(link); link.click(); document.body.removeChild(link); setTimeout(() => URL.revokeObjectURL(url), 2000); }

三个细节值得说。第一，type必须写全，写成application/vnd.ms-excel也能下，但部分系统会按旧格式处理。第二，link要挂到 DOM 上再点，Safari 对游离节点的click()有时无响应。第三，revokeObjectURL不要紧跟着就调用，太早释放会让下载中断，加个延时最稳。

文件名里带中文在部分环境会出现乱码，稳妥做法是同时提供 UTF-8 编码后的名字，或者干脆用英文加时间戳，把中文放到工作表标题里。

4. 反向操作：把用户上传的表格读成干净数据

4.1 加载与遍历的基本骨架

async function parseExcel(file) { const arrayBuffer = await file.arrayBuffer(); const workbook = new ExcelJS.Workbook(); await workbook.xlsx.load(arrayBuffer); const sheet = workbook.worksheets[0]; const rows = []; sheet.eachRow({ includeEmpty: false }, (row, rowNumber) => { if (rowNumber === 1) return; // 跳过表头 const values = row.values; // 注意：这是 1-based 数组 rows.push({ orderNo: values[1], orderTime: values[2], customer: values[3], amount: values[4], status: values[5], }); }); return rows; }

row.values是个 1-based 数组，values[0]永远是undefined，第一次用的人经常会写成values[0]然后拿到一串undefined怀疑人生。

另外，eachRow的includeEmpty: false会跳过完全空白的行，但不会跳过中间有隐藏行的行。如果业务上需要处理被隐藏的行，得自己判断row.hidden：

sheet.eachRow({ includeEmpty: false }, (row, rowNumber) => { if (row.hidden) return; // 按需过滤隐藏行 // ... });

4.2 写一个能扛住各种脏数据的清洗函数

真实业务里上传的表格什么都可能出现：数字被存成文本、日期被存成字符串、空单元格、合并单元格、公式、错误值。指望业务方规范填写是不现实的，必须在解析层做统一归一化：

function normalize(value) { if (value === null || value === undefined) return ''; if (value instanceof Date) { const y = value.getUTCFullYear(); const m = String(value.getUTCMonth() + 1).padStart(2, '0'); const d = String(value.getUTCDate()).padStart(2, '0'); return `${y}-${m}-${d}`; } if (typeof value === 'object') { if (Array.isArray(value.richText)) return value.richText.map(r => r.text).join(''); if ('text' in value && 'hyperlink' in value) return String(value.text); if ('formula' in value || 'sharedFormula' in value) return normalize(value.result); if ('error' in value) return ''; } return String(value).trim(); }

这个函数看着不起眼，但它是我所有导入功能的公共底座。richText是富文本，一段文字可能被拆成多个片段；hyperlink是超链接对象；formula是公式对象，真正有用的是result；error比如#DIV/0!、#N/A，直接当空处理比原样抛给下游安全得多。

4.3 合并单元格该怎么读

合并区域里，只有左上角的格子里有值，其余位置读出来是null。如果表格里有纵向合并的分类列，直接按行读会得到“只有第一行有分类，后面的都是空”。

我的处理方式是把合并区域先扫一遍，建立一份“填充映射”：

function buildMergeMap(sheet) { const map = new Map(); const merges = sheet.model.merges || []; for (const range of merges) { const [start, end] = range.split(':'); const startCell = sheet.getCell(start); const value = startCell.value; const startAddr = startCell.address; sheet.getWorksheet(); const rangeObj = sheet.getCell(start); // 用坐标遍历更稳妥 const s = decodeAddress(start); const e = decodeAddress(end || start); for (let r = s.row; r <= e.row; r++) { for (let c = s.col; c <= e.col; c++) { map.set(`${r},${c}`, value); } } } return map; }

decodeAddress就是把A1这种地址拆成行列号的小工具，自己写十几行即可。读数据时优先查映射表，查不到再用cell.value。这么做之后，纵向合并的分类列就能正确铺满每一行。

需要提醒的是，sheet.model.merges属于内部结构，不同版本可能有差异。更稳的做法是遍历时判断cell.isMerged和cell.master，master指向合并区左上角那个格子：

const raw = cell.isMerged ? cell.master.value : cell.value;

这行代码解决 90% 的合并单元格读取问题，比我上面那套映射简单得多，推荐优先用。

5. 十万行往上：内存、耗时和进度反馈

5.1 为什么 writeBuffer 会在大数据下顶不住

writeBuffer()的语义是“把所有内容在内存里组装成一个完整文件，然后一次性返回”。十万行、每行十列、带样式的数据，中间产生的对象和字符串数量非常可观，浏览器标签页的内存曲线会直接竖起来。我自己实测过一份约 15 万行的明细，带斑马纹和条件格式，Chrome 的内存峰值涨到 900MB 上下，低配机器上会直接崩。

问题的根源不在库本身，而在于“一次性组装”这个模式。xlsx 本质是个 zip 包，里面有一堆 XML，理论上可以边写边压缩落盘，不必全量驻留内存。这正是流式 API 存在的意义。

5.2 Node 端的流式写入

const fs = require('fs'); const ExcelJS = require('exceljs'); async function exportLarge(list, filepath) { const writer = new ExcelJS.stream.xlsx.WorkbookWriter({ filename: filepath, useStyles: true, useSharedStrings: false, }); const sheet = writer.addWorksheet('明细'); sheet.columns = [ { header: '编号', key: 'id', width: 18 }, { header: '名称', key: 'name', width: 30 }, { header: '数值', key: 'value', width: 14 }, ]; for (const item of list) { sheet.addRow(item).commit(); // 关键：写完就提交，及时释放 } sheet.commit(); await writer.commit(); }

两个参数值得解释。useStyles: true是流式模式下启用样式的开关，默认是关的，很多人抱怨“流式导出没有样式”就是因为它。useSharedStrings: false关掉共享字符串表——共享字符串能显著减小文件体积（重复文本只存一份），但需要在内存里维护整张表，数据量大时反而更吃内存。关掉之后体积变大，但内存曲线平坦很多，属于典型的空间换内存。

5.3 浏览器端的大文件策略

浏览器里没有fs，流式写入要配合WritableStream或者第三方流式保存方案，复杂度不低。我在实际项目里用过的三种策略，按推荐度排：

第一种，分片导出多个文件。超过 5 万行就按 5 万切片，生成明细_1.xlsx、明细_2.xlsx，用循环依次触发下载。用户体验上不如单文件优雅，但实现成本最低，也不会炸内存。

第二种，把重活挪到 Web Worker。主线程只负责收集数据和最终下载，解析和组装放在 worker 里跑：

// worker.js import ExcelJS from 'exceljs'; self.onmessage = async (e) => { const { rows } = e.data; const wb = new ExcelJS.Workbook(); const sheet = wb.addWorksheet('明细'); sheet.columns = [ { header: '编号', key: 'id', width: 18 }, { header: '名称', key: 'name', width: 30 }, ]; rows.forEach(r => sheet.addRow(r)); const buffer = await wb.xlsx.writeBuffer(); self.postMessage({ buffer }, [buffer]); // 转移所有权，避免结构化克隆 };

注意postMessage的第二个参数——把buffer列进转移列表，它会以零拷贝的方式移交主线程，比普通克隆快一个数量级。这一步如果漏了，几十 MB 的数据在主线程和 worker 之间复制，耗时会明显上升。

第三种，交给服务端。数据量到了几十万这个级别，其实就不该在浏览器里折腾了。前端把查询条件和分页参数发给服务端，服务端跑流式写入，生成好后给一个下载链接。这条路的体验最好，但需要后端配合。

进度反馈这块也别忽略。无论是 worker 还是分片，给用户一个“正在生成 3/8”的进度，比转圈等一分钟的体验好太多。我个人习惯在每处理完一万行就回传一次进度。

6. 踩过才知道的那些细节

6.1 日期差一天，问题出在时区

这是导入场景里出现频率最高的问题。用户在表格里填2024-06-01，读出来变成2024-05-31。原因是 xlsx 里的日期本质上是一个从某个基准日算起的浮点数序列，库把它转成Date对象时用的是 UTC 基准；如果你在东八区用getFullYear()、getMonth()去取，就会因为本地时区偏移而倒退一天。

解法很直接：取日期一律用getUTC*系列方法，就是上面那个normalize函数里的写法。反过来，写日期的时候如果是从用户输入解析来的Date，也要注意别用一个本地时间构造的对象直接塞进去，最好先规整到零点再写：

function toExcelDate(input) { const d = new Date(input); return new Date(Date.UTC(d.getFullYear(), d.getMonth(), d.getDate())); }

如果业务上日期就是纯日期、不涉及时分秒，我更推荐直接用字符串加numFmt，把cell.value设成'2024-06-01'，然后设置单元格格式。这样显示正常、读取也正常，彻底绕开时区的坑，代价是失去了日期计算能力。在“只是展示和记录”的场景里，这个取舍很划算。

6.2 列宽自适应不能用 length 算

中文字符宽度是 ASCII 的两倍，直接用String.length算列宽，中文列会被挤成一条缝。我的近似算法是逐字符判断码点区间：

function displayWidth(text) { let w = 0; for (const ch of String(text ?? '')) { w += /[\u4e00-\u9fa5\u3000-\u303f\uff00-\uffef]/.test(ch) ? 2 : 1; } return w; } function autoFit(sheet, { min = 8, max = 60, padding = 2 } = {}) { sheet.columns.forEach((col, index) => { let widest = min; col.eachCell({ includeEmpty: false }, (cell) => { const text = cell.value == null ? '' : String(cell.value); widest = Math.max(widest, displayWidth(text)); }); sheet.getColumn(index + 1).width = Math.min(widest + padding, max); }); }

max上限很重要。我见过一份备注字段超长的数据，某一列被撑到 200 多，横向滚动条拉到底也看不全，体验很差。设个 60 左右的上限，配合wrapText: true让它自动换行，效果更自然。另外这个算法对富文本、公式对象会拿到[object Object]，需要先过一遍normalize。

6.3 图片、超链接、数据验证的写法差异

图片是我觉得最容易卡住人的一块，因为它涉及异步加载：

const imageId = workbook.addImage({ buffer: await fetch(imageUrl).then(r => r.arrayBuffer()), extension: 'png', }); sheet.addImage(imageId, { tl: { col: 0, row: 2 }, ext: { width: 120, height: 90 }, });

tl是左上角锚点，ext是显示尺寸，两者可以给坐标也可以给行列。注意图片必须先进workbook再挂到 sheet 上，而且extension要和实际格式一致，写png塞进 jpg 数据会导致文件打开时报错。

超链接的写法前面提过，{ text, hyperlink }的结构。想要更细的控制，还可以加tooltip。数据验证则挂在单元格上：

cell.dataValidation = { type: 'list', allowBlank: false, formulae: ['"待处理,处理中,已完成"'], };

formulae里的列表值是用逗号连接后包在引号里的一整个字符串，总长度受 255 字符限制。选项一多就会超，超了之后 Excel 打开时会提示修复。选项多的情况建议改成引用另一个工作表里的区域，或者干脆不用下拉。

6.4 体积这件事，别等上线才发现

完整引入 ExcelJS，gzip 后大概在两三百 KB 这个量级。对一个只有“导出”一个按钮的后台页面来说，这个代价不算小。我的处理办法通常是动态导入：

async function exportOrders(rows) { const { default: ExcelJS } = await import('exceljs'); const wb = new ExcelJS.Workbook(); // ... }

这样这部分代码会单独打成一个 chunk，只有用户真的点了导出才去加载。配合一个“正在准备…”的 loading 态，体验上的损失几乎感知不到。

还有一个偷懒的优化：如果只是做读取，很多场景下把文件转成 CSV 再解析其实更轻，但前提是文件本身格式不复杂。一旦涉及多 sheet、合并单元格、样式判断，还是老老实实用 ExcelJS。

7. 和几个替代方案摆在一起看，怎么选

7.1 对比维度不该只看“能不能导出”

我在选型时一般看四个维度：写入能力（样式、合并、公式）、读取能力（能否可靠解析复杂表格）、运行环境（浏览器 / 服务端）、体积与内存。按这四个维度摆一下常见的几种：

结论其实很简单：需求里只要出现“合并单元格”和“自定义样式”这两个词，前端的可选范围就基本只剩 ExcelJS 了。反过来，如果只是把一批数据丢出去、样式无所谓，用更轻的方案甚至直接 CSV 都能省事。

7.2 什么时候我会主动放弃前端生成

有三种情况我会劝团队别硬扛。一是单次导出稳定超过二十万行——不是不能做，是投入产出不成正比。二是导出内容需要留痕归档、要有下载记录——这本质上是服务端的职责。三是文件里需要嵌入敏感信息的脱敏逻辑——放在前端跑，脱敏规则等于公开了。

反过来说，下面这些场景我是坚定站前端方案的：数据本身就来自用户当前筛选的结果、不需要落库；导出频率高、希望即时反馈；后端资源紧张但前端页面本来就打开了。这几种情况下，前端生成省掉的是一次网络往返和一轮排期沟通。

7.3 一个容易被忽略的收益：可回读的闭环

我最近做的一个功能是“批量导入配置”，流程是：用户点“下载模板”→ 在本地填好 → 上传 → 前端先本地解析校验 → 有问题的行标红回显 → 用户改完再传。整个闭环全部在浏览器完成，服务端只在最后接收清洗好的数据。

这个方案能成立，核心就在于生成和解析用的是同一套对象模型。模板里的表头、下拉选项、示例行、说明文字，都是同一份配置生成的；解析时按同一份配置去校验，字段名对不上是不可能的。如果用两套技术栈分别做生成和解析，光是字段映射就要维护两份，改动一次两边都要同步。

8. 最后说几个我自己的习惯

写这类代码，我现在会强制自己做三件事。第一，把列定义抽成常量，导出、导入、校验、模板生成全用它，改一处生效四处。第二，把 normalize 和 autoFit 这类函数放进公共工具，别每次重新写一遍，那些时区和富文本的判断逻辑值得被复用。第三，导出的文件名带时间戳，订单明细_20240601_1430.xlsx这种，用户下载一堆文件时能快速分辨，也省得你被问“哪份是最新的”。

另外提醒一句，浏览器端的 Excel 操作基本都会碰到“文件已经生成但用户点下载没反应”的情况，尤其在页面刚打开、资源还没加载完的时候。我现在的做法是：生成阶段就显示进度，生成完把 Blob 存起来，再给一个明确的下载按钮，而不是生成完立刻自动触发。让用户主动点一次，失败的概率明显更低，也方便在出问题时定位到底是生成阶段还是下载阶段挂的。

ExcelJS 这个库本身更新节奏不算快，但核心能力这些年一直很稳，没有出现过破坏性变更。我的建议是锁一个明确的版本号，别用范围符，然后安心用。真遇到它搞不定的场景，多半也不是库的问题，而是数据量或者架构该调整了。