ASP.NET Core应用VS2019运行正常 命令行启动后无法访问5001端口

1. 核心原因为线程池饥饿：你集成的WorkflowCore后台轮询任务如果采用了同步阻塞的实现逻辑，或是轮询间隔配置过短、工作线程数配置过高，会快速占满.NET线程池的可用工作线程，导致Kestrel服务器没有多余线程处理HTTP请求、甚至无法执行心跳检测逻辑，最终表现为端口监听正常但无法响应请求。
2. Visual Studio启动无异常的原因：VS调试模式启动应用时，默认会调整线程池的最小线程数阈值，或是部分后台任务的调试级优化会降低调度优先级，不会出现线程快速被占满的情况；而命令行直接启动时用的是默认运行时配置，线程池最小线程数默认较低，很容易被密集的后台阻塞任务占满。

• 调整WorkflowCore的轮询配置：找到WorkflowCore的服务注册代码，适当调大轮询间隔、减少轮询工作线程数，示例修改如下：

// 原错误配置示例
services.AddWorkflow(options => 
{
    options.PollInterval = TimeSpan.FromMilliseconds(100); // 间隔过短导致频繁调度
    options.MaxConcurrentWorkflows = 100; // 并发数过高占用大量线程
});

// 修改为合理配置
services.AddWorkflow(options => 
{
    options.PollInterval = TimeSpan.FromSeconds(1); // 调大轮询间隔
    options.MaxConcurrentWorkflows = 10; // 根据业务实际需求调低并发数
});

• 调整.NET线程池最小线程数：在Program.cs的Main方法最开头添加线程池配置，提前预留足够的工作线程避免被瞬间占满：

public static void Main(string[] args)
{
    // 最小工作线程和IO线程数可根据实际业务规模调整
    ThreadPool.SetMinThreads(50, 50);
    CreateHostBuilder(args).Build().Run();
}

• 检查工作流业务代码：排查所有工作流执行逻辑中是否存在同步阻塞调用（比如Task.Result、Wait()、Thread.Sleep()这类写法），全部改为异步非阻塞的await写法，避免阻塞工作线程。
• 快速定位验证：启动应用时加上参数--urls http://0.0.0.0:5000;https://0.0.0.0:5001排除IP绑定限制问题，同时临时禁用WorkflowCore的后台任务启动，若此时HTTP请求可以正常响应，即可100%定位为WorkflowCore调度导致的线程池问题。

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