不是“该选哪个”，而是“.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></appsettings>和
<connectionstrings></connectionstrings>，而
.NET 6+默认使用
IConfiguration+
appsettings.json，二者结构不兼容。
app.config中的
<startup><supportedruntime></supportedruntime></startup>在 .NET Core 中完全无效，应删除
<connectionstrings></connectionstrings>必须手动映射到
appsettings.json的
"ConnectionStrings"节点，否则
GetConnectionString("Name") 返回 null自定义配置节（如继承
ConfigurationSection）无法直接复用，需重写为 POCO 类 +
Bind()或
Get<t>()</t>
Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") 控制配置加载顺序，不是靠文件名后缀（如 appsettings.Production.json）自动生效，要确保环境变量已设
真正棘手的从来不是语法转换，而是那些藏在
web.config的
<system.webserver></system.webserver>模块、GAC 引用、WCF
binding配置、或者用
Reflection.Emit动态生成类型的老代码——它们在 .NET Core 中要么无替代方案，要么需要彻底重构。
