我刚刚注意到，我们应用程序中的日志记录代码使用
streamWriter.Write(message);
而不是
await streamWriter.WriteAsync(message);
但是.Write真的会像普通异步操作那样阻塞当前线程吗？在一个大规模并发系统中，我是否会看到转移到WriteAsync的性能优势？
StreamWriter是否会阻塞取决于它将数据写入的流。如果你查看StreamWriter的源代码，你会发现Write只会将数据添加到其内部缓冲区，并在缓冲区满时将其刷新到流。
流将数据复制到其内部缓冲区，当缓冲区已满时，它将被刷新。冲洗将进行实际节约。
如果Stream是MemoryStream，那么Flush不会花太多钱，但如果它写入文件，那么可能需要一些时间。
总而言之，您可以看到所有涉及的缓冲区。Stream和StreamWriter概念的设计者在异步等待发明之前就已经考虑过改进响应时间的方式。
可能要进行实际写入的设备驱动程序也有一些缓冲机制，以防止写入程序必须等待数据真正写入硬盘。
理论上，如果您的StreamWriter已满，并将数据刷新到已满的Stream，然后将数据刷新至已满的磁盘缓冲区，则您将获得处理时间，磁盘缓冲区已满，必须等待数据真正写入。然而，我怀疑这种情况是否经常发生。
是的，最好转移到WrtieAsync，因为WriteAsync方法使您能够在不阻塞主线程的情况下执行资源密集型I/O操作。
这种性能考虑在Windows 8.x应用商店或桌面应用程序中尤为重要，因为在这些应用程序中，耗时的流操作可能会阻塞UI线程，并使您的应用程序看起来好像不工作。async方法与Visual Basic和C#中的async和await关键字一起使用。
https://learn.microsoft.com/en-us/dotnet/api/system.io.stream.writeasync?view=netframework-4.7.2