ASP.NET Core项目必须启用发布配置才能正确构建镜像
直接在项目根目录运行
dotnet publish时若未指定配置，会默认使用
Debug，导致生成的输出包含调试符号、未裁剪的依赖，镜像体积大且存在安全风险。Docker 构建过程应严格使用
Release配置。 确保
.csproj中未硬编码
DebugType或覆盖
Optimize； Dockerfile 中的
dotnet publish命令必须显式加
-c Release； 若项目引用了
Microsoft.AspNetCore.App共享框架，发布时需用
--self-contained false（默认行为），否则会打包整个运行时，镜像膨胀数倍。
Dockerfile 多阶段构建必须匹配 SDK 与 Runtime 镜像版本
常见错误是 SDK 镜像用
7.0，而 runtime 镜像写成
6.0，导致
Could not load file or assembly或启动失败。版本不一致还会引发 TLS、JSON 序列化等运行时行为差异。 查看项目
TargetFramework（如
net7.0），以此为准选择镜像标签； SDK 阶段用
mcr.microsoft.com/dotnet/sdk:7.0，runtime 阶段用
mcr.microsoft.com/dotnet/aspnet:7.0（不是
runtime，ASP.NET Core 应用需
aspnet镜像，它内置了 IIS 模块和 HTTPS 支持）； 避免使用
latest标签——它可能跨主版本，破坏确定性。
ENTRYPOINT 必须指向已发布的可执行文件，而非项目文件
写成
ENTRYPOINT ["dotnet", "MyApp.csproj"]是错的：容器内没有 SDK，且
.csproj不是可执行体。正确路径是发布后生成的
.dll文件，且该文件名与项目名一致（除非显式设置了
AssemblyName）。 发布命令输出目录（如
./bin/Release/net7.0/publish/）中的
MyApp.dll才是入口；
ENTRYPOINT ["dotnet", "MyApp.dll"]是标准写法； 若应用监听非
http://+:80地址，需通过
ASPNETCORE_URLS环境变量覆盖，例如
ENV ASPNETCORE_URLS=http://+:5000； 不要在 Dockerfile 中用
CMD替代
ENTRYPOINT—— 后者更符合 .NET 容器最佳实践，也便于
docker run传参扩展。
构建时忽略 .git、obj、bin 目录能显著提速并防止敏感泄露
Docker 构建上下文默认上传当前目录所有文件。若未排除
obj/和
bin/，不仅拖慢构建，还可能把本地 NuGet 缓存路径、用户密钥等意外打进镜像层。 在项目根目录创建
.dockerignore，内容包括：
.git<br>bin/<br>obj/<br>.vs/<br>.user<br>.env不要在 Dockerfile 中用
RUN rm -rf /app/obj补救——这些文件早已存在于上层镜像中，无法真正删除； 若项目含
appsettings.Development.json，也建议加入
.dockerignore，生产镜像应只保留
appsettings.json和环境变量驱动的配置。 实际构建命令就是
docker build -t myapp .，但镜像是否精简、能否稳定运行，全取决于上面四点是否被严格执行。最容易被跳过的其实是
.dockerignore和 runtime 镜像版本对齐——这两个地方出问题，往往表现为容器启动后立即退出，日志里只有
exit code 139或空白输出。
