一次StackOverflow

现象：

系统部署在iis，是一款小程序，当操作小程序的时候，突然就出现加载很久的问题，后来发现是接口卡了。

排查过程：

刚开始第一反应是网络问题，最近又刚好遇上华为云(挂在华为云）不稳定，所以一段时间认为是华为云的问题

接着发现很有规律，就操作那几个接口的时候出问题，而那几个接口的共性是使用了 DotNetCore.CAP，考虑是否是该组件不支持net6

遂换为MassTransit，但是问题依旧

接着定位到MassTransit实际执行的过程中，一个是发送短信，一个是发送公众号模板消息

逐个去除测试，最终确认为发送了公众号模板消息，每次发送都会出现卡住问题（系统表现为出现windows问题反馈的进程，以及在系统事件中出现restart 程序的问题）

使用的是Senparc.Weixin，按理说不应该，这个已经使用了好多年，看源代码，也没什么会出现死循环的，但是这个问题有人提出，官方只是说不是他们触发的

怀疑是windows server 2019 系统的问题

网上搜索也确实有很多相关的，有更新系统的，有安装缺失vc++的，但是问题没解决

只能换了操作系统，使用linux

当部署好之后，运行，问题依旧

查看执行日志（iis中不好查看），发现在处理微信事件的时候，出现了死循环

问题解决

总结

要非常注意Senparc.Weixin的默认消息处理DefaultResponseMessage，它父类方法是abstract的，当你不想输出任何东西的时候，按正常逻辑，很容易就写成如下，编译没问题，实际是个死循环：

public override IResponseMessageBase DefaultResponseMessage(IRequestMessageBase requestMessage)
{
    /* 所有没有被处理的消息会默认返回这里的结果，
    * 因此，如果想把整个微信请求委托出去（例如需要使用分布式或从其他服务器获取请求），
    * 只需要在这里统一发出委托请求，如：
    * var responseMessage = MessageAgent.RequestResponseMessage(agentUrl, agentToken, RequestDocument.ToString());
    * return responseMessage;
    */
    DefaultResponseMessage(requestMessage);
}

实际应该如下

public override IResponseMessageBase DefaultResponseMessage(IRequestMessageBase requestMessage)
{
    /* 所有没有被处理的消息会默认返回这里的结果，
    * 因此，如果想把整个微信请求委托出去（例如需要使用分布式或从其他服务器获取请求），
    * 只需要在这里统一发出委托请求，如：
    * var responseMessage = MessageAgent.RequestResponseMessage(agentUrl, agentToken, RequestDocument.ToString());
    * return responseMessage;
    */
    return new SuccessResponseMessage();
}