Docker中运行.NET Core应用：dotnet watch与调试能否共存？

我想在Docker容器里修改源代码后让进程自动重启，用dotnet watch --project ...能检测文件变更实现自动重启，但没法在Rider里调试；直接构建完整应用调试正常，却不能检测文件变更。看起来dotnet watch和调试器不兼容，搜了两天没找到答案，想知道这背后的合理原因。

支持调试但无自动重载的Dockerfile最终阶段 #

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "AiaApi.dll"]

支持自动重载但无法调试的命令 #

ENTRYPOINT ["dotnet", "watch", "--project", "Core", "run", "--urls=http://+:5000", "--configuration", "Debug"]

核心原因解析 #

• 进程托管机制冲突：dotnet watch是一个上层监视进程，负责检测文件变更并重启实际的应用进程。而Rider调试器需要直接附着到目标应用进程上，当watch重启应用时，原调试连接会因进程ID变化而断开，且调试器无法自动重新附着到新生成的子进程——因为调试会话绑定的是初始启动的watch进程，而非它启动的应用进程。

• 调试上下文丢失：即使指定了--configuration Debug，dotnet watch在启动子进程时，可能未完整传递调试所需的环境变量、符号加载参数等上下文。直接运行dotnet AiaApi.dll时，调试器能直接加载完整的调试符号，但watch作为中间层会干扰这一过程，导致调试符号无法正确加载。

• Docker容器的调试限制：Rider调试容器内应用依赖端口映射和进程ID追踪，dotnet watch频繁重启进程会导致进程ID持续变化，而Rider默认没有自动追踪并重新附着到新进程的逻辑，进一步加剧了调试失效的问题。

内容的提问来源于stack exchange，提问作者InfoSpunge