1.4 该用老版本还是新版本：一张决策表

正面回答这个高频疑问

前几节铺垫了定位、时间线与文档站，本节直接给出全书最核心的答案。先说结论：新项目一律用 2.13.x（截至 2026 年 8 月，最新版本为 2.13.9）；存量老项目按升级成本评估，能升则升；必须兼容 IE8 的场景，钉死在 2.9.x。先把几条硬约束列成速查：

一张决策表

下面这张表是本篇的落点，也是全书的总纲之一：

读这张表时注意两点。第一，推荐版本不是唯一解：比如维护中的 2.6.x 项目，若改动预期极少、生命周期只剩几个月，留在原地也是理性选择；但只要项目还要长期演进，升级就应尽早排期。第二，场景可以叠加：一个需要 i18n、团队又恰好是 jQuery 老手的新项目，答案依然是 2.13.x——多重约束取交集即可，并不冲突。

为什么不建议用老版本开新项目

• 理由一：老版本停在 2.6.8，是一条已经终止的版本线，问题不会再有官方修复，踩到的坑只能自己填。
• 理由二：新版本自 2.8.0 起持续迭代，到 2.13.9 已进入高频发版期，新项目从第一天起就站在活跃维护的红利上。
• 理由三：升级成本会随时间放大，代码量越大越难迁移；用新版本起步，等于把未来升级的成本提前归零。

这三条理由中，第二条最容易被低估。很多团队不关注发版节奏，直到遇上无人修复的问题才意识到，框架是否持续活跃，本身就是项目长期稳定的一部分。

老项目怎么办

老项目不必恐慌，也不必立刻大动干戈。我的建议分三步走：

• 第一步，确认项目当前使用的 layui 版本，先把家底摸清。
• 第二步，评估升级成本：查新官网 notes 里的 2.8+ 升级指南与浏览器兼容说明，梳理项目对老组件、老行为的依赖点。
• 第三步，按成本排期：能平滑升级就升到 2.13.x；确有 IE8 硬约束的，留在 2.9.x；暂时不动的，至少把文档版本对齐，避免查错文档。

具体到每个版本段的升级差异与操作细节，本书后续篇章会逐一展开，这里先把方向定下来。

还有一类读者要特别提醒：接手别人留下的 layui 项目时，不要假设文档和代码是配套的。先核对版本号，再决定查哪个站、用哪份文档——这一步在 1.3 节已经强调过，放在选型场景下同样成立。

写在最后

选型问题的答案其实从来不复杂：能用新的就用新的，被历史绊住的按成本解套。layui 这条从 2.6.8 停更到 2.13.9 重启活跃的版本曲线，已经替你回答了大方向；剩下的，只是把手上的项目对号入座。带着这张决策表，我们进入下一篇，去看看新老版本之间到底差在哪里。