1. 文件操作从“知道”到“会用”的鸿沟在C#开发里文件读写听起来是个基础得不能再基础的话题。但凡学过几天C#谁不知道用File.ReadAllText或者StreamReader呢但真到了项目里面对一个几百兆的日志文件要解析或者需要处理用户上传的图片又或者要保证多线程环境下的写入安全很多人就开始抓瞎了。基础不牢地动山摇。文件操作这块“基础”恰恰是区分“代码搬运工”和“能解决问题的开发者”的一道坎。它不仅仅是调用几个API更涉及到资源管理、异常处理、性能取舍和不同场景下的最佳实践。这篇文章我就结合自己这些年趟过的坑把C#里文件读取和写入那点事掰开了揉碎了讲清楚目标是让你看完之后面对任何文件操作需求都能立刻选出最合适、最稳妥的方案并且知道为什么这么选。2. 基石理解System.IO的核心类与“流”的概念在动手写代码之前我们必须先建立正确的认知模型。C#中文件操作的核心命名空间是System.IO。这里面的类看似繁多但按职责可以清晰地分为几层。最顶层是静态工具类比如File和Directory它们提供了一次性操作的便捷方法。中间层是各种Reader和Writer例如StreamReader,StreamWriter,BinaryReader,BinaryWriter它们提供了基于文本或二进制的、带缓冲的高层操作接口。而最底层也是最核心的是Stream流这个抽象类。你可以把“流”想象成一根连接你的程序和磁盘或网络、内存的水管。数据就像水在这根管子里单向流动读取时从源流向程序写入时从程序流向目标。FileStream,MemoryStream,NetworkStream都是Stream的具体实现分别对应文件、内存和网络这三种“水源”或“水池”。为什么“流”如此重要因为它引入了两个关键概念资源管理流代表了一个需要被妥善管理的系统资源如文件句柄。你必须在使用完毕后关闭它否则会导致资源泄漏在长时间运行的程序中可能耗尽系统资源。增量处理流允许你一次只处理一小块数据比如1KB的缓冲区而不是一次性将整个文件加载到内存。这对于处理大文件至关重要。很多初学者犯的第一个错误就是只记住File.ReadAllText遇到大文件就直接内存溢出。理解了流你就知道在什么时候该换用FileStream配合缓冲区来一点点“舀水”。2.1 File类的便捷性与局限性File类非常适合执行简单的、原子性的文件操作。它的方法都是静态的用起来非常顺手。// 写入创建或覆盖文件 File.WriteAllText(C:\data\test.txt, Hello, World!); // 追加内容 File.AppendAllText(C:\data\test.txt, \nThis is a new line.); // 读取全部内容 string content File.ReadAllText(C:\data\test.txt); // 按行读取返回字符串数组 string[] lines File.ReadAllLines(C:\data\test.txt);为什么这么方便因为这些方法内部帮你完成了打开文件流、创建读写器、处理数据、关闭流等一系列操作。你一行代码它背后可能做了十件事。但是局限性也很明显内存压力ReadAllText和ReadAllLines会把整个文件内容一次性加载到内存中的字符串或数组里。一个100MB的文件就会瞬间占用100MB以上的内存字符串还有额外开销。文件稍大程序就可能崩溃。缺乏控制你无法在读取过程中进行复杂的逻辑判断比如读到某一行不符合条件就提前终止也无法精细控制缓冲区大小。异常处理如果文件很大读取过程中发生异常你可能已经占用了大量内存。结论File类的快捷方法适用于小配置文件、临时文本等确定很小的文件操作。但凡对文件大小没有绝对把握或者需要处理过程控制就应该考虑使用基于流的方式。2.2 使用StreamReader和StreamWriter进行文本处理当需要逐行处理文本文件或者文件较大时StreamReader和StreamWriter是黄金搭档。它们内部封装了流并提供了针对文本编码的缓冲读写功能既保持了流的可控性又提升了文本处理的便利性。核心用法始终使用using语句这是文件操作中最重要的最佳实践没有之一。using语句能确保即使在发生异常的情况下底层的流资源也会被正确关闭和释放。// 写入示例 string filePath C:\data\log.txt; using (StreamWriter writer new StreamWriter(filePath, append: true)) // append: true 表示追加模式 { writer.WriteLine(${DateTime.Now}: Application started.); writer.WriteLine(Another log entry.); } // 离开using范围writer和底层流会自动Dispose文件句柄被释放 // 读取示例 using (StreamReader reader new StreamReader(filePath)) { string line; while ((line reader.ReadLine()) ! null) // 逐行读取到文件尾时ReadLine返回null { Console.WriteLine($Processing: {line}); // 可以在这里加入业务逻辑例如解析日志、过滤数据等 if (line.Contains(ERROR)) { // 发现错误日志进行特殊处理 } } }关键细节与避坑指南编码问题超级大坑文本文件的本质是字节需要编码规则如UTF-8、GB2312将字节解码成字符。如果编码不对中文等非ASCII字符就会显示为乱码。StreamReader默认使用UTF-8编码。如果你的文件是GB2312编码的必须显式指定。using (StreamReader reader new StreamReader(filePath, Encoding.GetEncoding(GB2312))) using (StreamWriter writer new StreamWriter(filePath, false, Encoding.UTF8)) // 指定写入为UTF-8最稳妥的方式是知道源文件的编码。在Windows下创建的.txt文件可能是带BOM的UTF-8或无BOM的UTF-8也可能是ANSI即系统默认代码页如GBK。文件路径使用原始字符串前缀可以避免转义反斜杠。更好的做法是使用Path.Combine来拼接路径它能自动处理不同操作系统的路径分隔符。string dir C:\data; string fileName log.txt; string fullPath Path.Combine(dir, fileName); // 输出: C:\data\log.txt异常处理文件操作可能抛出多种异常FileNotFoundException文件不存在、DirectoryNotFoundException目录不存在、UnauthorizedAccessException无权限、IOException文件被占用、磁盘已满等。务必用try-catch包裹核心操作给用户或日志提供友好的错误信息。try { using (var reader new StreamReader(filePath)) { // ... } } catch (FileNotFoundException ex) { Console.WriteLine($文件没找到: {ex.FileName}); } catch (IOException ex) { Console.WriteLine($读写文件时出错: {ex.Message}); }3. 进阶直接操控FileStream与二进制处理当你需要处理图片、音频、视频、自定义格式数据包等非文本文件或者需要对文件进行随机访问如修改文件中间某一段数据时FileStream和BinaryReader/BinaryWriter就派上用场了。3.1 使用FileStream进行字节级操作FileStream提供了最底层的文件访问能力直接操作字节数组。// 示例复制一个文件模拟基础功能 string sourceFile C:\data\source.jpg; string destFile C:\data\dest.jpg; byte[] buffer new byte[4096]; // 4KB的缓冲区这是一个经验值平衡了内存和IO次数 using (FileStream sourceStream new FileStream(sourceFile, FileMode.Open, FileAccess.Read)) using (FileStream destStream new FileStream(destFile, FileMode.Create, FileAccess.Write)) { int bytesRead; while ((bytesRead sourceStream.Read(buffer, 0, buffer.Length)) 0) { destStream.Write(buffer, 0, bytesRead); // 注意这里写入的是实际读取的字节数(bytesRead)而不是buffer.Length } }关键点解析FileMode指定操作系统打开文件的方式。常用值有Open打开现有文件、Create创建新文件如果存在则覆盖、CreateNew创建新文件如果存在则抛出异常、Append打开文件并定位到末尾用于追加。FileAccess指定流的访问方式。Read、Write、ReadWrite。合理设置可以提高代码的意图清晰度和安全性。缓冲区大小byte[] buffer的大小直接影响性能。太小如512字节会导致频繁的IO操作增加系统调用开销太大如10MB会浪费内存且单次IO延迟可能变高。通常4KB到64KB是一个合理的范围因为这与磁盘扇区大小和操作系统页面大小较为匹配。在实际项目中可以通过性能测试来找到最佳值。bytesRead的重要性Read方法返回实际读取的字节数。最后一次读取时文件剩余数据可能不足以填满整个缓冲区bytesRead就会小于buffer.Length。写入时必须使用这个值否则会把缓冲区中上次残留的无用数据也写进去。3.2 使用BinaryReader和BinaryWriter处理结构化二进制数据对于具有固定格式的二进制文件例如一个自定义的游戏存档文件前4字节是版本号接着8字节是玩家金币数然后是可变长度的玩家名直接操作byte[]会很繁琐。BinaryReader和BinaryWriter提供了读写基本数据类型如int,double,string的便捷方法它们内部会处理字节序等问题。// 写入一个自定义格式的二进制文件 string dataFile C:\data\player.dat; using (FileStream fs new FileStream(dataFile, FileMode.Create)) using (BinaryWriter writer new BinaryWriter(fs)) { writer.Write(1); // 写入int版本号 writer.Write(999999L); // 写入long类型的金币数 writer.Write(PlayerOne); // 写入字符串会先写入长度前缀 } // 读取该文件 using (FileStream fs new FileStream(dataFile, FileMode.Open)) using (BinaryReader reader new BinaryReader(fs)) { int version reader.ReadInt32(); long gold reader.ReadInt64(); string name reader.ReadString(); // 会根据写入时的长度前缀正确读取 Console.WriteLine($Version:{version}, Gold:{gold}, Name:{name}); }注意事项读写顺序必须严格对应先写什么就必须先读什么。顺序错乱会导致读取到错误的数据甚至引发EndOfStreamException。字符串的编码BinaryWriter.Write(string)默认使用UTF-8编码并在字符串数据前写入一个长度前缀7位编码的整数。BinaryReader.ReadString()会依赖这个前缀来读取正确数量的字节。如果你需要与其他程序交互必须确认编码和格式是否一致。资源释放只需要释放最外层的BinaryReader/BinaryWriter它们会关闭底层包装的Stream。4. 实战场景与性能优化策略掌握了基本工具后我们来看看如何在实际场景中应用并优化。4.1 场景一高效读取并处理超大日志文件假设有一个超过1GB的服务器日志文件server.log需要统计其中“ERROR”级别的日志行数。使用File.ReadAllLines是自杀行为。优化方案异步流读取从 .NET Framework 4.5 / .NET Core 开始StreamReader提供了异步方法可以在等待IO操作磁盘读取时不阻塞当前线程提高应用程序的响应能力特别是在UI程序或Web服务中。public async Taskint CountErrorLinesAsync(string filePath) { int errorCount 0; const int bufferSize 8192; // 8KB缓冲区 // File.OpenText 是一个快捷方式用于创建读取UTF-8编码文本的StreamReader using (var reader new StreamReader(filePath, Encoding.UTF8, true, bufferSize)) { // 异步读取所有行到内存不我们仍然需要流式处理。 // 但我们可以异步地逐行读取。 string line; while ((line await reader.ReadLineAsync().ConfigureAwait(false)) ! null) { if (line.Contains(ERROR)) { errorCount; // 这里可以加入更复杂的分析逻辑 } } } return errorCount; }为什么用ConfigureAwait(false)在库代码或非UI的上下文如控制台程序、Web API的后台逻辑中使用ConfigureAwait(false)可以避免回调强制回到原始的同步上下文如UI线程能轻微提升性能并避免死锁。但在UI事件处理程序中通常需要回到UI线程来更新控件这时就不应该使用它。4.2 场景二多线程环境下的安全写入如果多个线程或进程需要同时向同一个日志文件追加内容直接使用StreamWriter可能会造成日志内容交错混乱。解决方案使用锁或专用日志库简单的进程内锁如果只是同一个应用程序内的多个线程要写日志可以使用lock语句确保同一时刻只有一个线程在执行写入操作。private static readonly object _logFileLock new object(); public void LogMessage(string message) { lock (_logFileLock) { using (StreamWriter sw new StreamWriter(_logFilePath, true)) { sw.WriteLine(${DateTime.Now:yyyy-MM-dd HH:mm:ss} - {message}); } } }注意lock只对同一进程内的线程有效。如果多个独立进程如多个网站工作进程需要写同一个文件此方法无效。使用成熟的日志库对于生产环境强烈推荐使用Serilog,NLog,log4net等专业日志库。它们内置了线程安全、异步写入、文件滚动按日期或大小分割新文件、日志级别过滤、多种输出目标文件、数据库、网络等高级功能比自己造轮子稳定高效得多。4.3 场景三监控文件变化并实时读取有时需要监视一个目录下的文件变化如新生成的日志文件并实时读取新增的内容。.NET 提供了FileSystemWatcher类。public void WatchLogDirectory(string directoryPath) { FileSystemWatcher watcher new FileSystemWatcher(); watcher.Path directoryPath; watcher.Filter *.log; // 只监视.log文件 watcher.NotifyFilter NotifyFilters.LastWrite | NotifyFilters.FileName; // 监视写入和文件名变化 // 事件处理 watcher.Changed OnFileChanged; // 文件被修改 watcher.Created OnFileCreated; // 新文件被创建 watcher.Deleted OnFileDeleted; watcher.Renamed OnFileRenamed; watcher.EnableRaisingEvents true; // 开始监视 Console.WriteLine($开始监视目录: {directoryPath}); } private void OnFileChanged(object source, FileSystemEventArgs e) { // 注意Changed事件可能会被触发多次例如大文件写入时 if (e.ChangeType WatcherChangeTypes.Changed) { Console.WriteLine($文件被修改: {e.FullPath}); // 这里可以触发一个延迟处理或者使用一个队列来避免短时间内重复处理同一个文件 } } private void OnFileCreated(object source, FileSystemEventArgs e) { Console.WriteLine($新文件创建: {e.FullPath}); // 立即读取新文件内容 Task.Run(() ProcessNewFile(e.FullPath)); }避坑提示FileSystemWatcher的Changed事件可能因为文件的多次写入而被快速、连续地触发多次。直接在里面做复杂的文件读取操作可能导致资源竞争或重复处理。常见的做法是使用一个定时器或生产者-消费者队列将文件路径放入队列由后台线程间隔一定时间后去统一处理。它有一定延迟不是完全实时的。确保程序有权限访问被监视的目录。5. 现代C#中的新选择File类的新API与System.Text.Json随着 .NET Core / .NET 5 的发展文件操作也引入了一些更现代、更简洁的API。5.1 File类的异步方法File类现在也提供了异步版本的方法如ReadAllTextAsync,WriteAllTextAsync等。它们对于处理中等大小的文件非常方便同时不会阻塞调用线程。// 异步读取一个配置文件 string configJson await File.ReadAllTextAsync(appsettings.json); // 异步写入 await File.WriteAllTextAsync(output.json, configJson);切记这些方法依然是一次性加载整个文件到内存。它们只是把IO等待过程变成了异步的并没有改变其内存消耗大的本质。适用于已知较小的文件。5.2 使用System.Text.Json流式处理JSON文件处理大型JSON文件时全量加载到内存再用JsonSerializer.Deserialize反序列化同样会内存爆炸。System.Text.Json提供了基于Utf8JsonReader的流式读取API。// 假设有一个巨大的JSON数组文件我们需要逐个读取其中的对象 using (FileStream fs File.OpenRead(large_data.json)) using (var jsonDocument JsonDocument.Parse(fs)) // 注意JsonDocument.Parse(Stream) 仍然会完整读取流但对于文档模型是高效的。 { // 更彻底的流式处理需要使用 Utf8JsonReader这里用JsonDocument演示遍历 JsonElement root jsonDocument.RootElement; if (root.ValueKind JsonValueKind.Array) { foreach (JsonElement element in root.EnumerateArray()) { // 逐个处理数组中的元素每个element在内存中只存在一个 if (element.TryGetProperty(id, out JsonElement idProp)) { int id idProp.GetInt32(); Console.WriteLine($Processing item ID: {id}); } } } }对于极大的JSON文件更推荐使用Utf8JsonReader它是一个向前只读的阅读器可以像XmlReader一样在流上逐步前进内存占用极低。但它的API较为底层需要手动处理JSON令牌。文件读写是C#程序员的基本功但绝不是简单的记忆API。从选择File的便捷到StreamReader的灵活再到FileStream的精准控制每一层都有其适用的场景和需要避开的陷阱。理解“流”的概念是掌握这一切的钥匙而妥善的资源管理using语句和全面的异常处理则是写出健壮代码的保障。在性能敏感的场景下考虑缓冲区大小、异步操作和流式处理在复杂场景下借助成熟的第三方库。把这些点连成线形成你自己的知识体系下次再面对文件操作的需求时你就能从容地选出那把最合适的“手术刀”干净利落地解决问题。