简介这份资源面向需要在网页端实现表格在线编辑的前端开发者与企业应用团队围绕HTML页面集成Excel编辑能力这一常见需求提供可运行的示例工程与配套代码。压缩包共41个文件约1.44MB以17个css样式文件、7个js脚本、9个png图片为主另含html入口页、字体文件与Web.config配置覆盖界面样式、交互逻辑与资源加载等模块。示例中集成了表格控件与文件保存相关脚本并准备了多套Excel风格主题样式便于直接对照研究表格渲染、单元格编辑与导出保存的实现方式。目前已有5074人学习下载适合希望快速搭建在线表格编辑原型、了解前端表格控件集成思路与兼容性处理策略的开发者参考借鉴。1. 在 HTML 页面里塞进一个能用的 Excel为什么大多数方案都翻车了做过管理后台的人大概率都接过这种需求页面里要有一个表格用户能像用 Excel 一样编辑公式、合并单元格、复制粘贴、格式刷都得有最后还要能导出成.xlsx。第一反应通常是找个表格组件库Handsontable、Luckysheet、x-spreadsheet挑一个npm 一装页面一嵌看起来就完事了。真上线才发现组件库给你的是「像 Excel 的表格」不是「Excel 本身」——公式引擎是残缺的粘贴从 Excel 复制过来的带格式内容会错位导出文件用 WPS 打开提示格式损坏用户第一句话就是「这跟我电脑上的 Excel 不一样」。这个标题真正要解决的问题是在浏览器里提供一个兼容 Excel 文件格式、兼容 Excel 操作习惯的在线编辑能力。它适合两类人一类是要在 OA、报表、财务系统里嵌入表格编辑的前后端工程师另一类是想把线下 Excel 流程搬到线上、又不想让用户重新学一套操作的业务开发者。核心矛盾只有一个——你是自己实现一个表格还是复用一个真的 Excel 引擎。选错方向后面全是血泪。2. 三条技术路线怎么选自研表格、前端组件库、文档服务引擎在动手之前先把路线定死。这个决定比后面任何一行代码都重要因为它决定了你的天花板和你的维护成本。2.1 自研或轻量组件库便宜但公式和格式是黑匣子用原生table加contenteditable或者用x-spreadsheet这类轻量库优点是体积小、可控、不依赖后端。适合的场景很窄只需要录入二维数据不需要公式不需要保留单元格样式导出时自己拼一个 CSV 或简单 xlsx。一旦需求里出现「求和公式」「跨表引用」「条件格式」「数据验证下拉」这条路基本就走死了。因为 Excel 的公式引擎是一个巨大的状态机SUMIFS、VLOOKUP、数组公式、循环引用检测任何一个都不是几天能补齐的。我见过团队花两个月自研公式解析最后连INDIRECT都没搞定用户一个跨表引用就崩了。2.2 前端组件库开箱即用但导出和粘贴是重灾区Handsontable、Luckysheet、Univer属于这一类。它们在前端渲染表格、处理编辑交互公式能力比自研强很多Luckysheet 和 Univer 都内置了公式引擎。适合中小型后台用户量不大、文件不复杂。坑集中在两个地方。第一是粘贴用户从本地 Excel 复制一片带格式的区域粘贴进来后组件只拿到纯文本或简单 HTML样式、公式、合并信息全丢。第二是导出组件自己生成的 xlsx 往往不是标准 OOXML用 Excel 打开正常用 WPS 或 Numbers 打开就报错。如果你的用户群里有 WPS 用户这一条会直接让你返工。2.3 文档服务引擎最重但兼容性最好OnlyOffice、Collabora Online这类方案本质是把一个真正的文档处理内核跑在服务端前端只是一个渲染和交互的壳。它天然支持 xlsx 的完整格式、公式、协同编辑、版本历史。代价是部署重需要一台独立的文档服务前后端要打通鉴权和文件回调运维成本明显上升。选它的判断标准很简单如果用户会拿你的页面和本地 Excel 对比并且会较真格式和公式就上文档服务引擎。如果只是内部录入用户不会较真前端组件库足够。下面这张表是我自己在选型时会填的可以直接对照维度自研/轻量库前端组件库文档服务引擎公式支持基本没有部分支持完整xlsx 格式兼容差中好从 Excel 粘贴保真差中好协同编辑无部分支持原生支持部署复杂度低低高适合场景纯数据录入中小后台报表/财务/协同提示不要因为「部署重」就无脑排除文档服务引擎。很多团队前期用组件库省事等业务做大了再迁移迁移成本远高于一开始就上重方案。3. 用前端组件库跑通最小可用版本从引入到导出 xlsx这一章给一条能直接抄的路径。以Luckysheet为例它体积适中、公式能力够用、社区资料多适合作为第一版落地。如果你选的是Univer或Handsontable思路一致API 名换一下即可。3.1 引入依赖并初始化一个可编辑表格先建一个干净的 HTML 页面注意!doctype html和meta charsetutf-8这两行别省中文乱码十有八九是这里出的问题。!doctype html html langzh-cn head meta charsetutf-8 meta nameviewport contentwidthdevice-width, initial-scale1 title在线 Excel 编辑/title !-- Luckysheet 的样式和脚本按官方 CDN 引入 -- link relstylesheet href/static/luckysheet/plugins/css/pluginsCss.css link relstylesheet href/static/luckysheet/plugins/plugins.css link relstylesheet href/static/luckysheet/css/luckysheet.css script src/static/luckysheet/plugins/js/plugin.js/script script src/static/luckysheet/luckysheet.umd.js/script /head body !-- 容器必须有明确的宽高否则表格渲染不出来 -- div idsheet stylewidth:100%;height:600px;/div script // 初始化一个空工作簿data 为空数组时组件会创建默认 sheet luckysheet.create({ container: sheet, data: [], showinfobar: false, // 隐藏顶部信息栏嵌入后台更干净 allowCopy: true, // 允许复制粘贴保真依赖它 enableAddRow: true, enableAddBackTop: false }); /script /body /html逻辑说明luckysheet.create是唯一入口container对应上面那个 div 的 id。data传空数组时组件会自己建一个默认工作表如果你要从后端加载已有文件这里传的是解析后的单元格配置数组不是原始 xlsx 二进制。参数说明showinfobar控制顶部那条带文件名和保存按钮的栏嵌入系统时通常关掉allowCopy必须为 true否则用户从 Excel 复制粘贴会失效。3.2 加载后端返回的表格数据真实场景里表格内容来自后端。常见做法是后端把 xlsx 解析成 JSON 单元格配置前端直接喂给data。// 假设后端接口 /api/sheet/1024 返回 { data: [...], config: {...} } async function loadSheet(sheetId) { const res await fetch(/api/sheet/${sheetId}); if (!res.ok) throw new Error(加载表格失败); const payload await res.json(); luckysheet.create({ container: sheet, data: payload.data, // 单元格配置数组 config: payload.config || {},// 列宽、合并、冻结等 showinfobar: false, allowCopy: true }); } loadSheet(1024).catch(err { // 失败时给用户一个明确提示不要静默 document.getElementById(sheet).innerHTML p stylepadding:20px;color:#c00;表格加载失败请刷新重试/p; console.error(err); });逻辑说明data的结构是「工作表数组」每个工作表里有celldata每个单元格包含r、c、v值和可选的f公式。后端解析 xlsx 时要把这些字段对齐否则会出现「有值但显示空白」的玄学问题。参数说明config里最常调的是merge合并单元格和columnlen列宽这两个字段名在不同版本里略有差异升级组件时优先核对。3.3 导出为 xlsx 并处理公式导出是这类方案最容易翻车的一环。Luckysheet 提供了luckysheet.getAllSheets()拿到当前所有工作表数据再交给后端或前端库生成 xlsx。// 前端拿到数据后POST 给后端生成 xlsx避免前端库格式不标准 async function exportXlsx() { const sheets luckysheet.getAllSheets(); const res await fetch(/api/sheet/export, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ sheets }) }); if (!res.ok) throw new Error(导出失败); // 后端返回二进制流前端触发下载 const blob await res.blob(); const url URL.createObjectURL(blob); const a document.createElement(a); a.href url; a.download export.xlsx; a.click(); URL.revokeObjectURL(url); }逻辑说明getAllSheets()返回的是组件内部数据结构包含公式字符串。后端用openpyxl或exceljs重新写入时公式要以SUM(A1:A10)这种字符串形式写入单元格的value而不是计算结果。参数说明如果后端用 Pythonopenpyxl写公式直接赋值字符串即可如果用 Nodeexceljs需要设置cell.value { formula: SUM(A1:A10) }两种写法别搞混否则导出的文件公式会变成纯文本。注意不要在前端用xlsx库直接生成文件它对样式和公式的支持有限导出的文件在 WPS 里经常提示「文件已损坏」。让后端生成前端只负责下载。4. 避坑与排查那些让表格「看起来能用、实际不能用」的问题这一章是我自己踩过和帮别人排查过的记录按「现象 → 原因 → 解决」写遇到对应症状直接对号入座。现象一从本地 Excel 复制一片区域粘贴进来格式全丢只剩纯文本。原因组件默认只监听paste事件的纯文本没有解析剪贴板里的text/html富文本格式。Excel 复制时会同时写入纯文本和 HTML 两种格式组件没读 HTML 那份。 解决在初始化时确认allowCopy为 true并检查组件版本是否支持富文本粘贴。如果组件本身不支持需要在paste事件里手动读event.clipboardData.getData(text/html)解析成单元格配置再写入。这一步比较脏但能救回大部分格式。现象二导出的 xlsx 用 Excel 打开正常用 WPS 打开提示格式错误。原因前端库生成的 xlsx 不是严格的 OOXML缺少某些必需的命名空间或关系文件。Excel 容错强WPS 容错弱问题就暴露了。 解决把生成逻辑挪到后端用成熟的库Python 的openpyxl、Node 的exceljs生成。这两个库产出的文件经过大量生产验证WPS 兼容性没问题。现象三表格里公式显示为#NAME?或直接变成文本。原因公式里用了组件不支持的函数或者导出时公式被当成字符串写入了。前者是组件能力边界后者是导出逻辑写错。 解决先确认组件支持的函数列表SUMIFS、VLOOKUP这类常用函数主流组件都支持但数组公式和INDIRECT往往不支持。导出时检查写入方式Python 用ws[A1] SUM(B1:B10)Node 用cell.value { formula: ... }写错就会变文本。现象四页面里表格渲染出来了但一片空白控制台没有报错。原因容器 div 没有明确高度或者初始化时容器还没挂载到 DOM。Luckysheet 依赖容器的实际尺寸来计算渲染区域。 解决给容器写死height不要用height: auto。如果是在 Vue/React 里确保在mounted或useEffect之后再调用create不要在setup阶段就调。现象五多人同时编辑同一个表格后保存的覆盖先保存的。原因前端组件库大多不带协同能力每次保存都是全量覆盖。 解决如果协同是硬需求别在组件库上硬做直接换OnlyOffice这类原生支持协同的引擎。如果只是偶尔冲突可以在保存时带上版本号后端做乐观锁校验冲突时提示用户刷新。5. 进阶把编辑能力做成可复用的服务而不是一次性页面第一版跑通之后真正决定这套东西能不能长期用的是架构不是某个 API 用得多熟。我自己的习惯是从第一天起就把「表格数据」和「页面」解耦让编辑能力变成一个可以被多个页面调用的服务。具体做法是后端维护一个sheet表存表格的元信息id、名称、版本号、创建人单元格数据单独存一张sheet_cell表或者直接存 JSON 字段。前端页面只做两件事——按 id 拉数据渲染、把变更推回后端。这样以后要加「历史版本」「权限控制」「模板复制」都只是在后端加逻辑前端不用动。验证这套架构是否合理有一个很简单的测试你能不能在不改前端代码的前提下把表格的存储从 MySQL 换成 MongoDB。如果能说明解耦到位了如果换个存储就要改一堆前端字段映射说明数据结构和渲染逻辑耦合太紧早晚要重构。再往上一层如果业务里表格种类很多报表、预算、排班可以做一个「表格模板」机制模板定义列结构、公式、校验规则用户新建时选模板后端按模板生成初始单元格配置。这一步做完你的在线编辑就从「一个页面」变成了「一个平台能力」。最后说一个我自己的教训。早期做这类需求时我总想着「先把功能做出来架构以后再说」结果第三个业务方接入时发现前两个页面的数据格式完全不一样光对齐字段就花了一周。后来我定了一个规矩任何表格相关的需求先定数据结构和导出格式再写第一行渲染代码。这个顺序反过来后面全是后悔药。希望帮到你。本文还有配套的精品资源点击获取 在线Excel编辑方案选型：自研、组件库还是文档引擎？
简介这份资源面向需要在网页端实现表格在线编辑的前端开发者与企业应用团队围绕HTML页面集成Excel编辑能力这一常见需求提供可运行的示例工程与配套代码。压缩包共41个文件约1.44MB以17个css样式文件、7个js脚本、9个png图片为主另含html入口页、字体文件与Web.config配置覆盖界面样式、交互逻辑与资源加载等模块。示例中集成了表格控件与文件保存相关脚本并准备了多套Excel风格主题样式便于直接对照研究表格渲染、单元格编辑与导出保存的实现方式。目前已有5074人学习下载适合希望快速搭建在线表格编辑原型、了解前端表格控件集成思路与兼容性处理策略的开发者参考借鉴。1. 在 HTML 页面里塞进一个能用的 Excel为什么大多数方案都翻车了做过管理后台的人大概率都接过这种需求页面里要有一个表格用户能像用 Excel 一样编辑公式、合并单元格、复制粘贴、格式刷都得有最后还要能导出成.xlsx。第一反应通常是找个表格组件库Handsontable、Luckysheet、x-spreadsheet挑一个npm 一装页面一嵌看起来就完事了。真上线才发现组件库给你的是「像 Excel 的表格」不是「Excel 本身」——公式引擎是残缺的粘贴从 Excel 复制过来的带格式内容会错位导出文件用 WPS 打开提示格式损坏用户第一句话就是「这跟我电脑上的 Excel 不一样」。这个标题真正要解决的问题是在浏览器里提供一个兼容 Excel 文件格式、兼容 Excel 操作习惯的在线编辑能力。它适合两类人一类是要在 OA、报表、财务系统里嵌入表格编辑的前后端工程师另一类是想把线下 Excel 流程搬到线上、又不想让用户重新学一套操作的业务开发者。核心矛盾只有一个——你是自己实现一个表格还是复用一个真的 Excel 引擎。选错方向后面全是血泪。2. 三条技术路线怎么选自研表格、前端组件库、文档服务引擎在动手之前先把路线定死。这个决定比后面任何一行代码都重要因为它决定了你的天花板和你的维护成本。2.1 自研或轻量组件库便宜但公式和格式是黑匣子用原生table加contenteditable或者用x-spreadsheet这类轻量库优点是体积小、可控、不依赖后端。适合的场景很窄只需要录入二维数据不需要公式不需要保留单元格样式导出时自己拼一个 CSV 或简单 xlsx。一旦需求里出现「求和公式」「跨表引用」「条件格式」「数据验证下拉」这条路基本就走死了。因为 Excel 的公式引擎是一个巨大的状态机SUMIFS、VLOOKUP、数组公式、循环引用检测任何一个都不是几天能补齐的。我见过团队花两个月自研公式解析最后连INDIRECT都没搞定用户一个跨表引用就崩了。2.2 前端组件库开箱即用但导出和粘贴是重灾区Handsontable、Luckysheet、Univer属于这一类。它们在前端渲染表格、处理编辑交互公式能力比自研强很多Luckysheet 和 Univer 都内置了公式引擎。适合中小型后台用户量不大、文件不复杂。坑集中在两个地方。第一是粘贴用户从本地 Excel 复制一片带格式的区域粘贴进来后组件只拿到纯文本或简单 HTML样式、公式、合并信息全丢。第二是导出组件自己生成的 xlsx 往往不是标准 OOXML用 Excel 打开正常用 WPS 或 Numbers 打开就报错。如果你的用户群里有 WPS 用户这一条会直接让你返工。2.3 文档服务引擎最重但兼容性最好OnlyOffice、Collabora Online这类方案本质是把一个真正的文档处理内核跑在服务端前端只是一个渲染和交互的壳。它天然支持 xlsx 的完整格式、公式、协同编辑、版本历史。代价是部署重需要一台独立的文档服务前后端要打通鉴权和文件回调运维成本明显上升。选它的判断标准很简单如果用户会拿你的页面和本地 Excel 对比并且会较真格式和公式就上文档服务引擎。如果只是内部录入用户不会较真前端组件库足够。下面这张表是我自己在选型时会填的可以直接对照维度自研/轻量库前端组件库文档服务引擎公式支持基本没有部分支持完整xlsx 格式兼容差中好从 Excel 粘贴保真差中好协同编辑无部分支持原生支持部署复杂度低低高适合场景纯数据录入中小后台报表/财务/协同提示不要因为「部署重」就无脑排除文档服务引擎。很多团队前期用组件库省事等业务做大了再迁移迁移成本远高于一开始就上重方案。3. 用前端组件库跑通最小可用版本从引入到导出 xlsx这一章给一条能直接抄的路径。以Luckysheet为例它体积适中、公式能力够用、社区资料多适合作为第一版落地。如果你选的是Univer或Handsontable思路一致API 名换一下即可。3.1 引入依赖并初始化一个可编辑表格先建一个干净的 HTML 页面注意!doctype html和meta charsetutf-8这两行别省中文乱码十有八九是这里出的问题。!doctype html html langzh-cn head meta charsetutf-8 meta nameviewport contentwidthdevice-width, initial-scale1 title在线 Excel 编辑/title !-- Luckysheet 的样式和脚本按官方 CDN 引入 -- link relstylesheet href/static/luckysheet/plugins/css/pluginsCss.css link relstylesheet href/static/luckysheet/plugins/plugins.css link relstylesheet href/static/luckysheet/css/luckysheet.css script src/static/luckysheet/plugins/js/plugin.js/script script src/static/luckysheet/luckysheet.umd.js/script /head body !-- 容器必须有明确的宽高否则表格渲染不出来 -- div idsheet stylewidth:100%;height:600px;/div script // 初始化一个空工作簿data 为空数组时组件会创建默认 sheet luckysheet.create({ container: sheet, data: [], showinfobar: false, // 隐藏顶部信息栏嵌入后台更干净 allowCopy: true, // 允许复制粘贴保真依赖它 enableAddRow: true, enableAddBackTop: false }); /script /body /html逻辑说明luckysheet.create是唯一入口container对应上面那个 div 的 id。data传空数组时组件会自己建一个默认工作表如果你要从后端加载已有文件这里传的是解析后的单元格配置数组不是原始 xlsx 二进制。参数说明showinfobar控制顶部那条带文件名和保存按钮的栏嵌入系统时通常关掉allowCopy必须为 true否则用户从 Excel 复制粘贴会失效。3.2 加载后端返回的表格数据真实场景里表格内容来自后端。常见做法是后端把 xlsx 解析成 JSON 单元格配置前端直接喂给data。// 假设后端接口 /api/sheet/1024 返回 { data: [...], config: {...} } async function loadSheet(sheetId) { const res await fetch(/api/sheet/${sheetId}); if (!res.ok) throw new Error(加载表格失败); const payload await res.json(); luckysheet.create({ container: sheet, data: payload.data, // 单元格配置数组 config: payload.config || {},// 列宽、合并、冻结等 showinfobar: false, allowCopy: true }); } loadSheet(1024).catch(err { // 失败时给用户一个明确提示不要静默 document.getElementById(sheet).innerHTML p stylepadding:20px;color:#c00;表格加载失败请刷新重试/p; console.error(err); });逻辑说明data的结构是「工作表数组」每个工作表里有celldata每个单元格包含r、c、v值和可选的f公式。后端解析 xlsx 时要把这些字段对齐否则会出现「有值但显示空白」的玄学问题。参数说明config里最常调的是merge合并单元格和columnlen列宽这两个字段名在不同版本里略有差异升级组件时优先核对。3.3 导出为 xlsx 并处理公式导出是这类方案最容易翻车的一环。Luckysheet 提供了luckysheet.getAllSheets()拿到当前所有工作表数据再交给后端或前端库生成 xlsx。// 前端拿到数据后POST 给后端生成 xlsx避免前端库格式不标准 async function exportXlsx() { const sheets luckysheet.getAllSheets(); const res await fetch(/api/sheet/export, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ sheets }) }); if (!res.ok) throw new Error(导出失败); // 后端返回二进制流前端触发下载 const blob await res.blob(); const url URL.createObjectURL(blob); const a document.createElement(a); a.href url; a.download export.xlsx; a.click(); URL.revokeObjectURL(url); }逻辑说明getAllSheets()返回的是组件内部数据结构包含公式字符串。后端用openpyxl或exceljs重新写入时公式要以SUM(A1:A10)这种字符串形式写入单元格的value而不是计算结果。参数说明如果后端用 Pythonopenpyxl写公式直接赋值字符串即可如果用 Nodeexceljs需要设置cell.value { formula: SUM(A1:A10) }两种写法别搞混否则导出的文件公式会变成纯文本。注意不要在前端用xlsx库直接生成文件它对样式和公式的支持有限导出的文件在 WPS 里经常提示「文件已损坏」。让后端生成前端只负责下载。4. 避坑与排查那些让表格「看起来能用、实际不能用」的问题这一章是我自己踩过和帮别人排查过的记录按「现象 → 原因 → 解决」写遇到对应症状直接对号入座。现象一从本地 Excel 复制一片区域粘贴进来格式全丢只剩纯文本。原因组件默认只监听paste事件的纯文本没有解析剪贴板里的text/html富文本格式。Excel 复制时会同时写入纯文本和 HTML 两种格式组件没读 HTML 那份。 解决在初始化时确认allowCopy为 true并检查组件版本是否支持富文本粘贴。如果组件本身不支持需要在paste事件里手动读event.clipboardData.getData(text/html)解析成单元格配置再写入。这一步比较脏但能救回大部分格式。现象二导出的 xlsx 用 Excel 打开正常用 WPS 打开提示格式错误。原因前端库生成的 xlsx 不是严格的 OOXML缺少某些必需的命名空间或关系文件。Excel 容错强WPS 容错弱问题就暴露了。 解决把生成逻辑挪到后端用成熟的库Python 的openpyxl、Node 的exceljs生成。这两个库产出的文件经过大量生产验证WPS 兼容性没问题。现象三表格里公式显示为#NAME?或直接变成文本。原因公式里用了组件不支持的函数或者导出时公式被当成字符串写入了。前者是组件能力边界后者是导出逻辑写错。 解决先确认组件支持的函数列表SUMIFS、VLOOKUP这类常用函数主流组件都支持但数组公式和INDIRECT往往不支持。导出时检查写入方式Python 用ws[A1] SUM(B1:B10)Node 用cell.value { formula: ... }写错就会变文本。现象四页面里表格渲染出来了但一片空白控制台没有报错。原因容器 div 没有明确高度或者初始化时容器还没挂载到 DOM。Luckysheet 依赖容器的实际尺寸来计算渲染区域。 解决给容器写死height不要用height: auto。如果是在 Vue/React 里确保在mounted或useEffect之后再调用create不要在setup阶段就调。现象五多人同时编辑同一个表格后保存的覆盖先保存的。原因前端组件库大多不带协同能力每次保存都是全量覆盖。 解决如果协同是硬需求别在组件库上硬做直接换OnlyOffice这类原生支持协同的引擎。如果只是偶尔冲突可以在保存时带上版本号后端做乐观锁校验冲突时提示用户刷新。5. 进阶把编辑能力做成可复用的服务而不是一次性页面第一版跑通之后真正决定这套东西能不能长期用的是架构不是某个 API 用得多熟。我自己的习惯是从第一天起就把「表格数据」和「页面」解耦让编辑能力变成一个可以被多个页面调用的服务。具体做法是后端维护一个sheet表存表格的元信息id、名称、版本号、创建人单元格数据单独存一张sheet_cell表或者直接存 JSON 字段。前端页面只做两件事——按 id 拉数据渲染、把变更推回后端。这样以后要加「历史版本」「权限控制」「模板复制」都只是在后端加逻辑前端不用动。验证这套架构是否合理有一个很简单的测试你能不能在不改前端代码的前提下把表格的存储从 MySQL 换成 MongoDB。如果能说明解耦到位了如果换个存储就要改一堆前端字段映射说明数据结构和渲染逻辑耦合太紧早晚要重构。再往上一层如果业务里表格种类很多报表、预算、排班可以做一个「表格模板」机制模板定义列结构、公式、校验规则用户新建时选模板后端按模板生成初始单元格配置。这一步做完你的在线编辑就从「一个页面」变成了「一个平台能力」。最后说一个我自己的教训。早期做这类需求时我总想着「先把功能做出来架构以后再说」结果第三个业务方接入时发现前两个页面的数据格式完全不一样光对齐字段就花了一周。后来我定了一个规矩任何表格相关的需求先定数据结构和导出格式再写第一行渲染代码。这个顺序反过来后面全是后悔药。希望帮到你。本文还有配套的精品资源点击获取