file.readalllines适合小文件，一次性加载全部行到内存；file.readlines适合大文件，延迟加载节省内存；streamreader适合复杂控制需求，需注意资源释放和编码匹配。
用 File.ReadAllLines 一次性读取所有行，适合小文件
如果文件不大（比如几 MB 以内），File.ReadAllLines 是最直接的选择。它返回 string[]，每项是一行内容（不含换行符）。
注意：它会把整个文件加载进内存，大文件容易触发 OutOfMemoryException。
- 自动处理 BOM（如 UTF-8 带签名），但编码默认是系统当前编码（
Encoding.Default），非 UTF-8 文件可能乱码 - 想指定编码，必须用重载：
File.ReadAllLines(path, Encoding.UTF8) - 空行会被保留为长度为 0 的字符串，不会跳过
用 File.ReadLines 流式读取，推荐用于大文件或逐行处理
File.ReadLines 返回 IEnumerable<string></string>，底层使用延迟执行 + 按需读取，内存占用低，且支持 foreach 直接遍历。
它不会一次性加载全部内容，读到哪行才解析哪行，适合日志分析、过滤、转换等场景。
里面有2个文件夹。其中这个文件名是:finishing，是我项目还没有请求后台的数据的模拟写法。请求后台数据之后，瀑布流的js有一点点变化，放在文件名是：finished。变化在于需要穿参数到后台，和填充的内容都用后台的数据填充。看自己项目需求来。由于chrome模拟器是不允许读取本地文件json的，所以如果你要进行测试，在hbuilder打开项目就可以看到效果啦，或者是火狐浏览器。
- 同样支持编码指定：
File.ReadLines(path, Encoding.UTF8) - 与
ReadAllLines不同，它不缓存结果 —— 不能多次遍历同一返回值（除非转成List或ToArray） - 文件被其他进程占用时，首次
foreach迭代就抛异常，而不是等到最后才报错
用 StreamReader 手动控制读取逻辑，适合复杂需求
当需要精确控制缓冲区大小、响应中断、跳过前 N 行、或边读边解密/解压时，StreamReader 更灵活。
常见错误是忘记调用 Dispose 或没用 using，导致文件句柄泄漏。
- 务必用
using包裹：using (var reader = new StreamReader(path, Encoding.UTF8)) { string line; while ((line = reader.ReadLine()) != null) { // 处理 line } } -
reader.ReadLine()返回null表示 EOF，不是空字符串；空行返回"" - 若文件含混合编码或损坏字节，
StreamReader默认会抛ArgumentException，可设detectEncodingFromByteOrderMarks: false或捕获异常
遇到中文乱码？先确认文件实际编码再选 API
很多“读不出来中文”的问题，根源是编码不匹配。记事本另存为时选“UTF-8”和“UTF-8-BOM”在 C# 中行为不同：File.ReadLines 能识别 BOM 并自动切到 UTF-8，但若文件是无 BOM 的 UTF-8，又没显式传 Encoding.UTF8，就会按系统默认编码（如 GBK）解析，必然乱码。
- 用十六进制编辑器或命令行
file -i filename（Linux/macOS）查真实编码 - Windows 上可用 PowerShell：
Get-Content -Path file.txt -Encoding UTF8测试是否正常 - 别依赖
Encoding.Default，尤其部署到服务器时，系统区域设置可能和开发机不同
逐行读取本身不难，难的是在不同大小、编码、权限、并发场景下选对方式——尤其是编码不明确时，ReadLines 看似省事，反而容易掩盖问题。
