WPF中OnStartup原生方法与绑定到Startup事件的_Startup方法的核心区别

看你是从零搭WPF App想找最佳实践，刚好纠结这俩启动方式的区别是吧？我给你唠得明明白白！

1. 本质逻辑完全不是一回事儿 #

• 重写OnStartup是直接扩展基类的启动逻辑：它是WPF的Application基类自带的虚方法，你得在自己写的App类里用override关键字重写它，属于把启动逻辑直接融入到应用的核心启动流程里，是类自身的一部分。
• 绑定Startup事件的_Startup方法是给启动流程插个监听钩子：相当于给Application的Startup事件挂了个回调函数，只要启动流程走到触发这个事件的环节，你的函数就会执行。它和核心启动逻辑是松耦合的，哪怕你不碰OnStartup，只要订阅了事件就能加自己的操作。

2. 执行顺序有先后，还能被你掌控 #

应用启动的默认流程是：先跑你重写的OnStartup代码，而Startup事件是在base.OnStartup(e)这个基类调用里触发的。

划重点！要是你在重写的OnStartup里没写base.OnStartup(e)，那Startup事件直接就不会触发！也就是说你可以完全决定要不要让那些事件回调的代码跑起来。
反过来，要是你只订阅了Startup事件，那它的代码会在基类默认的OnStartup逻辑执行之后才跑。

3. 各自适合的场景不一样 #

• 选override OnStartup：适合你要深度定制启动流程的时候，比如启动时要做全局配置初始化、全局异常捕获、决定要不要跳过主窗口直接后台运行，甚至替换整个默认启动逻辑——毕竟你能完全掌控这个方法里的每一行代码，连基类的默认逻辑都能跳过。
• 选Startup事件回调：适合只加一点轻量操作的场景，比如启动时弹个欢迎提示、加载一些非核心的小插件，而且多个组件都能订阅这个事件，能把不同的启动逻辑拆到不同的类里，不用全堆在App类里，代码看着更清爽。

4. 异常处理的小差异 #

要是你在重写的OnStartup里没做异常捕获，没处理的异常会直接往上抛，很可能直接导致应用崩了；而Startup事件回调里的未处理异常，会被Application的DispatcherUnhandledException事件捕获（只要你订阅了这个全局异常事件），容错性相对高那么一丢丢——当然这也得看你有没有配置对应的异常处理逻辑。

内容来源于stack exchange