.NET SDK10.0.400

.NET SDK 是创建、编译、测试和发布 .NET 应用所需的开发工具包，不等于只负责运行程序的 Runtime，也不等于 Visual Studio、VS Code 或 Rider 这些编辑器。当前官方页面把 .NET 10 标为 LTS 版本，SDK 稳定版为 10.0.400，发布日期为 2026-08-11；安装前最重要的是确认项目目标框架、操作系统架构、SDK 选择规则与最终部署方式。

先分清 SDK、Runtime 和编辑器

SDK 包含 dotnet CLI、编译器、MSBuild、模板、NuGet 还原和发布工具，负责把源代码变成可测试或可部署的产物。Runtime 只提供运行已构建应用所需的组件；SDK 会带上对应的 .NET Runtime，但单独安装 Runtime 不能替代开发环境。Visual Studio、VS Code、Rider 等编辑器可以调用 SDK，却不会改变项目实际选择的 SDK 版本。

如果目标只是运行别人发布的桌面、Web 或控制台程序，先看它要求的 Runtime；如果要创建项目、安装工作负载、执行测试或生成发布目录，才需要 SDK。这个区分能避免在服务器上安装不必要的开发组件，也能减少本地“能运行、不能构建”的误判。

先判断 LTS、补丁和预览版本

官方支持策略把偶数主版本作为 LTS 轨道，.NET 10 的支持期到 2028-11-14；当前页面同时展示 .NET 11 Preview，但预览版用于提前试用，不应在没有明确验证计划时作为生产默认。SDK 的完整版本号、Runtime 的补丁版本和 Visual Studio 的兼容版本不是同一个字段，更新时要分别记录。

版本号还会影响 SDK feature band、模板和语言工具链。不要只看到“10.0”就认为所有 10.0 SDK 完全等价；项目若依赖特定模板、工作负载或构建行为，应在仓库中固定可接受的 SDK 范围，并把升级作为一次可回滚的变更。

按系统和架构选安装入口

.NET 10 SDK 官方页面列出 Windows、macOS 和 Linux 安装入口，并区分 x64、x86、Arm64，以及 Linux 的 Arm32 和 Alpine 变体。下载前先确认运行开发工具的主机架构；发布目标的架构可以在后续通过 Runtime Identifier（RID）另行选择，不要因为目标要部署到 ARM 就把开发机安装包也随意换成 ARM 版本。

安装完成后先在新终端执行 dotnet --info、dotnet --list-sdks 和 dotnet --list-runtimes。它们分别帮助确认当前解析结果、已安装 SDK 列表和 Runtime 列表；如果 IDE 与终端结果不同，再检查 IDE 的工作目录、环境变量和它实际调用的 dotnet 路径。

从模板创建一个可运行项目

让 CLI 先建立项目边界

1. 创建目录：为项目准备独立目录，避免在包含多个解决方案的父目录中误用模板或 global.json。
2. 生成模板：运行 dotnet new console --name HelloApp，Web、类库和测试项目则选择对应模板；模板只是起点，目标框架仍需结合项目约束检查。
3. 还原并运行：进入项目目录执行 dotnet run。多数需要依赖的 CLI 命令会隐式执行 restore，网络或私有 NuGet 源异常时要把还原阶段单独看待。
4. 记录产物边界：确认 .csproj、解决方案文件、目标框架、包引用和生成目录，不要只以终端出现 Hello World 判断项目已经适合交付。

官方 CLI 的优势在于编辑器之外也有一条可重复的入口：模板、构建、测试和发布都能放进脚本或 CI。编辑器可以提高体验，但项目真正的依赖关系和构建参数仍由项目文件、SDK、NuGet 源与命令行参数决定。

用 global.json 控制 SDK 解析

global.json 用来选择 .NET CLI 使用的 SDK 版本，与项目目标 Runtime 版本相互独立。没有它时，CLI 通常使用机器上可用的最高 SDK；写入具体版本后，rollForward 决定精确版本缺失时能否滚动到同一 feature band、更新补丁或更高版本。

排查“本地成功、CI 失败”时，先比较 dotnet --version、当前工作目录、global.json 位置、NuGet 源和目标框架，再决定是安装缺少的 SDK、调整滚动策略还是修复工作目录。直接删除 global.json 往往只是把版本漂移隐藏起来。

把构建、测试和发布拆开

开发循环最好分成可定位的阶段：先 restore，再 build，再 test，最后 publish。dotnet test 会构建并运行测试；dotnet publish 会编译应用、读取依赖并把部署所需文件写入输出目录。把它们合并成一个“发布失败”命令后，通常很难判断问题来自包源、编译器、测试运行器还是目标运行时。

• 还原：确认 NuGet 源、锁定文件、私有包凭据和网络代理；公开日志不要输出访问令牌。
• 构建：先使用明确的 --configuration Release 或 Debug 配置，检查目标框架和警告，再进入测试。
• 测试：按项目或解决方案运行 dotnet test，需要时使用过滤器、结果日志和固定测试运行器。
• 发布：明确输出目录、目标 RID、是否 self-contained，并保存发布目录清单和版本信息。

在 CI 中可以让 restore、build、test、publish 使用同一个 SDK 镜像和提交版本，但不要把缓存命中当成构建证据。缓存键至少应考虑 SDK、操作系统、架构、目标框架、锁定依赖和构建配置。

发布模式决定目标机需要什么

dotnet publish 的输出不是简单复制一个 DLL。framework-dependent 发布依赖目标机已有兼容 Runtime；self-contained 会把 Runtime 一并带上，但仍需为目标 RID 生成对应产物，文件体积、补丁责任和部署策略也会改变。

如果只是验证项目能否编译，先执行默认的 dotnet build；如果要交付给另一台设备，再使用目标 RID 和明确的 self-contained 策略执行 dotnet publish。发布成功只说明构建链完成，不自动证明目标系统的服务权限、配置文件、外部数据库或原生依赖已经就绪。

按层排查 SDK 与发布问题

.NET SDK 的稳定使用方式不是永远停留在某个旧版本，而是让版本、依赖、测试和发布目标都可追踪。新项目可以从 .NET 10 LTS 开始评估，维护旧项目则先看目标框架、包兼容性和部署环境，再决定升级 SDK、Runtime 还是只更新补丁。