Visual Studio生成的.Net Core Dockerfile三大技术疑问

以下是Visual Studio生成的默认Dockerfile：

FROM mcr.microsoft.com/dotnet/aspnet:7.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build
WORKDIR /src
COPY ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
RUN dotnet restore "WebApplication1/WebApplication1.csproj"
COPY . .
WORKDIR "/src/WebApplication1"
RUN dotnet build "WebApplication1.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "WebApplication1.csproj" -c Release -o /app/publish /p:UseAppHost=false

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]

(1) 为何同时使用aspnet:7.0运行时镜像与SDK镜像？SDK镜像已包含运行时，是否属于重复使用？ #

这是Docker分层构建的最佳实践，完全不是重复使用：

• SDK镜像体积庞大（包含编译器、调试工具、依赖管理工具等全套开发环境），仅用于编译、构建、发布等开发阶段；
• aspnet运行时镜像体积小很多，只包含.NET运行所需的最小依赖，用于最终的生产镜像。
  用轻量的运行时镜像作为最终镜像，能大幅减少镜像体积、降低资源占用，同时缩小攻击面，提升生产环境的安全性和性能。

(2) 先拷贝csproj文件执行依赖下载，再COPY . .拷贝所有文件，理论上能否跳过第一步的拷贝操作？ #

不能跳过，这是为了最大化利用Docker构建缓存：

• Docker的缓存规则是：如果某一步的上下文内容没变化，就复用之前的缓存结果。
• 如果直接执行COPY . .再dotnet restore，那么项目中任何文件（比如业务代码、配置文件）的改动，都会导致这一步的缓存失效，触发重新下载所有依赖；
• 先单独拷贝csproj再执行restore，只有当csproj文件（依赖声明）发生变化时，才会重新下载依赖，业务代码改动不会影响这一步的缓存，能大幅加快构建速度。

(3) Dockerfile中的RUN dotnet build "WebApplication1.csproj" -c Release -o /app/build构建步骤是否可以跳过？ #

从功能上来说，dotnet publish命令会自动执行build操作，所以跳过这一步直接执行publish是可行的，但保留这一步是出于分层缓存和流程清晰的考虑：

• 拆分build和publish阶段，可以让build的缓存独立复用：比如代码改动后，build阶段重新编译，但restore的缓存依然有效；
• 如果后续需要在构建流程中加入其他步骤（比如单元测试，需要依赖build产物），这个阶段可以直接复用；
• 分层构建让整个流程更清晰，便于排查构建过程中的问题。
  如果你的场景不需要中间build产物，也可以将build和publish合并为一步，但官方默认的写法是更通用的最佳实践。

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