簡介C#結(jié)合Epplus庫操作Excelxlsx的封裝資源面向需要報表導(dǎo)出、數(shù)據(jù)分析及圖表展示的.NET開發(fā)者覆蓋讀取、寫入與折線圖/曲線圖生成等高頻場景。壓縮包共315個文件大小35.67MB以xml、dll、cs源文件為主另含xlsx示例文件、png示意圖與txt/說明文檔構(gòu)成“源碼-依賴-樣例-文檔”的完整結(jié)構(gòu)便于直接參考或集成。目前已有131人學(xué)習(xí)下載。資源重點封裝了Excel讀寫的通用方法可傳入文件路徑快速訪問工作表、行列與單元格也支持多類型數(shù)據(jù)精確寫入圖表部分針對趨勢展示做了專門封裝只需指定數(shù)據(jù)與圖表類型即可生成折線圖或曲線圖并插入工作表中。同時體現(xiàn)異常處理與擴展性設(shè)計遇到文件缺失或格式錯誤能給出友好提示開發(fā)者可在此基礎(chǔ)上按業(yè)務(wù)繼續(xù)擴展減少重復(fù)勞動。 做C#這塊時間長了尤其是寫過幾年上位機和數(shù)據(jù)管理系統(tǒng)的朋友應(yīng)該都有一個共同的體會Excel導(dǎo)出、導(dǎo)入這個需求基本是躲不掉的。業(yè)務(wù)方說“給我導(dǎo)個報表”領(lǐng)導(dǎo)說“把這個數(shù)據(jù)整理成表格發(fā)我”客戶說“要把設(shè)備采集的數(shù)據(jù)能導(dǎo)出來分析”。一開始我用CSV糊弄可一旦遇到格式要求、圖表要求CSV就完全頂不住了。后來轉(zhuǎn)用EPPlus發(fā)現(xiàn)這東西確實好用但用久了又覺得煩——因為每次處理xlsx都要反復(fù)寫一堆讀取循環(huán)、樣式設(shè)置、圖表配置代碼越寫越臃腫而且每個人寫的風(fēng)格還不一樣維護起來特別痛苦。這篇博文就是從我自己的項目實踐整理出來的我用C#對EPPlus做了一層封裝把xlsx的讀取、寫入以及折線圖和曲線圖生成統(tǒng)一封裝成一套簡潔的方法。這樣業(yè)務(wù)代碼只關(guān)心數(shù)據(jù)不用關(guān)心Excel細(xì)節(jié)。如果你也在做C#相關(guān)的數(shù)據(jù)導(dǎo)出、報表生成或者想在上位機項目里直接把實時數(shù)據(jù)畫成圖表這篇內(nèi)容應(yīng)該能給你一個可以直接抄作業(yè)的方案。1. 選型EPPlus之前的糾結(jié)很多新人拿到“操作Excel”這個需求第一反應(yīng)是搜“C# Excel庫”然后會看到NPOI、Aspose.Cells、EPPlus還有一個老古董Microsoft.Office.Interop.Excel。這幾種方案各有各的坑我在踩過一圈之后才鎖定EPPlus先說結(jié)論再講理由。1.1 放棄COM組件和NPOI的真實原因先說Microsoft.Office.Interop.Excel。它的本質(zhì)是調(diào)用本機安裝的Office軟件來操作Excel也就是說目標(biāo)電腦和服務(wù)器必須裝著Office。這在開發(fā)機上挺方便但部署到客戶現(xiàn)場就麻煩了要不要裝Office裝哪個版本裝了之后DCOM權(quán)限怎么配服務(wù)端跑著跑著Excel進程崩潰卡死怎么辦我見過不少項目被這個com組件坑到懷疑人生它非常適合個人桌面電腦上用但放到需要穩(wěn)定運行的業(yè)務(wù)系統(tǒng)里基本就是定時炸彈。NPOI是Java POI項目的.NET移植優(yōu)點是完全免費而且不需要Office環(huán)境。但我實際用下來覺得它的API風(fēng)格太“Java”了寫起來啰嗦尤其要生成圖表時NPOI的圖表支持非常弱基本上要靠手工拼XML那個操作真的是能把人逼瘋。如果你的需求只是簡單讀寫表格NPOI還湊合一旦涉及圖表、樣式、透視表這些高級特性開發(fā)效率會直線下降。1.2 EPPlus的核心優(yōu)勢與許可證提醒EPPlus是基于OpenXML協(xié)議的.NET庫不需要裝Excel跨平臺API設(shè)計得很符合C#開發(fā)者的直覺。它內(nèi)置了圖表、數(shù)據(jù)透視表、樣式、公式計算等能力而且性能也不錯算是.NET生態(tài)里做Excel報表的“六邊形戰(zhàn)士”。不過必須提醒一句EPPlus從4.5版本開始變更了許可證使用的是Polyform Noncommercial License非商業(yè)場景免費商業(yè)使用需要購買授權(quán)。這是個非常容易踩的合規(guī)問題。很多同行早期用4.x版本習(xí)慣了升級到5.x/6.x之后突然遇到LicenseException一臉懵。解決方案一般有兩個要么在非商業(yè)項目里設(shè)置ExcelPackage.LicenseContext LicenseContext.NonCommercial要么公司有預(yù)算時直接購買商業(yè)授權(quán)要么繼續(xù)鎖在4.5以下的老版本但這樣會失去新特性。我自己的建議是不管項目性質(zhì)如何開工前先把許可證這條確認(rèn)清楚免得做到一半被法務(wù)或者技術(shù)排查找上門。2. 封裝設(shè)計的整體思路EPPlus本身功能很強大但直接用原生API寫業(yè)務(wù)代碼還是會有大量重復(fù)。比如讀取一個表格要處理空行、格式轉(zhuǎn)換、合并單元格寫入一個表格要處理表頭樣式、列寬、自動篩選生成圖表要配數(shù)據(jù)源、坐標(biāo)軸、圖例。這些邏輯每個項目都要寫一遍于是我決定做一層封裝。2.1 先把調(diào)用方想清楚設(shè)計這個封裝時我反復(fù)問自己一個問題業(yè)務(wù)程序員拿到這個庫他最想寫怎樣的代碼順著這個思路我抽象出三個核心動作讀取給一個文件路徑和Sheet名返回DataTable或者List 。寫入給一個DataTable或者List 指定文件路徑自動建表并寫入。畫圖給一組數(shù)據(jù)和圖表參數(shù)在指定Sheet上生成折線圖或曲線圖。接口定了之后就好辦多了。內(nèi)部實現(xiàn)無論怎么改調(diào)用方完全不用關(guān)心。比如未來我把底層從EPPlus換成別的庫對上層業(yè)務(wù)代碼幾乎是無感知的。這里有一個很關(guān)鍵的封裝決策所有文件操作都統(tǒng)一用FileInfo而不是字符串路徑。原因是EPPlus的ExcelPackage構(gòu)造函數(shù)接受FileInfo它在解析路徑、處理相對路徑時更規(guī)整而且天然支持后續(xù)的文件流操作。如果你在封裝里到處傳字符串路徑后面還得自己處理Path.GetFullPath之類的邏輯不如一開始就統(tǒng)一。2.2 核心類與接口約定我定義了一個靜態(tài)類ExcelHelper主要方法大體是這樣public static class ExcelHelper { // 讀取返回DataTable public static DataTable ReadToDataTable(string filePath, string sheetName null); // 寫入DataTable寫入xlsx可指定Sheet名 public static void WriteDataTable(DataTable dt, string filePath, string sheetName Sheet1); // 寫入泛型集合寫入xlsx public static void WriteListT(ListT data, string filePath, string sheetName Sheet1); // 圖表折線圖/曲線圖 public static void AddLineChart(string filePath, string sheetName, Dictionarystring, Listdouble seriesData, Liststring categories, string chartTitle, bool smooth false, string chartSheetName null); }這只是一個外部形態(tài)真正的實現(xiàn)遠(yuǎn)比這幾個方法復(fù)雜。比如在ReadToDataTable內(nèi)部要處理空Sheet、找不到Sheet、單元格類型轉(zhuǎn)換在WriteListT內(nèi)部要利用反射讀取泛型對象的屬性名作為表頭。這些細(xì)節(jié)我會在下面幾節(jié)展開。3. 讀取xlsx的細(xì)節(jié)實現(xiàn)讀取是相對基礎(chǔ)的一塊但越是基礎(chǔ)越容易出錯。最典型的場景是生產(chǎn)系統(tǒng)導(dǎo)出的Excel里有空行、有合并單元格、有各種日期格式直接按固定列索引讀很容易踩到坑。3.1 基礎(chǔ)讀取從ExcelWorksheet到DataTable用EPPlus讀取一個Sheet核心代碼如下using OfficeOpenXml; // 5.0及以上版本必須設(shè)置許可證上下文 ExcelPackage.LicenseContext LicenseContext.NonCommercial; using (var package new ExcelPackage(new FileInfo(filePath))) { var worksheet string.IsNullOrEmpty(sheetName) ? package.Workbook.Worksheets[1] : package.Workbook.Worksheets[sheetName]; if (worksheet null) throw new Exception($未找到Sheet: {sheetName}); var dt new DataTable(worksheet.Name); var dimension worksheet.Dimension; if (dimension null) return dt; // 第一行作為列名 foreach (var cell in worksheet.Cells[1, 1, 1, dimension.End.Column]) dt.Columns.Add(cell.Text); // 從第二行開始讀數(shù)據(jù) for (int row 2; row dimension.End.Row; row) { if (IsRowEmpty(worksheet, row, dimension.End.Column)) continue; var dataRow dt.NewRow(); for (int col 1; col dimension.End.Column; col) dataRow[col - 1] worksheet.Cells[row, col].Text; dt.Rows.Add(dataRow); } return dt; }這段代碼看起來挺標(biāo)準(zhǔn)但有兩個細(xì)節(jié)要注意。第一worksheet.Dimension如果你不提前判斷當(dāng)Sheet是空的時候直接訪問Dimension.End.Row會拋空引用異常。第二讀取單元格用了.Text而不是.Value因為.Text返回的是單元格格式化后的字符串比如日期列在Excel里顯示成“2024-01-15”.Text就直接拿到“2024-01-15”而.Value拿到的是Excel內(nèi)部的OADate序列號比如“45221”這種數(shù)字對業(yè)務(wù)方來說完全不友好。3.2 三個最容易翻車的讀取場景第一個是空行判斷。我見過太多人直接判斷第一列是否為空結(jié)果數(shù)據(jù)剛好第一列有空值整行就被跳過了。我的做法是把整行所有列的文本拼起來判斷是否全為空private static bool IsRowEmpty(ExcelWorksheet worksheet, int row, int endCol) { for (int col 1; col endCol; col) { if (!string.IsNullOrWhiteSpace(worksheet.Cells[row, col].Text)) return false; } return true; }第二個是日期列。如果Excel里的日期列是真正的日期格式用.Text拿到的字符串格式是“2024/1/15”還是“2024-01-15”取決于單元格的數(shù)字格式。更穩(wěn)妥的做法是在讀取前明確約定業(yè)務(wù)方在Excel里把日期列設(shè)置成文本格式或者我們讀取后用DateTime.TryParse嘗試轉(zhuǎn)換確保拿到的是標(biāo)準(zhǔn)化的DateTime對象。如果你拿到的是OADate序列號記得用DateTime.FromOADate(Convert.ToDouble(rawValue))轉(zhuǎn)換。第三個是合并單元格。Excel的合并單元格值只存在區(qū)域左上角的那個單元格里其他區(qū)域如果直接按行列去讀拿到的都是空字符串。比如產(chǎn)品名稱列做了一個從第2行到第5行的合并單元格你遍歷到第3、4、5行時讀到的產(chǎn)品名稱全是空的。解決思路有兩種一是用worksheet.Cells[row, col].Merge屬性判斷是否在合并區(qū)域內(nèi)一旦發(fā)現(xiàn)合并就向上找合并區(qū)域的起始單元格取值二是讀取前先對合并單元格做“向下填充”把值填滿整個合并區(qū)域。第一種更通用但實現(xiàn)復(fù)雜一點。3.3 讀取性能大數(shù)據(jù)量時的優(yōu)化如果你只是讀幾百行數(shù)據(jù)上面那個雙層循環(huán)完全沒有問題。但如果數(shù)據(jù)量到了幾萬行、幾十萬行逐單元格讀取就會變得非常慢。我有一次處理一個5萬行、30列的生產(chǎn)記錄表用逐單元格讀法跑了將近1分鐘后來做了兩層優(yōu)化使用worksheet.Cells.Value一次性取出整個二維數(shù)組在內(nèi)存里循環(huán)避免反復(fù)訪問Excel對象的開銷。關(guān)閉事件和屏幕刷新雖然EPPlus不需要屏幕刷新但可以通過package.Workbook.Worksheets級別的操作減少內(nèi)部開銷。優(yōu)化后同樣數(shù)據(jù)量基本能壓縮到2秒以內(nèi)。所以如果你封裝讀取方法建議內(nèi)部先探測數(shù)據(jù)規(guī)模超過某個閾值就切到數(shù)組批量讀取模式。4. 寫入xlsx的細(xì)節(jié)實現(xiàn)寫入比讀取更難的一點是你不僅要考慮數(shù)據(jù)還要考慮格式。因為業(yè)務(wù)方最討厭看見一坨沒排版的數(shù)據(jù)表頭不加粗、列寬不一致、數(shù)字不帶千分位這在展示層是災(zāi)難。4.1 從DataTable到工作表的快速寫入EPPlus提供了一個很省事的擴展方法LoadFromDataTable。它能一次性把整個DataTable寫進工作表比逐單元格賦值高效很多?；敬a如下using (var package new ExcelPackage()) { var worksheet package.Workbook.Worksheets.Add(Sheet1); worksheet.Cells[A1].LoadFromDataTable(dt, true); // 設(shè)置表頭樣式 using (var range worksheet.Cells[1, 1, 1, dt.Columns.Count]) { range.Style.Font.Bold true; range.Style.Fill.PatternType ExcelFillStyle.Solid; range.Style.Fill.BackgroundColor.SetColor(Color.LightGray); range.Style.HorizontalAlignment ExcelHorizontalAlignment.Center; } // 自動列寬 worksheet.Cells[worksheet.Dimension.Address].AutoFitColumns(); package.SaveAs(new FileInfo(filePath)); }LoadFromDataTable的第二個布爾參數(shù)表示是否把列名寫為表頭。這里有個小坑如果DataTable的列名是英文比如ProductName而我們需要中文表頭“產(chǎn)品名稱”直接LoadFromDataTable就不合適了。我的方案是先手動寫一行中文表頭再從第二行開始逐列賦值或者干脆用反射把實體屬性上的[DisplayName]特性讀取出來做表頭。后者更工程化適合實體類已經(jīng)定義好的項目。4.2 樣式與細(xì)節(jié)別讓報表顯得太業(yè)余樣式這塊體面的報表至少要處理三件事。第一表頭樣式。表頭加粗、加背景色、加邊框這些都能讓表格清晰很多。我習(xí)慣把表頭背景色設(shè)置成淺灰色或者淡藍(lán)色而不是純黑色因為純黑底白字打印起來太浪費墨。第二列寬。AutoFitColumns()在英文內(nèi)容下效果不錯但中文場景下經(jīng)常偏窄尤其是帶長文本的列。我在實際項目中很少完全依賴自動列寬而是先AutoFitColumns再對指定列做二次調(diào)整比如把“備注”這類列手動設(shè)成50把ID列設(shè)成8保證表格既不過分擁擠也不至于太松散。第三數(shù)字格式。寫金額、百分比、小數(shù)時如果直接寫double原始值Excel會顯示一長串比如1234.5678甚至1234.5678000001。正確做法是在寫入前用worksheet.Cells[D2:D100].Style.Numberformat.Format #,##0.00設(shè)置數(shù)字格式。這個事看似很小但對報表的專業(yè)度影響極大。尤其要注意浮點精度問題寫入前對數(shù)據(jù)做Math.Round(value, 2)既能保證顯示正確也能避免Excel計算時出現(xiàn)0.30000000000000004這種怪異結(jié)果。4.3 大數(shù)據(jù)量寫入從幾秒到幾百毫秒LoadFromDataTable在數(shù)據(jù)量上萬時性能還可以但到10萬行以上也會開始變慢。更高效的做法是直接用二維數(shù)組賦值給整個Rangevar dataArray new object[dt.Rows.Count, dt.Columns.Count]; for (int i 0; i dt.Rows.Count; i) for (int j 0; j dt.Columns.Count; j) dataArray[i, j] dt.Rows[i][j]; worksheet.Cells[2, 1].LoadFromArrays(dataArray);LoadFromArrays是EPPlus里專門用來批量寫二維數(shù)組的方法比逐單元格賦值要快一個量級。如果你的數(shù)據(jù)源不是DataTable而是ListT可以先反射轉(zhuǎn)換成object[,]再走同樣路徑。另外一個經(jīng)驗是如果是一次性導(dǎo)出大數(shù)據(jù)量不要邊寫邊設(shè)置樣式先把所有數(shù)據(jù)寫進去最后統(tǒng)一設(shè)置Range的樣式否則性能會急劇惡化。5. 生成折線圖與曲線圖圖表部分是很多人的盲區(qū)。EPPlus支持很多圖表類型但API有點繞尤其在5.x和6.x之間還有差異。我在封裝的迭代過程中也被坑過幾次下面把核心邏輯說清楚。5.1 圖表必須掛在Drawing上EPPlus里的圖表不是獨立文件而是掛在工作表的Drawings集合里。你可以理解為Excel里的“浮動圖形圖層”圖表和數(shù)據(jù)可以放在同一個Sheet也可以放在單獨的一個Sheet。創(chuàng)建折線圖的典型代碼是var chart worksheet.Drawings.AddChart(chartSales, eChartType.Line); chart.Title.Text 月度銷售趨勢; chart.SetPosition(2, 0, 6, 0); // 左上角位置 chart.SetSize(800, 400); var series chart.Series.Add(worksheet.Cells[B2:B13], worksheet.Cells[A2:A13]); series.Header 銷售額;AddChart方法接受兩個參數(shù)圖表名稱Sheet內(nèi)唯一和圖表類型。eChartType.Line是折線圖eChartType.LineMarkers是帶數(shù)據(jù)標(biāo)記的折線圖。Series.Add的第一個參數(shù)是Y值區(qū)域第二個參數(shù)是X軸類別區(qū)域。這里有個反直覺的坑圖表系列的數(shù)據(jù)源必須指向工作表中實際存在的單元格區(qū)域不能直接傳一個List數(shù)組。也就是說你要畫圖數(shù)據(jù)必須先寫進工作表的某個區(qū)域然后再通過worksheet.Cells[B2:B13]這種方式告訴EPPlus“從哪塊區(qū)域取數(shù)”。所以封裝時我的邏輯是先把數(shù)據(jù)寫到一個隱藏Sheet或者數(shù)據(jù)區(qū)域再創(chuàng)建圖表引用它。畫完之后這個數(shù)據(jù)區(qū)域可以隱藏掉避免用戶看到一堆輔助數(shù)據(jù)。5.2 折線圖和曲線圖的真正區(qū)別很多人以為“折線圖”和“曲線圖”是兩種不同的圖表類型其實在EPPlus里它們都是LineChart。唯一的區(qū)別在于系列有沒有開啟平滑曲線。開啟smooth之后原本的折線會變成圓滑的貝塞爾曲線視覺上更柔和常用于趨勢類展示。具體代碼是在拿到ExcelLineChartSeries之后設(shè)置Series.Smooth truevar lineSeries (ExcelLineChartSeries)chart.Series.Add(rangeY, rangeX); lineSeries.Smooth true; // false就是普通折線圖換句話說我的封裝里加了一個bool smooth參數(shù)內(nèi)部就是把LineChart系列的Smooth屬性設(shè)一下。這里有個細(xì)節(jié)AddChart返回的ExcelChart對象Series.Add返回的是ExcelChartSeries需要把它強制轉(zhuǎn)換成ExcelLineChartSeries才能訪問Smooth。如果類型不匹配說明你創(chuàng)建圖表時用的枚舉類型不對。5.3 圖表參數(shù)的可配置化實際業(yè)務(wù)場景中圖表的標(biāo)題、X軸名稱、Y軸名稱、圖例位置每個項目要求都不一樣。我在封裝里把這些都作為可選參數(shù)暴露出來。例如chart.XAxis.Title.Text 月份; chart.YAxis.Title.Text 金額; chart.Legend.Position eLegendPosition.Right;還有個容易被忽略的地方是網(wǎng)格線。默認(rèn)生成的圖表自帶橫向網(wǎng)格線做趨勢圖還好但如果客戶要求簡潔風(fēng)記得把網(wǎng)格線關(guān)掉chart.YAxis.MajorGridlines.Fill.Color Color.Transparent;圖表位置和大小的設(shè)置也要注意。SetPosition和SetSize在EPPlus里是按像素算的SetPosition(row, rowOffsetPixels, col, colOffsetPixels)表示圖表左上角距離某行某列交點的偏移量。如果你希望圖表完全覆蓋在某幾個固定單元格區(qū)域還得按單元格的寬高估算偏移這個在封裝階段至少要做到“能放對位置、能被用戶拖動微調(diào)”不用追求像素級精確。6. 常見異常與掉坑實錄這一節(jié)是我最想寫的。很多坑網(wǎng)上文檔里根本不提只有實際做了才碰得到。整理成速查表方便你寫代碼的時候?qū)φ铡?.1 LicenseExceptionEPPlus 5的許可證異常這是最常見的異?！，F(xiàn)象是代碼運行到new ExcelPackage()時直接拋LicenseException提示需要設(shè)置LicenseContext。網(wǎng)上很多老教程沒有這一行因為它們在寫4.x版本。解決辦法很簡單ExcelPackage.LicenseContext LicenseContext.NonCommercial;這行要在創(chuàng)建ExcelPackage實例前執(zhí)行。我建議在封裝類的靜態(tài)構(gòu)造函數(shù)里設(shè)置一次而不是在每個方法里重復(fù)寫。如果你用的不是最新包還有一種做法是寫配置文件但靜態(tài)構(gòu)造函數(shù)顯式賦值最直觀排查起來也最快。6.2 生成的文件Excel打開提示損壞這個問題我排查過很久最終發(fā)現(xiàn)原因多種多樣但最常見的有三類。一是文件路徑的擴展名和實際內(nèi)容不一致比如保存的文件擴展名是.xls但內(nèi)容實際是xlsx格式Excel打開時就會提示“文件格式與擴展名不匹配”。二是寫入圖表時chart.Series.Add指向的數(shù)據(jù)區(qū)域不存在或者引用錯誤導(dǎo)致生成的OpenXML內(nèi)容異常。三是保存過程中有異常發(fā)生但沒有正常關(guān)閉文件流文件沒有完整寫入。這個問題的排查思路是用記事本或者解壓工具直接打開生成的xlsx文件看看[Content_Types].xml和xl/charts/目錄下的內(nèi)容是否完整。如果對OpenXML不熟也可以寫一個自動校驗的小邏輯生成后用ExcelPackage重新打開一次文件能打開就說明結(jié)構(gòu)基本沒問題。6.3 圖表不顯示或只有坐標(biāo)軸沒有線出現(xiàn)這種情況九成都是數(shù)據(jù)區(qū)域引錯了。EPPlus的圖表引用單元格區(qū)域時字符串要傳絕對引用比如Sheet1!$B$2:$B$13或者直接用worksheet.Cells[B2:B13]。如果傳成相對引用B2:B13某些版本下不會生效圖表會顯示空白。另外如果數(shù)據(jù)源區(qū)域里包含空單元格折線圖會在空值處斷開。如果需要連續(xù)曲線要么把空值用#N/A代替Excel圖表默認(rèn)忽略#N/A不畫線要么在寫入數(shù)據(jù)時對空值做填充。6.4 性能問題導(dǎo)出10萬行卡死EPPlus雖然性能不錯但如果你用逐單元格組合樣式10萬行能寫到你懷疑人生。我踩過最大的坑是在循環(huán)里給每個單元格設(shè)置邊框和字體結(jié)果導(dǎo)出10000行用了將近3分鐘。后來改成批量設(shè)置Range樣式整個操作縮短到3秒以內(nèi)。所以性能優(yōu)化的核心原則就是能用Range批量操作絕不逐單元格操作。包括樣式、數(shù)字格式、列寬都要合并成一個Range統(tǒng)一設(shè)置。另外如果你的數(shù)據(jù)源是DataTable最好把DataTable中的ColumnName和實際Excel列對應(yīng)關(guān)系先處理好避免寫入時做二次映射否則表格大了之后光是映射關(guān)系就夠你折騰的。6.5 跨平臺部署時的注意事項EPPlus是純托管庫部署到Linux和Docker容器里沒有問題不需要安裝Excel。但有兩點要注意第一在Linux環(huán)境操作高并發(fā)的Excel生成時要注意臨時目錄的權(quán)限EPPlus在寫入大文件時會用到臨時文件/tmp目錄沒權(quán)限就報錯。第二文件路徑分隔符不要硬編碼Windows的\用Path.Combine或/否則在Linux上會找不到文件。7. 封裝庫的后續(xù)擴展思路根據(jù)我這段時間的使用體驗這個封裝庫在實際項目中還可以繼續(xù)演進。目前我新增的一個能力是模板化導(dǎo)出先創(chuàng)建一個帶好樣式、圖表占位、公式的Excel模板文件然后EPPlus打開模板用真實數(shù)據(jù)填充指定位置。這種方式特別適合周報、月報這類固定格式的場景比代碼里寫死樣式要靈活得多前端做好Excel模板后扔給后端填數(shù)效率和美觀度都能兼顧。還有一個方向是支持多Sheet報表。比如一個數(shù)據(jù)分析報告里第一頁放運營匯總數(shù)據(jù)第二頁放明細(xì)第三頁放趨勢圖。目前的封裝單方法處理單Sheet后續(xù)可以考慮增加一個“報表描述對象”把頁面結(jié)構(gòu)、數(shù)據(jù)源、圖表位置統(tǒng)一描述然后一鍵生成整個工作簿。這種改進對調(diào)用方來說幾乎是零學(xué)習(xí)成本。最后再分享一個小技巧因為EPPlus的核心操作都是圍繞ExcelPackage展開的封裝里一定要保證using或者Dispose正確否則文件流不釋放生成完文件還處于占用狀態(tài)后面再讀取就會報“文件被另一個進程使用”。我自己的做法是統(tǒng)一走using塊并且在寫文件之前先判斷目標(biāo)文件是否存在存在則備份重命名避免覆蓋失敗把原文件搞壞。這一套封裝用下來最大的感受就是Excel操作并不難難的是把各種邊界情況都處理好。如果你們項目里也經(jīng)常被Excel需求和圖表需求反復(fù)折騰建議早點做一層這樣的封裝把這篇文章里的幾個坑提前規(guī)避掉能省下不少排查和加班的時間。本文還有配套的精品資源點擊獲取