docker-compose.yml中每个service必须指定image或build，否则报错“service 'xxx' has neither an image nor a build context”；image用于拉取远程镜像，build用于本地构建，二者至少其一且不可同时省略。
docker-compose.yml 中必须指定 image 或 build，否则服务启动失败
很多 C# 开发者写完 docker-compose.yml 后执行 docker-compose up 报错：Service 'webapi' has neither an image nor a build context specified。这是因为每个 service 至少要提供镜像来源——要么拉取现成镜像（image: mcr.microsoft.com/dotnet/aspnet:8.0），要么本地构建（build: ./src/WebApi）。
常见错误场景：
- 只写了
container_name和ports，漏掉image或build -
build路径指向一个没有Dockerfile的目录 - 在
build下误用context但没配dockerfile，而项目里Dockerfile改了名（比如叫Dockerfile.prod）
建议：C# 项目优先用 build + Dockerfile，便于控制 SDK 版本、发布模式（self-contained 还是 framework-dependent）和运行时优化。示例片段：
services:
webapi:
build:
context: ./src/WebApi
dockerfile: Dockerfile
ports:
- "5000:80"
ASP.NET Core 容器必须暴露端口且监听 0.0.0.0，否则外部连不上
本地调试时 dotnet run 默认监听 http://localhost:5000，但容器内 localhost 指向自身，其他容器或宿主机根本访问不到。不改监听地址，docker-compose 里的 ports 映射就形同虚设。
解决方式只有两个，缺一不可：
- 启动命令中加
--urls http://0.0.0.0:80（适用于ENTRYPOINT ["dotnet", "WebApi.dll"]场景） - 或在
Program.cs中显式调用builder.WebHost.UseUrls("http://0.0.0.0:80")（.NET 6+ 推荐用builder.WebHost.ConfigureKestrel(...)） - 确保
Dockerfile中的EXPOSE 80与应用实际监听端口一致（别写成EXPOSE 5000却让程序监听 80）
顺带一提：ASPNETCORE_URLS 环境变量也能生效，但不如代码层控制可靠，尤其在多环境配置切换时容易遗漏。
多个 C# 服务间通信不能靠 localhost，得用服务名当 host
比如 webapi 要调用 redis，写成 redis://localhost:6379 必然失败——这是容器网络隔离决定的。Docker Compose 自动为每个 service 创建 DNS 记录，名称就是 service 键的值。
正确做法：
- 连接字符串里用
redis://redis:6379（假设 redis 服务名为redis） - HTTP 调用写成
http://auth-service/login（对应auth-service这个 service 名） - 如果服务启用了健康检查或需要等待依赖就绪，别手写
sleep 10 && dotnet ...，改用depends_on+ 自定义健康检查（healthcheck）更稳妥
注意：depends_on 只控制启动顺序，不保证目标容器“已就绪”。C# 客户端应实现重试逻辑（如 Polly），或用 dotnet watch 配合 readiness probe。
.NET 应用在 docker-compose 中日志丢失或无法实时查看
执行 docker-compose logs -f webapi 看不到输出？大概率是 Kestrel 默认把日志写到了 stdout 以外的地方，或者被 Console.WriteLine 外的 logger provider 拦截了。
关键检查点：
-
Dockerfile中是否用了ENTRYPOINT ["dotnet", "WebApi.dll"]？如果是sh -c "dotnet..."，可能因 shell 缓冲导致日志延迟甚至丢失 - 确认
Program.cs中未禁用控制台日志：builder.Logging.ClearProviders();会干掉Console输出 - Linux 容器中，.NET 默认使用
Console+Systemd提供商；若你手动添加了FileLoggerProvider，记得保留AddConsole()
最简验证法：在 Program.cs 开头加一行 Console.WriteLine("App starting...");，再跑 docker-compose logs -f webapi —— 如果这行都看不到，问题一定出在容器启动方式或日志重定向上。
C# 用 Docker Compose 编排的核心难点不在语法，而在理解容器网络模型、.NET 运行时行为与 Docker 生命周期的交叠点。最容易被忽略的是：服务名即 DNS 名、localhost 在容器内不等于宿主机、日志必须走 stdout 才能被 docker-compose logs 捕获——这三个前提没立住，后面所有配置都会事倍功半。
