.NET Docker项目如何减小镜像体积？多阶段构建与镜像优化实战

在.NET项目部署到Docker之后，一个比较常见的问题就是镜像体积过大。尤其是直接使用 mcr.microsoft.com/dotnet/sdk 作为最终运行镜像时，SDK、编译器以及各种开发工具都会被一起打包进去，不仅增加镜像体积，也会影响镜像拉取、部署和启动效率。

.NET官方本身就区分了SDK镜像和Runtime镜像：SDK镜像主要用于开发和编译，而生产环境通常只需要ASP.NET Core Runtime镜像。

使用多阶段构建

这是优化.NET Docker镜像最重要的方法。不要在同一个镜像中完成编译和运行，而是将SDK用于Build阶段，最终镜像只保留运行程序需要的文件。

例如：

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src

COPY ["MyApp.csproj", "."]
RUN dotnet restore "MyApp.csproj"

COPY . .
RUN dotnet publish "MyApp.csproj" -c Release -o /app/publish --no-restore

FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS final
WORKDIR /app

COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "MyApp.dll"]

这样最终镜像不会包含SDK、源代码和编译过程中产生的大量临时文件。Docker官方也推荐通过多阶段构建将编译环境和运行环境分离。

不要把SDK镜像用于生产环境

很多.NET项目的Dockerfile直接写成：

FROM mcr.microsoft.com/dotnet/sdk:10.0

然后在里面执行 dotnet run。这种方式虽然简单，但会把完整SDK带进生产镜像。

ASP.NET Core项目通常应该使用：

FROM mcr.microsoft.com/dotnet/aspnet:10.0

如果是普通.NET Worker、Console等应用，则可以根据实际情况使用 dotnet/runtime。Runtime镜像只包含运行程序所需的环境，体积明显小于SDK镜像。

配置.dockerignore

Docker构建时不要把整个项目目录原封不动地发送给Docker。建议创建 .dockerignore：

bin/
obj/
.git/
.vs/
.idea/
.vscode/
TestResults/
*.user
*.suo
Dockerfile*
README.md

其中 bin、obj 通常是最值得排除的目录，因为它们包含本地编译产生的文件。

.dockerignore不仅可以减少构建上下文，也能避免无关文件进入镜像构建流程。Docker官方也建议将需要排除的内容放入该文件。

优化dotnet publish

生产环境应该使用Release模式：

dotnet publish -c Release

Dockerfile中可以进一步使用：

RUN dotnet publish -c Release -o /app/publish --no-restore

其中 --no-restore 可以避免前面已经完成 dotnet restore 后再次恢复依赖。

如果项目适合，还可以进一步研究ReadyToRun、Trim等发布方式，但这些选项并不是所有项目都适合直接开启，尤其是依赖反射、动态加载程序集的项目，需要先进行兼容性测试。

选择更小的基础镜像

如果项目对操作系统环境没有特殊要求，可以考虑Alpine、Ubuntu Chiseled或者其他面向小体积优化的.NET镜像。

例如部分场景可以使用：

FROM mcr.microsoft.com/dotnet/aspnet:10.0-alpine

.NET官方文档目前将Alpine、Mariner Distroless和Ubuntu Chiseled列为面向镜像体积优化的方案。

不过，小镜像并不意味着一定更适合生产环境。Alpine等镜像在系统库、调试工具、Globalization等方面存在差异，切换之前应该充分测试。

如果应用完全不需要复杂的国际化功能，还可以研究Invariant Globalization模式，这能够进一步减少相关依赖。但如果程序需要中文、日期、时区或其他Globalization能力，就不能为了追求小体积而盲目关闭相关功能。

不要把无用文件COPY进最终镜像

多阶段构建中，建议只复制publish目录：

COPY --from=build /app/publish .

不要简单地：

COPY . .

后者很容易把源代码、配置文件、Git目录以及其他开发文件一起带入最终镜像。

.NET官方提供的Docker示例同样采用了Build阶段生成发布文件，再将发布结果复制到ASP.NET Core Runtime镜像中的方式。

如何判断优化是否有效？

可以通过下面的命令查看镜像大小：

docker images

进一步分析镜像每一层占用了多少空间，可以使用：

docker history myapp:latest

如果发现某一层突然增加几百MB，通常就需要检查该层对应的 COPY 或 RUN 操作。

实际优化时，不建议单纯追求镜像大小。生产环境还需要同时考虑启动速度、兼容性、安全更新、漏洞数量以及后续维护成本。

总结

.NET Docker项目减小镜像体积，最优先应该做的是多阶段构建+Runtime镜像+合理的.dockerignore。在此基础上，再根据项目实际情况选择Alpine、Chiseled、Trim或其他发布优化方案。

一个比较稳妥的思路是：SDK只负责构建，publish只输出生产文件，Runtime镜像只负责运行。这样既能降低镜像体积，也能减少生产环境中的无用工具和攻击面，是.NET项目容器化部署中比较值得长期采用的实践。