async/await搭配Task.Run的按钮点击实现相比同步实现有何优势？

以下结论默认基于WinForms/WPF/MAUI等主流桌面UI框架的场景，这类框架的所有UI事件回调默认运行在独占的UI线程上，UI线程被阻塞时程序会直接进入无响应状态。
两种写法的差异和第一种实现的收益如下：

• 避免UI阻塞：如果DoSomething是CPU密集型的耗时操作（比如复杂业务计算、批量数据处理、大文件序列化等），第二种同步写法执行期间UI线程会被完全占用，用户无法拖动窗口、点击其他按钮、最小化程序，整体表现为程序卡死。而第一种写法会通过Task.Run将DoSomething调度到线程池线程执行，await期间UI线程会被释放，可正常响应其他用户操作，全程不会出现无响应的情况。
• 更容易扩展交互逻辑：如果后续需要给耗时操作加进度展示、中途取消的能力，第一种写法可以直接配合IProgress<T>、CancellationToken实现，执行过程中可以安全地将进度同步回UI线程更新进度条，也能快速响应用户的取消操作。这些需求在第二种同步写法中实现成本极高，很容易出现线程安全问题或者仍然阻塞UI。
• 降低后续改造成本：如果后续DoSomething需要替换为异步IO实现（比如调用HTTP接口、读写大文件、操作数据库），第一种写法只要调整DoSomething为异步方法，去掉Task.Run直接await即可，整体方法结构不需要做大幅调整。第二种同步写法要对接异步逻辑则需要完全重构方法结构，还容易触发同步等待异步带来的死锁问题。
• 适用场景限制：如果DoSomething本身是执行时间极短的轻量操作，第一种写法反而会产生不必要的线程池调度开销，这种场景下没有使用的必要。

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