基于Telegram.Bot的.NET 5.0 Bot转Windows服务后失效且无异常日志

• 基于.NET 5.0 开发的简易Telegram Bot，依赖NuGet平台提供的Telegram.Bot类库实现核心能力，程序形态为基础命令行应用
• 直接通过命令行方式启动时，Bot功能可完全正常运行
• 调用.UseWindowsService()扩展方法将程序托管为Windows服务部署后，Bot完全失去响应，且全程无任何异常日志输出

• 服务运行账户的网络访问限制
  Windows服务默认的运行身份为NETWORK SERVICE或内置本地系统账户，不少主机环境的防火墙、第三方安全软件会对这类系统账户的出站HTTPS连接设置拦截规则——而Telegram.Bot不管用长轮询还是Webhook模式，都需要稳定的出站HTTPS连通性。命令行启动时程序是跟着当前登录用户的身份运行的，根本不会触发这类账户级别的拦截，所以功能表现正常。
• 控制台句柄缺失引发的静默任务终止
  .NET 5 环境下，很多命令行应用默认会依赖控制台的标准输入/输出句柄跑逻辑，比如Telegram.Bot部分早期版本的默认日志输出组件、部分异步轮询任务的取消令牌绑定，都是直接和控制台句柄挂钩的。等程序被托管成Windows服务后，系统根本不会给服务分配交互式控制台句柄，这类资源直接缺失的话，相关异步任务会直接静默终止，连可捕获的异常都抛不出来，自然也等不到日志输出。
• 默认工作目录差异导致的配置加载失败
  用命令行启动程序时，默认工作目录就是exe所在的文件夹，但Windows服务启动时的默认工作目录是C:\Windows\System32——如果启动时是靠相对路径加载Bot配置（比如Bot的访问令牌、回调路由规则），会直接找不到对应的配置文件。如果代码里没给配置加载失败的逻辑写显式的异常捕获和文件日志落盘，程序就会直接卡在初始化阶段，半点反应都没有。
• 会话隔离带来的网络栈配置不兼容
  不少Windows版本对不同运行会话下的网络请求有隔离规则，Telegram.Bot底层用的System.Net.Http组件跑在服务专属的Session 0会话下时，如果没有正确适配代理配置，会出现请求发不出去但不抛错的情况。尤其是主机本身需要挂代理才能访问Telegram接口的场景，命令行启动时能读到的用户级代理配置，在服务运行时是完全读不到的。
• 服务生命周期绑定不完整
  调用.UseWindowsService()的时候，如果没把Telegram Bot的轮询任务正确绑定到主机的IHost生命周期上，会出现主机刚启动完成，Bot的后台任务因为缺乏正确的生命周期感知，在服务跑起来几秒后就被系统判定为空闲直接终止，整个过程根本不会触发可捕获的异常日志。

排查参考思路：可以先临时把服务的运行身份改成当前登录用户，放开所有出站网络拦截，同时把之前打在控制台的日志改成写到本地文件里，先确定程序到底是卡在初始化、发送网络请求的阶段，还是后台任务直接退出，再顺着定位根因就会快很多。

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