同一Azure App Service中.NET Core 2.2与3.1应用槽能否共存？

核心结论：完全可以独立运行，不存在底层层面的冲突，这本身就是Azure部署槽支持的标准用法之一，只需要注意几个关键的配置边界即可。

为什么不会产生底层冲突 #

• 每个部署槽本质是依托同一App Service计算资源的独立运行单元，拥有独立的文件系统、独立的应用进程上下文，运行时栈配置是槽级独立设置，不会全局锁死所有槽的版本。
• Azure App Service底层会预装所有受支持的.NET Core运行时版本，每个槽启动时会按照自身选定的运行时版本加载对应组件，不会出现不同版本运行时互相覆盖的问题。哪怕是同一台宿主机上同时跑2.2和3.1的应用进程，运行时组件也是按进程隔离加载的，没有版本兼容冲突。
• 两种.NET Core常见部署模式都可以正常兼容这种版本差异：
  • 框架依赖部署：直接在对应槽的配置里选择匹配的.NET Core版本即可，不需要手动安装运行时
  • 自包含部署：把对应版本的运行时打包在应用文件夹里，哪怕槽配置的运行时栈和实际应用版本不匹配也能正常跑，文件系统完全独立的特性也不会让两个槽的打包运行时互相干扰

实际使用中容易踩的配置坑 #

• 务必把运行时相关的配置标记为槽固定设置：默认在Azure门户里通过「配置-常规设置」选择的.NET Core运行时版本，会自动标记为槽固定，不会在槽交换时跟着移动；但如果是你手动添加的环境变量（比如自定义指定DOTNET_VERSION、DOTNET_ROLL_FORWARD这类参数），一定要在设置里勾选「部署槽设置」选项，否则槽交换时，staging槽的3.1版本配置会被交换到生产槽，直接把原本跑2.2的生产应用打崩。
• 注意App Service计划的资源配额：两个槽的应用是共享所在App Service计划的CPU、内存资源的，只要总负载不超过计划的规格上限，不会因为跑两个不同版本的.NET Core应用就出现异常的资源挤占问题。
• 如果你用的是Linux/容器化的App Service部署槽，只要保证每个槽拉取的容器镜像和自己要跑的.NET Core版本匹配就行，两个槽的容器运行环境完全隔离，不存在交叉影响。

针对当前迁移场景的实操建议 #

• 第一次把3.1版本发布到staging槽前，单独进入staging槽的配置页，确认它的.NET Core运行时版本是3.1.x，和生产槽当前的2.2.x版本做明确区分，不要依赖全局默认配置。
• 发布完成后可以先在staging槽的专属域名上做一轮功能验证，通过运行时版本检查接口确认实际加载的是3.1版本后，再按你的节奏做后续的槽交换准备。
• 额外提醒：.NET Core 2.2已结束官方支持周期，无后续安全补丁与bug修复，建议staging验证通过后尽快完成全量切换，不要长期维持生产环境跑2.2版本的状态。

内容的提问来源于stack exchange，提问作者gordieb