Aspire 项目启动时服务间调用超时，是不是并发调试没配对？
不是超时本身的问题，而是 Aspire 的
Aspire.Hosting默认启用服务发现 + 健康检查重试机制，在并发调试场景下，若某个服务（如 API 网关）尚未完成就绪探针（
/health），下游服务会持续等待或失败——看起来像“卡在启动”，实则是健康检查阻塞了依赖注入链。 检查
Program.cs中是否对关键服务调用了
.WithHealthCheck()；若调试阶段不需要严格就绪控制，可临时移除或改用
.WithHealthCheck("/ready", timeout: TimeSpan.FromSeconds(1))
确认所有服务的 ASPNETCORE_ENVIRONMENT一致（如都为
Development），否则健康端点路径或行为可能不匹配 在
appsettings.Development.json中为
Microsoft.Extensions.Diagnostics.HealthChecks日志级别设为
Debug，观察日志里是否有
Health check 'xxx' failed或
Waiting for health check to pass...
断点只在本地进程生效，进不了容器里的服务？
Aspire 默认使用
Docker Compose启动容器化服务，而 Visual Studio / VS Code 的调试器默认只 attach 到本机 .NET 进程。容器内服务需显式暴露调试端口并启用
dotnet-dbg支持。 确保项目文件（
.csproj）中包含
<isaspirehost>true</isaspirehost>，且 SDK 版本 ≥
8.0.200（旧版不支持容器内调试） 在
AppHost项目的
Program.cs中，对目标服务添加
.WithReference(...).WithEnvironment("DOTNET_STARTUP_HOOKS=/usr/share/dotnet/startup_hooks/dotnet-startup-hook-debug.dll")
手动验证容器调试端口：运行 docker ps找到服务容器 ID，再执行
docker port <container-id></container-id>，确认
5000/tcp（或你配置的
DOTNET_DEBUG_PORT）已映射到宿主机
多个服务同时写日志导致时间戳错乱、请求链路断开？
Aspire 内置的
OpenTelemetry采集器默认按服务粒度上报，但若所有服务共用同一
OTEL_SERVICE_NAME或未正确传播
traceparentheader，分布式追踪就会失效，表现为日志时间跳变、Span 无父子关系。 每个服务的
appsettings.json必须独立设置
"OTEL_SERVICE_NAME": "orders-api"（不能全用
aspire-app） 检查 HTTP 客户端是否注入了
HttpClient的 OpenTelemetry 集成：确保已调用
services.AddHttpClient<iorderclient orderclient>().AddHttpMessageHandler<distributedcontextpropagationhandler>()</distributedcontextpropagationhandler></iorderclient>避免在中间件里手动修改
Activity.Current?.IdFormat；Aspire 8.1+ 要求使用
W3C格式，硬设为
Hierarchical会导致跨服务 traceId 解析失败
并发压测时 Aspire Dashboard 显示服务状态忽绿忽红？
Dashboard 的实时状态依赖各服务主动上报心跳，默认间隔 30 秒。高并发下若服务线程池耗尽、GC 暂停过长，或健康检查 endpoint 因锁竞争响应超时，就会被 Dashboard 误判为宕机。
降低 Dashboard 心跳频率：在AppHost的
Program.cs中，将
.WithDashboard()替换为
.WithDashboard().WithEnvironment("ASPNETCORE_DASHBOARD_HEARTBEAT_INTERVAL_SECONDS=60")
为健康检查 endpoint 单独配置最小线程数：ThreadPool.SetMinThreads(100, 100); // 在 Program.cs 最前调用禁用非必要中间件（如
UseDeveloperExceptionPage）——它在并发异常时会显著拖慢响应，干扰健康检查结果 Aspire 的并发调试难点不在代码逻辑，而在服务生命周期管理与可观测性基础设施的耦合深度。一个
WithHealthCheck调用、一行
DOTNET_STARTUP_HOOKS环境变量、甚至 Dashboard 的心跳间隔，都可能成为多服务协同调试时最隐蔽的瓶颈。
