必须启用Release配置发布、匹配SDK与Runtime镜像版本、ENTRYPOINT指向发布后的.dll文件、配置.dockerignore文件。否则会导致镜像臃肿、启动失败或安全风险。
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
bin/
obj/
.vs/
.user
.env - 不要在 Dockerfile 中用
RUN rm -rf /app/obj补救——这些文件早已存在于上层镜像中，无法真正删除； - 若项目含
appsettings.Development.json，也建议加入.dockerignore，生产镜像应只保留appsettings.json和环境变量驱动的配置。
docker build -t myapp .，但镜像是否精简、能否稳定运行，全取决于上面四点是否被严格执行。最容易被跳过的其实是 .dockerignore 和 runtime 镜像版本对齐——这两个地方出问题，往往表现为容器启动后立即退出，日志里只有 exit code 139 或空白输出。 
