)
做過Word模板導(dǎo)出功能開發(fā)的人多半都被“插入圖片”這件事卡過。客戶的描述永遠很具體報告生成到第三頁這一段下面必須放質(zhì)檢照片或者一個大表格里某些單元格要貼圖。你翻遍POI的文檔找到addPicture這個方法調(diào)完之后圖片確實進來了位置卻是文檔末尾。今天這篇就專門聊聊“用POI操作Word在指定位置插入圖片”的完整思路、代碼實現(xiàn)和踩坑記錄適合正在做報表導(dǎo)出、合同生成、批量證書打印或者任何用POI碰過Word模板填充的開發(fā)者。1. 別上來就寫代碼先搞清楚圖片在docx里到底存在哪第一次用POI往Word里插圖片的人基本都會走這么一條彎路先new XWPFDocument()然后doc.addPicture(...)圖片確實進去了但永遠在文檔末尾。這不是bug也不是POI故意坑你而是因為docx的物理結(jié)構(gòu)和我們?nèi)粘慦ord時的直覺完全不一樣。一個.docx文件本質(zhì)上是一堆XML打包在一起。正文內(nèi)容放在word/document.xml里結(jié)構(gòu)大致是文檔Document下面是一個BodyBody下面是一排塊級元素最主要的兩種塊是段落w:p和表格w:tbl。每個段落內(nèi)部又有若干Runw:rRun才是真正承載文本的最小單位。一張圖片在XML里不是一個獨立的塊它是掛在某個Run下面的一串Drawing元素。這就是關(guān)鍵點POI里段落XWPFParagraph沒有addPicture方法能插圖片的只有XWPFRun也就是段落里某個Run。所以“指定位置插入圖片”這句話拆開看其實是兩步定位到目標位置對應(yīng)的段落或Run再調(diào)用那個Run上的addPicture。理解了這一層再看XWPFDocument.addPicture為什么沒用就清楚了——它確實也能把圖片加進文檔但它只能新建一個段落并把圖片放進去這個段落被追加在Body最后面。它不是“文檔級”該有的操作更像是一個方便追加的快捷方法。想要往文檔中間、模板某個位置插圖必須自己控制游標和段落。還有一個容易忽略的細節(jié)Word中的Run是一段格式相同的文本。比如你寫“第一段加粗第二段普通”這兩段里就有不同的標簽。圖片掛在某個Run下意味著圖片會和這個Run擁有相同的段落格式、字體設(shè)置。這也是為什么插入圖片后它的縮進、行距、對齊方式經(jīng)常要額外單獨設(shè)置——因為圖片事實上繼承或者部分繼承了Run所在的段落樣式。搞清楚對象模型之后下一個問題自然就來了怎么定位標題里的“指定位置”到底怎么表達給POI2. 定位方案對比索引、文本錨點、書簽到底選哪個“指定位置”說起來簡單但實現(xiàn)時定位方式有幾種選錯后面全是坑。我把常見方案整理了一下按實際體驗排序。定位方式實現(xiàn)難度抗模板改動能力模板可讀性實測推薦度段落索引定位低差模板多一個段落就全錯位差靠猜不推薦文本錨點定位中好只要錨點文字不被刪就行好模板里一眼能看出標記強推書簽定位中高好但POI對書簽的封裝比較繞一般Word里才看得見可以用但不優(yōu)先表格行/單元格定位中取決于具體場景一般特定場景用索引定位是我最早試的方法。寫起來最省事doc.getParagraphs().get(index)拿到段落就往前面插。但壞處非常致命模板只要被編輯過一次哪怕是多空了一行索引全部位移。而且批量插入時前一次插入會改變后續(xù)段落的索引位置得從后往前倒著插調(diào)試起來非常消耗耐心。這個方法只適合那種完全用代碼動態(tài)生成的、結(jié)構(gòu)永遠不變化的文檔不適合模板填充。書簽定位理論上很優(yōu)雅。Word里CtrlShiftF2加個書簽POI里也有XWPFBookmark、getBookmarks()之類的東西。實際試下來書簽要綁定到段落或者Run的XML節(jié)點上定位之后進行操作還得自己轉(zhuǎn)游標代碼繞模板使用者還未必會加書簽。不是不行是性價比低。我最后穩(wěn)定使用的是文本錨點定位。做法很簡單在Word模板里寫一行占位符比如{{IMG}}或者更具體的{{IMG_QUALITY}}、{{IMG_SIGNATURE}}代碼先遍歷所有段落包括表格里的段落找到包含這個標記的段落然后在它前面或后面插入一個帶圖片的新段落。好處是模板長什么樣不影響定位編輯過也最多是標記文字被改視覺上占位符本身對排版影響也小。占位符設(shè)計有兩個小經(jīng)驗。第一標記盡量加雙花括號比如{{IMG}}這和渲染模板的語法一致不容易和正文文字沖突第二每個插入位置用不同的標記名稱而不是復(fù)用同一個{{IMG}}這樣批量插入時不會出現(xiàn)“每次找到的都是第一個標記”的問題。選定文本錨點方案之后剩下的核心就是游標操作了。這也是POI插入圖片最繞、最容易出問題的地方。3. 游標定位法完整實現(xiàn)從依賴到代碼一步步來先說環(huán)境。我用的是Maven工程最常用的POI版本是5.2.3用4.x也差不多但5.x的API更干凈推薦以5.x為準。dependency groupIdorg.apache.poi/groupId artifactIdpoi-ooxml/artifactId version5.2.3/version /dependencypoi-ooxml這個包會把poi、xmlbeans、poi-ooxml-lite等依賴一并帶進來做Word段落、Run、圖片操作已經(jīng)足夠不需要額外引入poi-scratchpad。3.1 先在模板里埋好占位符打開Word模板在需要插入圖片的位置輸入{{IMG_LOGO}}比如公司技術(shù)認證報告 {{IMG_LOGO}} 申請人信息如下……這里的{{IMG_LOGO}}會在運行時被圖片替換掉。模板里這一行可以單獨占一個段落也可以和其他文字混在一起。為了排版省心我建議單獨占一行。3.2 查找錨點段落的核心代碼查找錨點有兩個層面要處理文檔正文段落和表格內(nèi)段落。很多人只寫了doc.getParagraphs()結(jié)果表格里的占位符永遠定位不到這是最常見的坑之一。import org.apache.poi.xwpf.usermodel.*; public class AnchorFinder { /** * 在文檔所有段落含表格單元格中的段落中查找包含指定占位符的段落。 */ public static XWPFParagraph findAnchor(XWPFDocument doc, String placeholder) { // 1. 正文區(qū)段落 for (XWPFParagraph p : doc.getParagraphs()) { if (p.getText() ! null p.getText().contains(placeholder)) { return p; } } // 2. 表格內(nèi)單元格的段落 for (XWPFTable table : doc.getTables()) { for (XWPFTableRow row : table.getRows()) { for (XWPFTableCell cell : row.getTableCells()) { for (XWPFParagraph p : cell.getParagraphs()) { if (p.getText() ! null p.getText().contains(placeholder)) { return p; } } } } } return null; } }這里注意cell.getParagraphs()在POI 5.x返回的是ListXWPFParagraph和正文段落一樣操作沒區(qū)別。3.3 在錨點段落之前插入帶圖片的新段落定位到錨點段落之后最常用的需求是把圖片插到占位符所在位置。以“圖片插在錨點段落之前”為例完整代碼如下import org.apache.poi.util.Units; import org.apache.poi.xwpf.usermodel.*; import org.apache.xmlbeans.XmlCursor; import java.io.FileInputStream; import java.io.InputStream; public class WordImageInserter { /** * 在錨點段落之前插入一個包含圖片的新段落。 */ public static void insertImageBefore(XWPFParagraph anchor, String imagePath, int widthPx, int heightPx) throws Exception { // 關(guān)鍵拿到錨點段落的底層XML游標 XmlCursor cursor anchor.getCTP().newCursor(); // 在游標當前位置插入新段落。游標正好指向錨點段落的開始 // 所以新段落會落在錨點段落之前。 XWPFParagraph imgParagraph anchor.getDocument().insertNewParagraph(cursor); // 讓圖片段落居中視覺效果最穩(wěn) imgParagraph.setAlignment(ParagraphAlignment.CENTER); // 新建Run圖片掛在Run上 XWPFRun run imgParagraph.createRun(); // 根據(jù)文件擴展名判斷圖片類型 int picType getPictureType(imagePath); // addPicture的寬高單位是EMU不是像素這里用Units轉(zhuǎn)換 try (InputStream is new FileInputStream(imagePath)) { run.addPicture(is, picType, imagePath, Units.toEMU(widthPx), Units.toEMU(heightPx)); } // 插入完成之后把占位符從錨點段落里清掉 clearPlaceholder(anchor, {{IMG_LOGO}}); } private static int getPictureType(String imagePath) { String lower imagePath.toLowerCase(); if (lower.endsWith(.png)) return XWPFDocument.PICTURE_TYPE_PNG; if (lower.endsWith(.jpg) || lower.endsWith(.jpeg)) return XWPFDocument.PICTURE_TYPE_JPEG; if (lower.endsWith(.emf)) return XWPFDocument.PICTURE_TYPE_EMF; if (lower.endsWith(.wmf)) return XWPFDocument.PICTURE_TYPE_WMF; if (lower.endsWith(.dib)) return XWPFDocument.PICTURE_TYPE_DIB; throw new IllegalArgumentException(不支持的圖片格式: imagePath); } private static void clearPlaceholder(XWPFParagraph paragraph, String placeholder) { StringBuilder sb new StringBuilder(); for (XWPFRun run : paragraph.getRuns()) { sb.append(run.getText(0) null ? : run.getText(0)); } if (sb.indexOf(placeholder) 0) { String newText sb.toString().replace(placeholder, ); ListXWPFRun runs paragraph.getRuns(); if (!runs.isEmpty()) { // 把清理后的文本放到第一個Run其他Run清空 runs.get(0).setText(newText, 0); for (int i 1; i runs.size(); i) { runs.get(i).setText(, 0); } } } } }這段代碼看起來不長但幾個關(guān)鍵點不解釋清楚換一個場景就抓瞎。XmlCursor是Apache XMLBeans提供的游標它可以直接在底層XML節(jié)點上做前后移動和插入操作。anchor.getCTP().newCursor()返回的游標位置我實測下來是在錨點段落w:p的開始標簽處。doc.insertNewParagraph(cursor)這個方法是XWPFDocument提供的專門用來在指定XML位置創(chuàng)建段落它和普通的createParagraph()不同后者只會追加到Body尾部前者才是真正的“指哪打哪”。寬高參數(shù)是另一個容易翻車的地方。addPicture方法簽名里的最后兩個參數(shù)是EMUEnglish Metric Unit不是像素。Word內(nèi)部繪圖單位是EMU1英寸等于914400 EMU1像素大概是9525 EMU。如果直接拿像素數(shù)字傳進去圖片會小得幾乎看不見或者大得離譜。Units.toEMU()就是干這個換算的沒這個工具類只能自己乘9525。clearPlaceholder做的事是把占位符文本從錨點段落里抹掉。為什么要單獨做這一步因為占位符留在模板里第一次運行時被圖片替換了但如果不清掉第二次生成時同一個模板還會再匹配到它就會出現(xiàn)重復(fù)插入。3.4 想插到錨點段落之后怎么辦很多需求是“在某某段落后邊加一張圖”比如“以上為申請信息下方為簽字照片”。這種場景下圖片要插在錨點段落后面做法是先把游標往后移動到錨點段落的結(jié)束標簽位置XmlCursor cursor anchor.getCTP().newCursor(); cursor.toEndToken(); XWPFParagraph imgParagraph anchor.getDocument().insertNewParagraph(cursor); // 后續(xù)邏輯同上創(chuàng)建Run、addPicture、清占位符toEndToken()把游標移動到當前元素結(jié)束標簽的位置此時調(diào)用insertNewParagraph新段落會落在錨點段落之后。這個和插入到前面剛好對稱。不過要提醒一句不同版本XMLBeans對游標位置“在結(jié)束標簽上”和“在結(jié)束標簽后”的語義行為略有差異萬一插出來位置不對在toEndToken()之后補一行cursor.toNextToken()再插入通常就能糾正。如果你的場景比較復(fù)雜圖既要插在錨點前又要插在錨點后或者一時拿不準方向最穩(wěn)妥的做法是模板里放一對占位符比如{{IMG_START}}和{{IMG_END}}圖片先插到{{IMG_END}}之前再把兩個占位符都清掉。這樣無論版本怎么變位置始終可控。4. 圖片大小、對齊和樣式繼承插進去不難插得好看才難圖片能插進去了不代表完事了。我見過很多初學(xué)者把圖插進去之后一打開Word圖片要么大得超出頁面要么歪在頁面邊上要么和周圍文字擠在一起版式完全沒法看。這一節(jié)把排版相關(guān)的細節(jié)一次說透。4.1 按比例縮放圖片而不是寫死寬高最樸素的寫法是直接傳固定像素值比如Units.toEMU(300)、Units.toEMU(200)。問題在于原圖可能是4000x3000的大圖傳300x200會變形原圖是800x600傳300x200又會模糊。正確做法是先讀圖片原始尺寸按目標寬度等比計算高度。import javax.imageio.ImageIO; import java.awt.image.BufferedImage; import java.io.File; public static int[] calcScaledSize(String imagePath, int maxWidthPx, int maxHeightPx) throws Exception { BufferedImage img ImageIO.read(new File(imagePath)); int width img.getWidth(); int height img.getHeight(); double scale Math.min( (double) maxWidthPx / width, (double) maxHeightPx / height ); if (scale 1) { return new int[]{width, height}; } return new int[]{(int)(width * scale), (int)(height * scale)}; }至于最大寬高設(shè)多少要結(jié)合頁面實際可用寬度來算。A4紙寬度是21厘米默認頁邊距左右各3.17厘米也就是說文字區(qū)的可用寬度大概是14.65厘米。如果你希望圖片鋪滿整個可用寬度14.65厘米換算成像素大概是14.65 / 2.54 * 96 ≈ 553像素。我一般取550作為最大寬度高度限制在350-400左右基本不會超出頁面。4.2 對齊方式單獨設(shè)置圖片段落既然是獨立的段落它的對齊方式就由段落屬性控制。居中是最常見的需求imgParagraph.setAlignment(ParagraphAlignment.CENTER);左右對齊也是同理。要注意的是如果錨點段落原來的對齊方式是左對齊而你新插入的圖片段落沒有顯式設(shè)置那么圖片會沿用段落默認樣式可能是左對齊也可能是兩端對齊整體看起來就很隨機。所以每次插入都顯式setAlignment不要依賴默認值。4.3 圖片段落繼承錨點段落的樣式模板里不同段落的字體、行距、縮進可能不同。如果圖片段落是全新建的“裸段落”它的樣式可能和其他段落格格不入。最簡單的解法是把錨點段落的段落屬性拷貝過來import org.openxmlformats.schemas.wordprocessingml.x2006.main.CTP; import org.openxmlformats.schemas.wordprocessingml.x2006.main.CTPPr; CTP anchorCtp anchor.getCTP(); CTP imgCtp imgParagraph.getCTP(); if (anchorCtp.isSetPPr()) { imgCtp.setPPr((CTPPr) anchorCtp.getPPr().copy()); }這樣做的好處是行距、縮進、段前段后間距全都和錨點段落保持一致。如果你連字體格式都希望圖片Run繼承可以再拷貝Run的RPr不過圖片本身沒有字體影響不大。4.4 圖片和周圍文字之間的間距圖片段落默認的行距可能會讓圖片和上下文字貼得很近讀起來很擠?？梢栽趫D片段落的setSpacingBefore和setSpacingAfter上稍微加點:imgParagraph.setSpacingBefore(200); imgParagraph.setSpacingAfter(200);這里的單位是緹twips1磅等于20緹200緹就是10磅視覺上比較舒服。具體大小看實際效果微調(diào)。5. 實測踩坑記錄這份避坑清單能省你大半天時間這部分整理了我在實際項目中遇到過的坑有些坑可能浪費了你幾個小時也不一定想到。每一條都是從報錯到排錯到解決完整走過來的不是從官方文檔摘抄的。5.1 占位符被Word拆到多個Run里replace不掉這是第一個真正惡心到我的坑。模板里手寫的{{IMG_LOGO}}存盤之后Word不一定把整串文字放在同一個Run里可能{{在一個RunIMG_LOGO在另一個Run}}又在第三個Run。你用paragraph.getText()能拿到完整文本一replace卻發(fā)現(xiàn)段落里根本沒變化因為你要替換的內(nèi)容跨越了Run邊界。clearPlaceholder里我用了“拼完整文本、改第一個Run、清空其余Run”的策略就是為了應(yīng)對這種情況。如果替換完發(fā)現(xiàn)錨點段落里還殘留半個大括號的文本多半是遍歷時遺漏了哪個Run的getText(0)返回null處理時判空就行。5.2 只查正文段落表格里的占位符永遠找不到上文代碼里已經(jīng)處理了這個問題但我在實際開發(fā)中見到不少同事只寫了doc.getParagraphs()。文檔一旦涉及表格比如申請表、報價單占位符放在表格單元格里查正文段落就找不到程序直接往下走圖片就全堆到了文檔末尾。表面看是“插入位置不對”本質(zhì)是定位邏輯根本沒覆蓋到表格。排查這類問題先確認錨點是不是在表格里再決定遍歷方式。5.3 重復(fù)插入同一個占位符被命中多次這不是死循環(huán)但效果類似。假設(shè)模板里有好幾處{{IMG}}你調(diào)用findAnchor每次都從頭遍歷那么返回的永遠是第一個{{IMG}}段落。第一張圖插入后會清理占位符但第二次查找時第一個段落已經(jīng)沒有標記了可代碼是從頭再查的結(jié)果還是會找到第二個位置之前的第一個{{IMG}}——如果只插入一次還好循環(huán)插入就會錯亂。我的解法是模板里的占位符一律帶編號{{IMG_1}}、{{IMG_2}}、{{IMG_3}}。這樣每個位置有唯一標識查找時按編號精確匹配。如果要插入同一張圖到多個位置就顯式多次調(diào)用每次傳不同的占位符邏輯清晰也不容易錯。5.4 圖片類型判斷錯誤生成的docx打不開addPicture里的第二個參數(shù)必須和實際圖片字節(jié)格式匹配。之前出現(xiàn)過一次文件擴展名是.png但實際內(nèi)容被改成了JPEG編碼getPictureType判斷成了PNG結(jié)果打開生成的Word時報“無法讀取圖片文件已損壞”。嚴格來說這不是判斷邏輯的問題而是圖片文件的真實格式問題。穩(wěn)妥做法是用ImageIO.read()解析圖片通過ImageIO.getImageReaders()獲取真實格式再映射到POI的圖片類型常量。如果項目里圖片來源可控都是程序生成的PNG用擴展名判斷就夠了如果圖片是外部上傳的建議按真實格式判斷。5.5 生成的文件提示“要修復(fù)”的問題排查思路如果你插入后生成的docx在Word里提示“發(fā)現(xiàn)無法讀取的內(nèi)容是否嘗試修復(fù)”別慌九成是XML結(jié)構(gòu)出了問題。我的排查順序是先把生成的文件用解壓工具解壓打開word/document.xml直接看新插入段落前后的XML標簽是否閉合正常。段落嵌套層級不正確是最常見原因。檢查是不是游標位置操作出了問題比如在Body層級的段落外又插入了孤立節(jié)點或者插入到了一個表格單元格的非法位置。單獨跑一個最小復(fù)現(xiàn)用例只插入一張圖片、只操作一個占位符看能不能復(fù)現(xiàn)。能復(fù)現(xiàn)問題就在插入邏輯不能復(fù)現(xiàn)說明是模板本身有問題。另外所有插入操作完成后記得調(diào)用一次doc.write()刷新內(nèi)部結(jié)構(gòu)再關(guān)閉輸出流。不要用doc.getDocument().toString()直接拼字符串查問題那個是底層XML的toString和實際寫入文件的內(nèi)容不完全一樣。5.6 圖片流資源泄漏addPicture需要傳入InputStream如果你用裸寫new FileInputStream()不關(guān)流批量生成文檔時容易出現(xiàn)文件句柄耗盡或文件被占用刪除不掉。上面代碼全用了try-with-resources這個習慣一定要帶上。尤其是在循環(huán)內(nèi)插入幾十張圖片的場景不關(guān)流的后果會非常明顯。6. 批量插入場景的性能優(yōu)化與模板復(fù)用最后一個常見場景一份文檔里要插入幾十張圖比如產(chǎn)品目錄、員工證件照集合、訂單截圖列表。按前面的單張插入方法每張圖都從頭遍歷整篇文檔找錨點復(fù)雜度是O(n*m)文檔段落很多時會明顯變慢。這個環(huán)節(jié)給幾個優(yōu)化思路。6.1 一次性收集錨點避免反復(fù)全表掃描不管插入多少張圖先做一次遍歷把占位符和對應(yīng)的圖片路徑配對收集起來然后再統(tǒng)一處理?？梢杂靡粋€小結(jié)構(gòu)class ImageAnchor { String placeholder; String imagePath; XWPFParagraph anchor; }遍歷時只掃一遍所有段落含表格把每個占位符對應(yīng)的段落引用存下來。這樣后續(xù)插入直接拿對象操作不需要反復(fù)從頭找。插入新段落時注意底層XML是動態(tài)變化的但你已經(jīng)拿到的XWPFParagraph對象引用依然有效因為它是基于CTP包裝的不會因為插入新段落而失效。6.2 “可反復(fù)運行”的冪等處理真實業(yè)務(wù)里往往要求同一個模板重復(fù)生成多份文檔比如批量套打證書。如果模板里的占位符被第一次運行改掉第二次想再復(fù)用同一份模板文檔就會發(fā)現(xiàn)占位符沒了。我的做法是每次生成前都從原始模板重新加載一份副本占位符永遠以原始模板為準。生成流程變成三條固定步驟new XWPFDocument(templateInputStream)加載原始模板查占位符、插入圖片、清理占位符輸出寫入新的docx文件模板文件只讀絕不寫入。這樣無論跑多少次模板永遠是干凈的。6.3 線程安全的取舍XWPFDocument不是線程安全的同一個模板對象多線程操作會互相干擾。如果并發(fā)量高要么每個線程各自加載一份模板副本要么用線程池串行化處理同一模板的生成任務(wù)。最省事的做法是把模板內(nèi)容readAllBytes()讀進字節(jié)數(shù)組每次new XWPFDocument(new ByteArrayInputStream(bytes))生成新實例。模板不大時開銷可以忽略換來的是完全隔離不用加鎖。6.4 不要邊遍歷邊改結(jié)構(gòu)的深層原因有些操作在循環(huán)內(nèi)直接用doc.getParagraphs()并同時調(diào)用insertNewParagraph這背后的隱患不只是索引偏移XMLBeans的游標遍歷邏輯在節(jié)點增刪過程中有時會拋出ConcurrentModificationException有時會靜默跳過新插入節(jié)點導(dǎo)致插入順序錯亂。把“收集”和“操作”分成兩階段不僅是性能考慮更是規(guī)避這類詭異問題的根本手段。我在批量插入場景里統(tǒng)一遵守一個規(guī)則收集階段只return段落引用操作階段只使用已收集到的引用做插入絕不在遍歷的同時修改文檔結(jié)構(gòu)。這套思路跑下來上百張圖片的文檔生成也穩(wěn)定。如果你也要做類似功能建議先把這個原則定下來再寫業(yè)務(wù)代碼。 POI操作Word指定位置插入圖片：占位符與游標定位實戰(zhàn)
做過Word模板導(dǎo)出功能開發(fā)的人多半都被“插入圖片”這件事卡過。客戶的描述永遠很具體報告生成到第三頁這一段下面必須放質(zhì)檢照片或者一個大表格里某些單元格要貼圖。你翻遍POI的文檔找到addPicture這個方法調(diào)完之后圖片確實進來了位置卻是文檔末尾。今天這篇就專門聊聊“用POI操作Word在指定位置插入圖片”的完整思路、代碼實現(xiàn)和踩坑記錄適合正在做報表導(dǎo)出、合同生成、批量證書打印或者任何用POI碰過Word模板填充的開發(fā)者。1. 別上來就寫代碼先搞清楚圖片在docx里到底存在哪第一次用POI往Word里插圖片的人基本都會走這么一條彎路先new XWPFDocument()然后doc.addPicture(...)圖片確實進去了但永遠在文檔末尾。這不是bug也不是POI故意坑你而是因為docx的物理結(jié)構(gòu)和我們?nèi)粘慦ord時的直覺完全不一樣。一個.docx文件本質(zhì)上是一堆XML打包在一起。正文內(nèi)容放在word/document.xml里結(jié)構(gòu)大致是文檔Document下面是一個BodyBody下面是一排塊級元素最主要的兩種塊是段落w:p和表格w:tbl。每個段落內(nèi)部又有若干Runw:rRun才是真正承載文本的最小單位。一張圖片在XML里不是一個獨立的塊它是掛在某個Run下面的一串Drawing元素。這就是關(guān)鍵點POI里段落XWPFParagraph沒有addPicture方法能插圖片的只有XWPFRun也就是段落里某個Run。所以“指定位置插入圖片”這句話拆開看其實是兩步定位到目標位置對應(yīng)的段落或Run再調(diào)用那個Run上的addPicture。理解了這一層再看XWPFDocument.addPicture為什么沒用就清楚了——它確實也能把圖片加進文檔但它只能新建一個段落并把圖片放進去這個段落被追加在Body最后面。它不是“文檔級”該有的操作更像是一個方便追加的快捷方法。想要往文檔中間、模板某個位置插圖必須自己控制游標和段落。還有一個容易忽略的細節(jié)Word中的Run是一段格式相同的文本。比如你寫“第一段加粗第二段普通”這兩段里就有不同的標簽。圖片掛在某個Run下意味著圖片會和這個Run擁有相同的段落格式、字體設(shè)置。這也是為什么插入圖片后它的縮進、行距、對齊方式經(jīng)常要額外單獨設(shè)置——因為圖片事實上繼承或者部分繼承了Run所在的段落樣式。搞清楚對象模型之后下一個問題自然就來了怎么定位標題里的“指定位置”到底怎么表達給POI2. 定位方案對比索引、文本錨點、書簽到底選哪個“指定位置”說起來簡單但實現(xiàn)時定位方式有幾種選錯后面全是坑。我把常見方案整理了一下按實際體驗排序。定位方式實現(xiàn)難度抗模板改動能力模板可讀性實測推薦度段落索引定位低差模板多一個段落就全錯位差靠猜不推薦文本錨點定位中好只要錨點文字不被刪就行好模板里一眼能看出標記強推書簽定位中高好但POI對書簽的封裝比較繞一般Word里才看得見可以用但不優(yōu)先表格行/單元格定位中取決于具體場景一般特定場景用索引定位是我最早試的方法。寫起來最省事doc.getParagraphs().get(index)拿到段落就往前面插。但壞處非常致命模板只要被編輯過一次哪怕是多空了一行索引全部位移。而且批量插入時前一次插入會改變后續(xù)段落的索引位置得從后往前倒著插調(diào)試起來非常消耗耐心。這個方法只適合那種完全用代碼動態(tài)生成的、結(jié)構(gòu)永遠不變化的文檔不適合模板填充。書簽定位理論上很優(yōu)雅。Word里CtrlShiftF2加個書簽POI里也有XWPFBookmark、getBookmarks()之類的東西。實際試下來書簽要綁定到段落或者Run的XML節(jié)點上定位之后進行操作還得自己轉(zhuǎn)游標代碼繞模板使用者還未必會加書簽。不是不行是性價比低。我最后穩(wěn)定使用的是文本錨點定位。做法很簡單在Word模板里寫一行占位符比如{{IMG}}或者更具體的{{IMG_QUALITY}}、{{IMG_SIGNATURE}}代碼先遍歷所有段落包括表格里的段落找到包含這個標記的段落然后在它前面或后面插入一個帶圖片的新段落。好處是模板長什么樣不影響定位編輯過也最多是標記文字被改視覺上占位符本身對排版影響也小。占位符設(shè)計有兩個小經(jīng)驗。第一標記盡量加雙花括號比如{{IMG}}這和渲染模板的語法一致不容易和正文文字沖突第二每個插入位置用不同的標記名稱而不是復(fù)用同一個{{IMG}}這樣批量插入時不會出現(xiàn)“每次找到的都是第一個標記”的問題。選定文本錨點方案之后剩下的核心就是游標操作了。這也是POI插入圖片最繞、最容易出問題的地方。3. 游標定位法完整實現(xiàn)從依賴到代碼一步步來先說環(huán)境。我用的是Maven工程最常用的POI版本是5.2.3用4.x也差不多但5.x的API更干凈推薦以5.x為準。dependency groupIdorg.apache.poi/groupId artifactIdpoi-ooxml/artifactId version5.2.3/version /dependencypoi-ooxml這個包會把poi、xmlbeans、poi-ooxml-lite等依賴一并帶進來做Word段落、Run、圖片操作已經(jīng)足夠不需要額外引入poi-scratchpad。3.1 先在模板里埋好占位符打開Word模板在需要插入圖片的位置輸入{{IMG_LOGO}}比如公司技術(shù)認證報告 {{IMG_LOGO}} 申請人信息如下……這里的{{IMG_LOGO}}會在運行時被圖片替換掉。模板里這一行可以單獨占一個段落也可以和其他文字混在一起。為了排版省心我建議單獨占一行。3.2 查找錨點段落的核心代碼查找錨點有兩個層面要處理文檔正文段落和表格內(nèi)段落。很多人只寫了doc.getParagraphs()結(jié)果表格里的占位符永遠定位不到這是最常見的坑之一。import org.apache.poi.xwpf.usermodel.*; public class AnchorFinder { /** * 在文檔所有段落含表格單元格中的段落中查找包含指定占位符的段落。 */ public static XWPFParagraph findAnchor(XWPFDocument doc, String placeholder) { // 1. 正文區(qū)段落 for (XWPFParagraph p : doc.getParagraphs()) { if (p.getText() ! null p.getText().contains(placeholder)) { return p; } } // 2. 表格內(nèi)單元格的段落 for (XWPFTable table : doc.getTables()) { for (XWPFTableRow row : table.getRows()) { for (XWPFTableCell cell : row.getTableCells()) { for (XWPFParagraph p : cell.getParagraphs()) { if (p.getText() ! null p.getText().contains(placeholder)) { return p; } } } } } return null; } }這里注意cell.getParagraphs()在POI 5.x返回的是ListXWPFParagraph和正文段落一樣操作沒區(qū)別。3.3 在錨點段落之前插入帶圖片的新段落定位到錨點段落之后最常用的需求是把圖片插到占位符所在位置。以“圖片插在錨點段落之前”為例完整代碼如下import org.apache.poi.util.Units; import org.apache.poi.xwpf.usermodel.*; import org.apache.xmlbeans.XmlCursor; import java.io.FileInputStream; import java.io.InputStream; public class WordImageInserter { /** * 在錨點段落之前插入一個包含圖片的新段落。 */ public static void insertImageBefore(XWPFParagraph anchor, String imagePath, int widthPx, int heightPx) throws Exception { // 關(guān)鍵拿到錨點段落的底層XML游標 XmlCursor cursor anchor.getCTP().newCursor(); // 在游標當前位置插入新段落。游標正好指向錨點段落的開始 // 所以新段落會落在錨點段落之前。 XWPFParagraph imgParagraph anchor.getDocument().insertNewParagraph(cursor); // 讓圖片段落居中視覺效果最穩(wěn) imgParagraph.setAlignment(ParagraphAlignment.CENTER); // 新建Run圖片掛在Run上 XWPFRun run imgParagraph.createRun(); // 根據(jù)文件擴展名判斷圖片類型 int picType getPictureType(imagePath); // addPicture的寬高單位是EMU不是像素這里用Units轉(zhuǎn)換 try (InputStream is new FileInputStream(imagePath)) { run.addPicture(is, picType, imagePath, Units.toEMU(widthPx), Units.toEMU(heightPx)); } // 插入完成之后把占位符從錨點段落里清掉 clearPlaceholder(anchor, {{IMG_LOGO}}); } private static int getPictureType(String imagePath) { String lower imagePath.toLowerCase(); if (lower.endsWith(.png)) return XWPFDocument.PICTURE_TYPE_PNG; if (lower.endsWith(.jpg) || lower.endsWith(.jpeg)) return XWPFDocument.PICTURE_TYPE_JPEG; if (lower.endsWith(.emf)) return XWPFDocument.PICTURE_TYPE_EMF; if (lower.endsWith(.wmf)) return XWPFDocument.PICTURE_TYPE_WMF; if (lower.endsWith(.dib)) return XWPFDocument.PICTURE_TYPE_DIB; throw new IllegalArgumentException(不支持的圖片格式: imagePath); } private static void clearPlaceholder(XWPFParagraph paragraph, String placeholder) { StringBuilder sb new StringBuilder(); for (XWPFRun run : paragraph.getRuns()) { sb.append(run.getText(0) null ? : run.getText(0)); } if (sb.indexOf(placeholder) 0) { String newText sb.toString().replace(placeholder, ); ListXWPFRun runs paragraph.getRuns(); if (!runs.isEmpty()) { // 把清理后的文本放到第一個Run其他Run清空 runs.get(0).setText(newText, 0); for (int i 1; i runs.size(); i) { runs.get(i).setText(, 0); } } } } }這段代碼看起來不長但幾個關(guān)鍵點不解釋清楚換一個場景就抓瞎。XmlCursor是Apache XMLBeans提供的游標它可以直接在底層XML節(jié)點上做前后移動和插入操作。anchor.getCTP().newCursor()返回的游標位置我實測下來是在錨點段落w:p的開始標簽處。doc.insertNewParagraph(cursor)這個方法是XWPFDocument提供的專門用來在指定XML位置創(chuàng)建段落它和普通的createParagraph()不同后者只會追加到Body尾部前者才是真正的“指哪打哪”。寬高參數(shù)是另一個容易翻車的地方。addPicture方法簽名里的最后兩個參數(shù)是EMUEnglish Metric Unit不是像素。Word內(nèi)部繪圖單位是EMU1英寸等于914400 EMU1像素大概是9525 EMU。如果直接拿像素數(shù)字傳進去圖片會小得幾乎看不見或者大得離譜。Units.toEMU()就是干這個換算的沒這個工具類只能自己乘9525。clearPlaceholder做的事是把占位符文本從錨點段落里抹掉。為什么要單獨做這一步因為占位符留在模板里第一次運行時被圖片替換了但如果不清掉第二次生成時同一個模板還會再匹配到它就會出現(xiàn)重復(fù)插入。3.4 想插到錨點段落之后怎么辦很多需求是“在某某段落后邊加一張圖”比如“以上為申請信息下方為簽字照片”。這種場景下圖片要插在錨點段落后面做法是先把游標往后移動到錨點段落的結(jié)束標簽位置XmlCursor cursor anchor.getCTP().newCursor(); cursor.toEndToken(); XWPFParagraph imgParagraph anchor.getDocument().insertNewParagraph(cursor); // 后續(xù)邏輯同上創(chuàng)建Run、addPicture、清占位符toEndToken()把游標移動到當前元素結(jié)束標簽的位置此時調(diào)用insertNewParagraph新段落會落在錨點段落之后。這個和插入到前面剛好對稱。不過要提醒一句不同版本XMLBeans對游標位置“在結(jié)束標簽上”和“在結(jié)束標簽后”的語義行為略有差異萬一插出來位置不對在toEndToken()之后補一行cursor.toNextToken()再插入通常就能糾正。如果你的場景比較復(fù)雜圖既要插在錨點前又要插在錨點后或者一時拿不準方向最穩(wěn)妥的做法是模板里放一對占位符比如{{IMG_START}}和{{IMG_END}}圖片先插到{{IMG_END}}之前再把兩個占位符都清掉。這樣無論版本怎么變位置始終可控。4. 圖片大小、對齊和樣式繼承插進去不難插得好看才難圖片能插進去了不代表完事了。我見過很多初學(xué)者把圖插進去之后一打開Word圖片要么大得超出頁面要么歪在頁面邊上要么和周圍文字擠在一起版式完全沒法看。這一節(jié)把排版相關(guān)的細節(jié)一次說透。4.1 按比例縮放圖片而不是寫死寬高最樸素的寫法是直接傳固定像素值比如Units.toEMU(300)、Units.toEMU(200)。問題在于原圖可能是4000x3000的大圖傳300x200會變形原圖是800x600傳300x200又會模糊。正確做法是先讀圖片原始尺寸按目標寬度等比計算高度。import javax.imageio.ImageIO; import java.awt.image.BufferedImage; import java.io.File; public static int[] calcScaledSize(String imagePath, int maxWidthPx, int maxHeightPx) throws Exception { BufferedImage img ImageIO.read(new File(imagePath)); int width img.getWidth(); int height img.getHeight(); double scale Math.min( (double) maxWidthPx / width, (double) maxHeightPx / height ); if (scale 1) { return new int[]{width, height}; } return new int[]{(int)(width * scale), (int)(height * scale)}; }至于最大寬高設(shè)多少要結(jié)合頁面實際可用寬度來算。A4紙寬度是21厘米默認頁邊距左右各3.17厘米也就是說文字區(qū)的可用寬度大概是14.65厘米。如果你希望圖片鋪滿整個可用寬度14.65厘米換算成像素大概是14.65 / 2.54 * 96 ≈ 553像素。我一般取550作為最大寬度高度限制在350-400左右基本不會超出頁面。4.2 對齊方式單獨設(shè)置圖片段落既然是獨立的段落它的對齊方式就由段落屬性控制。居中是最常見的需求imgParagraph.setAlignment(ParagraphAlignment.CENTER);左右對齊也是同理。要注意的是如果錨點段落原來的對齊方式是左對齊而你新插入的圖片段落沒有顯式設(shè)置那么圖片會沿用段落默認樣式可能是左對齊也可能是兩端對齊整體看起來就很隨機。所以每次插入都顯式setAlignment不要依賴默認值。4.3 圖片段落繼承錨點段落的樣式模板里不同段落的字體、行距、縮進可能不同。如果圖片段落是全新建的“裸段落”它的樣式可能和其他段落格格不入。最簡單的解法是把錨點段落的段落屬性拷貝過來import org.openxmlformats.schemas.wordprocessingml.x2006.main.CTP; import org.openxmlformats.schemas.wordprocessingml.x2006.main.CTPPr; CTP anchorCtp anchor.getCTP(); CTP imgCtp imgParagraph.getCTP(); if (anchorCtp.isSetPPr()) { imgCtp.setPPr((CTPPr) anchorCtp.getPPr().copy()); }這樣做的好處是行距、縮進、段前段后間距全都和錨點段落保持一致。如果你連字體格式都希望圖片Run繼承可以再拷貝Run的RPr不過圖片本身沒有字體影響不大。4.4 圖片和周圍文字之間的間距圖片段落默認的行距可能會讓圖片和上下文字貼得很近讀起來很擠?？梢栽趫D片段落的setSpacingBefore和setSpacingAfter上稍微加點:imgParagraph.setSpacingBefore(200); imgParagraph.setSpacingAfter(200);這里的單位是緹twips1磅等于20緹200緹就是10磅視覺上比較舒服。具體大小看實際效果微調(diào)。5. 實測踩坑記錄這份避坑清單能省你大半天時間這部分整理了我在實際項目中遇到過的坑有些坑可能浪費了你幾個小時也不一定想到。每一條都是從報錯到排錯到解決完整走過來的不是從官方文檔摘抄的。5.1 占位符被Word拆到多個Run里replace不掉這是第一個真正惡心到我的坑。模板里手寫的{{IMG_LOGO}}存盤之后Word不一定把整串文字放在同一個Run里可能{{在一個RunIMG_LOGO在另一個Run}}又在第三個Run。你用paragraph.getText()能拿到完整文本一replace卻發(fā)現(xiàn)段落里根本沒變化因為你要替換的內(nèi)容跨越了Run邊界。clearPlaceholder里我用了“拼完整文本、改第一個Run、清空其余Run”的策略就是為了應(yīng)對這種情況。如果替換完發(fā)現(xiàn)錨點段落里還殘留半個大括號的文本多半是遍歷時遺漏了哪個Run的getText(0)返回null處理時判空就行。5.2 只查正文段落表格里的占位符永遠找不到上文代碼里已經(jīng)處理了這個問題但我在實際開發(fā)中見到不少同事只寫了doc.getParagraphs()。文檔一旦涉及表格比如申請表、報價單占位符放在表格單元格里查正文段落就找不到程序直接往下走圖片就全堆到了文檔末尾。表面看是“插入位置不對”本質(zhì)是定位邏輯根本沒覆蓋到表格。排查這類問題先確認錨點是不是在表格里再決定遍歷方式。5.3 重復(fù)插入同一個占位符被命中多次這不是死循環(huán)但效果類似。假設(shè)模板里有好幾處{{IMG}}你調(diào)用findAnchor每次都從頭遍歷那么返回的永遠是第一個{{IMG}}段落。第一張圖插入后會清理占位符但第二次查找時第一個段落已經(jīng)沒有標記了可代碼是從頭再查的結(jié)果還是會找到第二個位置之前的第一個{{IMG}}——如果只插入一次還好循環(huán)插入就會錯亂。我的解法是模板里的占位符一律帶編號{{IMG_1}}、{{IMG_2}}、{{IMG_3}}。這樣每個位置有唯一標識查找時按編號精確匹配。如果要插入同一張圖到多個位置就顯式多次調(diào)用每次傳不同的占位符邏輯清晰也不容易錯。5.4 圖片類型判斷錯誤生成的docx打不開addPicture里的第二個參數(shù)必須和實際圖片字節(jié)格式匹配。之前出現(xiàn)過一次文件擴展名是.png但實際內(nèi)容被改成了JPEG編碼getPictureType判斷成了PNG結(jié)果打開生成的Word時報“無法讀取圖片文件已損壞”。嚴格來說這不是判斷邏輯的問題而是圖片文件的真實格式問題。穩(wěn)妥做法是用ImageIO.read()解析圖片通過ImageIO.getImageReaders()獲取真實格式再映射到POI的圖片類型常量。如果項目里圖片來源可控都是程序生成的PNG用擴展名判斷就夠了如果圖片是外部上傳的建議按真實格式判斷。5.5 生成的文件提示“要修復(fù)”的問題排查思路如果你插入后生成的docx在Word里提示“發(fā)現(xiàn)無法讀取的內(nèi)容是否嘗試修復(fù)”別慌九成是XML結(jié)構(gòu)出了問題。我的排查順序是先把生成的文件用解壓工具解壓打開word/document.xml直接看新插入段落前后的XML標簽是否閉合正常。段落嵌套層級不正確是最常見原因。檢查是不是游標位置操作出了問題比如在Body層級的段落外又插入了孤立節(jié)點或者插入到了一個表格單元格的非法位置。單獨跑一個最小復(fù)現(xiàn)用例只插入一張圖片、只操作一個占位符看能不能復(fù)現(xiàn)。能復(fù)現(xiàn)問題就在插入邏輯不能復(fù)現(xiàn)說明是模板本身有問題。另外所有插入操作完成后記得調(diào)用一次doc.write()刷新內(nèi)部結(jié)構(gòu)再關(guān)閉輸出流。不要用doc.getDocument().toString()直接拼字符串查問題那個是底層XML的toString和實際寫入文件的內(nèi)容不完全一樣。5.6 圖片流資源泄漏addPicture需要傳入InputStream如果你用裸寫new FileInputStream()不關(guān)流批量生成文檔時容易出現(xiàn)文件句柄耗盡或文件被占用刪除不掉。上面代碼全用了try-with-resources這個習慣一定要帶上。尤其是在循環(huán)內(nèi)插入幾十張圖片的場景不關(guān)流的后果會非常明顯。6. 批量插入場景的性能優(yōu)化與模板復(fù)用最后一個常見場景一份文檔里要插入幾十張圖比如產(chǎn)品目錄、員工證件照集合、訂單截圖列表。按前面的單張插入方法每張圖都從頭遍歷整篇文檔找錨點復(fù)雜度是O(n*m)文檔段落很多時會明顯變慢。這個環(huán)節(jié)給幾個優(yōu)化思路。6.1 一次性收集錨點避免反復(fù)全表掃描不管插入多少張圖先做一次遍歷把占位符和對應(yīng)的圖片路徑配對收集起來然后再統(tǒng)一處理?？梢杂靡粋€小結(jié)構(gòu)class ImageAnchor { String placeholder; String imagePath; XWPFParagraph anchor; }遍歷時只掃一遍所有段落含表格把每個占位符對應(yīng)的段落引用存下來。這樣后續(xù)插入直接拿對象操作不需要反復(fù)從頭找。插入新段落時注意底層XML是動態(tài)變化的但你已經(jīng)拿到的XWPFParagraph對象引用依然有效因為它是基于CTP包裝的不會因為插入新段落而失效。6.2 “可反復(fù)運行”的冪等處理真實業(yè)務(wù)里往往要求同一個模板重復(fù)生成多份文檔比如批量套打證書。如果模板里的占位符被第一次運行改掉第二次想再復(fù)用同一份模板文檔就會發(fā)現(xiàn)占位符沒了。我的做法是每次生成前都從原始模板重新加載一份副本占位符永遠以原始模板為準。生成流程變成三條固定步驟new XWPFDocument(templateInputStream)加載原始模板查占位符、插入圖片、清理占位符輸出寫入新的docx文件模板文件只讀絕不寫入。這樣無論跑多少次模板永遠是干凈的。6.3 線程安全的取舍XWPFDocument不是線程安全的同一個模板對象多線程操作會互相干擾。如果并發(fā)量高要么每個線程各自加載一份模板副本要么用線程池串行化處理同一模板的生成任務(wù)。最省事的做法是把模板內(nèi)容readAllBytes()讀進字節(jié)數(shù)組每次new XWPFDocument(new ByteArrayInputStream(bytes))生成新實例。模板不大時開銷可以忽略換來的是完全隔離不用加鎖。6.4 不要邊遍歷邊改結(jié)構(gòu)的深層原因有些操作在循環(huán)內(nèi)直接用doc.getParagraphs()并同時調(diào)用insertNewParagraph這背后的隱患不只是索引偏移XMLBeans的游標遍歷邏輯在節(jié)點增刪過程中有時會拋出ConcurrentModificationException有時會靜默跳過新插入節(jié)點導(dǎo)致插入順序錯亂。把“收集”和“操作”分成兩階段不僅是性能考慮更是規(guī)避這類詭異問題的根本手段。我在批量插入場景里統(tǒng)一遵守一個規(guī)則收集階段只return段落引用操作階段只使用已收集到的引用做插入絕不在遍歷的同時修改文檔結(jié)構(gòu)。這套思路跑下來上百張圖片的文檔生成也穩(wěn)定。如果你也要做類似功能建議先把這個原則定下來再寫業(yè)務(wù)代碼。