首先来说第一个问题——Docker for Windows选镜像的逻辑，核心是本地匹配优先+Windows内核强绑定，具体拆成这几点：

• 本地镜像优先匹配：当你在docker命令里指定一个镜像（比如microsoft/dotnet-framework:latest），Docker第一时间会扫本地镜像仓库，找标签完全一致的镜像。如果本地有现成的，直接用本地的；没有的话才会去Docker Hub拉取对应标签的镜像。
• Windows内核版本必须严格匹配：这是Windows Docker最容易踩的坑！容器的内核版本必须和宿主机的内核版本完全对齐。比如Windows 10 1709对应的内核是10.0.16299，Server 2016 LTS对应的是10.0.14393——哪怕你拉了latest标签的镜像，如果这个镜像的内核版本和你宿主机不匹配，根本启动不了，甚至拉取的时候Docker会自动转成宿主机兼容的镜像变体（这也是后面问题的根源）。
• 镜像分层的依赖连锁：Docker镜像是分层拼出来的，基础镜像的内核版本会决定整个镜像链的兼容性。比如你基于某个基础镜像构建自定义镜像，基础镜像的内核不兼容，你加的任何上层内容都会继承这个问题。

接下来看你的第二个问题，结合你的场景，我几乎能确定问题出在镜像版本的隐性不一致上，咱们一步步拆解：

核心原因分析 #

你的两台构建服务器内核版本不一样：Windows 10 1709（内核10.0.16299）和Server 2016 LTS（内核10.0.14393）。虽然你们都用microsoft/dotnet-framework:latest构建，但latest标签是个“动态标签”——微软会随时间更新它指向的镜像版本，而且更关键的是：不同内核版本的机器拉取latest时，会自动获取与自身内核兼容的镜像变体，而不是同一个镜像！

举个例子：Server 2016的机器拉microsoft/dotnet-framework:latest，实际拿到的是适配1607内核的版本；而Windows 10 1709的机器拉同一个标签，拿到的是适配1709内核的版本。当Server 2016构建的镜像部署到测试主机（Server 2016）时，看似内核一致，但可能存在这些细节问题：

1. 测试主机checkpoint里的latest镜像，可能因为checkpoint更新时拉取的是更高版本的变体（比如微软悄悄把latest指向了Server 2019的镜像，但测试主机因为内核限制，实际拉的是1607的旧补丁版本），和构建服务器拉的latest补丁版本不一致；
2. 构建过程中引入了仅适配Server 2016特定补丁的依赖，而测试主机的checkpoint环境补丁版本不同；
3. Docker的内核版本校验非常严格，哪怕同是Server 2016，镜像的内核补丁级别比宿主机高，也会启动失败。

排查和解决步骤 #

1. 先确认所有机器的镜像实际版本 #

在构建服务器（Server 2016）、测试主机上分别执行这个命令，查看镜像的实际内核版本：

docker inspect microsoft/dotnet-framework:latest | findstr "OsVersion"

对比输出的版本字符串，比如10.0.14393.4881，必须完全一致才行。如果不一致，说明两边拉的latest不是同一个镜像。

2. 彻底抛弃latest标签，改用固定版本标签 #

这是解决Windows Docker兼容性问题的关键！微软为.NET Framework镜像提供了明确的版本标签，比如：

• 针对Server 2016 LTS的：microsoft/dotnet-framework:4.8-windowsservercore-ltsc2016
• 针对Windows 10 1709的：microsoft/dotnet-framework:4.8-windowsservercore-1709

修改你的Dockerfile，把基础镜像改成这些固定标签，比如：

# 给Server 2016构建服务器用的Dockerfile
FROM microsoft/dotnet-framework:4.8-windowsservercore-ltsc2016
# 后面的构建步骤不变...

这样构建出来的镜像内核版本完全固定，不会因为latest标签的更新而变来变去。

3. 检查测试主机的checkpoint环境 #

测试主机每次恢复checkpoint后，执行以下操作：

• 用docker images确认固定版本的基础镜像已经存在；
• 手动尝试启动Server 2016构建的容器，看具体错误日志：

  docker run --name test-debug <你的镜像ID>
  # 如果启动失败，看日志找原因
  docker logs test-debug
  

  常见错误比如The container operating system does not match the host operating system，直接说明镜像和宿主机内核版本不匹配。

4. 统一构建环境（可选但推荐） #

如果你的测试环境是Server 2016 LTS，建议把Windows 10 1709的构建服务器也换成Server 2016 LTS。Windows Docker的内核兼容性限制太严格，跨内核版本构建的镜像几乎没法保证稳定运行，统一环境能从根源避免这类问题。

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