不会卡主线程——Task.Run将while(true)循环放入线程池执行，避免阻塞UI线程；但需用Thread.Sleep或await Task.Delay让出CPU，并配合CancellationToken实现可控取消。
用 Task.Run + while (true) 会卡主线程吗？
不会卡主线程——前提是别在 UI 线程（比如 WinForms 的 Form.Load 或 WPF 的 Loaded 事件）里直接写 while (true)。一旦这么干，界面就冻结了，因为循环占着线程不放。
正确做法是用 Task.Run 把循环扔进线程池：
Task.Run(() =>
{
while (true)
{
// 做点事，比如轮询、发心跳、处理队列
Thread.Sleep(5000); // 必须有让步，否则 CPU 拉满
}
});
-
Thread.Sleep或await Task.Delay不可省：没有暂停，线程会死循环压满一个 CPU 核 - 别在
async void方法里启动这种循环：异常会静默丢失，无法捕获 - 如果需要取消，必须传入
CancellationToken并在循环中检查token.IsCancellationRequested
为什么 BackgroundService 比裸写 Task.Run 更适合长期服务？
因为 BackgroundService 是 .NET Core / .NET 5+ 官方推荐的后台任务基类，它把生命周期管理（启动/停止/异常传播）封装好了，而裸 Task.Run 得自己处理这些。
典型错误是：服务停止时，循环还在跑，或者没等当前迭代结束就强行退出，导致数据不一致。
- 必须重写
ExecuteAsync(CancellationToken stoppingToken)，并在里面用while (!stoppingToken.IsCancellationRequested) - 不能在
StopAsync里直接Wait()或Result：会死锁，要用await - 如果循环里有 I/O（如 HTTP 请求），优先用
await Task.Delay(..., stoppingToken)，让取消信号能及时生效
Task.Delay 和 Thread.Sleep 在无限循环里能混用吗？
不能混用。混用会导致线程模型错乱：在 async 方法里用 Thread.Sleep，会阻塞线程池线程；在同步循环里用 await Task.Delay，编译不过（缺少 async 修饰符）。
选哪个，取决于你写的上下文：
- 同步循环（
Task.Run(() => { while(...) {...} })）→ 只能用Thread.Sleep - 异步循环（
async Task ExecuteAsync(...)）→ 必须用await Task.Delay(..., token) -
Task.Delay支持取消令牌，Thread.Sleep不支持；这是关键区别，不是风格问题
Windows 服务里部署无限循环，为什么一启动就退出？
常见原因是没正确注册 BackgroundService，或没调用 AddHostedService<myservice>()</myservice>。.NET 主机启动后，发现没有任何托管服务，就认为“没活干”，直接退出进程。
另一个坑是：本地调试时忘了用 UseWindowsService()，但发布到 Windows 服务时又没配好服务安装参数，导致 SCM（服务控制管理器）超时后强制杀掉进程。
- 确保
Program.cs中调用了hostBuilder.UseWindowsService() - 服务安装命令里必须带
--service参数（.NET 6+），否则主机不知道自己该以服务模式运行 - 日志输出要写到文件或 EventLog：控制台日志在 Windows 服务里默认不可见，排查时容易误判为“没运行”
stoppingToken 就算完，得确保所有阻塞点（尤其是第三方 SDK 的等待调用）都接受并响应它。否则关服务时，进程可能挂住十几秒才退出。 
