StreamReader调用ReadLine()返回null最常见原因是文件路径错误、为空、流已关闭或Position在末尾；读大文件应流式逐行处理；中文乱码因未指定UTF8编码；ObjectDisposedException多因using块外访问或异步调用不当。
StreamReader 读取文件时为什么一调用 ReadLine() 就返回 null？
最常见原因是文件路径错误或文件为空，但更隐蔽的是流已被提前关闭或 StreamReader 构造时传入了已读到末尾的 Stream。比如用 File.OpenRead() 创建流后又手动调用了 stream.Position = stream.Length，再传给 StreamReader，此时它从末尾开始读，ReadLine() 立即返回 null。
实操建议：
- 优先用字符串路径构造
StreamReader：new StreamReader("data.txt")，它会自动打开并管理底层流 - 若必须传入
Stream，确保其Position == 0，且未被其他代码关闭 - 检查文件是否真实存在且有读取权限——Windows 上常因 UAC 或文件被记事本独占而静默失败
用 StreamReader 读大文件时内存暴增，怎么安全分块读？
StreamReader 本身不缓存整文件，但若反复调用 ReadToEnd() 或把所有 ReadLine() 结果存进 List<string></string>，就会吃光内存。真正“分块”不是靠 StreamReader 切片，而是控制每次处理的数据量。
实操建议：
- 避免
ReadToEnd()；用while ((line = reader.ReadLine()) != null)流式逐行处理 - 如需按字节数读（例如跳过 BOM 后读 8192 字节），改用
Read(char[], int, int)，并配合Encoding.GetByteCount()估算实际字符数 - 对超大日志文件，考虑用
File.ReadLines("path")（返回IEnumerable<string></string>，延迟执行，不加载全量）代替StreamReader手动循环
中文乱码：为什么 StreamReader 读 UTF-8 文件显示成“”？
默认构造函数使用系统当前 ANSI 编码（如 Windows-1252），不是 UTF-8。即使文件带 BOM，.NET Framework 的 StreamReader 有时也无法自动识别；.NET Core / 6+ 改进较多，但仍建议显式指定。
实操建议：
- 明确传入编码：
new StreamReader("log.txt", Encoding.UTF8) - 若不确定编码，用
StreamReader的CurrentEncoding属性检查实际检测结果（仅限带 BOM 文件） - 注意：UTF-8 无 BOM 文件 + Windows 默认 ANSI 环境 = 必然乱码；别依赖“自动识别”
- 写入时也保持一致：用
StreamWriter指定相同Encoding，否则读写闭环断裂
为什么 using (var r = new StreamReader(...)) 有时抛出 ObjectDisposedException？
常见于跨作用域持有 StreamReader 引用，或在 using 块外访问已释放的实例。另一个高危场景是：将 StreamReader 传给异步方法（如 Task.Run(() => r.ReadLine())），但 using 块已结束、流被关闭，异步操作才真正执行。
实操建议：
-
using块内完成全部读取逻辑，不要把StreamReader实例传出 - 异步读取请用
ReadLineAsync()+await，并在同一using块中 await 完毕 - 若需复用，用
File.OpenText()（返回未缓冲的StreamReader）比手动 new 更安全，但它仍需using
编码和生命周期这两块最容易被忽略，尤其在团队协作或维护旧代码时——一个没指定 Encoding，一个在 using 外调 Dispose，问题就藏得深。
