簡介面向C#/WPF開發(fā)者的CSV文件操作實戰(zhàn)資源覆蓋讀寫、增刪改查以及與Excel、txt的兼容處理。內(nèi)容從CSV基礎(chǔ)結(jié)構(gòu)入手系統(tǒng)講解TextFieldParser、CsvHelper、FileHelpers三類庫的選型與用法并演示在WPF中通過DataGrid綁定展示數(shù)據(jù)、使用文件對話框選擇文件、以異步方式讀寫避免界面卡頓適合需要快速在桌面應(yīng)用集成輕量級數(shù)據(jù)管理的初中級開發(fā)者。壓縮包共46個文件以C#源碼13個cs、XAML界面2個xaml、可執(zhí)行程序及調(diào)試文件為主另含項目配置與說明文檔整體僅330KB結(jié)構(gòu)緊湊便于直接打開工程查閱或復(fù)用。目前已有4325人學(xué)習(xí)下載。資源內(nèi)附完整示例工程與關(guān)鍵代碼如CSVHelper類、主窗口邏輯等可幫助理解CSV解析細節(jié)、異常處理與編碼注意事項尤其適合正在做WPF數(shù)據(jù)導(dǎo)入導(dǎo)出或小型臺賬功能的開發(fā)者。1. CSV 操作第一課C#/WPF 里讀寫與增刪改查先死在編碼和逗號上C#/WPF 項目里做 CSV 的讀寫和增刪改查表面是最不起眼的雜活打開文件、按逗號切一刀、塞進 DataGrid再寫回去。真上手會發(fā)現(xiàn)亂碼、錯列、界面不刷新、最后一行丟失每個坑都能耗掉半天。CSV 沒有數(shù)據(jù)庫的強約束也沒有表格軟件的格式容錯它只是一段帶分隔符的文本解析規(guī)則、編碼規(guī)則、換行規(guī)則全是裸奔狀態(tài)。前陣子一個同事拿Split(,)切開用戶從表格軟件導(dǎo)出的名單結(jié)果地址字段里自帶的逗號讓整列錯位生成的對賬表全廢。這篇文章按「解析器 → 增刪改查 → WPF 綁定 → 避坑 → 驗證」的順序把一套能直接照做的方案講清楚適合要做數(shù)據(jù)導(dǎo)入導(dǎo)出、報表生成、配置遷移功能的 WPF 開發(fā)者也適合剛接觸 C# 想找一套穩(wěn)妥 CSV 操作模板的人。2. 先把 CSV 解析器寫穩(wěn)編碼檢測與 RFC 4180 字段格式2.1 為什么 Split(,) 不是解析 CSV引號里的逗號和換行會讓你翻車CSV 不是「逗號分隔的純文本」它有一套字段格式約束字段可以用雙引號包裹字段內(nèi)如果包含逗號、雙引號或換行必須整體放進引號里字段內(nèi)部的雙引號用兩個連續(xù)雙引號轉(zhuǎn)義?？催@一行數(shù)據(jù)a,b,c,d這一行真正只有 3 個字段a、b,c、d。Split(,)會拆成 4 段因為第二個字段里的逗號被誤判成分隔符。更極端的情況是字段里有換行一個字段橫跨兩行按行讀取再切分必然斷錯。所以一個能用的解析器至少要是一個小狀態(tài)機在引號內(nèi)和引號外兩種狀態(tài)間切換。private static Liststring ParseCsvLine(string line) { var fields new Liststring(); var current new StringBuilder(); bool inQuotes false; for (int i 0; i line.Length; i) { char c line[i]; if (inQuotes) { if (c ) { // 相鄰兩個引號是轉(zhuǎn)義表示一個真正的引號 if (i 1 line.Length line[i 1] ) { current.Append(); i; } else { inQuotes false; } } else { current.Append(c); } } else if (c ) { inQuotes true; } else if (c ,) { fields.Add(current.ToString()); current.Clear(); } else { current.Append(c); } } fields.Add(current.ToString()); return fields; }這段代碼的核心是inQuotes狀態(tài)變量只有在這個變量為false時逗號才參與切分引號出現(xiàn)在字段開頭時進入引號狀態(tài)引號狀態(tài)內(nèi)遇到連續(xù)兩個引號把它當(dāng)作一個普通引號追加進內(nèi)容而不是結(jié)束字段。需要注意我把字符串值原樣保留沒有做Trim()因為某些場景下字段內(nèi)容前后的空格是有意義的清理動作應(yīng)該放到業(yè)務(wù)層統(tǒng)一決定。還要說明一個邊界這個方法按「一行一個字段序列」處理如果 CSV 里真的出現(xiàn)引號內(nèi)換行ReadLine()會把完整字段攔腰切斷這種情況需要改成按字符流讀取并維護跨行狀態(tài)2.3 會再提。2.2 編碼決定文件能不能讀無 BOM 的 UTF-8、GBK 與表格軟件導(dǎo)出習(xí)慣編碼問題是 CSV 操作里最隱蔽的翻車點。StreamReader默認(rèn)按 UTF-8 解碼但中文環(huán)境下很多表格軟件導(dǎo)出的 CSV 是 GBK 編碼記事本另存為 UTF-8 無 BOM 后再用 GBK 解碼就是滿屏亂碼。所以打開文件之前要先探測編碼探測依據(jù)是文件頭部的 BOM以及無 BOM 時的內(nèi)容試探。public static Encoding DetectCsvEncoding(string path) { byte[] head; using (var fs new FileStream(path, FileMode.Open, FileAccess.Read)) { int len (int)Math.Min(8192, fs.Length); head new byte[len]; fs.Read(head, 0, len); } // 有 BOM 時直接確定編碼 if (head.Length 3 head[0] 0xEF head[1] 0xBB head[2] 0xBF) return new UTF8Encoding(true); if (head.Length 2 head[0] 0xFF head[1] 0xFE) return Encoding.Unicode; // 無 BOM先按嚴(yán)格 UTF-8 解碼出現(xiàn)替換字符就回退 GBK string probe new UTF8Encoding(false, true).GetString(head); if (!probe.Contains(\uFFFD)) return new UTF8Encoding(false); try { return Encoding.GetEncoding(GBK); } catch { return Encoding.Default; } }這個方法的順序很關(guān)鍵先看 BOM再看無 BOM 時的解碼結(jié)果。new UTF8Encoding(false, true)的第二個參數(shù)throwOnInvalidBytes為true遇到非法 UTF-8 序列會拋異常所以配合try/catch可以當(dāng)作合法性探測器而\uFFFD是解碼替換字符出現(xiàn)它說明這段字節(jié)不是合法 UTF-8大概率是 GBK。如果你在 .NET Core 或 .NET 5 下運行Encoding.GetEncoding(GBK)之前必須調(diào)用一次Encoding.RegisterProvider(CodePagesEncodingProvider.Instance)否則會直接拋出「不支持的編碼」異常這一步很多人會漏掉。提示不要把編碼探測做成「猜一次用到底」。更穩(wěn)妥的做法是探測后把結(jié)果作為默認(rèn)值呈現(xiàn)給用戶同時在界面上留一個編碼下拉框用戶導(dǎo)入亂碼時可以手動切換。2.3 解析邊界參數(shù)空行、Trim 時機與列數(shù)不齊的容錯解析器的行為要在邊界處定清楚否則生產(chǎn)環(huán)境里什么樣的臟數(shù)據(jù)都能遇到。我常用的約定是空行跳過字段內(nèi)容不主動Trim留給字段映射層處理列數(shù)不齊不直接崩潰而是記錄行號讓調(diào)用方?jīng)Q定是報錯還是補空。下面是一個帶行號的完整讀取方法public class CsvRow { public int LineNo { get; set; } public Liststring Fields { get; set; } new(); } public static ListCsvRow ReadCsv(string path) { Encoding enc DetectCsvEncoding(path); var rows new ListCsvRow(); using var reader new StreamReader(path, enc); string? line; int lineNo 0; while ((line reader.ReadLine()) ! null) { lineNo; if (string.IsNullOrWhiteSpace(line)) continue; var fields ParseCsvLine(line); rows.Add(new CsvRow { LineNo lineNo, Fields fields }); } return rows; }LineNo是排查問題的關(guān)鍵用戶把文件丟給你說「有一行壞了」你能直接告訴他第幾行有問題。列數(shù)不齊的校驗建議放在調(diào)用方做因為解析器并不知道業(yè)務(wù)上應(yīng)該有幾列。比如導(dǎo)入學(xué)生名單時讀取后判斷每行Fields.Count是否等于表頭列數(shù)不相等就收集行號一次性彈給用戶。這里還有一個實際限制需要說清楚上面的ReadCsv用ReadLine()逐行讀意味著它默認(rèn)字段內(nèi)不包含換行符。如果你的業(yè)務(wù)確實會遇到「一個字段里有多行文本」解析器必須改成從字符流層面維護狀態(tài)機讀入換行符時判斷當(dāng)前是否處于引號狀態(tài)這會讓代碼復(fù)雜度上一個臺階通常只在導(dǎo)入多行備注字段時才有必要。3. 把增刪改查落到代碼倉儲設(shè)計、臟數(shù)據(jù)與保存策略3.1 先定存儲模型全量內(nèi)存、臨時庫還是直接改文件動手寫增刪改查之前先決定數(shù)據(jù)在程序里怎么存在。CSV 本身沒有隨機寫能力你要修改一行要么全量重寫文件要么按字節(jié)定位覆蓋——后者非常脆弱字段長度一變就會錯位。所以實際方案選型通常按數(shù)據(jù)量走我一般這樣定數(shù)據(jù)量推薦方案原因1000 行以內(nèi)內(nèi)存ListT 保存時全量重寫簡單可靠幾毫秒完成1000 ~ 1 萬行內(nèi)存ListT 批量延遲保存全量重寫幾十毫秒可接受1 萬 ~ 10 萬行導(dǎo)入臨時數(shù)據(jù)庫如 SQLite查詢修改后導(dǎo)出全量重寫慢且界面卡頓明顯只做導(dǎo)入導(dǎo)出不建存儲模型解析后直接消費增刪改查不是這個場景的核心需求這個決策直接影響后面的代碼寫法。超過 1 萬行還堅持全量讀寫用戶點一次保存就要等一兩秒體驗會直線下降而 10 萬行級別的文件光是解析成對象列表內(nèi)存占用就可能上百兆。以下代碼按「內(nèi)存ListT 統(tǒng)一保存」實現(xiàn)適合絕大多數(shù)桌面工具場景。3.2 CsvRepository 最小實現(xiàn)讀全量、按鍵增刪改、統(tǒng)一保存?zhèn)}儲層把「數(shù)據(jù)操作」和「文件 IO」隔開。核心設(shè)計是啟動時讀入全部數(shù)據(jù)到內(nèi)存增刪改只操作內(nèi)存并打臟標(biāo)記用戶點保存時才全量寫回文件。這樣既避免頻繁 IO也讓界面操作非?？?。public class CsvRepositoryT where T : class { private readonly string _path; private readonly ListT _items; private bool _dirty; public CsvRepository(string path) { _path path; _items LoadFromDisk(); } public IReadOnlyListT GetAll() _items; // keySelector 返回業(yè)務(wù)主鍵字符串存在則替換不存在則新增 public void Upsert(T item, FuncT, string keySelector) { string key keySelector(item); int index _items.FindIndex(x keySelector(x) key); if (index 0) _items[index] item; else _items.Add(item); _dirty true; } public void Delete(FuncT, string keySelector, string key) { int removed _items.RemoveAll(x keySelector(x) key); if (removed 0) _dirty true; } public void Save(FuncT, string serializer) { if (!_dirty) return; string tmp _path .tmp; using (var writer new StreamWriter(tmp, false, new UTF8Encoding(true))) { writer.NewLine \r\n; foreach (var item in _items) writer.WriteLine(serializer(item)); } File.Copy(tmp, _path, true); File.Delete(tmp); _dirty false; } private ListT LoadFromDisk() { var rows CsvReader.ReadCsv(_path); // 這里通過 CsvSerializer.Deserialize 把 CsvRow 映射成 T return rows.Select(r CsvSerializer.DeserializeT(r.Fields)).ToList(); } }所有增刪改操作集中在Upsert和Delete兩個入口好處是調(diào)用方不需要關(guān)心文件什么時候?qū)?、怎么拼字符串。_dirty臟標(biāo)記避免用戶只是打開看了一眼就退出時產(chǎn)生多余寫入。Save里先寫臨時文件再File.Copy覆蓋是為了防止保存中途程序崩潰把原文件寫壞。這里的serializer參數(shù)把序列化方式交給調(diào)用方方便 3.3 的字段映射方案自由插入。3.3 字段映射特性標(biāo)注還是手寫序列化數(shù)據(jù)結(jié)構(gòu)化映射是增刪改查的基礎(chǔ)。固定列數(shù)的場景我推薦用特性標(biāo)注屬性通過反射自動生成列順序這樣新增字段時只需要加一個屬性不用改序列化代碼。[AttributeUsage(AttributeTargets.Property)] public class CsvColumnAttribute : Attribute { public string? Name { get; set; } public int Order { get; set; } } public class Student { [CsvColumn(Name 學(xué)號, Order 1)] public string Id { get; set; } ; [CsvColumn(Name 姓名, Order 2)] public string Name { get; set; } ; [CsvColumn(Name 成績, Order 3)] public decimal Score { get; set; } [CsvColumn(Name 備注, Order 4)] public string Remark { get; set; } ; }序列化和反序列化都基于這個特性數(shù)組且順序統(tǒng)一由Order控制public static string SerializeT(T item) { var props typeof(T).GetProperties() .Where(p p.GetCustomAttributeCsvColumnAttribute() ! null) .OrderBy(p p.GetCustomAttributeCsvColumnAttribute()!.Order); var values new Liststring(); foreach (var prop in props) { string? text prop.GetValue(item)?.ToString() ?? ; if (text.Contains(,) || text.Contains() || text.Contains(\n)) { text \ text.Replace(\, \\) \; } values.Add(text); } return string.Join(,, values); } public static T DeserializeT(Liststring fields) where T : new() { var instance new T(); var props typeof(T).GetProperties() .Where(p p.GetCustomAttributeCsvColumnAttribute() ! null) .OrderBy(p p.GetCustomAttributeCsvColumnAttribute()!.Order); int index 0; foreach (var prop in props) { if (index fields.Count) break; string raw fields[index].Trim(); // Trim 統(tǒng)一放在這里 if (prop.PropertyType typeof(string)) { prop.SetValue(instance, raw); } else if (!string.IsNullOrWhiteSpace(raw)) { object converted Convert.ChangeType(raw, prop.PropertyType); prop.SetValue(instance, converted); } index; } return instance; }序列化時的轉(zhuǎn)義邏輯在Serialize里凡是字段值包含逗號、引號或換行就整體用雙引號包起來內(nèi)部引號雙寫。反序列化時Trim()統(tǒng)一放在轉(zhuǎn)換入口避免解析器里過早清理。Convert.ChangeType對空字符串會拋異常所以數(shù)字和日期類型在空值時要跳過賦值否則一行只填了學(xué)號和姓名就會崩。反射在這個場景里性能完全夠用幾千行數(shù)據(jù)毫秒級完成只有當(dāng)單文件幾十萬行、且對導(dǎo)入速度有硬性要求時才值得改成手寫switch-case逐字段轉(zhuǎn)換。3.4 寫回選擇UTF-8 BOM 與 CRLF 的取舍寫文件時的編碼和換行決定了生成的文件拿到別的軟件里是否還認(rèn)。我固定的組合是UTF-8 帶 BOM CRLF 換行。UTF-8 帶 BOM 能讓表格軟件直接識別編碼不會打開亂碼CRLF 是為了兼容舊編輯器以及避免某些軟件把 LF 換行的文件識別成單行。static void WriteAllLines(string path, IEnumerablestring lines) { string tmp path .tmp; using (var writer new StreamWriter(tmp, false, new UTF8Encoding(true))) { writer.NewLine \r\n; // 顯式指定不要依賴 Environment.NewLine foreach (var line in lines) writer.WriteLine(line); } File.Copy(tmp, path, true); File.Delete(tmp); }writer.NewLine單獨設(shè)置而不是手動拼\r\n是因為WriteLine會自動追加換行手動拼會導(dǎo)致部分行雙換行、部分行沒換行。注意UTF8Encoding(true)的布爾參數(shù)是寫入 BOMfalse則無 BOM這一步經(jīng)常有人寫錯成new UTF8Encoding()結(jié)果生成的文件又是無 BOM UTF-8。如果你的工具只給自己程序用也可以堅持無 BOM 的 UTF-8 保持純凈但凡是導(dǎo)出給非技術(shù)人員使用務(wù)必帶 BOM。4. 從數(shù)據(jù)到界面DataGrid 綁定與增刪改查的聯(lián)動方式4.1 ObservableCollection 與 INotifyPropertyChanged界面刷新的底層前提WPF 里把ListT直接綁到 DataGrid運行起來會發(fā)現(xiàn)新增行不出現(xiàn)、修改值后界面不更新。原因是 WPF 的綁定系統(tǒng)需要集合通知和屬性通知ListT兩者都沒有。集合層面用ObservableCollectionT行對象層面要實現(xiàn)INotifyPropertyChanged缺一個界面就「看起來沒反應(yīng)」。public class StudentRow : INotifyPropertyChanged { private string _name ; public string Id { get; set; } ; public string Name { get _name; set { if (_name value) return; _name value; PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(Name))); } } public decimal Score { get; set; } public event PropertyChangedEventHandler? PropertyChanged; }這里Name屬性的 setter 通過PropertyChanged讓界面在值變化時立即刷新Id和Score如果不需要業(yè)務(wù)邏輯可以直接自動屬性。ViewModel 里用ObservableCollectionStudentRow保存數(shù)據(jù)增刪時只操作這個集合DataGrid 會自動響應(yīng)。如果你用 MVVM 框架PropertyChanged的封裝可以交給基類核心仍是這兩層通知缺一不可。4.2 DataGrid 列定義只讀主鍵、格式化列與編輯配置DataGrid 默認(rèn)會自動生成列但自動生成的列無法控制順序、寬度和是否只讀。固定列布局的寫法是關(guān)閉AutoGenerateColumns逐列聲明。DataGrid ItemsSource{Binding Students} AutoGenerateColumnsFalse SelectionModeSingle HeadersVisibilityColumn DataGrid.Columns DataGridTextColumn Header學(xué)號 Binding{Binding Id} IsReadOnlyTrue Width100/ DataGridTextColumn Header姓名 Binding{Binding Name} Width120/ DataGridTextColumn Header成績 Binding{Binding Score, StringFormatF2} Width100/ /DataGrid.Columns /DataGridIsReadOnlyTrue用在主鍵列防止用戶把學(xué)號改成重復(fù)值導(dǎo)致Upsert邏輯錯亂StringFormatF2讓成績列顯示兩位小數(shù)但要注意它只是顯示格式化編輯時輸入原始字符串取值時仍按Score屬性類型轉(zhuǎn)換。DataGrid 的提交時機默認(rèn)是單元格失焦所以用戶在編輯狀態(tài)下直接點保存按鈕當(dāng)前單元格的值可能還沒寫回綁定屬性這個問題專門在 5.3 給解決方案。4.3 保存只做一次批量校驗、統(tǒng)一寫盤而不是每次編輯都 IO不要在CellEditEnding事件里每改一個單元格就寫一次文件。CSV 沒有事務(wù)寫一半斷電整個文件就廢了。我一般把保存收斂到一個按鈕用戶完成所有增刪改后點保存先做業(yè)務(wù)校驗再統(tǒng)一走倉儲的Save()。private void SaveButton_Click(object sender, RoutedEventArgs e) { // 強制 DataGrid 把正在編輯的單元格提交到綁定屬性 dataGrid.CommitEdit(DataGridEditingUnit.Row, true); var badRows Students .Where(s string.IsNullOrWhiteSpace(s.Id) || s.Score 0) .ToList(); if (badRows.Count 0) { MessageBox.Show($有 {badRows.Count} 行數(shù)據(jù)未通過校驗學(xué)號不能為空成績不能為負(fù)數(shù)。, 校驗失敗); return; } _repository.Save(row CsvSerializer.Serialize(row)); MessageBox.Show(保存完成); }CommitEdit(DataGridEditingUnit.Row, true)的第二個參數(shù)是editableCollectionView讓它把當(dāng)前編輯行的值寫回行對象這一行是避免「最后一行丟失」的關(guān)鍵。校驗放在寫文件之前攢到保存時一次彈給用戶而不是改錯一個單元格就打斷一次。批量保存另一個好處是可以在Save()里做臨時文件替換配合 .bak 備份把操作系統(tǒng)層面的崩潰風(fēng)險降到最低。5. 避坑清單CSV 操作里最容易翻車的現(xiàn)場5.1 編碼與文件格式現(xiàn)場坑一導(dǎo)出文件用表格軟件打開全是亂碼?，F(xiàn)象是程序里讀出來正常用表格軟件打開中文全變成「錕斤拷」一類字符或者一堆問號。原因是寫文件時用了無 BOM 的 UTF-8而表格軟件在 Windows 中文環(huán)境下默認(rèn)按 GBK 解析。解決方法是寫回時統(tǒng)一用new UTF8Encoding(true)寫入 BOM并對導(dǎo)入操作保留編碼切換選項。只用Encoding.UTF8或StreamWriter(path)默認(rèn)編碼都不夠穩(wěn)?？佣４娴揭话氤绦虮罎⒒驍嚯娫?CSV 文件損壞打不開。原因是直接打開原文件寫入寫入點到一半文件截斷。解決方法是先寫.tmp臨時文件完整寫完后用File.Copy(tmp, path, true)覆蓋再刪臨時文件更穩(wěn)妥的做法是覆蓋前先把原文件復(fù)制一份.bak。臨時文件方案是最小必要防護生產(chǎn)級場景建議兩者疊加。5.2 數(shù)據(jù)解析與類型轉(zhuǎn)換現(xiàn)場坑三導(dǎo)入時明明按逗號Split(,)了一加載列就錯位?，F(xiàn)象是某一行字段數(shù)比其他行多數(shù)據(jù)跑到錯誤的列里。原因是字段內(nèi)容里本身包含逗號或英文雙引號簡單切分把字段拆斷了。解決方法是使用帶引號狀態(tài)機的解析器見 2.1并且序列化時對含逗號、引號、換行的字段做轉(zhuǎn)義包裹。這個坑在地址、備注、描述類字段占比高的文件里幾乎是必現(xiàn)的?？铀膶?dǎo)入時數(shù)字列報InvalidCastException或者成績變成 0?，F(xiàn)象是某行的成績列有值但轉(zhuǎn)換失敗程序中斷另一種是空字符串被Convert.ChangeType轉(zhuǎn)換時拋異常。原因是用戶從表格軟件復(fù)制數(shù)據(jù)時數(shù)字列可能帶了不可見空格、千分位符號或全角數(shù)字空字符串也沒有被處理。解決方法是在Deserialize的轉(zhuǎn)換入口統(tǒng)一Trim()空字符串跳過賦值并捕獲轉(zhuǎn)換異常后記錄行號繼續(xù)處理而不是整個文件失敗。5.3 界面綁定與提交時機現(xiàn)場坑五DataGrid 里新增了一行點保存后最后一行沒進文件或者修改了某個單元格界面上顯示的仍是舊值。原因是新增行還處于編輯狀態(tài)數(shù)據(jù)沒提交到綁定屬性修改值沒刷新則可能是行模型沒實現(xiàn)INotifyPropertyChanged。解決方法是保存前先調(diào)用dataGrid.CommitEdit(DataGridEditingUnit.Row, true)強制提交當(dāng)前編輯同時確保行模型的標(biāo)準(zhǔn)屬性都走屬性通知。還要注意ObservableCollection的集合級通知和行屬性通知是兩個獨立機制集合沒通知看ObservableCollection行內(nèi)值沒刷新看INotifyPropertyChanged排查時按這個順序查。6. 驗證與進階用測試釘死解析器再處理大文件分塊6.1 用單元測試把解析器鎖死CSV 解析器是純函數(shù)非常適合用數(shù)據(jù)驅(qū)動測試固定行為。改代碼最怕的就是「修了一個邊界壞了一個舊場景」單元測試就是后悔藥。我至少會覆蓋含引號內(nèi)逗號、雙引號轉(zhuǎn)義、空字段、行尾不閉合引號這四類用例。[Theory] [InlineData(a,b,c, 3)] [InlineData(a,\b,c\,d, 3)] [InlineData(\a\\b\,c, 2)] [InlineData(,a,, 3)] public void ParseCsvLine_FieldCountIsCorrect(string line, int expected) { var fields CsvParser.ParseCsvLine(line); Assert.Equal(expected, fields.Count); } [Fact] public void ParseCsvLine_QuotedCommaIsOneField() { var fields CsvParser.ParseCsvLine(a,\b,c\,d); Assert.Equal(b,c, fields[1]); }第一個用例a,\b,c\,d斷言引號內(nèi)逗號不被切分第二個用例\a\\b\,c斷言雙引號轉(zhuǎn)義后ab是完整字段空字段用例保證,,中間的空串被保留。這類測試跑一遍只要幾毫秒但能攔住大部分回歸。6.2 迭代器讀大文件不把整個文件裝進內(nèi)存超過幾萬行的文件一次性ReadAllLines再解析會占幾百兆內(nèi)存。改成迭代器逐行產(chǎn)出讓調(diào)用方按需消費public static IEnumerableCsvRow ReadRowsLazy(string path) { Encoding enc DetectCsvEncoding(path); using var reader new StreamReader(path, enc); string? line; int lineNo 0; while ((line reader.ReadLine()) ! null) { lineNo; if (string.IsNullOrWhiteSpace(line)) continue; yield return new CsvRow { LineNo lineNo, Fields ParseCsvLine(line) }; } }yield return讓方法變成惰性求值調(diào)用方foreach到哪一行才解析哪一行。配合 WPF 的async/await分批讀取界面不會因為解析大文件卡死。要注意這個方案同樣受限于「字段內(nèi)沒有換行」而且惰性迭代期間文件句柄一直打開不要在這個迭代器存活期間去寫同一個文件。6.3 寫盤前留 .bak一個小習(xí)慣擋住一次事故我自己的習(xí)慣是每次寫回 CSV 前把原文件復(fù)制成.bak再覆蓋。某次幫客戶做一個數(shù)據(jù)清洗工具保存時正好遇到磁盤空間不足臨時文件寫入失敗原本幾千行的數(shù)據(jù)文件只剩一半。從那以后所有涉及覆蓋寫文件的代碼一律先做.bak備份代碼就一行File.Copy(_path, _path .bak, true);備份文件可以定期清理也可以保留最近一次成本極低但用戶手里的數(shù)據(jù)從此多一道保險。CSV 操作這件事本身不難難的是把格式邊界、編碼邊界和保存時機都想清楚解析器加單元測試、寫回走臨時文件加備份、界面保存前強制提交這幾條做到位大部分坑都在上線前被攔住了。希望幫到你。本文還有配套的精品資源點擊獲取