2026 年 11 月 10 日，Microsoft 将在同一天停止为两个 .NET 版本发布安全更新：.NET 8 和 .NET 9。在这一天之后，平台中发现的任何漏洞都不会在这两个版本中得到修补。如果你的会计系统、销售终端或 ERP 构建在其中之一上——在沙特市场，很多系统正是如此——你只有不到两个月的时间来决定下一步去向。对大多数企业来说，正确的目标是支持到 2028 年 11 月 14 日的 .NET 10，而不是首个候选版本两天前才刚刚发布的 .NET 11。

9 月 8 日发生了什么

2026 年 9 月 8 日，Microsoft 宣布 .NET 11 已达到 Release Candidate 1，并附带 go-live 支持许可——这意味着在正式版发布之前，Microsoft 就正式支持在真实生产环境中运行它。同一天，.NET 10、.NET 9 和 .NET 8 也发布了例行维护更新。

这是技术新闻。对企业主真正重要的新闻却在一个完全不同的页面上：同一天更新的官方支持政策页面明确写着，.NET 8 和 .NET 9 将于 2026 年 11 月 10 日结束支持。光鲜的发布公告吸引了所有注意力，而真正让你花钱的那一行，却写在一张枯燥的表格里。

为什么"长期支持"版本也会失去支持

Microsoft 每年 11 月发布一个 .NET 主要版本。偶数编号版本属于长期支持，可获得三年免费补丁；奇数编号版本属于标准支持，可获得两年。

.NET 8 于 2023 年 11 月 14 日发布，因此它的三年将于 2026 年 11 月到期。.NET 9 于 2024 年 11 月 12 日发布，因此它的两年也大约在同一时间到期。这就是两者都落在 11 月 10 日的原因。团队往往在这里措手不及："长期支持"并不意味着永久支持。它意味着从发布日起算的三年，而在没人留意的时候，这段时间已经过去了很大一部分。

正确的目标是 .NET 10，而不是 .NET 11

面对这样的新闻，条件反射式的反应是"那我们就升级到最新版"。对大多数企业系统来说，这是错误的决定，原因就在同一张支持表里。

.NET 10 于 2025 年 11 月 11 日发布，是长期支持版本，支持到 2028 年 11 月 14 日。一次升级就能为你换来两年多一点的稳定期，无需重新处理这件事。.NET 11 是奇数编号版本，因此只有两年的标准支持，尽管它更新，却会比 .NET 10 更早结束支持。升级到一个更新但更早到期的版本并不是升级——而是附带一张额外账单的推迟。

还有第二点需要考虑。.NET 11 候选版本本身只支持到 2026 年 10 月 13 日，因为它是一个过渡版本，你本应从它继续前进——先到下一个候选版本，再到 11 月的正式版。任何把"go-live"理解为可以把候选版本装进会计系统并一直留在那里的人，非但没有摆脱升级循环，反而给自己报名了一个每月一次的升级周期。

对于运行会计或运营软件的公司，实用规则是：始终选择偶数编号的长期支持版本。把奇数编号版本留给那些持续升级、希望尽早获得新功能的产品团队。

.NET 11 实际带来了什么

为了让决策建立在了解而不是回避之上，下面是候选版本包含的内容。在 C# 方面，版本 15 稳定了联合类型——一种更清晰地表达可以呈现多种形态的值的方式，例如一个要么成功、要么因特定原因失败的操作。在工具方面，测试命令改进了对移动应用的处理，并增加了运行级别的控制选项。

在容器发布方面，镜像生成现在是可复现的，并且会跳过重新上传已存在的层，从而缩短部署时间，也让审计你所交付的内容更加容易。在包管理方面，即使把警告视为错误，现在也能更新存在已知漏洞的软件包——这是一个老问题，过去迫使团队仅仅为了让构建通过而关闭安全检查。在 ASP.NET Core 中，SignalR 的身份验证刷新 API 已最终定型，Blazor Server 线路现在会在刷新后更新其状态，而不是保留过期的身份。Unix 系统上新增了进程内崩溃报告，这意味着服务器在凌晨三点宕机时能获得更好的诊断信息。

这些都是真正的改进。但没有一项能抵消在一个比替代方案更早到期的版本上运行财务系统的风险。

为什么这是合规问题，而不是技术问题

运行一个不再接收安全补丁的平台，并不是工程偏好的问题。《个人数据保护法》(PDPL) 要求任何处理客户数据的组织采取适当的保护措施，而任何一次认真的安全审查都会问你使用的是哪个平台版本、它的支持何时结束。"我们用的是一个八个月前就已结束支持的版本"——这样的回答，你无法在审计师面前、在签约前向你发送安全问卷的企业客户面前，或在网络保险公司面前为之辩护。

同样的道理也适用于接入 Fatoora 平台的电子发票系统。一个对发票进行数字签名并将其传送给政府机构的系统，必须运行在仍能获得加密补丁的平台上。这不是内部细节——它是你的发票所依赖的信任链的一部分。

从现在到 11 月的行动计划

  • 本周——弄清现状。请你的供应商或技术团队列出你运行的每个系统背后的 .NET 版本清单，包括那些没人会想到的小型内部工具和后台服务。在服务器上，dotnet --list-runtimes 可以显示版本；在项目本身中，它是项目文件里的目标框架条目。
  • 下周——分类处理。标记所有运行在 .NET 8 或更早版本上的系统，以及所有运行在 .NET 9 上的系统。已经在 .NET 10 上的系统在 2028 年之前都是安全的。运行在 .NET 6 或 7 上的系统已经多年不受支持，需要紧急处理，而不是排进日程。
  • 两周内——阅读重大变更。Microsoft 会为每个版本发布重大变更列表。从 8 迁移到 10 通常很顺利，但在开始之前阅读能节省好几天。
  • 一个月内——先升级测试环境。更改目标框架、编译、运行测试，然后首先让系统在一份真实数据的副本上运行。
  • 11 月之前——部署。在 11 月 10 日之前至少留出两周的安全余量，不要在月末结账期间或销售旺季部署。
  • 一次到位，长期有效。今天就把 2028 年 11 月 14 日写进公司日历，并定下一条规则：每次升级都升到下一个偶数编号版本。这样，这件事就从每年的意外变成了一项已知的预算科目。

如果系统来自供应商

许多公司并不拥有源代码；他们从供应商那里购买成品系统。在这种情况下，你今天要发出的那一封邮件只需问三件事：系统运行在哪个 .NET 版本上，你们什么时候交付基于 .NET 10 的版本，以及这次升级是包含在我们的支持合同中，还是另行收费。供应商的回答方式，比任何演示文稿都更能说明产品的情况。而一个不知道答案或者一味拖延的供应商，正是你在 11 月 11 日要打电话找的那一个。

来源