.NET Core 已是唯一主线，.NET Framework 停止更新且仅限 Windows；2023年起新项目应基于.NET 6+；.NET Framework无自包含部署，依赖系统运行时；HttpClient底层实现、证书验证、配置迁移等存在关键差异。
不是“该选哪个”，而是“.NET Core 已经是唯一主线，.NET Framework 停止更新且仅限 Windows”。2023 年起所有新项目都应基于 .NET 6 或更高版本（即统一后的 .NET），.NET Framework 4.8 是最终版，不再接收功能更新，只在极少数遗留场景下维持安全补丁。
为什么 dotnet publish 在 .NET Framework 下不生成独立可执行文件
.NET Framework 依赖系统全局安装的运行时（如 C:\Windows\Microsoft.NET\Framework64\v4.0.30319），它没有“自包含部署”概念；而 .NET 5+ 默认支持 --self-contained true，会把运行时打包进输出目录。
- 在
.NET Framework中，publish只复制程序集和配置，目标机器必须已安装对应版本的 Framework - 在
.NET 6+中，dotnet publish -r win-x64 --self-contained true会输出完整可运行目录，无需预装运行时 - 若误用
TargetFramework为net48却期望跨平台发布，会直接失败或运行时报System.IO.FileNotFoundException: Could not load file or assembly
HttpClient 在 .NET Framework 和 .NET Core 中的行为差异
HttpClient 的生命周期管理在两个平台上表现一致，但底层实现不同：.NET Framework 使用 WinHTTP 或 WebClient 栈（受系统代理、TLS 版本策略限制），而 .NET Core 使用托管 SocketsHttpHandler，默认启用 HTTP/2、更细粒度控制 DNS 超时和连接池。
-
.NET Framework下HttpClient.DefaultRequestHeaders.UserAgent可能被系统策略清空，需显式设置 -
.NET 6+中HttpClient默认启用http2，若服务端不支持，需手动禁用：var handler = new SocketsHttpHandler { EnableMultipleHttp2Connections = false, MaxConnectionsPerServer = 100 }; - 证书验证逻辑不同：.NET Framework 遵循 Windows 证书存储，.NET Core 使用 OpenSSL（Linux/macOS）或 Schannel（Windows），
CertificateValidationCallback的触发时机和参数结构也略有区别
迁移 app.config 到 appsettings.json 时容易漏掉的点
.NET Framework 项目长期依赖 ConfigurationManager 读取 app.config 中的 <appSettings> 和 <connectionStrings>，而 .NET 6+ 默认使用 IConfiguration + appsettings.json，二者结构不兼容。
-
app.config中的<startup><supportedRuntime>在 .NET Core 中完全无效，应删除 -
<connectionStrings>必须手动映射到appsettings.json的"ConnectionStrings"节点，否则GetConnectionString("Name")返回null - 自定义配置节（如继承
ConfigurationSection）无法直接复用，需重写为 POCO 类 +Bind()或Get<T>() -
Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT")控制配置加载顺序，不是靠文件名后缀（如appsettings.Production.json）自动生效，要确保环境变量已设
真正棘手的从来不是语法转换，而是那些藏在 web.config 的 <system.webServer> 模块、GAC 引用、WCF binding 配置、或者用 Reflection.Emit 动态生成类型的老代码——它们在 .NET Core 中要么无替代方案，要么需要彻底重构。
