不加Wait()的问题 #

你最初写的Task.Run(async () => { ... })相当于启动了一个后台“火并忘”任务：

• ASP.NET Core的启动流程（Configure()方法）不会等这个任务执行完就继续往下走，可能种子数据还没写入数据库，程序已经完成启动，甚至DbContext可能已经被依赖注入容器回收释放，导致数据库操作失败。
• 如果任务里抛出异常（比如数据库连接失败），因为没有任何代码等待这个任务，异常会被默默吞掉（或者触发全局的UnobservedTaskException事件），你根本不知道初始化失败了，排查问题会非常困难。

加Wait()之后的变化 #

加上.Wait()后，相当于强制把后台任务变成了同步阻塞执行：

• Configure()方法的执行线程会停下来，直到Task.Run里的所有异步操作（AnyAsync()、AddAsync()、SaveChangesAsync()）全部完成，确保种子数据写入后才继续后续启动步骤，这就是为什么代码能正常工作了。

和原同步代码的效果对比 #

• 表面功能一致：最终都能确保程序启动时完成种子数据初始化，不会出现数据缺失的情况。
• 底层执行逻辑有差异：
  原同步代码全程在启动线程执行，没有线程切换；而加Wait()的版本是把异步逻辑丢给线程池线程，启动线程阻塞等待。这意味着：
  1. 多了线程切换的开销，性能上略逊于原同步代码；
  2. 虽然EF Core的DbContext是轻量级且支持在不同线程使用，但线程环境和原同步代码不同，如果有特殊的线程依赖逻辑可能出问题；
  3. 异常处理不同：原同步代码的异常直接抛出，加Wait()的版本会抛出AggregateException，需要额外处理包装后的异常。

小建议 #

其实你完全没必要用Task.Run+Wait()这种绕弯子的写法：如果想保留异步逻辑，ASP.NET Core支持异步启动流程（比如用IHostBuilder.ConfigureAsync），直接在异步方法里await所有异步操作即可；如果只是想快速实现，直接用同步方式调用异步方法（比如_context.Table.AnyAsync().GetAwaiter().GetResult()）也比Task.Run+Wait()更高效。

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