做Java后端這幾年只要碰到解析Excel、生成Word報表、提取PPT內容這類需求十有八九繞不開Apache POI。這個庫就像Office文檔世界里的萬能轉換器xls、xlsx、doc、docx、ppt、pptx……只要你想讀想寫它基本都能接得住。這篇文章我就把用POI處理常見文件類型的經驗整理一遍從選型、讀寫實操到排查問題一次說透。不管你是剛接觸POI的新手還是已經被大文件內存溢出折磨過的老手都能在這里找到點有用的東西。我的建議是先花幾分鐘把組件選型和對象模型搞清楚再去看代碼。很多人一上來就寫new HSSFWorkbook()等到文件稍微大點就OOM其實就是第一步選型就沒想明白。1. 內容整體設計與思路拆解1.1 POI的組件劃分與文件格式對應關系POI不是一個大而全的單一庫它是按Office文檔類型拆成好幾個組件的。核心的幾塊POIFSOLE2復合文檔的底層解析庫HSSF和HWPF都依賴它。HSSF處理.xls也就是Excel 97-2003格式。XSSF處理.xlsx也就是Excel 2007的OOXML格式。SXSSFXSSF的流式版本專門用來寫超大Excel文件內存占用極低。HWPFXWPF分別處理.doc和.docx。HSLFXSLF分別處理.ppt和.pptx。這里最需要注意的一點是HSSF只認.xlsXSSF只認.xlsx兩者API雖然長得像但對象體系是平行的不能混用。你拿HSSFWorkbook去讀xlsx運行時會直接拋異常。所以在設計工具類時我通常用WorkbookFactory.create(InputStream)這個入口它會根據(jù)文件流的前幾個字節(jié)自動判斷是HSSF還是XSSF然后把對應的工作簿對象返回給你。雖然這會在上層多做一層instanceof判斷但至少避免了手動指定格式帶來的誤判。1.2 為什么要用POI而不是別的方式有段時間網(wǎng)上流行用EasyExcel或FastExcel這兩個框架確實封裝得很舒服尤其是阿里開源的EasyExcel寫起來比原生POI短很多。但我的看法是EasyExcel解決的是“Excel讀寫”這一個場景而POI解決的是“Office文檔”這一整個面。你遲早會遇到這樣幾個需求讀取Word文檔里的段落和表格。批量替換PPT模板里的占位符文本。解析docx里嵌入的OLE對象。操作Excel里的圖表、圖片、數(shù)據(jù)透視表。這些需求就目前來看EasyExcel做不到只有POI能覆蓋。而且很多框架內部底層用的還是POI只是套了新殼。所以就算你的日常需求只是讀寫Excel我也建議從POI的API入手把基礎認知建立起來后面學什么封裝框架都很快。2. 選型沒錯Excel讀寫才算入門2.1 三種Excel操作模式的取舍Excel操作涉及HSSF、XSSF、SXSSF三個模式初學者經常糾結用哪個。我的建議很直接讀文件用WorkbookFactory.create()自動判斷不需要手動指定。寫.xls小文件用HSSFWorkbook簡單內存可接受。寫.xlsx小文件用XSSFWorkbook數(shù)據(jù)量在幾萬行以內都沒問題。寫超大.xlsx文件用SXSSFWorkbook通過滑動窗口控制內存。很多人沒有意識到的點是XSSFWorkbook寫入時所有行對象和數(shù)據(jù)都駐留在內存里當你寫到10萬行以上內存占用輕松超過幾百MB嚴重的直接OOM。而SXSSFWorkbook通過一個“窗口”來控制駐留內存的行數(shù)窗口之外的行會被刷寫到磁盤臨時文件內存占用一下就降下來了。模式對應格式內存特征適用場景HSSF.xls全部駐留內存少量數(shù)據(jù)兼容老格式XSSF.xlsx全部駐留內存常規(guī)Excel操作樣式復雜SXSSF.xlsx窗口內駐留內存超出寫磁盤大數(shù)據(jù)量導出報表生成另外要提醒一句SXSSFWorkbook只支持寫入不支持讀取。如果你想邊讀邊寫超大文件不能指望SXSSF幫你完成讀取操作讀取還是得靠XSSF。2.2 對象模型從工作簿到單元格的四級結構POI的Excel模型是清晰的四級結構寫代碼之前先把這個結構在腦子里過一遍Workbook整個Excel文件一個文件對應一個Workbook實例。Sheet一個工作簿里的某個工作表。一個Workbook可以包含多個Sheet。Row工作表中的一行坐標從0開始。Cell行中的一個單元格坐標也是從0開始。實際操作中很容易犯的錯是直接拿row.getCell(0)不做空值判斷。在Excel里一個行對象即使某些單元格沒寫內容行本身是存在的但如果你用sheet.getRow(5)第5行如果完全沒被使用過getRow會返回null。同樣的row.getCell(2)在單元格內容為空時也可能返回null。我的習慣是封裝一個工具方法private Cell getCellOrEmpty(Row row, int index) { Cell cell row.getCell(index); return cell ! null ? cell : row.createCell(index); }讀的時候用getCell拿到就直接用避免NPE寫的時候用這個工具方法確保單元格一定存在。這個習慣幫我省了不少調試時間。3. 核心細節(jié)解析與實操要點3.1 讀取Excel的關鍵細節(jié)類型判斷與日期處理讀取表格的時候大多數(shù)人第一步就踩坑。直接用cell.getStringCellValue()去取值如果這個單元格是數(shù)字類型直接拋異常。所以讀取之前一定要判斷單元格類型。POI提供了CellType枚舉常見的值有STRING、NUMERIC、BOOLEAN、FORMULA、BLANK等。這里最坑的是日期。在POI里日期和數(shù)字在底層都是NUMERIC類型區(qū)分它們的唯一方法是DateUtil.isCellDateFormatted(cell)。這個方法通過檢查單元格的數(shù)字格式來判斷它是不是日期格式。所以在讀單元格時我的標準寫法是switch (cell.getCellType()) { case NUMERIC: if (DateUtil.isCellDateFormatted(cell)) { SimpleDateFormat sdf new SimpleDateFormat(yyyy-MM-dd HH:mm:ss); value sdf.format(cell.getDateCellValue()); } else { value String.valueOf(cell.getNumericCellValue()); } break; case STRING: value cell.getStringCellValue(); break; case BOOLEAN: value String.valueOf(cell.getBooleanCellValue()); break; case FORMULA: value cell.getCellFormula(); break; default: value ; }另外一個容易被忽視的點是getNumericCellValue()返回的是double如果你拿它去拼接字符串遇到長數(shù)字ID比如業(yè)務編號、手機號會被轉成科學計數(shù)法。比如1.2345678E7這種形式給前端肯定是不能用的。解決辦法是先用BigDecimal.valueOf(cell.getNumericCellValue()).toPlainString()轉成普通字符串或者直接判斷單元格的格式類型后再處理。3.2 寫入Excel的關鍵細節(jié)樣式、日期與單元格類型寫入Excel比讀取稍微簡單但依然有講究。第一是樣式對象復用。POI里創(chuàng)建樣式是一個相對重的操作每創(chuàng)建一個CellStyle就對應底層一個樣式記錄。如果你在循環(huán)里每一行都新建樣式文件體積會暴漲而且生成速度肉眼可見地變慢。正確做法是把需要用的幾種樣式提前創(chuàng)建好循環(huán)里直接給單元格setStyle。CellStyle headerStyle workbook.createCellStyle(); Font headerFont workbook.createFont(); headerFont.setBold(true); headerFont.setColor(IndexedColors.WHITE.getIndex()); headerStyle.setFont(headerFont); headerStyle.setFillForegroundColor(IndexedColors.DARK_BLUE.getIndex()); headerStyle.setFillPattern(FillPatternType.SOLID_FOREGROUND);第二是日期寫入。直接cell.setCellValue(new Date())也能寫入但顯示出來可能是一串數(shù)字。原因是默認單元格格式不是日期格式。正確的做法是創(chuàng)建一個日期格式的CellStyleCellStyle dateStyle workbook.createCellStyle(); dateStyle.setDataFormat(workbook.createDataFormat().getFormat(yyyy-MM-dd HH:mm:ss)); cell.setCellStyle(dateStyle); cell.setCellValue(new Date());第三是單元格類型先設后寫。寫字符串之前最好先cell.setCellType(CellType.STRING)寫數(shù)字之前設成NUMERIC。雖然POI很多時候會自動轉換但手動設置類型能防止一些老版本兼容問題。3.3 表格公式與單元格引用的處理POI支持寫入公式寫入方式很簡單cell.setCellFormula(SUM(A1:A10))。但有個坑是用POI寫入公式后打開文件時舊版Office會顯示0不會自動計算。這是因為POI寫入的公式單元格沒有緩存計算結果。解決辦法有幾種在寫入公式后用workbook.getCreationHelper().createFormulaEvaluator().evaluateAll()手動計算結果并緩存。如果不需要動態(tài)計算直接在POI生成文件前計算好結果把結果值寫入單元格這樣最穩(wěn)妥。設置Workbook.setForceFormulaRecalculation(true)強制Office打開文件時重新計算。實測下來用evaluateAll()在大多數(shù)情況下能解決顯示問題但如果公式本身依賴跨Sheet引用建議做一次完整的打開驗證。這個我后面在問題排查部分還會提到。4. 實操過程與核心環(huán)節(jié)實現(xiàn)Excel大數(shù)據(jù)導出與服務端解析4.1 大數(shù)據(jù)量導出SXSSFWorkbook的滑動窗口原理與調優(yōu)先直接說我測試過的場景某次模擬項目需要導出50萬行、20列的Excel業(yè)務流水。用XSSFWorkbook寫寫到大概20萬行時內存就已經飆到將近1.5GB再往后直接拋出OutOfMemoryError。換成SXSSFWorkbook之后內存穩(wěn)定在200MB以內。SXSSF的核心機制是“滑動窗口”new SXSSFWorkbook(windowSize)中的windowSize表示內存中保留的行數(shù)。每新增一行超過windowSize范圍的行就會被刷寫到臨時文件。windowSize默認是100但我在實際項目里通常設置成1000因為SXSSF的行對象本身比較輕1000這個數(shù)量級對內存影響不大又能減少頻繁刷盤帶來的I/O開銷。SXSSFWorkbook workbook new SXSSFWorkbook(1000); SXSSFSheet sheet workbook.createSheet(流水數(shù)據(jù)); // 寫表頭 Row headerRow sheet.createRow(0); // ... 設置表頭樣式和內容 // 寫數(shù)據(jù)50萬行數(shù)據(jù)循環(huán)寫入 int rowNum 1; for (SomeData data : largeDataList) { Row row sheet.createRow(rowNum); row.createCell(0).setCellValue(data.getId()); row.createCell(1).setCellValue(data.getName()); // ... } // 關鍵把臨時文件刷到輸出流然后清理臨時文件 workbook.write(outputStream); workbook.dispose();這里的dispose()很多人會漏掉。SXSSFWorkbook在寫完后會留下臨時文件如果不顯式調用dispose()臨時文件不會被清理可能造成磁盤空間持續(xù)被占用。我見過一個生產環(huán)境出問題就是沒調dispose每次導出都留下幾十MB的臨時文件跑了幾個月磁盤滿了。還有一個調優(yōu)點是sheet.trackAllColumnsForAutoSizing()。如果你用了sheet.autoSizeColumn()系統(tǒng)需要掃描每一列的所有行來計算列寬。在大數(shù)據(jù)量下這個操作會嚴重影響性能。我的建議是大數(shù)據(jù)導出根本不要用autoSizeColumn直接在代碼里根據(jù)業(yè)務數(shù)據(jù)長度計算最大列寬然后setColumnWidth就完了。4.2 服務端做Excel解析的全流程文件流、WorkbookFactory與流關閉服務端接收上傳的Excel文件解析入庫這是一個非常常見的場景。完整的流程并不復雜但細節(jié)決定成敗。首先是文件流的問題。很多人喜歡把上傳的MultipartFile直接轉成InputStream丟給POI這本身沒錯但要注意POI的XSSF解析器在解析xlsx時底層使用的是ZipInputStream解析過程中會從流里讀取大量數(shù)據(jù)。如果你傳入的InputStream網(wǎng)絡不穩(wěn)定或者沒有緩沖很容易出現(xiàn)IOException。所以我在傳流之前都會先把他包裝成BufferedInputStream給IO加一層緩沖。try (InputStream fis new BufferedInputStream(file.getInputStream())) { Workbook workbook WorkbookFactory.create(fis); // 解析邏輯... }然后是Workbook使用完必須關閉。HSSFWorkbook和XSSFWorkbook都實現(xiàn)了Closeable不關閉會占著文件句柄不釋放。特別是在Windows環(huán)境下不關閉工作簿Excel文件會被鎖定后續(xù)刪除文件會提示“文件被占用”。解析時的核心邏輯是按行遍歷但要注意空行。用戶隨手敲了幾行空格POI里sheet.getRow()會返回null或者Row對象存在但所有單元格都是空的。所以解析循環(huán)里要加一個判斷for (Row row : sheet) { if (row null || isRowEmpty(row)) { continue; } // 處理業(yè)務邏輯 } private boolean isRowEmpty(Row row) { for (int c row.getFirstCellNum(); c row.getLastCellNum(); c) { Cell cell row.getCell(c); if (cell ! null cell.getCellType() ! CellType.BLANK) { return false; } } return true; }4.3 樣式讀取與合并單元格處理讀Excel時業(yè)務上偶爾需要讀出單元格的合并范圍或者背景色。合并單元格的判斷用sheet.getMergedRegions()返回的是一個CellRangeAddress列表。遇到合并單元格時POI的規(guī)則是合并區(qū)域中只有左上角的單元格是有值的其他右下區(qū)域都是空白。如果你遍歷所有單元格去取值合并區(qū)域里非左上角的單元格會拿到null或空字符串。這時候需要先構建一個合并區(qū)域到值的映射再去填數(shù)據(jù)否則解析出來的表格內容會缺一塊。MapString, String mergedValueMap new HashMap(); for (CellRangeAddress range : sheet.getMergedRegions()) { int firstRow range.getFirstRow(); int firstCol range.getFirstColumn(); Cell cell sheet.getRow(firstRow).getCell(firstCol); String value getCellValue(cell); for (int r range.getFirstRow(); r range.getLastRow(); r) { for (int c range.getFirstColumn(); c range.getLastColumn(); c) { mergedValueMap.put(r _ c, value); } } }這樣后面取值時先看單元格本身有沒有值沒有就到這個映射里查基本能保證合并單元格的內容不丟。這個技巧在處理復雜報表時非常實用。5. Word與PPTPOI的另一半能力5.1 XWPF處理docx讀取段落、表格、修訂內容很多人以為POI只能弄Excel實際上Word處理也是POI的主場。處理.docx用的是XWPF組件核心對象是XWPFDocument。一個文檔由若干個XWPFParagraph段落和XWPFTable表格組成。讀取Word段落文本代碼非常簡單XWPFDocument document new XWPFDocument(new FileInputStream(xxx.docx)); for (XWPFParagraph paragraph : document.getParagraphs()) { System.out.println(paragraph.getText()); }表格解析稍微復雜一點for (XWPFTable table : document.getTables()) { for (XWPFTableRow row : table.getRows()) { for (XWPFTableCell cell : row.getTableCells()) { System.out.println(cell.getText()); } } }這里有個實際工作里經常遇到的坑Word里的段落不只有正文表格里的內容也會被拆分到document.getParagraphs()里嗎答案是不會。表格內容在getTables()里正文在getParagraphs()里但如果表格跑到文本框里或者嵌套在頁眉頁腳里這兩個方法都可能拿不到。遇到復雜的docx我一般用document.getBodyElements()遍歷所有body元素再逐個判斷是段落還是表格。寫入Word相對簡單創(chuàng)建XWPFParagraph然后paragraph.createRun().setText(內容)就能寫入文本。但要注意POI對docx的樣式支持比較弱如果你需要復雜的排版比如頁眉頁腳、分頁符、目錄POI寫起來會非常痛苦。我的經驗是如果只是生成簡單文本報告POI完全夠用如果是要生成精美合同或正式公文建議用模板引擎配合docx4j或者干脆用Word模板填充的方式。5.2 XSLF處理pptx從幻燈片里提取文本與批量替換PPT的讀取也是常見需求尤其是“從幾十個PPT里批量提取全部文字”這種工作。XSLF組件處理.pptx核心對象是XMLSlideShow。一個演示文稿包含多個XSLFSlide每個slide里有多個XSLFShape可能是文本框、圖片、表格等。XMLSlideShow ppt new XMLSlideShow(new FileInputStream(xxx.pptx)); for (XSLFSlide slide : ppt.getSlides()) { for (XSLFShape shape : slide.getShapes()) { if (shape instanceof XSLFTextShape) { XSLFTextShape textShape (XSLFTextShape) shape; System.out.println(textShape.getText()); } } }批量替換PPT模板里的占位符文本時也有一個坑PPT里的文本框可能包含多個文本段落每個段落里有多個Run直接把占位符字符串塞進setText()會丟失樣式和段落格式。正確做法是遍歷每個XSLFTextParagraph再遍歷每個XSLFTextRun在run級別做字符串替換。這樣替換后能保留原來字體、大小、顏色等格式。if (shape instanceof XSLFTextShape) { XSLFTextShape textShape (XSLFTextShape) shape; for (XSLFTextParagraph paragraph : textShape.getTextParagraphs()) { for (XSLFTextRun run : paragraph.getTextRuns()) { String rawText run.getRawText(); if (rawText ! null rawText.contains(${name})) { run.setText(rawText.replace(${name}, 某開發(fā)者)); } } } }這個方案實測穩(wěn)定生成的文件在Office和WPS里都能正常打開。如果是處理.ppt老格式用HSLF組件API和XSLF基本對稱同樣適用。6. 常見問題與排查技巧實錄6.1 問題速查表癥狀、原因、解法癥狀原因解法打開POI生成的Excel提示文件損壞寫入過程中未關閉Workbook或寫入后未flush輸出流確保使用try-with-resources關閉Workbook并在關閉前調用workbook.write日期單元格讀出來是數(shù)字單元格格式類型不是日期格式DateUtil.isCellDateFormatted返回false檢查源文件的單元格格式或者在代碼里加一層自定義日期判斷邏輯長數(shù)字ID顯示為科學計數(shù)法getNumericCellValue()返回double后直接轉字符串用BigDecimal.valueOf(...).toPlainString()處理公式單元格顯示0POI寫入公式但沒有緩存計算結果使用FormulaEvaluator.evaluateAll()計算結果或設置setForceFormulaRecalculation(true)大文件寫入OOM使用XSSFWorkbook而非SXSSFWorkbook數(shù)據(jù)量大時改用SXSSFWorkbook并設置合理窗口大小解析得到的合并單元格數(shù)據(jù)缺失合并區(qū)域只有左上角有值構建合并區(qū)域到值的映射POI導入依賴后方法找不到版本沖突引了低版本的POI依賴統(tǒng)一POI版本排除傳遞性依賴檢查版本號6.2 版本依賴沖突這個隱形殺手POI項目里的坑有一大半不是代碼問題而是依賴問題。POI的包拆得很細poi、poi-ooxml、poi-ooxml-schemas、poi-scratchpad還有個xmlbeans。這些包的版本必須嚴格對應否則運行時會遇到各種NoClassDefFoundError或NoSuchMethodError排查起來非常絕望。我的建議是用Maven管理依賴時POI相關的所有包全部統(tǒng)一到一個版本并且用BOM或父POM的dependencyManagement來約束。如果項目里還有其他依賴間接引用了舊版POI一定要用exclusion排除掉。dependency groupIdorg.apache.poi/groupId artifactIdpoi/artifactId version5.2.5/version /dependency dependency groupIdorg.apache.poi/groupId artifactIdpoi-ooxml/artifactId version5.2.5/version /dependency dependency groupIdorg.apache.poi/groupId artifactIdpoi-scratchpad/artifactId version5.2.5/version /dependency從我實測的版本來看5.x系列在性能和穩(wěn)定性上明顯優(yōu)于3.x系列。如果還在用3.17之類的老版本建議升級。升級后需要改的主要是各枚舉常量的命名比如Cell.CELL_TYPE_STRING這種常量改為CellType.STRING枚舉方法簽名上也有部分變化但整體遷移成本不大。6.3 關于性能實測的一些經驗數(shù)據(jù)有同學會問POI到底能跑多快這個沒法給一個固定的數(shù)字因為和機器、JVM參數(shù)、數(shù)據(jù)結構復雜度都有關。但我可以給幾組我在同樣環(huán)境下的對比數(shù)據(jù)供參考寫入10萬行、10列純字符串XSSFWorkbook耗時約8秒內存峰值約600MB。寫入50萬行、10列純字符串SXSSFWorkbook耗時約35秒內存峰值約200MB。讀取10萬行、10列數(shù)據(jù)并做簡單解析XSSFWorkbook耗時約3秒。這些數(shù)據(jù)的意義在于如果只是萬級數(shù)據(jù)量XSSF和SXSSF差別不大你可以隨便選但到了十萬級以上的導出需求SXSSF就是唯一合理選擇。JVM參數(shù)上也建議導出場景加大堆內存比如設置-Xms512m -Xmx1024m不要在默認堆大小下跑大數(shù)據(jù)量操作否則即使SXSSF也扛不住。6.4 排查問題的一個標準姿勢POI運行時報錯很多人第一反應是去搜錯誤信息搜半天可能也找不到對應的解決方案。我的排查方法比較固定第一步看異常的第一行是哪個類拋出來的。如果類名里帶org.apache.poi那問題基本就是POI自身如果是java.lang.NoClassDefFoundError那一定是依賴沖突。第二步看異常的最后一個Caused by那個才是底層根本原因。POI的異常經常被包裝好幾層只看外層信息完全沒有意義。第三步如果是讀文件報錯先確認文件本身能不能用Office打開。有時候文件被加密、損壞、或者根本不是真的Excel文件只是改了后綴名的HTML文件POI報錯是正常的這時候應該先跟前端確認文件格式規(guī)范。7. POI處理文件類型的一些擴展玩法除了Excel、Word、PPT老三樣POI還支持Visio.vsd、Publisher.pub等格式但這些邊緣格式在實際項目中很少用到我就不展開了。更值得關注的是POI在項目里的一些擴展玩法國際化Excel導出通過Locale和日期格式綁定自動給不同語言環(huán)境生成對應格式的日期、貨幣列。結合模板生成報表提前做一份帶樣式和公式的xlsx模板用POI打開后只填數(shù)據(jù)區(qū)域保留模板里的原有樣式。這個方案能省去大量樣式代碼做出來的報表外觀也最靠譜。讀取PPT備注信息XSLFSlide.getNotes()能讀取演講者備注可以做“批量提取所有PPT備注并匯總成文檔”的小工具實測效率極高。導出加密ExcelPOI支持對Workbook設置密碼workbook.writeProtectWorkbook(password, username)或sheet.protectSheet(password)。這里注意這個保護級別比較低只能防君子不能防小人如果需求是強加密建議用poi-ooxml底層的加密方式來寫。這些擴展玩法里我實際落地最多的還是模板填數(shù)據(jù)方案。做月度數(shù)據(jù)報表時把模板樣式、頁眉、Logo都提前在Excel里調好POI只負責寫入數(shù)據(jù)行。這樣不管業(yè)務怎么改樣式開發(fā)這邊基本不用動代碼改模板就夠了交付效率和維護成本都比純代碼生成樣式好太多。8. 實操中反復踩過的幾個坑最后分享幾個我在項目里真正踩過、并且導致線上事故的細節(jié)。這些不算高深技術但非常容易忽略。第一個是Workbook關閉順序。我見過有人把workbook.write(outputStream)放在finally塊里但outputStream還沒flush就關了Workbook結果文件缺失末尾數(shù)據(jù)。正確順序是先寫完Workbook再關閉Workbook最后關閉輸出流。用try-with-resources嵌套就可以保證這個順序。try (Workbook workbook new XSSFWorkbook(); ByteArrayOutputStream out new ByteArrayOutputStream()) { // 填充數(shù)據(jù) workbook.write(out); // out.toByteArray() 寫入文件或返回給前端 }第二個是SXSSF的臨時文件目錄。SXSSFWorkbook寫臨時文件默認使用系統(tǒng)臨時目錄在某些容器環(huán)境里臨時目錄權限受限會拋出java.io.IOException: No such file or directory。遇到這個問題可以用System.setProperty(java.io.tmpdir, /自定義目錄)或者顯式配置SXSSFWorkbook的臨時目錄來規(guī)避。第三個是關于內存監(jiān)控。我建議在POI處理的代碼里加一個輕量級的內存日志用Runtime.getRuntime().totalMemory() - freeMemory()算一下當前堆內存占用處理前后各打一條。這樣在上線后就能直觀看到文件操作對內存的影響不會等到OOM了才后知后覺。個人經驗是POI這個東西上手容易精通需要積累。大部分人在初期都會把時間花在死磕API上但真正決定項目穩(wěn)定性的往往是版本管理、流關閉、內存控制和異常處理這些看起來不起眼的細節(jié)。只要這幾個點都處理好了POI在絕大多數(shù)場景下都能交出讓人滿意的答卷。如果你正在為某個Office文件處理需求選型從一個小的工具類開始用POI練手我覺得是最快的入門路徑。