File.AppendAllText是最简单的文本追加方法，但需手动换行、不支持自定义编码和并发安全；高要求场景应选StreamWriter或FileStream。
用 File.AppendAllText 最简单追加文本
如果只是往文件末尾加几行字符串，且不关心编码、异常细节或大文件性能，File.AppendAllText 是最直接的选择。它自动处理文件不存在时创建、存在时追加、默认 UTF-8 编码（BOM 不写入）等逻辑。
常见错误是误以为它会换行——它不会自动加 \n，你得自己拼进去：
File.AppendAllText("log.txt", "操作完成：" + DateTime.Now.ToString() + "\n");
- 文件不存在？自动创建
- 路径含中文或特殊字符？确保目录已存在，否则抛
DirectoryNotFoundException - 想用 GB2312 或 UTF-8 with BOM？不能用这个方法，得换
StreamWriter
需要控制编码或避免锁冲突时用 StreamWriter 配合 FileMode.Append
当要指定编码（如 Encoding.UTF8 带 BOM）、复用流、或在多线程/多进程场景下更精细控制文件访问时，手动构造 StreamWriter 更可靠。
关键点不是“打开再写”，而是明确传入 FileMode.Append 和 FileAccess.Write，否则可能覆盖原内容：
using (var sw = new StreamWriter("data.csv", true, Encoding.UTF8))<br>{<br> sw.WriteLine("新记录,2024-06-15");<br>}
- 第二个参数
true表示追加，等价于FileMode.Append - 显式传
Encoding.UTF8可避免系统默认编码（如中文 Windows 的 GB2312）导致乱码 - 没加
using或没调sw.Close()？文件句柄不释放，后续写入可能报IOException
AppendAllText 和 StreamWriter 在并发写入时都可能出错
两者都不是线程安全的。同一文件被多个线程/进程同时调用追加，大概率出现内容错乱、丢失或 IOException（“文件正由另一进程使用”）。
- 单进程多线程？加
lock或用ConcurrentQueue+ 单独写入线程 - 多进程（如多个 .NET 程序）？必须用文件锁（
FileStream.Lock）或改用日志库（如 NLog、Serilog） - 高频小写入（如每秒百次）？攒批写入比逐条追加快得多，也减少 I/O 压力
追加二进制数据不能用文本方法
如果目标是往文件末尾塞字节（比如合并图片、追加 protobuf 序列化数据），千万别用 AppendAllText 或 StreamWriter——它们会按文本编码转换，破坏原始字节。
必须用 FileStream 打开并定位到末尾：
using (var fs = new FileStream("out.bin", FileMode.OpenOrCreate, FileAccess.Write, FileShare.Read))<br>{<br> fs.Seek(0, SeekOrigin.End);<br> fs.Write(dataBytes, 0, dataBytes.Length);<br>}
-
FileMode.OpenOrCreate+Seek(0, SeekOrigin.End)是安全组合，不管文件是否存在都追加到末尾 - 漏掉
fs.Seek？可能从开头或当前位置写，覆盖原有内容 - 没设
FileShare.Read？其他程序读该文件时会失败
实际项目里，真正需要“纯追加”的地方往往隐含并发、编码、性能三重约束，光靠一行 AppendAllText 很难扛住。
