子线程出现Stack Overflow为何阻塞父线程？ASP.NET Core场景答疑

子线程Stack Overflow阻塞父线程的核心原因 #

StackOverflowException 在 .NET 中属于进程级致命异常，从 .NET 2.0 开始，CLR 就不允许应用程序代码捕获该异常（仅 CLR 内部极少数场景可以处理）。一旦任何线程触发栈溢出，CLR 会直接启动进程终止流程——因为栈溢出会破坏进程内存的完整性，CLR 无法保证进程后续能稳定运行。

你看到的父线程阻塞、VS 卡顿，本质不是父线程真的被子线程阻塞，而是：

• CLR 在终止进程前会执行一系列清理操作，这个过程会导致整个进程内的所有线程暂停响应；
• VS 调试器会捕获这个未处理的致命异常，进入中断模式，强制暂停整个进程的执行，所以你会看到卡顿数分钟后才抛出异常，且父线程无法继续。

与 ASP.NET Core/MVC、VS 内置服务器的关系 #

ASP.NET Core 应用（包括 VS 托管的 Kestrel/IIS Express）是单进程运行的，控制器代码、你创建的子线程都属于同一个进程。子线程的致命异常会直接触发整个进程的终止逻辑，不存在线程级的隔离保护。VS 内置服务器本身和应用进程是绑定的，所以进程终止前的调试器处理流程会进一步放大卡顿现象。

是 Bug 还是认知盲区？ #

这完全是对 .NET 异常处理机制的认知盲区，不是 VS 或 .NET Core 的 Bug。你之前的思路（用子线程隔离异常）只适用于普通可捕获异常，而 StackOverflowException 是 CLR 认定的无法恢复的致命错误，任何线程触发都会导致整个进程崩溃，无法通过线程隔离来规避。

临时处理建议 #

既然已知是 XSLT 逻辑问题，优先从根源入手：

• 检查 XSLT 中是否存在无限递归逻辑，手动限制递归深度；
• 对输入 XML 做预处理，避免触发会导致栈溢出的转换分支；
• 不要试图用线程、Task 或 CancellationToken 来拦截 StackOverflowException，这类方案从原理上就不可行。

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