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