.net core 和 .net framework 的区别

.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:Windowsmicrosoft.NETFramework64v4.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 中的 和 ，而 .NET 6+ 默认使用 IConfiguration + appsettings.json，二者结构不兼容。

• app.config 中的 在 .NET Core 中完全无效，应删除
• 必须手动映射到 appsettings.json 的 "ConnectionStrings" 节点，否则 GetConnectionString("Name") 返回 NULL
• 自定义配置节（如继承 ConfigurationSection）无法直接复用，需重写为 POCO 类 + Bind() 或 Get()
• Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") 控制配置加载顺序，不是靠文件名后缀（如 appsettings.Production.json）自动生效，要确保环境变量已设

真正棘手的从来不是语法转换，而是那些藏在 web.config 的 模块、GAC 引用、WCF binding 配置、或者用 Reflection.Emit 动态生成类型的老代码——它们在 .NET Core 中要么无替代方案，要么需要彻底重构。