1. 为什么我决定从零封装一套基于 Layui 的表格组件库先交代一下背景。这几年我在不同公司带过前端团队也深度参与过好几套后台管理系统的从 0 到 1。无一例外表格都是后台系统里出现频率最高、重复度最大的模块。列表查询、分页、搜索条件、排序、操作列、导出、行内编辑……每个项目做一遍表面上只是换个接口、换几个列字段但实际上每个项目都在重复一套非常繁琐的初始化逻辑而且每个开发写的风格还不一样。有的把请求写在组件里有的把分页参数写死有的把按钮事件绑在全局。结果就是项目一多维护成本直线上升新人接手光读懂各种表格的写法就要花好几天。后面我想明白一件事表格这种高频场景最应该做的就是统一封装。与其每个页面各写各的不如抽一个公共的表格组件库大家按约定传入配置剩下的事情组件内部去处理。我在技术选型时考虑过主流的 Vue Element 方案但当时团队里维护着一批基于 Layui 的存量系统完全推倒重来不现实。于是基于 Layui 把表格包装成一个可配置、可复用的组件库成了性价比最高的一条路。这篇实战教程的内容完完全全来自我实际封装过程中的代码和踩坑记录。我会把整体设计思路、封装实操步骤、核心代码实现以及常见的雷区全部梳理出来。适合这几类人看正在用 Layui 做后台系统、觉得重复代码太多想统一的开发者负责前端架构、想给团队沉淀基础组件的前端负责人以及刚接触 Layui、想深入理解 table 模块本质的初学者。2. 封装前必须想清楚的几个核心问题2.1 企业级表格到底需要什么在动手写代码之前我先把需求列了一遍。企业级这三个字不是白叫的它和“能跑就行”的个人项目天差地别。我归纳下来至少需要覆盖这些点接口返回格式必须统一。企业里后端开发水平参差不齐有的返回{code:0, data:{list:[], total:100}}有的返回{code:200, data:{rows:[], total:0}, msg:success}还有的直接返回一个数组。表格组件必须有能力适配这些差异而不是改一个项目就改一次组件。分页参数和响应解析要内置。Layui 默认的分页参数是page和limit但很多后端接口用的是pageNo、pageSize或者current、size。如果不做适配层每个页面都要改一遍请求参数封装就失去了意义。搜索表单和表格联动。通常页面上方有一排搜索条件点击查询按钮后表格要携带查询参数重新加载。这个逻辑如果每个页面写一遍就容易出现参数没重置、多带了一堆空字符串值之类的问题。操作列的按钮统一管理。编辑、删除、详情、状态切换这些按钮最好通过配置项生成不用每个页面手写一长串templet函数。错误状态处理。请求失败、接口超时、后端返回业务错误码这些情况都要有统一的处理策略。可扩展性。公司内部的需求千奇百怪组件库不能把路堵死得留出自定义插槽和事件透传的通道。2.2 设计原则约定优于配置但必须保留退路我封装这套组件库时最核心的一个设计哲学就是“约定优于配置同时保留退路”。通俗点说就是团队里绝大多数表格的用法是相似的那我们把相似的部分做成默认行为使用者只需要关注差异点。但如果某些页面有特殊需求组件也不能挡路必须能让你绕过默认行为直接拿到最底层的 Layui table 实例去操作。基于这个原则我在设计上确定了三个方向所有配置项都有默认值只传业务相关的核心配置就能跑起来。组件内部不直接访问后端的 URL而是通过一个统一的请求适配器去发请求这样接口格式变了只改适配器。每一次渲染都返回底层 table 实例并且把 Layui 原生的事件透传出来特殊场景可以直接操作实例。另外我把整个组件库按功能拆成了几个模块而不是一个大而全的文件。分别是配置管理器、请求适配器、表格渲染器、表单联动器、操作列生成器、事件总线。这样各模块之间低耦合后续修改某个模块不影响其它模块。3. 基于 Layui 封装表格组件库的核心结构与关键技术3.1 分层设计Layui 模块化思想的应用Layui 本身是一个模块化框架我们可以基于它的模块机制来组织组件库。首先在目录结构上我的划分是这样的src/ ├── modules/ │ ├── configManager.js // 配置管理器 │ ├── requestAdapter.js // 请求适配器 │ ├── tableRenderer.js // 表格渲染器 │ ├── formLinker.js // 表单联动器 │ ├── actionColumn.js // 操作列生成器 │ └── eventBus.js // 事件总线 └── index.js // 组件库入口每个模块通过 Layui 的layui.define来定义内部使用layui.use引入依赖的模块。这样做的好处是整个组件库可以像 Layui 原生模块一样通过layui.use([tablePro], function(){ ... })去加载使用体验对熟悉 Layui 的开发者来说非常自然。入口文件里我做的主要是模块注册和全局配置初始化。Layui 模块定义的基本结构是这样的// index.js layui.define([table, form, laytpl, layer], function(exports){ var table layui.table; var form layui.form; var laytpl layui.laytpl; var layer layui.layer; var tablePro { // 全局默认配置 config: {}, // 注册组件方法 render: function(options){ ... } }; // 把模块导出给全局使用 exports(tablePro, tablePro); });这个入口文件看起来简单但它是整个组件库的骨架。它决定了外部如何引入、如何调用。我建议入口文件里不要写具体业务逻辑只做模块加载、全局配置、方法分发。3.2 配置管理器与全局默认参数配置管理器是组件库的大脑。它负责把用户传入的配置和默认配置做深度合并最终产出一个完整且合法的渲染配置对象。为什么要专门做一层管理而不是直接jQuery.extend一把梭因为默认配置里有嵌套对象比如cols列配置、request请求配置、response响应配置浅拷贝会导致嵌套对象被多个实例共享一个实例改了会影响其它实例。这个问题我在最早一版就踩过坑所以配置管理器里必须做深拷贝合并。配置管理器的核心代码实现如下// configManager.js layui.define(function(exports){ // 深拷贝方法处理对象和数组 var deepCopy function(obj) { if (obj null || typeof obj ! object) return obj; if (obj instanceof Array) { var arr []; for (var i 0; i obj.length; i) { arr.push(deepCopy(obj[i])); } return arr; } var newObj {}; for (var key in obj) { if (obj.hasOwnProperty(key)) { newObj[key] deepCopy(obj[key]); } } return newObj; }; // 默认配置 var defaultConfig { // 请求相关默认配置 request: { pageName: page, // 页码参数名 limitName: limit // 每页条数参数名 }, // 响应相关默认配置 response: { statusName: code, // 状态字段名 statusCode: 0, // 成功状态值 msgName: msg, // 提示信息字段名 countName: count, // 总数字段名 dataName: data // 数据列表字段名 }, // 表格默认属性 defaultTableProps: { limit: 10, limits: [10, 20, 50, 100], page: true, loading: true, text: { none: 暂无相关数据 } }, // 默认错误提示 errorTips: function(msg) { layer.msg(msg || 数据加载失败请稍后重试); } }; // 配置合并方法 var mergeConfig function(userConfig) { var base deepCopy(defaultConfig); // 自定义合并逻辑处理特殊字段 if (userConfig.request) { base.request $.extend(base.request, deepCopy(userConfig.request)); delete userConfig.request; } if (userConfig.response) { base.response $.extend(base.response, deepCopy(userConfig.response)); delete userConfig.response; } base $.extend(true, base, deepCopy(userConfig)); return base; }; exports(configManager, { mergeConfig: mergeConfig, getDefault: function() { return deepCopy(defaultConfig); } }); });这个模块里我特别要强调深拷贝这件事。$.extend(true, ...)虽然能做深拷贝但在某些场景下会出现undefined值被覆盖成undefined导致的小问题所以我干脆自己封装了一个deepCopy遇到对象和数组递归处理代码逻辑一目了然也方便以后的扩展。3.3 数据请求层封装统一参数与响应处理请求适配器是整个组件库最具价值的部分之一。企业级表格和简单 Demo 最大的区别就在于表格需要和后端接口深度交互。我在封装时把请求层从渲染层里拆出来目的是让渲染层不用关心数据和接口是怎么来的它只负责把配置交给 Layui table然后拿数据渲染。先看请求适配器的实现// requestAdapter.js layui.define([jquery], function(exports){ var $ layui.$; var requestAdapter { // 根据配置发送请求 fetch: function(options) { var reqConfig options.request || {}; var respConfig options.response || {}; return $.ajax({ url: options.url, type: options.method || GET, data: options.where || {}, dataType: json, headers: options.headers || {}, success: function(res) { // 判断业务状态码 var statusCode res[respConfig.statusName]; if (statusCode respConfig.statusCode) { var data res[respConfig.dataName] || []; var count res[respConfig.countName]; // 兼容 data 为数组直接返回的情况 if (Array.isArray(data)) { count data.length; } else if (data data.list) { count data.total; data data.list; } options.success options.success(data, count); } else { // 业务错误 var msg res[respConfig.msgName] || 业务处理失败; options.error options.error(msg, res); } }, error: function(xhr, status, error) { var msg 网络请求异常 status ; options.error options.error(msg, xhr); } }); } }; exports(requestAdapter, requestAdapter); });这段代码最重要的地方在于把后端返回的各种格式兼容了。我在多个项目里遇到过不同的后端团队返回结构真的很不一样有的喜欢把列表放在data字段里有的放在data.list里有的直接返回数组。所以适配器里做了一个数据格式归一化处理全部转成data和count两个标准值表格渲染器拿到标准值之后直接用。后续再有新的返回格式只需要在适配器里加一个分支业务页面一行代码都不用改。3.4 表格渲染器与列配置的工程化表格渲染器是组件库的门面。它接收配置管理器产出的最终配置然后调用 Layui 的table.render。但这里有个关键细节Layui 的table.render是自带请求逻辑的如果我们把请求适配器独立出来了就需要让表格不走它默认的 URL 请求方案而是走我们自定义的data传入方案。具体做法是配置里不传url改传data然后通过done回调接收数据。但这又引出一个问题分页加载的时候怎么处理我的做法是自己监听表格的分页事件lay-page重新走请求适配器拿到数据后再用table.reload传入新数据。这样整个请求链路完全由我们自己控制既保持了请求格式的统一又不破坏 Layui 的分页 UI。具体代码如下// tableRenderer.js layui.define([table, configManager, requestAdapter], function(exports){ var table layui.table; var configManager layui.configManager; var requestAdapter layui.requestAdapter; var tableRenderer { render: function(options) { // 合并配置 var finalConfig configManager.mergeConfig(options); var elem finalConfig.elem; var tableIns null; // 构造 Layui table 配置 var tableOptions $.extend({}, finalConfig.defaultTableProps, { elem: elem, cols: finalConfig.cols, // 注意不传 url改用 data data: [], done: function(res) { // 统一调用 done 回调 finalConfig.done finalConfig.done(res); } }); // 首次渲染 tableIns table.render(tableOptions); // 监听分页事件手动加载数据 table.on(page( finalConfig.id ), function(obj) { var where $.extend({}, finalConfig.where || {}); where[finalConfig.request.pageName] obj.curr; where[finalConfig.request.limitName] obj.limit; requestAdapter.fetch($.extend({}, finalConfig, { where: where, success: function(data, count) { tableIns.reload({ data: data, count: count }); }, error: function(msg) { finalConfig.errorTips finalConfig.errorTips(msg); } })); }); return tableIns; } }; exports(tableRenderer, tableRenderer); });这里我踩过最大的一个坑是table.render之后拿到的tableIns在第一次加载完成之前是能用的但如果在done回调里又调用了tableIns.reload会导致重复渲染。后来我学乖了首次渲染走原生流程后续交互全部通过reload更新数据不再在done里做任何 reload 操作。3.5 操作列生成器按钮配置与事件处理操作列是企业级表格里最容易写乱的地方。每个页面都有编辑、删除、详情有的还有自定义按钮。如果用 Layui 原生templet写那每页都是一长串模板字符串加事件委托维护起来很痛苦。我的操作列生成器传一个操作按钮数组自动生成 Layui 的列配置同时注册事件处理函数。为了实现这个我把操作列生成器分成两个部分一个是生成列配置一个是绑定事件处理。先看生成列配置的代码// actionColumn.js layui.define(function(exports){ var actionColumn { // 生成操作列 build: function(actions, opts) { opts opts || {}; var btns ; var btnList []; actions.forEach(function(item) { // item 支持 { name:编辑, field:edit, type:primary, size:sm, icon:layui-icon-edit } var className layui-btn layui-btn-xs; if (item.type) { className layui-btn- item.type; } else { className layui-btn-primary; } if (item.size sm) { className layui-btn-sm; } var iconHtml item.icon ? i classlayui-icon item.icon /i : ; var btn a class className >// formLinker.js layui.define([form, laytpl, laydate], function(exports){ var form layui.form; var laytpl layui.laytpl; var laydate layui.laydate; var formLinker { // 渲染搜索表单 render: function(opts) { // opts.fields: [{name:username, label:用户名, type:text, placeholder:请输入, default:}] // opts.elem: 搜索表单容器DOM var tplStr [ form classlayui-form lay-filter opts.filter , div classlayui-form-item, {{# layui.each(d.fields, function(index, field){ }}, div classlayui-inline, label classlayui-form-label{{ field.label }}/label, div classlayui-input-inline, {{# if(field.type select){ }}, select name{{ field.name }}, {{# layui.each(field.options, function(i, opt){ }}, option value{{ opt.value }}{{ opt.name }}/option, {{# }); }}, /select, {{# } else if(field.type date){ }}, input typetext name{{ field.name }} classlayui-input placeholder{{ field.placeholder }} id{{ field.name }}_date, {{# } else { }}, input typetext name{{ field.name }} classlayui-input placeholder{{ field.placeholder }} value{{ field.default }}, {{# } }}, /div, /div, {{# }); }}, div classlayui-inline, button typebutton classlayui-btn layui-btn-primary lay-submit lay-filter opts.filter _search查询/button, button typebutton classlayui-btn lay-filter opts.filter _reset重置/button, /div, /div, /form ].join(); var tpl laytpl(tplStr); tpl.render(opts, function(html) { $(opts.elem).html(html); }); form.render(null, opts.filter); // 初始化日期选择器 opts.fields.forEach(function(field) { if (field.type date) { laydate.render({ elem: # field.name _date, type: field.dateType || date }); } }); // 查询按钮事件 form.on(submit( opts.filter _search), function(data) { var where data.field; // 过滤空值 var filtered {}; for (var key in where) { if (where[key] ! where[key] ! undefined where[key] ! null) { filtered[key] where[key]; } } opts.onSearch opts.onSearch(filtered); return false; }); // 重置按钮事件 form.on(submit( opts.filter _reset), function() { $(opts.elem).find(input,select).val(); form.render(null, opts.filter); opts.onReset opts.onReset(); return false; }); return opts; } }; exports(formLinker, formLinker); });这里有一个细节值得单独说查询参数的空值过滤。如果不做这一步每次查询都会把username这种空输入框的值传给后端后端还得自己判断空字符串。我在组件库里默认过滤掉空字符串、undefined和null这也是企业级接口的一种约定。4. 实战如何用这套组件库快速完成一个标准查询页4.1 标准页面组装实操手动把各个模块串起来的时候我习惯用一个统一入口方法而不是让使用者在每个页面都分别去调formLinker.render、tableRenderer.render。这样入口方法接收一个页面配置对象内部自动完成表单渲染、表格渲染、查询联动。入口方法的核心代码如下// index.js 中的完整页面渲染方法 tablePro.renderPage function(pageConfig) { // 页面级配置 // pageConfig { // tableId: demoTable, // tableUrl: /api/user/list, // elem: #demoTable, // filter: demoFilter, // columns: [...], // searchFields: [...], // searchElem: #searchForm, // actions: [{name:编辑, field:edit, type:primary}], // actionHandlers: { edit: function(row){ ... } }, // done: function(){ ... } // } // 先渲染搜索表单 layui.formLinker.render({ filter: pageConfig.filter, elem: pageConfig.searchElem, fields: pageConfig.searchFields || [], onSearch: function(where) { // 查询时带参重新加载表格 tableIns.reload({ where: where, page: { curr: 1 } }); }, onReset: function() { tableIns.reload({ where: {}, page: { curr: 1 } }); } }); // 生成操作列 var actionCol null; if (pageConfig.actions pageConfig.actions.length 0) { actionCol layui.actionColumn.build(pageConfig.actions, pageConfig.actionOptions); pageConfig.columns.push(actionCol.col); } // 渲染表格 var tableIns layui.tableRenderer.render({ id: pageConfig.tableId, elem: pageConfig.elem, url: pageConfig.tableUrl, cols: pageConfig.columns, where: pageConfig.where || {}, request: pageConfig.request, response: pageConfig.response, done: pageConfig.done, errorTips: pageConfig.errorTips }); // 绑定操作列事件注意这里要把 tableId 传入 if (actionCol) { layui.actionColumn.bindWithTable(tableIns, actionCol.btnList, pageConfig.actionHandlers); } return tableIns; };使用这套入口之后业务页面的代码量被大大压缩。一个标准查询页只需要写页面结构、配置搜索字段和列配置组件部分完全透明。团队里的新同学上手速度明显快了很多因为他们只需要理解配置项的含义而不需要关心 Layui table 的实现细节。4.2 多接口和后端格式差异的适配团队里同时维护多个老系统时最头疼的就是后端接口格式不统一。有的系统用code表示状态码有的用status数据列表字段有的叫data有的叫rows有的叫list。如果组件不支持配置这些字段名那适配成本就摊到了每个开发者头上。我在配置管理器里设计了request和response两个可覆盖配置块这就让每个页面可以根据当前系统后端的情况进行微调。比如某个老系统的返回结构长这样{ code: 200, data: { records: [ {id: 1, name: 张三} ], totalCount: 50 } }那页面上只要这么传tablePro.renderPage({ tableId: userTable, elem: #userTable, url: /api/user/list, request: { pageName: pageNum, limitName: pageSize }, response: { statusName: code, statusCode: 200, dataName: data, countName: totalCount, dataListField: records }, columns: [...] });请求适配器里加了一个dataListField配置如果有这个字段就先取data[dataListField]。对于这种特殊结构只要修改配置无需改组件代码。我自己在适配器里专门加了一个归一化函数把所有返回格式映射成{ list: [], count: n }的标准结构后续处理逻辑完全统一。4.3 复杂查询条件组件的扩展除了基本的文本框、下拉框和日期选择实际项目里经常有更复杂的搜索需求。例如“按部门树选择”或者“按负责人动态搜索带联想”Layui 的form本身不提供树形选择器但我们可以在表单联动器里预留一个自定义字段类型的通道。我的实现思路是在字段配置里加一个type custom并附带一个renderFn回调函数。表单联动器渲染时遇到custom类型就会调用renderFn(容器, 字段配置)让外部页面自己扩展控件。这样组件库保持核心代码简洁同时能力上可以无限扩展。有个项目是做 OA 审批流的需要在条件栏加一个按审批状态和时间区间组合查询我就是用这个自定义通道做成了一个日期范围加状态选择器的复合控件十分好用。5. 封装过程中遇到的典型问题与排查方法5.1 Layui table 数据格式校验失败这是我用 Layui 表格时最常遇到的问题。Layui 的 table 内置了对数据格式的校验默认要求返回{code: 0, msg:, count:100, data:[...]}这种格式如果字段对不上表格会直接提示数据格式错误并且控制台会输出解析失败信息。排查这类问题时我的经验是把请求适配器里的success回调先用console.log把原始请求响应打出来确认后端到底返回了什么。然后检查response配置里的字段名和后端实际返回是否一致。最容易出错的地方是count字段后端有的叫total有的叫totalCount有的叫count还有的放在data.total里一不小心就漏配了。有一次我们排查了很久最后发现是后端返回的data字段是一个对象而不是数组对象里再包了一层list。适配器里最初只兼容了data为数组的情况后来我看日志才发现这个结构差异于是加了一个dataListField配置专门处理“数据包一层”的情况。所以建议封装时把数据归一化做得尽量健壮用日志说话。5.2 表头固定和操作列宽度问题Layui table 开启了fixed列之后如果操作列按钮较多容易出现宽度不够、按钮换行、甚至表头和表体错位的问题。这种情况很影响观感操作列原本设计在右侧固定结果按钮折成两行整列宽度撑得很宽。我的排查步骤是先看操作列width设置是否合理。Layui 在未显式指定width时会根据内容自动计算但固定列的自动宽度计算有时并不准确。后来我总结了一套经验值操作列里两个按钮时宽度给 180三个按钮给 220四个按钮给 260按钮文字控制在 2 到 4 个字之间这样基本不会出问题。另外如果启用totalRow合计行固定列的宽度也需要手动对齐。我曾经在一个表格里开了合计行又同时开了操作列固定结果合计行错位看起来非常糟。排查后确认是固定列的数量不一致导致的最后在cols配置里显式给所有列都设置了width才解决。教训就是企业级表格如果需要固定列最好把所有列的宽度都显式指定别让表格自动计算自动计算在复杂的列组合下就是给自己埋坑。5.3 事件绑定的问题按钮点击失效、重复事件Layui 的事件绑定和 jQuery 不太一样table.on()绑定的监听器在每次table.render之后会自动清理还是不会清理要看版本。在我的实战过程中遇到过多次按钮点击触发两次甚至多次处理函数的情况。原因就是页面被局部刷新表格重新渲染旧的事件监听还在新的事件监听又加上去了。解决这个问题我用了两个手段。第一个是绑定事件时用命名空间和防重处理在绑定前先off掉该表格实例的同名事件。第二个是所有按钮事件尽量通过操作列生成器统一管理不要在各个页面到处去layui.table.on。统一管理的模式很简单操作列按钮上带>故障现象可能原因排查/解决方法表格提示数据格式错误后端返回结构和 response 配置不匹配打开浏览器控制台查看接口返回按真实结构调整statusName、dataName、countName等配置分页点不动/翻页后无数据分页参数名和后端不一致检查request.pageName和request.limitName配置操作列按钮点击无反应事件绑定时机不对或重复绑定统一使用操作列生成器的绑定方法确认在render完成后注册表格宽度错位/表头和表体对不齐固定列或合计行导致给cols里的每一列都显式设置width弹层里的表格不显示弹层未完全打开就执行渲染将渲染代码放到layer.open的success回调中执行查询条件翻页后失效where参数未在分页监听中带上分页监听里$.extend({}, finalConfig.where)重新拼接查询条件重置后页码没有回到第一页重置逻辑里只清空了表单值在重置回调里同时设置page: { curr: 1 }数据更新后表格未刷新重新渲染时用了render而不是reload数据场景下用tableIns.reload更新数据控制台报table.js:2的.done错误列配置或数据字段里有undefined值检查cols的字段名是否和后端数据的key完全匹配6. 组件库落地过程中的团队实践与扩展建议6.1 如何在团队里推广组件库而不是强推我在封装完组件库之后第一件事不是发全员邮件要求所有项目必须使用而是先选了一个合作比较顺畅的小项目做试点把组件库跑通后再从试点项目的页面里截几个对比图给大家看使用前后的代码量差异。开发最反感的是什么是领导要求用但没给出好东西。如果你的组件库能明显减少代码量统一处理掉各种边界问题不用推大家自然会用。我建议在推广初期准备一份精简的使用文档重点不是 API 列表而是两三个完整的使用例子。开发者照着例子抄一遍就能跑通比你写一百行文档都管用。我在团队里推行时就是靠一个名为“标准查询页示例”的代码片段别的同事复制过去改改字段就能上线反馈相当正面。6.2 事件的扩展与二次开发能力组件库不能是一潭死水。在后续的使用过程中团队一定会提出各种新需求。比如有的页面需要在表格渲染完成后触发一些图表初始化有的页面需要在点击查询后额外记录埋点日志。我在设计时预留了多个钩子done回调表格每次渲染完成后触发支持拿到当前返回数据。onSearch回调查询按钮点击后触发外部可做额外操作。onReset回调重置按钮点击后触发。beforeFetch钩子请求发送前触发用来修改请求参数。afterFetch钩子请求返回后触发用来处理附加逻辑。这些钩子让组件库成为一个框架而非死模板团队开发者可以基于钩子做二次开发而不需要去改组件内部源码。有段时间团队里有人要做一个“列表数据导出前确认弹窗”就是通过beforeFetch钩子拦截请求弹出确认框确认后才真正发请求完全没动组件核心逻辑。6.3 后续演进从 Layui 到跨框架复用基于 Layui 封装组件库在维护老项目时有很大的现实意义。但不可否认Layui 在技术栈更迭的背景下并不占优势。我在组件库设计之初就考虑过这件事所以尽量不让业务代码直接依赖 Layui 的底层对象。请求适配器、配置管理器、数据处理逻辑都是纯 JavaScript只有表格渲染和表单渲染使用了 Layui 的模块。这意味着将来如果要做技术栈升级把渲染器一层替换掉上层的配置和业务代码大部分可以复用。当然真到了全面重构的那一天直接用 Vue 或 React 重写组件库可能是更优的选择。我的经验是封装组件库的价值不在于它绑定了某个框架而在于它沉淀了业务对组件的要求。只要需求分析得足够清楚换框架只是换渲染层的实现。从这个角度讲就算这套基于 Layui 的组件库最终被淘汰我们在这过程中积累的设计经验也不会白费。最后再分享一个我在封装过程中的小体会很多人拿到 Layui 表格后第一反应是去看官方文档然后照着例子改遇到问题就各种百度。但真正的封装工作重点不在 API 记忆而在把业务场景抽象成配置、把重复逻辑压缩成约定、把易错点封装成默认处理。这需要你真正去梳理自己项目里几十个表格页面找出它们的共性和差异。我建议你想封装的话不要急着写代码先把团队里 30 个以上的表格页面的写法全部看一遍统计哪些代码是重复的哪些地方是容易出错的高发区。统计完再动手你会发现封装出来的东西自然就好用因为它是从实际问题里长出来的而不是从文档里抄出来的。
