streamwriter构造函数选new streamwriter(path, true)可追加写入；writeline后需flush或using确保落盘；默认utf-8编码，显式指定更稳妥；禁用autoflush并合理设置缓冲区大小以提升大文件写入性能。
StreamWriter 不是“写文件”的快捷键，而是可控写入的起点——用错构造函数或忽略 Flush，你写的字可能根本没落盘。
StreamWriter 构造函数选哪个？关键看要不要追加
直接传路径创建 StreamWriter 时，最常踩的坑就是默认覆盖文件，而不是追加。比如：
-
new StreamWriter("log.txt")→ 文件存在就清空重写，旧日志全丢 -
new StreamWriter("log.txt", true)→ 自动追加，适合日志场景 -
new StreamWriter("log.txt", false)→ 效果同第一个，false是默认值，可省略
注意：true/false 参数只控制“是否追加”，不控制“文件不存在时是否创建”——它总会创建。如果你需要更精细控制（比如只在文件存在时打开、禁止创建），必须先用 FileStream 构造，再传给 StreamWriter。
WriteLine 写进去了，但文件里看不到？检查 Flush 和 Dispose
常见现象：程序跑完，打开文件是空的，或者只有前几行。原因通常是缓冲区没刷出。
-
StreamWriter默认带缓冲，Write或WriteLine只写进内存缓冲区，不立即落盘 -
using块结束时会自动调用Dispose，进而触发Flush—— 这是安全写法 - 手动调用
Close()也行，但不如using可靠（异常时可能跳过） - 如果中间要确保内容已写入（比如写关键日志后立刻可见），显式调用
Flush()
错误示范：StreamWriter sw = new StreamWriter("a.txt"); sw.WriteLine("x"); sw.Close(); —— 看似没问题，但没 try/finally 或 using，异常时 Close 可能不执行。
编码不指定，中文就乱码？UTF-8 是默认，但得确认源环境
StreamWriter 默认用 UTF-8 编码（无 BOM），大多数现代系统兼容。但乱码往往来自两端不一致：
- 用
new StreamWriter("f.txt", true, Encoding.UTF8)显式指定，比依赖默认更稳妥 - 如果文件要被老旧工具（如某些 Windows 记事本版本）打开，且需显示中文，考虑用
Encoding.Default（即系统 ANSI 编码），但跨机器不可靠 - 用
Encoding.UTF8时，别指望记事本自动识别——它可能当 ANSI 解析；用 VS Code、Notepad++ 就没这问题
特别注意：Encoding.UTF8 和 new UTF8Encoding(true) 不同——后者带 BOM，前者不带。BOM 在多数 C# 场景下非必需，反而可能干扰解析。
大文件持续写入？别让 AutoFlush 拖慢你
开启 AutoFlush = true 听起来很安心，但每写一行都刷磁盘，性能会断崖式下跌。
- 默认
AutoFlush = false，靠缓冲区攒够再写，吞吐高 - 日志类场景，可用定时
Flush()或按大小阈值手动刷，平衡实时性与性能 - 千万别在循环里写一行、
Flush一次——这是典型低效模式
真正容易被忽略的点：StreamWriter 的缓冲区大小是 1024 字节（默认），如果单行超长或写入频繁小字符串，缓冲区可能频繁触发刷新。这时传入更大的缓冲区（如 new StreamWriter(fs, enc, 8192)）反而更稳。
