.NET 版本迁移：运行时、目标框架与发布产物核对

.NET 项目中的 SDK、目标框架、运行时、NuGet 依赖和发布方式各有作用。升级时仅在项目文件中调整目标框架，未必足以说明部署环境可运行；反过来，安装新的 SDK 也不意味着应用已使用它。迁移应以构建、测试和发布产物三组证据为基础，实际版本支持应在执行前确认。

辨认 SDK 与运行时

SDK 决定构建能力，运行时决定部署后进程能否启动。持续集成中应输出两者信息，并让发布镜像或服务器环境接受同样检查。对于自包含发布和框架依赖发布，验证重点不同：前者要注意产物体积和平台标识，后者要确认目标环境确实具有所需运行时。

目标框架调整可能改变可引用的 API、默认实现和分析器提示。先编译所有项目，再运行测试、命令行工具和 Web 启动路径。多目标库应逐个验证每个目标，不要只看默认目标。若某个 API 在不同目标上可用性不同，可在适配层集中处理，避免调用方到处出现条件判断。

版本变化常在 JSON 序列化、反射、网络协议、日期时间或本机互操作处体现。为这些边界准备固定输入和预期输出，并加入异常案例。对于程序集加载或插件模型，应测试缺少可选组件、重复版本和失败回收路径，确认日志能提供足够定位信息。

比较升级前后的文件清单、入口命令、配置读取和容器启动行为。需要时采用小范围部署，观察资源与错误趋势。延伸阅读为Java 长期支持版本迁移、Swift 工具链变化、安全修复版本选择和兼容性测试设计。

.NET 迁移需要同时证明“能构建、能启动、能发布”。明确 SDK 与运行时边界，测试目标框架和关键数据边界，才能降低上线后的环境差异。