原文来源：.NET 8 and .NET 9 will reach End of Support on November 10, 2026
这个公告很直接，团队应该以同样的清晰度回应：如果你计划在 2026 年 11 月 10 日之后继续在 .NET 8 或 .NET 9 上发布，你是在做出一个有意的不受支持运行时决定。
应用会继续运行。这不是重点。重点是安全和维护更新将会停止。一旦发生这种情况，每个已知的、没有反向移植路径的漏洞都会成为你的运维责任。
我的个人观点：组织经常将框架升级视为可选的维护，然后在紧急窗口、审计发现和匆忙的供应商升级中为这个决定付出代价。升级规划应该是一个产品路线图项目，而非一个支线任务。
面向 .NET 团队的实用迁移立场：
- 将 .NET 10 迁移设定为带日期的目标，而非开放式的积压项目。
- 现在就将兼容性和回归测试与功能开发并行进行，而不是等到第四季度。
- 将依赖和托管准备作为单独的工作流跟踪，因为很多失败发生在项目文件之外。
- 尽早使用 Upgrade Assistant 和破坏性变更文档，以提前发现意外。
如果你拥有多个产品使用的共享库，在组织内部公开发布你的 .NET 10 支持时间线。下游团队需要前置时间。
Visual Studio 的"不再受支持"组件标记在操作上也很重要。它创建了一个清晰信号，表明工具链清理是保持合规的一部分。忽视这一点的团队通常会在混合 SDK 状态和不一致的构建行为中越陷越深。
一个较少被讨论的细节是 .NET 8 和 .NET 9 在同一日期终止支持。这压缩了那些以为分批采用能获得更多缓冲的组织的升级窗口。如果你为了功能访问而迁移到 .NET 9，你仍然落在同一个支持悬崖上。
对于平台负责人来说，决策矩阵很简单：在截止日期前迁移，或者记录并接受带有补偿性控制的非受支持风险。没有第三个"什么都不变"的选项。
好消息是 .NET 10 是一个 LTS 目标，支持到 2028 年 11 月——一旦你完成迁移，就能获得稳定的运行时间。
不要等到最后的补丁星期二才开始。把它当作一个有安全影响的交付截止日期来对待，因为事实就是如此。
