最近把《C#基础》系列整理到第10篇正好轮到文件操作这一块。可能有朋友觉得文件操作没什么好讲的无非就是读文件、写文件、挪个位置。但真到业务项目里你会发现读配置、写日志、导数据、处理大文件每一类都有各自的讲究踩坑方式也五花八门。我从写上位机程序、桌面工具到后端服务前后折腾了十几年文件IO今天把C#文件操作的API选择、编码细节、日志实现、高频陷阱一次讲透。这篇适合刚学完C#循环和类的朋友也适合写了两年代码但没系统梳理过文件操作的老手。1. 为什么文件操作值得认真对待——思路拆解1.1 文件操作在真实项目里的四个典型场景先回答一个朴素的问题C#程序为什么要操作文件第一个场景是配置文件。桌面程序、上位机程序基本都会有一个配置文件什么串口波特率、设备IP、扭矩上限值这些参数如果写死在代码里客户要改就得重新编译发布。所以要用Json、ini或xml把参数放到外部程序启动时读进来。热词里提到的“读power focus 6000扭矩值”就是这么一回事——硬件参数要么来自通信协议要么来自本地配置文件文件读写就是承载这些参数的基础。第二个场景是日志。实时记录操作行为、异常堆栈、设备状态。尤其做上位机的朋友和硬件设备通信时数据一直在变出问题的时候没有日志排查起来基本靠猜。我自己就经历过设备偶发停机客户描述得玄乎最后是靠日志里一秒一秒的数据定位到是通讯超时导致的而不是硬件坏了。没有日志这种问题永远说不清。第三个场景是数据交换。比如导出一个CSV给客户在Excel里看或者反过来把Excel里的数据导入系统。C#做这类活儿很快前提是你知道文件读写用哪种姿势。很多人一上来就装Office的Com组件结果部署到客户机器上各种权限问题后面我会说更稳的做法。第四个场景是批处理工具。整理文件夹、批量重命名、按规则归档文件这些本质上都是文件操作。很多自动化工具的核心逻辑就是“读目录、找文件、做处理、移位置”把这一套玩明白了写出来的工具能省掉大量重复劳动。这四类场景对应了不同的API选择。有些人写文件习惯“一招鲜”——无论什么都File.WriteAllText小文件没问题但要是日志文件很大或者要持续追加就不合适了。这就是后面要细讲的部分。1.2 想清楚再动手同步还是异步、用哪套API文件操作的API看起来很多File、FileInfo、FileStream、StreamReader、StreamWriter第一次接触容易眼花。我的习惯是分三档。第一档是File静态类File.ReadAllText、File.WriteAllText、File.ReadAllLines这些适合一次性小文件。代码短、语义清楚读配置文件这种场景用它就够了。但缺点是一次性把整个文件装进内存如果是500MB的日志文件内存可能直接爆掉更别提大文件经常是按GB计算的。第二档是FileInfo和DirectoryInfo实例类。当你需要多次操作同一个文件时先把路径包成对象之后再调用Exists、Length、CopyTo等。好处是安全检查可以复用写起来也更面向对象。比如你要判断一个文件是否存在、多大、多久没更新、要不要清理用FileInfo就很顺手。第三档是FileStream、StreamReader、StreamWriter这类流式API。适合大文件、管道式读取、需要控制缓冲区的场景。操作文件本质上是和底层I/O打交道这一档更底层、更灵活也更容易写错。比如FileStream的Position、Seek、ReadAsync这些概念新手很容易搞混。至于同步还是异步我的建议很直接桌面程序和上位机UI线程里写文件千万别用同步阻塞文件一卡界面就飘了。比如点一个“导出报表”按钮文件有几十MB同步写法下界面能卡好几秒。用async/await读文件不会带来太多代码复杂度但体验差异巨大。注意异步不能写成fileStream.ReadAsync().Result之类否则容易死锁这个问题后面再展开。1.3 路径拼接别用字符串相加一个很容易被忽略的坑是路径。新手经常这样写string path C:\Users\admin\Desktop\data\20240401\log.txt;这样写首先可移植性差其次很不优雅。更稳的做法是用Path.Combinestring baseDir C:\Users\admin\Desktop\data; string path Path.Combine(baseDir, 20240401, log.txt);Path.Combine会根据操作系统自动选择斜杠和反斜杠避免手工拼错。跨平台跑的时候也不用担心——毕竟.NET Core现在到处都能跑说不定哪天你的工具就要挪到Linux服务器上到时候你会发现路径分隔符的问题到处都是。还有一种经典坑是相对路径。Console程序默认工作目录通常和exe所在目录不一致尤其是在Visual Studio里启动时工作目录可能是bin\Debug\net8.0这时候直接写log.txt会写到当前工作目录而不是项目根目录。如果你希望文件固定在exe旁边用AppDomain.CurrentDomain.BaseDirectory如果要用户文档目录用Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments)。路径最好由环境计算出来而不是写死这是文件操作里最基础的一条经验。2. 核心细节解析与实操要点2.1 File、FileInfo、FileStream三层API怎么选刚才说了分三档这里展开讲讲背后的设计逻辑。静态类和实例类本质上是同一个底层能力File是静态方法包装每个方法内部都会做权限检查、路径解析之类的操作FileInfo把文件封装成对象实例化之后可以调用成员方法。如果你需要在一个文件上多次调用Exists、CopyTo、Delete用FileInfo更直观因为每次调用File.Exists都要重新解析路径本质上是重复劳动。FileStream则更接近操作系统层面的文件句柄。构造它的时候需要指定FileMode、FileAccess、FileShare打开之后就可以读写字节流。典型的场景是处理一个巨大的日志文件或二进制文件想要逐块处理而不是一次性读入内存。举一个最常见的例子读一个文本文件按行处理文件可能500MB。用File.ReadAllLines会先把所有行加载到内存内存占用几乎等于文件大小的两倍。而用StreamReader逐行读内存占用几乎恒定。这个差别在高配机器上暂时不明显但到了客户那种只有4GB内存的老机器上问题就非常明显了。另一个区别在于写文件时的粒度。File.WriteAllLines适合一次性写出一个列表如果你要持续写、实时写比如设备每秒钟返回一条数据就必须用StreamWriter的追加模式不可能每秒都WriteAllLines一次。2.2 编码问题UTF-8的BOM到底要不要C#文件操作里最容易出乱码的就是编码问题尤其是和其他语言写的程序、Windows记事本、单片机工具联调时。我先说结论统一用UTF-8最好带BOM除非你有明确的兼容需求。为什么建议带BOM因为老版本Windows记事本不认识无BOM的UTF-8会把UTF-8当成ANSI来显示中文就变成乱码。而C#的StreamReader在读取时如果能识别BOM会自动切换编码如果没有BOM它会默认按UTF-8来读但此时如果文件是GBK编码读出来就是乱码。如果项目里老系统还在用GB2312或GBK编码读取时要显式指定var reader new StreamReader(path, Encoding.GetEncoding(GB2312));要注意.NET Core/.NET 5里Encoding.GetEncoding(GB2312)默认会抛异常需要先注册代码页Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);这些细节写过老项目的朋友应该深有体会。另外写入时BOM控制也很关键。默认的new StreamWriter(path)会写UTF-8带BOM如果要去掉BOM用new UTF8Encoding(false)明确创建一个不带BOM的编码再把编码传给StreamWriter。我自己平时写日志文件喜欢无BOM UTF-8因为Linux下grep、tail都正常而Windows记事本现在也不乱码了。但和Excel交换CSV时又一定要带BOM否则Excel打开中文CSV会乱码。这个细节我在第5节还会提到。2.3 FileMode、FileAccess、FileShare 三个枚举的含义很多人看到这三个枚举头大其实这就是文件打开方式的三个维度。FileMode是文件不存在/存在时怎么处理FileAccess是打开后打算读还是写FileShare是别人是否可以同时打开该文件。FileMode常用值CreateNew文件必须不存在否则抛异常Create文件存在则覆盖不存在则新建Open文件必须存在否则抛异常OpenOrCreate存在就打开不存在就新建Truncate文件存在则清空内容Append追加内容到文件末尾FileShare里最常用的是FileShare.ReadWrite。比如日志场景你要让其他进程也能读取正在写的日志就用FileShare.ReadWrite。如果写日志时用了FileShare.None那另一个监控程序想读当前日志就会被拒绝。反过来如果你读取文件时用了FileShare.ReadWrite就能避免“文件被占用”这种异常。我自己写日志组件时永远是用FileShare.ReadWrite来打开文件。FileAccess相对简单常见组合是读文件时FileMode.OpenFileAccess.Read写新文件时FileMode.CreateFileAccess.Write追加日志时FileMode.AppendFileAccess.Write这三个枚举搭配好了文件操作就成功了一半。2.4 FileStream 缓冲区多大合适缓冲区这个参数新手容易忽略。FileStream构造时有个bufferSize参数默认是4096字节。不是说设得越大越好因为缓冲区是每次读取时先从操作系统一次搬多少数据到内存。实际经验是小文件无所谓大文件顺序读IO建议8KB到64KB之间。过度增加到1MB并不会带来成倍提升反而可能增加内存压力。更常见的是把FileStream包在StreamWriter/StreamReader外面。比如using (var fs new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.ReadWrite, 8192)) using (var reader new StreamReader(fs, Encoding.UTF8)) { string line; while ((line reader.ReadLine()) ! null) { // 逐行处理 } }这样既控制了缓冲区大小又通过FileShare.ReadWrite允许其他进程同时读文件避免日志被锁死。在缓冲区的话题上还有一个容易踩坑的点StreamWriter默认带缓冲它会积累一部分内容才真正写入磁盘。如果你写完日志马上断电或者程序崩溃可能丢失几KB。所以写完重要内容之后要调用Flush()或者用using包住让它自动Flush。不过Flush不要太频繁每次Flush都等于一次真实的磁盘IO写日志场景下一行一Flush性能会很难看。3. 实操过程与核心环节实现3.1 文本读写的三个最小可用代码块下面给出一套可以直接抄进项目里的文本读写代码。读取文件按行string path D:\data\config.txt; if (File.Exists(path)) { foreach (var line in File.ReadLines(path)) { Console.WriteLine(line); } }File.ReadLines用的是延迟加载逐行读取不会把整个文件装进内存。如果行数不多也可以用File.ReadAllLines返回string[]用起来更方便而且还能用LINQ做筛选。写入文件覆盖模式string content string.Join(Environment.NewLine, lines); File.WriteAllText(path, content, new UTF8Encoding(false));追加日志模式using (var writer new StreamWriter(path, true, new UTF8Encoding(false))) { writer.WriteLine(${DateTime.Now:yyyy-MM-dd HH:mm:ss} - {message}); }第二个参数true表示追加如果文件不存在会自动创建。用完using释放顺便Flush到磁盘。很多人问为什么我在日志里要手动new UTF8Encoding(false)原因前面讲了为了确保编码一致性避免因为系统默认编码不同导致日志乱码。3.2 用Json文件做程序配置C#里最推荐的配置文件格式就是Json。.NET自带的Microsoft.Extensions.Configuration.Json包可以非常方便地读取配置。先在项目里安装dotnet add package Microsoft.Extensions.Configuration.Json然后在程序中这样读取var configuration new ConfigurationBuilder() .SetBasePath(AppDomain.CurrentDomain.BaseDirectory) .AddJsonFile(appsettings.json, optional: true, reloadOnChange: true) .Build(); var ip configuration[Device:Ip]; var port int.Parse(configuration[Device:Port]);这种方式的优点在于支持层级配置、环境变量覆盖而且reloadOnChange设置为true之后文件被修改会自动重新加载配置非常适合上位机调参。配一个appsettings.json{ Device: { Ip: 192.168.1.100, Port: 502 }, Log: { Level: Info, MaxFileSizeMB: 10 } }对于刚入门的朋友这比手工解析txt配置要可靠得多。Json配置有个容易踩坑的点Json文件保存格式必须正确标准Json不支持注释如果你用带注释的Json配置某些解析器会直接报错。还有文件如果有BOM部分早期解析器读不了。解决办法就是在编辑器里设置UTF-8无BOM保存。3.3 写一份像样的日志文件日志是文件操作的重灾区。很多人写日志就是File.AppendAllText(path, message)刚开始觉得挺好用起来会发现三个问题第一频繁打开关闭文件句柄有性能损耗第二高并发下文件写入互相冲突第三日志文件会无限增长。一个简单的规范做法是用一个static object锁对象public static class LogHelper { private static readonly object _lock new object(); public static void Write(string message) { lock (_lock) { var path Path.Combine(AppDomain.CurrentDomain.BaseDirectory, logs, ${DateTime.Now:yyyyMMdd}.log); Directory.CreateDirectory(Path.GetDirectoryName(path)); using (var writer new StreamWriter(path, true, new UTF8Encoding(false))) { writer.WriteLine(${DateTime.Now:yyyy-MM-dd HH:mm:ss.fff} - {message}); } } } }关键细节是用lock保证多线程写文件不抢占按天生成日志文件避免单个文件无限膨胀每次写入都先Directory.CreateDirectory确保logs目录存在用using自动Flush并释放句柄这段代码已经可以满足很多小型项目了。如果你的日志库要处理每秒几百条写日志的场景再考虑改用后台队列单独写线程的结构或者直接用Serilog/NLog没必要自己重复造轮子。3.4 用FileSystemWatcher监视文件变化有时候我们需要在文件变化时做点什么比如配置文件被改后自动重载、某设备输出文件到达后自动解析数据。FileSystemWatcher就是干这个的。var watcher new FileSystemWatcher(D:\data); watcher.NotifyFilter NotifyFilters.FileName | NotifyFilters.LastWrite; watcher.Filter *.csv; watcher.Changed (s, e) { Console.WriteLine($文件变化{e.FullPath}); }; watcher.EnableRaisingEvents true;这里有个非常容易踩的坑Changed事件可能会触发多次因为写文件的过程往往会多次修改最后写入时间。一般的处理办法是加一个延迟去抖比如记录上一次处理时间间隔小于500ms就忽略或者用一个Timer延迟触发。另一个坑是事件处理函数会在后台线程执行如果里面要更新UI控件必须用Invoke回到UI线程。这和热词里提到的“c# timer 访问控件”问题是同一种套路——跨线程更新UI必须封送。4. 常见问题与排查技巧实录4.1 文件被占用问题IOException怎么破Windows下最经典的报错是“文件正由另一进程使用因此该进程无法访问此文件”。碰到这个错误第一反应是看自己的代码有没有在没释放句柄的情况下反复打开同一个文件比如File.ReadAllLines之后忘了释放或者StreamReader没有用using包住。如果是别的程序占用了文件比如Excel打开了某个文件你的程序去写同样会报这个错。这时候可以检查是谁占用了文件在任务管理器里不好找最实用的工具是Process Explorer可以搜索文件句柄能直接看到是哪个进程的哪个线程占用了文件。实际开发中我自己的经验是尽量让程序对文件敞开门读取时用FileShare.ReadWrite写入时用FileShare.Read或FileShare.ReadWrite。这样别人在读日志的时候你也能继续追加不会因为一小段试读就互相卡死。还有一种文件替换的坑值得单独说如果你想更新一个正在被占用的文件不要直接DeleteCopy因为这期间占用可能再次出现。更稳的做法是用File.Replace或先写临时文件再File.Move(临时文件, 目标文件, true)原子替换。File.Move在.NET Core 3.0之后支持第三个参数overwrite它可以保证替换动作尽量原子化。4.2 日志乱码问题怎么排查乱码是文件操作第二常见的问题。常见的现象是日志文件打开后显示“鎴愬姛”或者“锟斤拷”这基本都是编码不对。“鎴愬姛”其实是“成功”两个字的UTF-8字节按GBK解码的结果。也就是说程序写文件时是UTF-8但打开时用的是GBK。检查顺序确认写入编码是什么是否指定了Encoding确认读取或打开的软件用什么编码比如旧版记事本默认ANSI统一为UTF-8无BOM或带BOM关键是所有环节统一如果涉及到老设备或老系统比如PLC、某些工控设备协议可能只支持ASCII或GBK。这时候读取端必须显式指定编码不能指望自动识别。一个更稳妥的方案是把文本文件另存为UTF-8后再让程序处理或者反过来程序这边在读取时指定正确的编码。下面这张表是编码问题速查算是比较典型的几类症状现象可能原因解决方向日志打开显示“鎴愬姛”UTF-8字节被按GBK解码统一UTF-8编码Excel打开CSV中文乱码CSV无BOM写入时加UTF-8 BOM程序读中文txt乱码读取编码与文件编码不一致显式指定Encoding.GetEncodingLinux下显示乱码文件带BOM且程序不识别写入无BOM UTF-84.3 权限不足与路径过长的处理权限问题是很多桌面程序在客户电脑上出现的无解问题。程序安装在C:\Program Files下时默认没有写权限File.WriteAllText会抛UnauthorizedAccessException。解决方案是绝不把日志、临时文件、用户数据写到程序安装目录而是写到用户目录或系统允许的应用数据目录。var dir Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData); var logPath Path.Combine(dir, MyApp, logs);Windows下有一条更隐蔽的坑是路径长度。传统Windows API支持路径最大260个字符如果你的目录嵌套很深文件路径超过MAX_PATHFile.Exists会返回false但你看着路径明明是存在的。解决办法是尽量缩短目录结构或者启用长路径支持需要系统策略和清单设置。这个坑在客户机器上特别难排查因为开发机上往往目录短不会触发。4.4 一次性写出和增量写出的取舍项目里经常遇到是把整段内容一次写出还是一行一行追加我的判断标准就三条文件大小、写入频率、失败容忍度。配置文件、导出报表这种一次性生成的文件小、频率低用File.WriteAllText/WriteAllLines最省事代码短且不会留下半截文件。如果担心写一半崩溃导致文件损坏可以先写临时文件写完后用File.Move覆盖正式文件这样至少保证正式文件要么是旧的要么是新的不会是乱写的半成品。日志、采集数据这类高频增量数据用StreamWriter的append模式长期打开一个句柄而不是每次File.AppendAllText。因为每次打开-写入-关闭的开销不小高频场景下性能差距肉眼可见。我自己在采集设备数据的时候曾经用每次AppendAllText写一秒十几次调用CPU占用能到百分之十几改成常驻StreamWriter后CPU占用几乎可以忽略。5. 文件操作的安全与进阶细节5.1 日志滚动和清理的简单实现日志无限增长是每个项目最终都会遇到的问题。有个偷懒的办法是每天新建一个日志文件然后定期清理N天前的文件。这样既避免单个文件过大又方便按时间查日志。private static void CleanOldLogs(string logDir, int keepDays) { var cutoff DateTime.Now.AddDays(-keepDays); foreach (var file in Directory.GetFiles(logDir, *.log)) { var info new FileInfo(file); if (info.CreationTime cutoff) { info.Delete(); } } }这个方案虽然简单但一般够用。如果日志量非常大再改造成按大小滚动写入前判断当前文件Length是否超过阈值超过就把当前文件改名为带时间戳的.log.20240401再开一个新文件。注意这种方案要处理好锁和重命名的关系尽量在同一个锁对象里完成判断和切换避免两个线程同时切文件否则会出现日志串文件的问题。5.2 防止反编译与敏感配置处理文件操作还有一个容易被忽视的方向安全和反编译。C#程序默认的MSIL可以轻易被反编译工具还原成接近源码的代码所以热词里有人问“C#怎样防止反编译”。真正有效的方案是引入混淆器比如Obfuscar免费或商业方案混淆类名、方法名、字符串能极大提高逆向门槛。但混淆不是万能的它挡不住决心足够高的逆向者。比反编译更值得关注的是敏感信息别放到明文里。连接字符串、设备密码、密钥不要硬编码在程序里也不要用明文Json存。.NET提供了数据保护APIDPAPI可以用当前用户或当前机器的凭据加密字节数组把密文写入配置文件运行时再解密。这样即使配置文件被拷走没有当前用户上下文也解不开。5.3 与其他文件格式Excel、CSV交互的方式C#读取Excel是个高频需求热词里就有“c#读取excel”“c# cannot读取excel中的数据并打印”。以前很多人用Microsoft.Office.Interop.Excel它在开发机上能用但放到服务器上非常脆弱轻则权限问题重则启动Excel进程泄露。更稳妥的方案是用开源类库比如NPOI、MiniExcel、EPPlus注意许可证。使用这些库读Excel就像读普通表格一样不依赖Office安装。如果数据量不大、列也不复杂最简单的方式其实就是CSV。写出CSV有一个小讲究如果客户会用Excel打开文件头建议加UTF-8 BOM否则中文表头会乱码。写入CSV时字段里有逗号、换行、引号的情况要转义手工拼字符串最容易出问题。建议找一个小库比如CsvHelper来做省心很多。这些“和其他格式交互”的操作本身依然是文件读写只是加了格式解析层。把基础的文件流、编码、异常处理搞明白之后上新库其实很快。写文件这事看起来基础其实项目里翻车大多翻在这种基础环节上。我自己的习惯是每次写完文件操作代码都手动测一次“文件已被占用”“磁盘只读”“路径不存在”这三种情况测完心里就有底了。如果你正在写上位机或者工具类程序建议把日志文件按天分割、编码统一UTF-8、路径用Path.Combine做到这三点大部分文件操作的问题都提前化解了。希望这篇对你有用下一篇继续聊——C#基础11我准备写序列化和反序列化。