.NET 11 的客户端，不是人了

十一月十日，一封通知躺在一个内部系统管理员的邮箱里：.NET 8 的支持到今天为止。没有报警，没有红字，系统照常跑着，早上要点的那个按钮还是那个按钮。同一时刻，另一块屏幕上，.NET Conf 的直播刚开始，会上宣布 .NET 11 正式发布。

两件事摆在一起，比单看任何一件都清楚：一个框架给新版本剪彩的同一天，把两个旧版本从支持名单上划掉了。.NET 8 和 .NET 9，都在 2026 年 11 月 10 日 EOL。日子是排好的，不是碰巧。

全篇一图看懂

剪彩和告别，排在同一天

.NET Conf 2026 从 11 月 10 日开到 12 日，全程线上。.NET 11 在会上正式发布，网页、移动端、桌面都在里面，AI 这一摊也在里面；C# 15、运行时异步、EF Core 11，全挤在这三天里讲完。

EOL 不是开关。程序还跑，包还能装，只是从这天起，安全补丁不再来了。一个停在旧版本上的内部系统，能这样安静地再活两三年，直到某个漏洞被公开，而没有人再为它修——断的是一整条补丁链，后果落在某一天，不落在通知里。

节奏早就定了：一年一版，奇数年发 LTS，偶数年发 STS。发布、支持、到期，像列车时刻表。真正的问题不是哪班车更新，是你手里的票对得上哪一班。

更麻烦的是，这件事不会有第二个人提醒你。监控盯的是进程、端口、错误率，没有一项指标叫「支持到期」；等它出现在周报上，往往是因为别的事先出了岔子。

这次最该看的一条，藏在发布清单的中段：ASP.NET Core 原生支持 MCP。现有 API 加几行配置，就能和 AI 智能体对话；dotnet new 里内置了 MCP Server 模板；官方的 MCP C# SDK 也发了 v2.0。

判断一：MCP 进 SDK 不是又一个集成。过去二十多年，框架的接口是写给程序员看的——文档、类型、报错、IDE 里的补全，全为了让一个人读懂它，然后用它。现在坐在对面的可能是一个模型。

模型不读 README。它读工具描述、参数结构、返回格式。你在文档里写一句「传 null 表示使用默认值」，以前是给人的提示；现在这句话会被一个 agent 当成决策依据。同一行字，读者换了，重量也换了。

官方路线图把「建智能体网页应用」列进了优先方向。优先级排序通常比功能表更能说明一个版本想去哪：暴露能力这件事，正从「写教程教人怎么调」变成「写清单告诉模型能做什么」。前者要读者有耐心，后者只要求描述准确。

新 SDK 的 v2.0 选了 stateless-by-default，默认无状态。默认值是软件里最硬的表态：文档可以写三条建议，默认值只有一个。

过去十年习惯的是另一套：长连接加会话状态，WebSocket、粘性会话、进程内存里那个字典。前提是对面坐着一个人，一个人一个会话，会话可以舒服地住在内存里。

无状态把这个前提抽走了。每个请求自带上下文，服务器不认人，只认请求；要扩容就加机器，不用管请求落在哪一台。代价是状态得搬到外面：数据库、缓存，或者调用方自己身上。

判断二：这是一次对习惯的反叛。老代码里那些 static 字典、进程内缓存、Session，全要重新想一遍。它不是免费的性能，是一次结构性的搬家，而且是在你还在写业务的时候发生的。换个角度想：过去默认「记住你是谁」，现在默认「不信你是谁」，各来一次请求，各带各的上下文，服务器反倒轻了。

运行时异步从预览转正，在 net11.0 里默认开启，异步繁重负载的内存开销大幅下降，据公开评测最高到 7,400 倍。转正的意思是：不用开开关，不用挂实验标记，升级之后它就在那儿干活。

倍数是倍数。这类数字多半来自特定压测场景，不是所有代码都吃得到。普通 CRUD 接口跑上去，感受很可能小得多。值不值，拿一段真实负载压一遍，比看榜靠谱。

C# 15 给的是另一类东西：联合类型、封闭类继承体系。听着抽象，落到手上是同一件事——把一个值可能是什么、不可能是什么，写进类型里，让编译器替你守。写业务的人先感觉到的，是少写了几段防御代码。

EF Core 11 加了 FullJoin，也加了向量加关键词的混合检索。数据库不再只是存表格的地方，开始给「找一个相似的东西」这类活预留座位。给模型的查询和给人的查询，写法开始分岔。

先只看日期。.NET 11 是 STS，支持 24 个月，预计 2028 年 5 月 EOL；.NET 10 是 LTS，支持到 2028 年 11 月。差这半年，够一个项目从评估走到上线。

把三条线并排摆在桌上，是这么三行：.NET 10｜LTS｜支持到 2028 年 11 月；.NET 11｜STS｜24 个月，约 2028 年 5 月 EOL；.NET 8 与 .NET 9｜已 EOL｜2026 年 11 月 10 日。

这半年也不是只差在纸面上。选 STS，等于把下一次迁移的起点提前半年摆到桌面上；选 LTS，是把这段时间买回来，代价是暂时用不上新版本的功能。两种选法没有对错，只有合不合适。

判断三：STS 不是升级理由。它的价值在于让想试新东西的团队有地方去，而不在于让所有人都上去。把它当成义务，一年一次的迁移会把人拖垮；把它当成一个可选的窗口，它才成立。

外部评论里有条建议值得照抄：大多数生产服务该上 .NET 10 LTS，只有要建 MCP 服务器、要用联合类型或运行时异步的团队，才值得升 .NET 11。拆成两栏，对号入座就行。

该等的（多数人）：还在 .NET 8 / .NET 9 上，或者跑生产服务、这半年没有硬需求的，先去 .NET 10，能安稳用到 2028 年 11 月。迁移本身变量已经够多，不必在迁移期再加一个 STS。
该升的（少数人）：要给现有 API 接智能体，或者建模上确实要联合类型和封闭继承的，.NET 11 是唯一站得住的答案。MCP 模板和 v2.0 SDK 省掉的那层胶水，比发布会上的形容词实在。

回到那封邮件。它不会催第二次，也不会有人打电话提醒补丁停了。支持窗口听着宽裕，扣掉评估、测试、灰度、回滚预案，剩下的日子并不长。框架往前走得很稳，是它的用户常常停在原地。