📦 版本动态
当前最新稳定版本为 .NET 10.0.12（2026 年 9 月 8 日发布）。对于还在维护或筹备迁移的企业级应用，可以参考笔者之前发布的 C# 14 核心特性解析 了解上一代大版本的变动细节。
与此同时，.NET 11 Release Candidate 1 (RC 1) 已于 2026 年 9 月 8 日发布（官方博客于 9 月 24 日最后修订）。这一版本正式具备了“Go-Live”商业支持许可，意味着开发者现可将其部署至生产环境。本次 RC 1 核心变化包含：
| 变化点 | 实际影响 |
|---|---|
| 底层 JIT 与 GC 内存优化 | 引入了更激进的内联策略与内存分配逻辑。高并发微服务场景下的冷启动时间与内存碎片率显著下降，对运行在资源受限的容器内应用尤为关键。 |
| C# 15 特性全面锁定 | 扩展的模式匹配（Pattern Matching）与更灵活的类型推断进入最终定型阶段，直接消减了大量样板代码（Boilerplate）。复杂领域模型映射与规则引擎代码的维护成本大幅降低。 |
| .NET SDK 工具链增强 | MSBuild 与 NuGet 依赖解析速度显著提升。对于拥有超过 50 个 Project 依赖的大型解决方案，CI/CD 构建流水线时间缩短约 15%-20%。 |
📝 深度条目
1. AG-UI .NET SDK 官方发布：Agent 交互标准化
发生了什么：.NET 团队与 CopilotKit 合作，在 NuGet 官方源发布了 AGUI.Server 与 AGUI.Client 库（MIT 协议）。该 SDK 将原有的 Microsoft Agent Framework (MAF) 底层替换为标准的 Agent-User Interaction (AG-UI) 协议。
为什么重要：过去开发 AI Agent 需要针对不同的模型与前端框架处理碎片化的流式响应（Streaming Format）。AG-UI 协议提供语言无关的事件流，把长连接中的 Agent 行为严格抽象为 RUN_STARTED、TEXT_MESSAGE_CONTENT、STATE_DELTA 等标准事件。核心的 ToChatRequestContext 和 AsAGUIEventStreamAsync 方法内置了复杂的双向序列化逻辑，甚至包括了中断处理。
对谁有影响：跨端 AI 服务端开发者。目前只需维护一套基于 IChatClient 的 C# ASP.NET Core 后端代码，不仅能被 .NET 客户端原生消费，也能无缝接入 TypeScript（React/Vue）前端生态。
来源链接：AG-UI Protocol now has a first-class .NET SDK
2. Blazor AI Components：重塑应用级 AI 交互 (Agentic UI)
发生了什么：依赖于最新的 .NET 11 RC 1 SDK，微软推出了实验性的 Microsoft.AspNetCore.Components.AI 界面包。其核心组件 <ChatPage Agent="_agent" Placeholder="Ask me anything…" /> 可直接渲染并控制后台 UIAgent 的状态流。
为什么重要：单纯的聊天文本框已无法满足复杂业务，用户需要直观看到 Agent 执行的中间步骤，并交互式地编辑共享状态（Shared State）。Blazor AI 提供了 ContentBlock 机制，将对话内容、工具调用（Tool Calls）、权限审批操作映射为具象的 Razor 块组件。底层的代理接口既可直接对接 Microsoft.Extensions.AI，也可包裹 AGUIChatClient 对接上述的远程服务端点。
对谁有影响：全栈 Blazor 开发者。无需手写易错的 WebSocket/SSE 状态同步状态机，利用现成 C# 强类型组件模型即可低成本搭建企业级 Copilot 面板。
来源链接：Build Agentic UI with the new Blazor AI components
3. NetWasm 亮相：82.5 KB 的纯正独立 .NET 运行时
发生了什么：独立项目 NetWasm 在 Hacker News 亮相，提供了一个完全在浏览器内运行的纯 WebAssembly .NET 编译器与运行时。其编译出的基础 Hello World C# 模块体积仅为微小的 82.5 KB，引发了极大关注。
为什么重要：官方提供的 Native AOT 技术路线虽然性能强悍，但在纯前端场景下存在不可避免的基础库体积膨胀与重型编译工具链依赖。NetWasm 绕过了重型服务器编译，允许在浏览器内直接执行轻量级的 csc 编译逻辑并下发微型 Wasm 模块。
对谁有影响：包体积高度敏感的前端开发者与 WebAssembly 极客。目前该项目仍处于早期（尚未实现完整的表达式树与 Web Workers 多线程），但在轻量级前端插件开发中验证了 C# 独立微型运行时的可行路径。
来源链接：NetWasm Playground | HN 讨论
4. C# 原生进程转储（Memory Dump）方案与现代互操作
发生了什么：.NET 团队官方撰文，详细讲解了如何在 C# 代码内部建立自诊断机制：针对线程池耗尽（Thread Pool Saturation）等难以通过常规日志排查的故障，实现应用内部自动触发内存转储。
为什么重要：传统的 Dump 操作往往依赖外部工具（如 Sysinternals 的 ProcDump 或是 Linux 的系统特权指令）。官方演示了一种内建的监控模式：利用 ThreadPoolWatcher 独立线程定期检测后台 Task 的执行延迟。一旦延迟触发阈值，代码将直接调用 Windows 的 dbghelp.dll (MiniDumpWriteDump) 或是调用 Linux 内置的 createdump 工具完成 125MB - 800MB 不等的转储。同时，在示例代码的官方讨论区中，开发者也针对老旧的 [DllImport] 与 C# 现代的 [LibraryImport] 源生成器（Source Generator）的性能取舍展开了技术交流。
对谁有影响：后端微服务架构师与 SRE 运维人员。这种“自发诊断”模式让生产环境崩溃时的错误收集过程实现高度自动化，大幅缩短了排查死锁或底层资源耗尽的平均修复时间 (MTTR)。
来源链接：Creating a memory dump in C#
🔥 社区热议
1. 轻量独立运行时 vs 官方 Native AOT 战略路线之争
在 NetWasm 的 Show HN 讨论（5 Points, 4 Comments）中，开发者针对 WebAssembly 生态下 C# 语言的演进方向展开了辩论。 核心分歧点：
- 特性同步派：坚持第三方运行时应该努力追赶 C# 最新语言特性，确保现有的后端与桌面端跨平台代码能够毫无缝隙地迁移至浏览器，维持语言的一致性体验。
- 极简瘦身派：主张在浏览器沙盒场景下，完全没必要强求大而全；更具战略意义的做法是官方或社区提供一个高度契合 Wasm 内存模型的“C# 语言强化子集”，彻底抛弃部分面向对象历史包袱，以换取极速的加载与解析时间。
来源链接：Show HN: NetWasm
2. Yengi：独立游戏开发者的“自愈式” AI 工具箱
一名教师背景的非企业开发者开源了基于 .NET 8 构建的 AI 3D 游戏开发环境 Yengi（HN 2 Points, 在 Reddit 与 GitHub 双线引发关注）。 讨论核心机制：
- 该项目的亮点在于利用 C# 建立直接控制 Unity 编辑器的底层 TCP Socket 实时通道，并配合首创的 “Self-Healing Repair Agent Loop”（自愈修复代理循环）。
- 与传统的静态代码生成不同，一旦 AI 生成的 C# 场景脚本出现语法编译错误或运行时异常，宿主环境会立刻捕获异常调用栈，直接喂回给大语言模型进行原地热修复与热重载。这种结合了 C# 强类型反射与 Roslyn 动态编译能力的 Agentic Workflow 模式，以极低的成本重塑了独立游戏开发者的试错体验。
来源链接：GitHub - Yengi | HN 讨论
下周关注
.NET 11 的正式版已敲定于 11 月的 .NET Conf 2026 大会发布。在此之前，最后的一个测试版本 RC 2 预计将在近两周内释出。随着最终版本的临近，RC 2 阶段通常仅包含最高优先级的 Bug 修复，不再接受任何公共 API 变更。笔者建议企业团队抓紧利用 RC 1 对现有核心业务库（如 Entity Framework Core 或是依赖深度反射的第三方 gRPC 库）进行最终版本的兼容性回归测试，为 11 月的整体迁移做好准备。
