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，问题就藏得深。
