所以最近我正在通过C＃阅读Richter的书 CLR。它是关于.NET Framework 4.5或类似的东西，他指出FileReader.ReadAsync并不是真正的异步，它实际上只是基于同步win32 API的异步包装。我不是.NET Framework开发人员，我使用.NET Core。所以我有几个问题：
FileReader.ReadAsync，它会异步读取吗？ FileOptions.Asynchronous有什么意义，如果您可以根据我调用的方法Read或ReadAsync来确定要同步还是异步操作？win32不提供的功能，为什么不使用WinRT进行异步读取/打开？ FileStream.ReadAsync始终从应用程序级别视图异步读取文件（从某种意义上说，此时调用并未被阻止，只是将控制权返回给用户代码）。
但这是真正的还是模拟的异步I / O-取决于FileOptions.Asynchronous选项：取决于Using Async for File Access (C#)
此选项导致异步I / O在操作系统上发生 水平。通过使用此选项，可以避免阻塞ThreadPool 在许多情况下都是线程
这是
的答案拥有该FileOptions.Asynchronous有什么意义
和书本
创建FileStream对象时，可以指定是否 想通过同步或异步操作进行通信 FileOptions.Asynchronous 标志（等同于调用 Win32 CreateFile 函数并向其中传递 FILE_FLAG_OVERLAPPED 旗）。如果未指定此标志，则Windows将执行所有 对文件进行同步操作。当然，你仍然可以 调用FileStream的 ReadAsync 方法，并在您的应用程序中 就像该操作是异步执行，但在内部执行一样 FileStream类使用另一个线程来模拟异步 行为;使用此线程很浪费，并且会影响性能。在 另一方面，您可以通过指定 FileOptions.Asynchronous 标志。然后您可以调用FileStream的Read 执行同步操作的方法。在内部，FileStream 类通过启动异步操作来模拟此行为，并且 然后立即使调用线程进入睡眠状态，直到操作完成 做完了。这也是低效的，但效率不如 使用没有构造的FileStream调用ReadAsync FileOptions.Asynchronous 标志
因此，此处声明FileStream类仅在您未指定 FileOptions.Asynchronous标志的情况下才使用另一个线程来模拟异步行为。
如果WinRT提供了该功能，为什么不使用WinRT进行异步读取/打开，以及 win32不？
winRT内部仍然会调用win32（或本机）api。