本文基于 Microsoft 官方博客及 .NET 团队公告整理翻译,及个人见解。

一、官方公告译文

原文标题End of support looms for .NET 8 and .NET 9

发布日期:2026 年 7 月 1 日

来源:Microsoft .NET Blog / DevBlogs


大家好,我是码农刚子,一个.NET开发程序员。微软近日宣布,.NET 8 和 .NET 9 将于 2026 年 11 月 10 日同时终止支持。这意味着在该日期之后,微软将不再为这两个版本提供服务更新、安全补丁或技术支持

值得注意的是,.NET 8 是一个长期支持(LTS)版本,于 2023 年 11 月发布,本应享有三年的支持周期;而 .NET 9 是一个标准支持(STS)版本,支持周期约为两年。然而,由于 .NET 团队对支持策略的调整,两个版本将在同一天迎来“生命终结”

.NET 团队在解释这一调整时表示:“我们知道一些客户出于对更长支持周期的考虑,选择停留在 LTS 版本上。”这次调整使得 LTS 和 STS 版本的支持结束日期对齐,旨在简化版本管理的复杂度。

支持终止后,现有应用程序仍可继续运行,但将永久暴露于此后发现的任何安全漏洞之中。微软也将在未来的服务更新中将 .NET 8 和 .NET 9 组件标记为“不受支持”。

作为替代方案,微软建议开发者升级到 .NET 10——这是目前最新的 LTS 版本,支持周期将持续至 2028 年 11 月。

.NET 支持时间线显示 .NET 8 和 .NET 9 于 2026 年 11 月 10 日结束,.NET 10 支持至 2028 年 11 月 。

二、我的见解与感受

1. LTS 与 STS 的界限正在模糊

这次调整最值得玩味的地方在于:一个本应享有三年支持的 LTS 版本(.NET 8)和一个仅有两年支持的 STS 版本(.NET 9),在同一天被“宣判死刑” 。这实际上打破了微软自己建立的支持周期承诺。

从积极的一面看,这种对齐简化了企业的版本规划——不再需要分别记住 LTS 和 STS 的不同截止日期。但从另一个角度看,“LTS”这个标签的含金量正在被稀释。如果一个 LTS 版本可以和 STS 版本同一天结束支持,那 LTS 的“长期”到底“长”在哪里?

这或许传递了一个信号:微软希望推动整个 .NET 生态系统以更快的节奏向前滚动,而不是让大量用户长期停留在某个 LTS 版本上。对于 .NET 团队来说,维护多个版本的负担是巨大的,缩短有效支持窗口可以让他们将更多精力投入到新版本的开发中。

2. 对开发者和企业的现实影响

距离 2026 年 11 月 10 日还有大约四个月时间。对于仍在使用 .NET 8 或 .NET 9 的团队来说,这不是一个可以忽视的“软截止日期”

  • 安全风险是真实存在的:支持终止后,任何新发现的安全漏洞都不会得到官方修复。对于面向互联网的应用,这相当于把大门敞开。
  • 合规性问题:许多企业的安全合规政策要求使用受支持的软件版本。继续使用 .NET 8/9 可能无法通过安全审计。
  • 依赖链风险:许多第三方库和工具会逐渐停止对过时 .NET 版本的支持,导致开发和部署流程受阻。

我个人的建议是:如果你的项目还在 .NET 8 上,现在是认真评估升级到 .NET 10 的时候了。.NET 10 作为最新的 LTS 版本,将支持到 2028 年,给你足够的时间窗口。

3. 一点感慨

作为一个长期关注 .NET 生态的开发者,我见证了这个平台从 .NET Framework 的封闭走向 .NET Core 的开源,再到如今每年一个版本的快节奏迭代。这种速度带来了新特性、新性能,但也带来了版本疲劳

每 12 个月就要面临一次“升级还是留下”的抉择,对于大型企业项目来说并不是一件轻松的事。.NET 团队显然意识到了这一点——他们试图通过让 LTS 和 STS 的 EOL 对齐来简化决策,但代价是削弱了 LTS 的“长期”承诺。

或许,未来 .NET 的支持策略还需要进一步演进——比如延长 LTS 的实际支持窗口,或者提供更平滑的原地升级路径。毕竟,开发者的时间应该花在构建产品上,而不是年复一年地折腾框架升级。


距离 .NET 8/9 支持终止还有约 130 天。你的项目准备好了吗?