4.1 升级前评估：兼容项、浏览器底线与破坏性变化

升级失败的项目，多半败在没评估就动手。我的习惯是先花半天时间，把项目里 layui 的使用面摸清楚，画出一张地图：哪些组件在用、多少页面引用了 layui、有没有深度定制。这张地图决定了后面替换与回归的工作量，也决定了你敢不敢升。评估不是走形式，是画地图——地图越细，后面的路越好走。

摸清使用面：三个盘点维度

盘点可以从三个维度展开：

组件维度：项目里用到了哪些组件。重点记录 table、form、layer、laydate、upload、element 这几个高频模块，它们是回归测试的主战场。
页面维度：多少页面引用了 layui，哪些是核心业务页。核心页要重点回归，边缘页抽查即可。
定制维度：有没有改过源码或深度定制主题。这是最大的不确定项，文末单独说。

盘点结果建议记录成表，方便团队对齐：

版本事实很清楚：2.10.0（2025-03-13）起浏览器底线是 IE9，这一版同时引入了 component 构建器、全新 tabs 组件，内置 jQuery 也升到了 3.7.1。如果你的项目还需要支持 IE8，就不要升到 2.10 及以上，钉在 2.9.x 是更稳妥的选择。

判断标准只有一个：看真实的用户访问数据，而不是拍脑袋。后台管理系统用户浏览器可控，多数可以直接升；面向公网的老系统要先查统计再定。

从 2.6 到 2.13 跨了多个版本区间，排查重点有三处：

jQuery 升级带来的插件兼容：内置 jQuery 升到 3.7.1，老项目里依赖 jQuery 旧行为的第三方插件可能出现兼容问题，需要逐一验证。
element 模块拆分：2.13.0（2025-10-24）把 element 拆成 tab、nav、breadcrumb、progress、collapse 五个组件模块，原接口保留兼容。虽然不迁移也能跑，但要统计项目里 element 的调用点，为后续迁移做准备。
laytpl 行为差异：2.11.0（2025-04-21）重构了 laytpl，模板里若有复杂语法或依赖旧解析行为的写法，需要重点回归渲染结果。

另外提醒一点：2.13.0 还重构了 carousel、colorpicker、flow、transfer、tree 这几个组件，如果项目重度使用它们，回归工作量要单独估算。这些组件的接口在重构后可能有细节调整，升级前把项目里的调用方式抄录下来，升级后逐条对照，是最省事的验证办法。

把所有检查项汇总成一张风险表，逐项确认后再决定动手时间：

这是我吃过亏之后的结论：谈升级之前，先搜索确认项目里的 layui 是不是官方原版。把本地的 layui.js、layui.css 与对应官方版本比对，凡是改过的文件都要标出来。魔改过的源码一旦被新版覆盖，那些改动会无声消失，等线上出问题才发现，代价远比升级本身大。

魔改项能改回官方写法的先改回去，实在改不回去的，记下来在升级时重新实现。重新实现也要趁早：带着魔改包袱升级，等于给新房埋了旧管线，早晚要再挖开一次。评估阶段多花的半天，换来的是升级当天的心里有底，这笔账怎么算都划算。