在Form.Closing中调用Form.Close引发的递归问题及平台差异咨询

首先得明确：在Form.Closing事件处理程序里调用Close()是完全错误的写法，必然会触发无限递归——因为Close()方法本身会触发窗体的Closing事件，等于每次执行到这行代码，都会重新进入Form1_Closing方法，循环往复。

为什么Win7会栈溢出，Win10却没问题？ #

这是因为不同系统对线程栈的限制和处理逻辑略有差异：Win7的栈空间阈值相对严格，递归次数达到一定程度就会触发栈溢出；而Win10可能优化了栈的分配，或者WinForms在Win10环境下对这种递归有隐性的终止处理（比如内部限制了Closing事件的触发次数），但本质上这个递归逻辑依然是有问题的，只是没表现出崩溃而已。

推测原开发者这么写的可能原因 #

结合WinForms开发的常见误区，大概率是下面几种情况之一：

• 对窗体关闭流程理解错误：原开发者可能误以为Closing事件只是“通知要关闭”，需要手动调用Close()来完成关闭动作。但实际上，Closing事件是窗体关闭流程中的一个环节——当用户点击关闭按钮、调用Close()等触发关闭时，系统会先触发Closing事件，允许你在这个阶段做清理或者取消关闭，之后会自动继续完成关闭流程，根本不需要手动再调用Close()。
• 想绕过取消逻辑：如果之前的自定义代码里有e.Cancel = true的逻辑（比如用户取消了确认对话框），原开发者可能误以为调用Close()能强制关闭窗体，忽略这个取消设置。但实际上，正确的做法应该是在需要强制关闭时设置e.Cancel = false，而不是调用Close()——后者只会引发递归。
• 代码复制粘贴的失误：可能是把其他场景下的代码（比如按钮点击事件里的关闭逻辑）直接复制到了Closing事件中，没注意上下文差异导致的错误。

关于你注释掉Close()后的情况 #

注释后功能正常，说明原来的自定义代码已经完成了关闭前的所有必要操作（比如保存数据、释放资源等），窗体的正常关闭流程可以顺利完成，完全不需要额外调用Close()。这也进一步证明了这行代码是多余的错误写法。

总结 #

这种写法没有任何合理的应用场景，纯粹是对WinForms窗体生命周期的误解或编码疏忽导致的错误。你现在注释掉这行Close()是完全正确的修复方式，既解决了潜在的栈溢出风险，又不影响原有功能的正常运行。

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