RichTextBox分块加载文件时AppendText出现空行问题及相关疑问

让我来帮你拆解这两个问题：

你遇到的多余空行问题，核心原因是没有利用ReadBlockAsync的返回值。

ReadBlockAsync方法会返回本次调用实际读取到的字符数——当文件剩余字符数小于你的bufferSize时（比如最后一次读取），buffer数组里未被填充的位置会保留默认的'\0'（空字符）。而你直接将整个buffer数组转换成字符串并Append到RichTextBox，这些空字符会被RichTextBox解析为空白内容，最终表现为多余的空行。

修正后的代码只需要截取实际读取的字符段即可解决这个问题：

richTextBox.Clear();
progressBar.Value = 0;
const int bufferSize = 1024 * 1024 * 3; 
using (StreamReader streamReader = new StreamReader(path))
{
    while (streamReader.Peek() != -1)
    {
        char[] buffer = new char[bufferSize];
        // 获取实际读取的字符数
        int actualReadCount = await streamReader.ReadBlockAsync(buffer, 0, bufferSize);
        // 只转换并追加实际读取的部分
        richTextBox.AppendText(new string(buffer, 0, actualReadCount));
        progressBar.Value = (int)(((double)streamReader.BaseStream.Position) / streamReader.BaseStream.Length * 100);
    }
}

另外补充一种可能的边缘情况：如果你的文件使用Unix风格的换行符（\n），而RichTextBox在某些环境下对单换行的渲染可能出现异常，但这不是你当前问题的核心，优先解决buffer截取的问题即可。

StreamReader vs FileStream/BinaryReader #

StreamReader确实会比FileStream或BinaryReader慢一些，原因很简单：

• StreamReader是文本读取器，它会在读取字节的基础上额外做编码转换（比如把UTF-8字节转换成.NET的char类型），还会处理换行符、编码检测等逻辑；
• FileStream和BinaryReader是直接操作字节流的，没有编码转换的开销。

但如果你的目标是读取文本内容并显示到RichTextBox，StreamReader是更合适的选择——它帮你处理了编码的复杂性，避免手动转换字节到字符时出现乱码问题。如果用FileStream/BinaryReader，你需要自己处理编码转换，反而容易出错。

Read vs ReadBlock #

两者的核心区别在于是否阻塞直到读取到指定数量的字符：

• Read方法会尝试读取最多指定数量的字符，但可能因为流的状态（比如网络流的延迟）返回更少的字符；
• ReadBlock方法会阻塞，直到读取到指定数量的字符，或者到达流的末尾。

对于本地文件的分块加载场景，ReadBlock（或异步版本ReadBlockAsync）是更好的选择，因为它能保证每次读取到最大可能的字符数（除非文件已经读完），减少循环次数，提升加载效率。而Read更适合处理不确定流（比如网络流）的场景。

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