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