现在，当用户想要退出我的应用程序时，我会做一些我必须做的事情（即从服务器断开连接，保存用户数据......）然后我执行以下操作：
这需要几秒钟才能退出，并且没有任何实际用途（所有内容都已保存在服务器上，所以我并不关心那里发生了什么）
如果我改用它，我会立即终止，没有我能想到的缺点：
System.Diagnostics.Process.GetCurrentProcess().Kill();
为什么我不终止我的进程并让 CLR 删除 AppDomain ？
我知道仔细处理您的共享资源（IO 文件处理程序等）很重要（所以请不要回答这个问题:)），但是一旦完成，是否有真正的理由干净地退出我的应用程序？
杀死进程意味着 finally 块将不会被执行，甚至可能不会执行关键的终结器对象，这实际上可能是关键的，并导致系统级别的资源泄漏。当其他人维护代码时，它还可能在将来导致意外的错误，因为他们（或您）将不得不扭头，每次他们编写 finally 块时都必须考虑它是否会被执行。
首先，我认为你的意思是Process.Kill()，不是Process.TerminateProcess()。其次，杀死进程只会把它撕掉。任何清理代码都不会执行，并且您的应用程序将没有机会取消终止（例如，如果用户有未保存的数据）。如果你对此感到满意，那就去吧。
这确实是一个好问题！
曾几何时（十多年前），我写了一个 VB6 应用程序，由于 WinINet OCX（或其他任何名称）中的一个确认错误，由于它正在与之交谈的 Web 服务器上使用的特定证书，该应用程序在终止时挂起。
没有任何办法解决这个错误，我使用了 TerminateProcess，据我所知，这个应用程序已经在数千台机器上使用了好几年，我从未听说过关于这个 hack 的任何问题！
使用第三方库而无法捕获它们的错误或泄漏，有时在不引发崩溃 MessageBox 的情况下结束它的唯一方法是终止进程。
请记住，如果您正在写入文件/网络流，则您的写入可能不完整。
如果您的应用程序已准备好以这种方式处理损坏的数据，那么没有理由不这样做。但是，如果您可以通过其他方式退出，我建议您这样做。
应该注意的是终结器实际上可能永远不会被执行，因此终止进程与跳过终结代码的任何其他原因没有太大区别，例如慢终结器或终结器抛出异常。
总而言之，我不会太担心关闭应用程序需要几秒钟，特别是如果它立即隐藏所有窗口并为用户“消失”。但是，如果关闭需要几十秒和/或用户可能会再次执行应用程序并且它不支持多个实例，那么调用Process.Kill可能是一个好主意。
我知道一些应用程序需要很长时间才能终止，我希望有一天他们会残忍地杀死自己，而不是让我，用户，这样做（在操作系统重新启动时尤其烦人）。
Why not use System.Environment.Exit(int)? It seems like you want to do this just to save code. To me it's much clearer to see the call to Exit does and your shutdown will be more controlled, Finalizers and Critical Finalizers will run.