Pinxian Li1. 先搞明白：Longterm release kernel 到底是什么
你可能在 kernel.org 首页见过那个表格，里面有个分支叫 longterm，后面跟着一串版本号，比如 6.1、5.15、5.10，下面写着 "EOL: Dec, 2026" 或者类似的日期。很多人扫一眼就过去了，以为它跟 mainline 或者 stable 没本质区别，无非就是维护久一点。这个理解方向对，但远远不够。
Longterm release kernel，一般直接叫 LTS（Long Term Support）内核，是 Linux 内核社区专门挑出来做超长周期维护的版本。普通的内核版本，比如 6.13、6.14，mainline 发出来之后，stable 分支大概只会维护六到八个礼拜。也就是说，你这个版本如果没跟上节奏，过了两个月再想修 bug、打安全补丁，上游基本就不管了，你得自己想办法往回移植补丁，或者干脆升到新版本。而 LTS 内核不一样，它的维护周期短则两年，长则六六年以上。
这中间的区别不仅仅是用多久的问题，而是整条产品维护策略的根基。特别是做嵌入式、做 Android 设备、做服务器、做网关这一类场景的，选内核版本跟普通开发者选一个 Linux 发行版完全是两种逻辑。普通桌面用户追新，出什么用什么，坏了重装；产品项目不能这么搞——你总不能因为上游停止维护了，就让卖出去的几万台设备集体换内核吧？
我记得有一次跟一个做工业网关的哥们儿聊天，他说他们的产品用了一个很旧的内核版本，刚开始选型的时候看着挺新，结果项目周期拖了两年，卖出去之后第三年，内核上游早就没人管了。期间爆出几个 CVE（通用漏洞披露），他们只能自己找补丁，手动移植到老内核上，那叫一个痛苦。所以后来他们一律改成 LTS 内核，起码在上游维护周期内，安全补丁和关键 bug 修复是有人管着的，团队要做的只是跟着 LTS 更新节奏走，工作量和风险都小很多。
LTS 到底解决了什么问题？一句话：让产品团队在选内核时，不需要赌“这个版本以后会不会有人管”，而是明确知道这个版本会管到哪一天。
这也就是为什么 kernel.org 上长期维护版本的列表永远是嵌入式、移动、服务器领域的第一参考。你现在去搜 Linux 内核相关的话题，除了那些追新版本的开发动态，真正有决策价值的信息全是围绕 LTS 版本展开的。包括最近频繁被讨论的 Android kernel 选型、高通 CAF kernel 基线，底层都离不开某个 LTS 版本做底座。后面我会详细拆。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. LTS 版本是怎么挑出来的
很多人以为 LTS 版本是内核社区按固定时间节奏发布的，比如“每年固定出一个 LTS”，其实不对。LTS 版本的挑选有一套自己的逻辑，而且充满了“人”的因素，不是纯自动化的流程。
2.1 谁能决定哪个版本成为 LTS
LTS 版本的拍板人不是某个委员会，而是内核稳定版维护者，目前是 Greg Kroah-Hartman（江湖人称 Greg KH）。他在内核邮件列表上发布消息，说“我打算把 6.1 作为 longterm 版本，请大家确认”，然后经过一段时间的反馈，最后宣布确认。这个机制下来有很强的个人判断成分——既要看这个版本是不是足够稳定，也要看是否有足够的维护者和企业愿意跟进。
为什么要看“有没有人愿意跟进”？因为 LTS 版本后续的补丁维护工作虽然是 Greg KH 主导，但实际很多补丁要依赖各个子系统的维护者、发行版团队、芯片厂商一起来投入。如果一个版本发布出来没人用、没企业愿意接手，硬把它定为 LTS，后续维护力量跟不上，反而不如不定。所以 LTS 的选定实际上是社区需求、企业反馈、维护者精力三方博弈之后的结果。
2.2 LTS 的维护周期不是统一的
这里有个关键细节：不是所有 LTS 版本的维护周期都一样长。内核官方给的 LTS 维护周期最短两年，但有些版本会被延长维护。举例来说：
- v4.4 原本维护到 2022 年 2 月，后来因为 Android 生态里大量设备还在用，就延长到了 2022 年 10 月。
- v4.9 原定维护周期结束后被延长到 2023 年 1 月，同样是出于 Android 和嵌入式设备的现实需求。
- v5.10、v5.15 都有类似情况，维护周期根据实际使用情况动态调整。
- v6.1 被确定为长期维护版本，目前计划维护六年，到 2026 年 12 月。这个六年周期在官方 LTS 里算是比较长的。
所以你在 kernel.org 上看到的 EOL（End of Life）日期