<p>选.NET Framework还是.NET 5+取决于项目类型和部署场景：WinForms/WPF旧系统维护且需兼容Windows 7或内网环境，选.NET Framework 4.8；新项目、跨平台、CI/CD或需C# 12特性则选.NET 8.0/9.0；ASP.NET Core Web API必须选.NET 6.0及以上。</p>
选错框架版本，轻则编译报错、IntelliSense 失效，重则运行时崩溃或部署失败——这不是配置问题，是目标平台契约的硬性约束。
选 .NET Framework 还是 .NET 5+？先看项目类型和部署场景
WinForms/WPF 旧系统维护项目，且需兼容 Windows 7 或企业内网未升级环境，选 .NET Framework 4.8（当前最高稳定版）；新项目、跨平台需求、CI/CD 自动化构建、或要使用 C# 12 特性（如主构造函数、别名指令），直接选 .NET 8.0 或 .NET 9.0（2026 年已发布预览版）。.NET Framework 不支持 dotnet publish --self-contained，而 .NET 8+ 默认支持无运行时依赖部署。
- ASP.NET Core Web API → 必须选
.NET 6.0及以上 - Windows 服务（传统 SCM）→
.NET Framework 4.7.2仍最稳妥 - 需要调用 COM 组件或旧版 GDI+ 代码 →
.NET Framework兼容性更强 - 用到
System.Text.Json的高级序列化选项（如JsonSerializerOptions.PropertyNamingPolicy）→.NET Core 3.0+才有，.NET Framework需额外 NuGet 包且功能受限
在创建向导里选版本时，注意三个隐藏陷阱
Visual Studio 2022+ 的“创建新项目”对话框中，.NET 版本下拉菜单看似直观，但实际受模板类型强绑定：
Visual Studio Professional 18.8.1
下载
Visual Studio 18.8.1 官方固定版本安装引导程序，当前条目使用微软发布历史中的 Professional Web Installer，适合旧项目兼容、环境回退、复现特定构建链和排查版本差异等场景。
- 选“Windows 窗体应用 (.NET Framework)”模板 → 下拉列表只显示
4.5到4.8，选不了.NET 5+ - 选“Windows 窗体应用”（无后缀）模板 → 下拉列表默认从
.NET 6.0开始，不显示任何.NET Framework版本 - 搜索模板时输入 “winforms” 会混出两类模板，必须看清括号标注，否则点“创建”后才发现目标框架不可改
- 某些模板（如“类库”）在 .NET 8 下默认启用
Nullable上下文，而同名模板在 .NET Framework 下默认关闭——这会导致迁移时大量空引用警告
改已建项目的框架版本，不是改个下拉框就完事
右键项目 → 属性 → 应用程序 → 目标框架，这个操作看似简单，但背后触发的是整套兼容性重校准：
-
.NET Framework 4.6.1 → 4.8：通常安全，但若项目引用了Microsoft.Bcl等兼容包，需手动移除，否则运行时可能加载冲突的System.Numerics.Vectors -
.NET 5.0 → .NET 8.0：MSBuild 工具链自动升级，但appsettings.json中的Logging配置节结构可能变化，需检查Program.cs中的Host.CreateDefaultBuilder调用是否被替换为WebApplication.CreateBuilder -
.NET Framework → .NET 6+：属于跨代迁移，不能直接改下拉框。必须新建项目，逐个迁移源码、重配 NuGet 引用（如把Newtonsoft.Json换成内置System.Text.Json），并验证所有 P/Invoke 声明（DllImport的EntryPoint和CallingConvention行为有差异）
真正容易被忽略的点：框架版本决定的是 API Surface 和 JIT 行为，而不是“能不能跑”。哪怕 TargetFrameworkVersion 改对了，如果项目里用了 Assembly.LoadFrom 动态加载一个只面向 .NET Framework 4.0 的 DLL，照样在 .NET 8 下抛 FileLoadException ——这种问题不会在编译时报错，得靠真实环境测试暴露。
