現(xiàn)Excel/CSV數(shù)據(jù)鍵值比對與差異核對實(shí)戰(zhàn))
簡介在日常Java開發(fā)中經(jīng)常需要比對兩份表格類數(shù)據(jù)文件可能是Excel工作簿也可能是CSV文本。核心思路通常是指定若干關(guān)鍵列作為鍵值來進(jìn)行行匹配先找到兩個(gè)文件中的對應(yīng)行再比較指定列的值是否變化從而發(fā)現(xiàn)修改、新增或缺失的數(shù)據(jù)。這份資源正是圍繞該需求整理的示例代碼完整演示了如何使用Apache POI讀取Excel、OpenCSV解析CSV、以鍵值組合構(gòu)造哈希表存儲(chǔ)行數(shù)據(jù)以及在遍歷過程中輸出各類差異信息的處理過程思路清晰適合有基礎(chǔ)Java語法、需要批量核對表格數(shù)據(jù)的開發(fā)者參考。壓縮包共24個(gè)文件包含9個(gè)Java源碼、9個(gè)編譯后的class文件、3個(gè)依賴jar包及工程配置文件整體僅666KB下載后可直接導(dǎo)入IDE查看或按需修改。已有2541人學(xué)習(xí)下載。資源小巧但結(jié)構(gòu)完整既提供了演示主類調(diào)用骨架也附帶了lib目錄下的依賴庫省去手動(dòng)查找外部包的麻煩對于學(xué)習(xí)POI/OpenCSV基礎(chǔ)用法或?qū)崿F(xiàn)輕量級表格比對工具都具有不錯(cuò)的實(shí)用價(jià)值。1. 鍵值比對讓兩張表的差異核對從人工變成代碼現(xiàn)實(shí)中經(jīng)常遇到這類場景某個(gè)系統(tǒng)導(dǎo)出一份 Excel 報(bào)價(jià)單另一個(gè)系統(tǒng)導(dǎo)出一份 CSV 清單業(yè)務(wù)要核對同一批數(shù)據(jù)在兩邊有哪些值不一樣或者上個(gè)月的全量數(shù)據(jù)文件跟這個(gè)月的做差異檢查。逐行翻表是純體力活行一多就眼花行順序稍微變一變就很容易看錯(cuò)。這個(gè)標(biāo)題要解決的就是把某幾列拼成唯一鍵把兩邊的行按鍵對齊再只對指定列做值比較輸出哪些行是新增、哪些是刪除、哪些值有變化。適合天天和數(shù)據(jù)文件打交道的開發(fā)、運(yùn)維和數(shù)據(jù)專員核心收益是讓核對變成一條命令能跑完的事。2. 先定鍵再選結(jié)構(gòu)比對方案的四項(xiàng)設(shè)計(jì)決策2.1 為什么選鍵值而不是逐行比對先說透一個(gè)道理兩張表行順序一致的情況在真實(shí)業(yè)務(wù)里非常少見。某個(gè)系統(tǒng)導(dǎo)出的清單行序可能按創(chuàng)建時(shí)間排另一邊導(dǎo)出可能按部門分組如果中間還經(jīng)過一次 Excel 手工調(diào)整行序就更不可信了。逐行比對在這種場景下完全不靠譜第一行和第一行根本不是同一個(gè)業(yè)務(wù)對象。所以必須找一個(gè)不依賴行序的對齊方式這就是鍵值比對的核心動(dòng)機(jī)把業(yè)務(wù)上的唯一標(biāo)識(shí)當(dāng)成行的地址再按地址把兩邊的行拉齊。這個(gè)思路跟數(shù)據(jù)庫里的 FULL OUTER JOIN 幾乎一模一樣表 A 按主鍵、表 B 按主鍵一次關(guān)聯(lián)就能區(qū)分出三種情況只在 A 里、只在 B 里、兩邊都有但某些字段不一致。只不過這里我們不想為一次性檢查建兩張表直接在內(nèi)存里用 Map 手工實(shí)現(xiàn)。選鍵有三條原則建議寫代碼前先確認(rèn)。第一是唯一性鍵如果在表里重復(fù)后讀進(jìn)來的行會(huì)覆蓋先讀進(jìn)來的行部分?jǐn)?shù)據(jù)被靜默丟棄。第二是穩(wěn)定性兩邊的拼接規(guī)則必須完全一致比如鍵是單號(hào)加行號(hào)那就兩邊都拼這兩列不能一邊拼三列一邊拼兩列。第三是注意空值鍵列里某格為空時(shí)拼接出來的鍵可能變成空字符串多個(gè)空行會(huì)撞到同一個(gè)鍵上。這三條如果業(yè)務(wù)上滿足不了正確做法不是硬寫代碼而是先去跟上游確認(rèn)數(shù)據(jù)含義。鍵值比對該不該做、能不能做答案往往不在代碼里而在對業(yè)務(wù)主鍵的理解有多深。我在模擬項(xiàng)目X里接過一個(gè)需求兩側(cè)導(dǎo)出的訂單編號(hào)一邊有前綴一遍沒前綴花了半小時(shí)想清楚鍵的歸一化問題比直接開寫快得多。2.2 數(shù)據(jù)結(jié)構(gòu)選型String數(shù)組還是列名Map讀進(jìn)來的每一行怎么存我一般看列數(shù)多少、列順序是否固定來決定。最穩(wěn)妥的起步方案是String[]存單元格值外加一個(gè)ListString存表頭。列順序兩邊一致時(shí)直接按下標(biāo)取單元格讀寫都最直觀讀取器不需要引入復(fù)雜模型比對器只需要把列下標(biāo)傳來傳去。缺點(diǎn)是列一多下標(biāo)含義要靠表頭來回查代碼可讀性下降。另一種方案是每行存成MapString, String列名做 key。優(yōu)點(diǎn)是列順序不一致甚至列數(shù)不同都不怕比對的列名直接當(dāng)作鍵來取缺點(diǎn)是每個(gè)單元格都要構(gòu)造一個(gè) Map.Entry內(nèi)存開銷比數(shù)組大不少幾萬行時(shí)尚可接受幾十萬行就明顯肉疼。我在一次數(shù)據(jù)核對中對比過兩種寫法同等數(shù)據(jù)量下后者的內(nèi)存占用大概是前者的三倍。判斷項(xiàng)String[] List表頭MapString, String內(nèi)存占用低高約 3 倍列順序不一致需要列名轉(zhuǎn)下標(biāo)天然支持讀取代碼量少稍多比對代碼按下標(biāo)直觀按列名語義清晰適用行數(shù)五萬行以上更友好幾萬行內(nèi)很舒服我的個(gè)人傾向是列數(shù)在 20 列以內(nèi)、兩邊列順序一致直接用數(shù)組列順序亂、列數(shù)十個(gè)以上寧可用 Map。如果你只打算寫一個(gè)一次性的核對腳本數(shù)組方案夠用且快改動(dòng)成本也最低。2.3 鍵值拼接策略分隔符、空值和重復(fù)鍵鍵值的生成是整個(gè)程序的地基地基錯(cuò)了后面全盤錯(cuò)。單列鍵簡單直接取該列單元格值多列鍵就需要一個(gè)拼接方法。常見做法是用分隔符把多列值串起來例如orderNo | lineNo。這個(gè)分隔符有個(gè)隱蔽的坑如果業(yè)務(wù)數(shù)據(jù)本身含有這個(gè)字符兩個(gè)不同組合可能拼出同一個(gè)鍵。比如訂單號(hào)AB|C和行號(hào)1拼出來是AB|C|1訂單號(hào)AB和行號(hào)C|1拼出來也是AB|C|1。規(guī)避辦法有兩種一是選一個(gè)數(shù)據(jù)里幾乎不可能出現(xiàn)的字符比如\u0001二是拼完后再加一個(gè)長度前綴比如3:AB|1:C|1這種寫法能徹底杜絕碰撞。還有人圖省事用Objects.hash(code, lineNo)生成整數(shù)鍵內(nèi)存省一點(diǎn)運(yùn)行也快。但哈希碰撞雖然概率低撞上一次足夠你懷疑人生。我的建議是能用字符串拼鍵就別用哈希除非你明確知道兩個(gè)鍵列允許存在重復(fù)且想用哈希把重復(fù)行聚到一起做統(tǒng)計(jì)那就另說。2.4 保持輸出順序穩(wěn)定的理由構(gòu)建映射表時(shí)用HashMap還是LinkedHashMap會(huì)影響差異報(bào)告里的行順序。HashMap的遍歷順序由哈希桶決定看著像隨機(jī)順序LinkedHashMap按插入順序遍歷先讀到的行先出現(xiàn)在報(bào)告里。這個(gè)細(xì)節(jié)平時(shí)不起眼真到了排查的時(shí)候差別很大。差異報(bào)告輸出順序如果和主文件行順序一一對應(yīng)你就能順著原始行一路查下來如果是亂序查一行要找半天。所以我在所有構(gòu)建映射的地方統(tǒng)一用LinkedHashMap代價(jià)幾乎為零收益是報(bào)告可直接和原文件對照。還有一個(gè)容易被忽略的決策主文件選哪一邊。我的做法是把增量基準(zhǔn)作為主表也就是舊表新表里多出來的行算新增舊表里消失的行算刪除。如果業(yè)務(wù)定義反過來只需要在調(diào)用時(shí)調(diào)換兩個(gè)參數(shù)輸出報(bào)告里新增刪除的語義就互換了程序內(nèi)部不必為這個(gè)邏輯做分支。提示如果你用 Java 9 以上的Map.of()構(gòu)造小常量集合要注意它們是不可變且不允許 null 鍵值。在鍵值拼接的單元測試?yán)镞@個(gè)點(diǎn)很容易被忽略。3. 最小可運(yùn)行實(shí)現(xiàn)讀取、對齊、比對三步走3.1 統(tǒng)一讀取入口CSV 和 Excel 各寫一個(gè)方法先明確一個(gè)前提我不會(huì)用同一個(gè)庫去解析 CSV 和 Excel它們的格式完全不同。常見做法是各寫一個(gè)讀取方法返回統(tǒng)一的數(shù)據(jù)結(jié)構(gòu)MapString, String[]調(diào)用方只關(guān)心我拿到了鍵值到整行單元格的映射不關(guān)心背后是哪種文件。CSV 我一般直接手寫解析比引入 OpenCSV 更輕也更容易控制細(xì)節(jié)。讀取時(shí)有三個(gè)注意點(diǎn)一是編碼必須在打開流時(shí)指定二是每行調(diào)用split(,, -1)必須帶第二個(gè)參數(shù) -1三是表頭行要單獨(dú)跳過。第三個(gè)問題雖然看起來簡單但表頭行也可能是空行只判斷行號(hào) 0 就會(huì)漏掉真正的內(nèi)容行。public MapString, String[] readCsv(Path file, Charset charset, ListInteger keyCols) throws IOException { MapString, String[] data new LinkedHashMap(); try (BufferedReader reader Files.newBufferedReader(file, charset)) { String line; boolean hasHeader false; while ((line reader.readLine()) ! null) { if (line.isBlank()) { continue; } if (!hasHeader) { hasHeader true; continue; } String[] cells line.split(,, -1); data.put(buildKey(cells, keyCols), cells); } } return data; }這段代碼里hasHeader用布爾值跳過第一行空行直接跳過split(,, -1)保留末尾空字段LinkedHashMap保證輸出順序。如果遇到中文亂碼把charset換成Charset.forName(GBK)大多能解決不過編碼問題不是這一句就能完全說清的后面避坑章會(huì)專門展開。Excel 的讀取我使用 Apache POI 的WorkbookFactory.create方法它自動(dòng)識(shí)別xls和xlsx省去自己判斷擴(kuò)展名。POI 讀取有幾個(gè)特點(diǎn)空單元格row.getCell(i)返回 null數(shù)字單元格默認(rèn)按 double 返回日期單元格在 POI 底層也是數(shù)字。所以讀取時(shí)必須做單元格類型轉(zhuǎn)換不能直接toString。public MapString, String[] readExcel(Path file, ListInteger keyCols) throws IOException { MapString, String[] data new LinkedHashMap(); try (Workbook workbook WorkbookFactory.create(file.toFile())) { Sheet sheet workbook.getSheetAt(0); boolean hasHeader false; for (Row row : sheet) { if (!hasHeader) { hasHeader true; continue; } int lastCell row.getLastCellNum(); String[] cells new String[lastCell]; for (int i 0; i lastCell; i) { cells[i] getCellValueAsString(row.getCell(i)); } data.put(buildKey(cells, keyCols), cells); } } return data; }需要留意row.getLastCellNum()它返回的是最后一個(gè)有內(nèi)容的列序號(hào)加一不是列數(shù)。某些行如果右半邊完全為空這個(gè)值比表頭列數(shù)小得到的String[]長度就不齊后面按下標(biāo)比對會(huì)數(shù)組越界。我的處理是在讀取表頭后先記錄表頭列數(shù)所有數(shù)據(jù)行統(tǒng)一按表頭列數(shù)創(chuàng)建數(shù)組長度永遠(yuǎn)一致。上面這段代碼為了保持簡短沒有寫出這個(gè)細(xì)節(jié)實(shí)際使用記得改掉。3.2 單元格值轉(zhuǎn)字符串?dāng)?shù)字、日期與空值的統(tǒng)一口徑POI 的Cell.getCellType()返回值類型有字符串、數(shù)字、布爾、公式、空等多種一一轉(zhuǎn)成字符串并不復(fù)雜麻煩的是格式細(xì)節(jié)。下面這個(gè)方法就是統(tǒng)一口徑的關(guān)鍵private static String getCellValueAsString(Cell cell) { if (cell null) { return ; } switch (cell.getCellType()) { case STRING: return cell.getStringCellValue().trim(); case NUMERIC: if (DateUtil.isCellDateFormatted(cell)) { return new SimpleDateFormat(yyyy-MM-dd).format(cell.getDateCellValue()); } double num cell.getNumericCellValue(); if (num Math.floor(num) !Double.isInfinite(num)) { return String.valueOf((long) num); } return String.valueOf(num); case BOOLEAN: return String.valueOf(cell.getBooleanCellValue()); case FORMULA: CellType cachedType cell.getCachedFormulaResultType(); if (cachedType CellType.NUMERIC) { return String.valueOf(cell.getNumericCellValue()); } if (cachedType CellType.STRING) { return cell.getStringCellValue(); } return ; default: return ; } }這個(gè)方法解決了兩個(gè)經(jīng)典翻車現(xiàn)場一是數(shù)值單元格存的是 100POI 卻返回 100.0直接轉(zhuǎn)字符串會(huì)讓兩邊對不上二是日期單元格不處理就是一串 45000 左右的浮點(diǎn)數(shù)。DateUtil.isCellDateFormatted判斷日期格式后再格式化比對的日期值就統(tǒng)一了。注意格式化粒度是天級別如果兩邊都是帶時(shí)間戳的單元格只差幾分鐘都會(huì)判為不同此時(shí)請把yyyy-MM-dd換成yyyy-MM-dd HH:mm:ss。公式分支我直接讀取緩存結(jié)果類型避免拿到VLOOKUP(...)這種公式文本和另一邊的300去比對。POI 解析文件時(shí)默認(rèn)會(huì)緩存公式結(jié)果但這里要注意如果文件里的公式依賴外部工作簿或 POI 無法計(jì)算緩存結(jié)果可能拿不到走到默認(rèn)分支返回空串比對的準(zhǔn)確性就會(huì)下降。對一次性核對來說遇到這類文件建議先在上游把公式轉(zhuǎn)成靜態(tài)值再導(dǎo)出。數(shù)字格式化的口徑也要統(tǒng)一考慮。Excel 單元格顯示為100.00時(shí)getNumericCellValue()返回的仍是 double我上面的寫法會(huì)把它轉(zhuǎn)成100如果 CSV 那邊存的是100.00兩邊數(shù)值一樣但字符串對不上。此時(shí)不要在讀取代碼里到處打補(bǔ)丁而是在normalize方法里集中做數(shù)字格式歸一化比如用BigDecimal比較數(shù)值大小或者統(tǒng)一保留兩位小數(shù)。3.3 比對邏輯新增、刪除、修改三路遍歷讀完文件、構(gòu)建好兩邊映射之后剩下的就是遍歷。我習(xí)慣分成三路先遍歷舊表鍵在新表中不存在就是刪除鍵存在就比較指定列的值有變化就是修改最后遍歷新表鍵在舊表中不存在就是新增。public CompareReport compare(MapString, String[] oldData, MapString, String[] newData, ListInteger valueCols) { CompareReport report new CompareReport(); for (Map.EntryString, String[] entry : oldData.entrySet()) { String key entry.getKey(); String[] oldRow entry.getValue(); String[] newRow newData.get(key); if (newRow null) { report.addDeleted(key, oldRow); continue; } ListString diffs new ArrayList(); for (int col : valueCols) { if (!Objects.equals(normalize(oldRow[col]), normalize(newRow[col]))) { diffs.add(col : normalize(oldRow[col]) - normalize(newRow[col])); } } if (!diffs.isEmpty()) { report.addModified(key, oldRow, newRow, diffs); } } for (Map.EntryString, String[] entry : newData.entrySet()) { if (!oldData.containsKey(entry.getKey())) { report.addAdded(entry.getKey(), entry.getValue()); } } return report; } private static String normalize(String value) { if (value null) { return ; } return value.trim(); }兩個(gè)參數(shù)值得在調(diào)用前想清楚valueCols是要比對的列下標(biāo)列表比如[3, 4, 5]如果希望所有非鍵列都比可以在 main 方法里從表頭長度生成一個(gè)連續(xù)下標(biāo)列表。normalize這里只做了空轉(zhuǎn)空串和去首尾空格實(shí)際業(yè)務(wù)里可能還要處理全角空格、大小寫、數(shù)字格式化這些都要依據(jù)業(yè)務(wù)自己在 normalize 里補(bǔ)。正?;@一步直接影響差異數(shù)量的真實(shí)性多花五分鐘調(diào)它比調(diào)任何其他環(huán)節(jié)都值。4. 輸出差異報(bào)告讓結(jié)果直接可讀4.1 差異數(shù)據(jù)模型新增、刪除、修改三類存儲(chǔ)比對完的結(jié)果不能只放一個(gè)總共有多少不同的計(jì)數(shù)后續(xù)要么打印到控制臺(tái)、要么寫文件、要么接自動(dòng)化測試斷言所以先定義一個(gè)可復(fù)用的模型。public class CompareReport { private final ListRowDiff added new ArrayList(); private final ListRowDiff deleted new ArrayList(); private final ListRowDiff modified new ArrayList(); public static class RowDiff { final String key; final String[] oldRow; final String[] newRow; final ListString fieldsChanged; RowDiff(String key, String[] oldRow, String[] newRow, ListString fieldsChanged) { this.key key; this.oldRow oldRow; this.newRow newRow; this.fieldsChanged fieldsChanged; } } public void addAdded(String key, String[] row) { added.add(new RowDiff(key, null, row, List.of())); } public void addDeleted(String key, String[] row) { deleted.add(new RowDiff(key, row, null, List.of())); } public void addModified(String key, String[] oldRow, String[] newRow, ListString fieldsChanged) { modified.add(new RowDiff(key, oldRow, newRow, fieldsChanged)); } public boolean hasDiff() { return !added.isEmpty() || !deleted.isEmpty() || !modified.isEmpty(); } // getter 按需補(bǔ)齊 }設(shè)計(jì)上有個(gè)細(xì)節(jié)容易被忽略fieldsChanged存的是列下標(biāo)加舊值加新值的字符串但oldRow和newRow也會(huì)完整保留。這樣做是為了輸出時(shí)可以整行打印也可以只打印變化字段兩種格式都覆蓋到。如果你只把變化字段拼成一句描述后面想換個(gè)輸出格式又得重新比對一遍等于寫死了一條路。模型類還應(yīng)該提供一個(gè)hasDiff()方法讓調(diào)用方一行判斷有沒有差異省得每次檢查三個(gè)列表是否為空。這個(gè)判斷在自動(dòng)化測試?yán)锓磸?fù)用到比如 CI 里跑完比對后直接斷言report.hasDiff() false干凈利落。提示List.of()返回的是不可變列表后續(xù)如果要在fieldsChanged上做動(dòng)態(tài)過濾建議在構(gòu)造函數(shù)里復(fù)制成new ArrayList(fieldsChanged)避免不可變集合上拋異常。4.2 控制臺(tái)輸出與文件輸出雙通道輸出通道我分兩種差異量小走控制臺(tái)差異量大走文件。控制臺(tái)輸出的目標(biāo)是掃一眼知道問題多大所以先打一個(gè)匯總統(tǒng)計(jì)再逐條打印明細(xì)。修改類應(yīng)該單獨(dú)把鍵、舊值、新值按塊打印方便肉眼對比新增和刪除直接整行打出來就行。public void printToConsole(CompareReport report, ListString headers) { System.out.printf(新增 %d 行刪除 %d 行修改 %d 行%n, report.getAdded().size(), report.getDeleted().size(), report.getModified().size()); for (CompareReport.RowDiff diff : report.getDeleted()) { System.out.println([刪除] 鍵 diff.key 數(shù)據(jù) Arrays.toString(diff.oldRow)); } for (CompareReport.RowDiff diff : report.getAdded()) { System.out.println([新增] 鍵 diff.key 數(shù)據(jù) Arrays.toString(diff.newRow)); } for (CompareReport.RowDiff diff : report.getModified()) { System.out.println([修改] 鍵 diff.key); for (String field : diff.fieldsChanged) { System.out.println( resolveColName(headers, field)); } } }當(dāng)差異量到幾千行時(shí)控制臺(tái)滾動(dòng)就不太適合了這時(shí)另一條通道是落 CSV 文件。落文件時(shí)把修改行展開成一行一條鍵、狀態(tài)、列名、舊值、新值。寫文件時(shí)記得每條記錄結(jié)束后寫\r\n而不是\n否則用 Windows 版 Excel 打開會(huì)看到所有內(nèi)容擠在同一行。public void writeToCsv(CompareReport report, ListString headers, Path output) throws IOException { try (BufferedWriter writer Files.newBufferedWriter(output, StandardCharsets.UTF_8)) { writer.write(鍵,狀態(tài),列名,舊值,新值\r\n); for (CompareReport.RowDiff diff : report.getAdded()) { writer.write(escapeCsv(diff.key) ,新增,,,\r\n); } for (CompareReport.RowDiff diff : report.getDeleted()) { writer.write(escapeCsv(diff.key) ,刪除,,,\r\n); } for (CompareReport.RowDiff diff : report.getModified()) { for (String field : diff.fieldsChanged) { String[] parts splitField(field); writer.write(escapeCsv(diff.key) ,修改, escapeCsv(parts[0]) , escapeCsv(parts[1]) , escapeCsv(parts[2]) \r\n); } } } }這里splitField需要從3:100 - 200這樣的文本里拆出列名、舊值、新值配合escapeCsv對值里的逗號(hào)和雙引號(hào)做轉(zhuǎn)義雙引號(hào)變成兩個(gè)雙引號(hào)整體再用雙引號(hào)包起來這是最簡且通用的 CSV 轉(zhuǎn)義規(guī)則。不加轉(zhuǎn)義的話地址、備注這類字段里一個(gè)逗號(hào)就能把整列撐錯(cuò)位。什么時(shí)候走文件輸出我會(huì)在 main 方法里加一個(gè)--output參數(shù)傳了它就寫文件不傳就打印控制臺(tái)。這樣同一個(gè) jar 包既能用于人工核對也能在定時(shí)任務(wù)里把報(bào)告落盤。這個(gè)參數(shù)設(shè)計(jì)改動(dòng)不大但讓工具的使用場景寬了一倍。4.3 把列下標(biāo)翻譯成列名報(bào)告才給業(yè)務(wù)看得懂到現(xiàn)在為止代碼里一直用列3列4表示變化字段開發(fā)時(shí)沒問題把報(bào)告交給業(yè)務(wù)看就說不過去了。翻譯很簡單讀文件時(shí)把表頭保存到ListString打印時(shí)按下標(biāo)查表頭。private static String resolveColName(ListString headers, String diffText) { int colon diffText.indexOf(:); if (colon 0) { return diffText; } int colIndex Integer.parseInt(diffText.substring(0, colon)); String colName (colIndex 0 colIndex headers.size()) ? headers.get(colIndex) : 列 colIndex; return colName diffText.substring(colon); }這個(gè)函數(shù)依賴fieldsChanged里的字符串格式固定因此構(gòu)造這個(gè)列表時(shí)一定要統(tǒng)一格式比如3:100 - 200這種帶冒號(hào)和箭頭的約定不要混入兩種格式否則解析時(shí)會(huì)出現(xiàn)各種怪異情況。如果你覺得字符串解析太脆弱更穩(wěn)妥的做法是在RowDiff里存ListInteger changedCols輸出時(shí)再按需查表頭轉(zhuǎn)列名適合長期維護(hù)的產(chǎn)品代碼resolveColName這個(gè)輕量方案適合一次性核對工具。5. 避坑指南鍵值比對最常見的五個(gè)翻車點(diǎn)5.1 空值和空字符串被誤判成修改現(xiàn)象兩邊文件同一位置一個(gè)單元格沒填、一個(gè)填了空字符串比對結(jié)果顯示一大票空 - 空的修改看得人心煩。原因讀取 Excel 時(shí)空單元格getCellValueAsString返回的是 null 或空串而 CSV 空字段解析出來是空串兩邊只要有一邊取到的形態(tài)不同Objects.equals就直接判不等。解決比對前統(tǒng)一做一次 normalize讓 null 和空串變成同一個(gè)值。如果兩邊都做了這一步還在報(bào)差異就要檢查是不是一邊有普通空格一邊有全角空格String.trim()也要進(jìn) normalize??罩嫡Z義還是要由業(yè)務(wù)確認(rèn)比如單價(jià)為空和單價(jià)為 0是否一致不要程序自己拍板。5.2 數(shù)字單元格變身科學(xué)計(jì)數(shù)法現(xiàn)象Excel 里一個(gè)大整數(shù)比對報(bào)告顯示1.2345678901E10CSV 那邊卻是普通寫法12345678901兩邊對不上。原因POI 的數(shù)字單元格按 double 讀入超過一定位數(shù)時(shí) Java 默認(rèn)用科學(xué)計(jì)數(shù)法轉(zhuǎn)字符串CSV 讀進(jìn)來的是原始字符串自然長不一樣。解決數(shù)字格式化工具方法里多加一道判斷整數(shù)部分直接轉(zhuǎn) long 去掉小數(shù)尾巴。超過 15 位的超長數(shù)字比如業(yè)務(wù)單號(hào)被 Excel 存成數(shù)字double 本身就有精度損失這個(gè)只能從源頭解決讓上游把該列存成文本。排錯(cuò)時(shí)可以用BigDecimal.valueOf(num).toPlainString()做臨時(shí)查看不要直接信Double.toString的顯示。5.3 CSV 中文亂碼編碼問題比想象中更常見現(xiàn)象比對結(jié)果里中文變成一串亂碼或問號(hào)數(shù)字和字母正常。原因CSV 文件本身的編碼和讀取時(shí)指定的Charset不一致。Windows 上用 Excel 另存的 CSV 多半是 GBK從服務(wù)端導(dǎo)出的通常是 UTF-8兩個(gè)交叉就容易亂。解決在 main 方法里暴露--charset參數(shù)并傳給Charset.forName默認(rèn)寫成 UTF-8。遇到亂碼先別猜用十六進(jìn)制方式看文件開頭的幾個(gè)字節(jié)有EF BB BF是帶 BOM 的 UTF-8沒有就是 GBK 或者無 BOM UTF-8。如果同事用 Excel 打開正常但程序讀亂碼大概率文件是 GBK傳--charset GBK即可。這個(gè)坑很小但在真實(shí)環(huán)境里出現(xiàn)頻率極高尤其當(dāng)文件經(jīng)手多個(gè)人時(shí)。5.4 鍵值重復(fù)導(dǎo)致行被靜默覆蓋現(xiàn)象比對結(jié)果顯示大量新增和刪除修改數(shù)為 0而且新增刪除行數(shù)接近看起來像整表重發(fā)。原因鍵值列不唯一Map.put時(shí)新行覆蓋舊行兩邊的重復(fù)行各自只保留下最后一條于是舊表有 A 鍵、新表有 A 鍵但指向不同的行就變成了刪一行增一行的假象。解決讀取時(shí)統(tǒng)計(jì)每個(gè)鍵的出現(xiàn)次數(shù)超過一次就向標(biāo)準(zhǔn)錯(cuò)誤打警告。加一行重復(fù)檢查代碼成本很低但能救回很多排查時(shí)間public void putWithDuplicateCheck(MapString, String[] data, String key, String[] row) { String[] existed data.put(key, row); if (existed ! null) { System.err.println(警告: 鍵值重復(fù), key 被覆蓋); } }如果業(yè)務(wù)上鍵必須唯一說明數(shù)據(jù)本身已經(jīng)臟了要先清洗再比對如果鍵只是主鍵的一部分需要重新確認(rèn)鍵列組合。無論如何都不要在看不警告的情況下直接信任比對結(jié)果。5.5 行尾逗號(hào)被吞整列數(shù)據(jù)悄悄錯(cuò)位現(xiàn)象CSV 中某一行末尾有空列讀進(jìn)來看不見報(bào)錯(cuò)但比對時(shí)那一列的值和其他行對不齊單獨(dú)看每行又好像沒問題。原因line.split(,)不加第二個(gè)參數(shù)會(huì)丟棄末尾空字符串。例如一行是A,B,split 得到 2 個(gè)元素而不是 3 個(gè)后續(xù)按下標(biāo)比對時(shí)少一列整行的末位列都會(huì)錯(cuò)位。解決堅(jiān)持用split(,, -1)保留空尾部。這個(gè)符號(hào)看著不起眼但它是 CSV 解析里最陰的坑之一錯(cuò)過一次印象就深了。另外如果 CSV 字段本身帶引號(hào)包裹的逗號(hào)手寫split就不夠用了需要引入一個(gè)支持轉(zhuǎn)義的狀態(tài)機(jī)解析器或者直接用現(xiàn)成的 CSV 解析庫不要硬手?jǐn)]。如果你手頭的場景跟上面五條都無關(guān)但還是翻車優(yōu)先懷疑數(shù)據(jù)本身先寫個(gè)最小復(fù)現(xiàn)用例用五六行假數(shù)據(jù)跑一遍比對確認(rèn)程序邏輯沒問題再去處理真實(shí)文件。把問題定位到數(shù)據(jù)還是代碼這一步是排查所有 Excel/CSV 類工具的關(guān)鍵。6. 進(jìn)階超過十萬行時(shí)怎么不把內(nèi)存打爆內(nèi)存 Map 方案在行數(shù)超過十幾萬時(shí)會(huì)明顯吃力。兩個(gè)MapString, String[]加上 POI 讀 Excel 時(shí)的對象開銷堆內(nèi)存占用很容易突破 1GB。如果只是臨時(shí)核對調(diào)大-Xmx是最快的路但要做成定時(shí)任務(wù)就得換思路。一個(gè)常用做法是流式讀取按鍵排序后落臨時(shí)文件再用雙指針歸并比較。流程是讀左邊每一行拼鍵按鍵排序?qū)懭肱R時(shí)文件右邊同樣處理然后兩個(gè)有序文件各取一個(gè)游標(biāo)鍵相等就比對指定列鍵不等時(shí)小的那個(gè)鍵所在的行就是只在一邊存在的差異。排序可以用 JDK 自帶的Files.lines()配合外部歸并排序?qū)崿F(xiàn)量會(huì)大一些但內(nèi)存占用可以控制在幾十 MB 以內(nèi)。還有一個(gè)中間量級非常好用的方案把兩個(gè)文件分別導(dǎo)入嵌入式數(shù)據(jù)庫表然后用一條 SQL 做 FULL OUTER JOIN比手寫 Java 穩(wěn)妥得多。Java 程序里只需要負(fù)責(zé)參數(shù)解析和把最終差異格式化輸出核心比對交給引擎SELECT a.key, a.val_old, b.val_new FROM old_file a FULL OUTER JOIN new_file b ON a.key b.key WHERE a.val_old IS DISTINCT FROM b.val_new到這一步鍵值比對的工具就從一次性腳本長成了能扛住生產(chǎn)數(shù)據(jù)量的核對程序。我的個(gè)人習(xí)慣是文件超過十萬行先問自己一句——真的要在 Java 里用 Map 硬扛嗎多數(shù)時(shí)候答案是不必。把讀取和比對下推給引擎程序里的邏輯少一半內(nèi)存問題也自然消失。希望這套做大文件的關(guān)鍵做法能幫到你。下次拿到兩張要對齊的表可以先花十分鐘想清楚鍵值、空值和數(shù)據(jù)量再動(dòng)手寫代碼能少走很多彎路。本文還有配套的精品資源點(diǎn)擊獲取