目war包打包部署全解析：從目錄結(jié)構(gòu)到實(shí)戰(zhàn)命令)
1. 從一個(gè)部署翻車現(xiàn)場(chǎng)說起為什么war包操作值得單獨(dú)聊剛?cè)胄心菚?huì)兒我接手過一個(gè)老項(xiàng)目的部署任務(wù)。開發(fā)同學(xué)丟給我一個(gè)壓縮包說“扔到服務(wù)器上跑起來就行”。我打開一看里面是一堆散落的class文件、JSP頁面、XML配置和幾個(gè)jar依賴目錄結(jié)構(gòu)亂七八糟。當(dāng)時(shí)我天真地以為直接丟進(jìn)應(yīng)用服務(wù)器目錄就能跑結(jié)果啟動(dòng)報(bào)錯(cuò)、類找不到、靜態(tài)資源404折騰了整整一個(gè)下午。后來才知道人家給我的其實(shí)是一個(gè)被錯(cuò)誤解壓過的war包——原本應(yīng)該是一個(gè)完整的、結(jié)構(gòu)規(guī)范的歸檔文件結(jié)果被當(dāng)成普通壓縮包解開了元數(shù)據(jù)全丟了。這件事讓我意識(shí)到war包這個(gè)東西雖然看起來只是“一個(gè)壓縮文件”但它背后牽扯的是Java Web項(xiàng)目從開發(fā)到部署的完整鏈路。很多人會(huì)寫代碼、會(huì)配框架但一到打包和部署環(huán)節(jié)就卡殼。尤其是現(xiàn)在前后端分離、容器化部署越來越普遍war包似乎有點(diǎn)“過時(shí)”了但你去看看銀行、政務(wù)、傳統(tǒng)企業(yè)內(nèi)部的Java項(xiàng)目war包依然是絕對(duì)主力。Tomcat、Jetty、WebLogic、WebSphere這些應(yīng)用服務(wù)器默認(rèn)吃的就是war包。所以這篇內(nèi)容我打算把war包這件事從頭到尾講透。不管你是剛接觸Java Web的新手還是工作幾年但一直沒搞明白打包細(xì)節(jié)的老手看完之后至少能做到三件事第一知道war包里面到底裝了什么第二能自己用命令行或者構(gòu)建工具打出規(guī)范的war包第三遇到解壓、壓縮、部署報(bào)錯(cuò)時(shí)知道從哪里下手排查。全文會(huì)圍繞實(shí)際操作展開命令都是可以直接復(fù)制去用的參數(shù)我也會(huì)解釋清楚為什么這么寫。2. war包到底是什么拆開看它的骨架和血肉2.1 從jar到war一字之差用途天差地別Java世界里最常見的歸檔格式是jar全稱Java Archive。jar本質(zhì)上就是一個(gè)zip壓縮包里面裝著編譯后的class文件、資源文件和一份META-INF/MANIFEST.MF清單。你可以用jar命令創(chuàng)建也可以用任何zip工具打開。jar的定位是“通用的Java類庫或可執(zhí)行程序歸檔”一個(gè)工具類庫可以打成jar一個(gè)Spring Boot應(yīng)用也可以打成可執(zhí)行jar。war則是Web Archive的縮寫專門為Java Web應(yīng)用設(shè)計(jì)。它同樣基于zip格式但多了一套約定俗成的目錄結(jié)構(gòu)。這套結(jié)構(gòu)不是隨便定的而是Servlet規(guī)范里明確要求的。應(yīng)用服務(wù)器拿到war包之后會(huì)按照這套結(jié)構(gòu)去加載類、初始化Servlet、映射URL、處理靜態(tài)資源。換句話說war包是給“Web容器”看的容器認(rèn)這個(gè)格式才能把你的應(yīng)用跑起來。我經(jīng)常用這樣一個(gè)類比來解釋jar像是一個(gè)工具箱里面裝著各種零件你拿它去修東西war則像是一套已經(jīng)按圖紙組裝好的家具搬進(jìn)房子里就能用。工具箱誰都能用但家具得放在合適的房子里——這個(gè)房子就是Tomcat這類Web容器。2.2 war包的標(biāo)準(zhǔn)目錄結(jié)構(gòu)逐層拆解一個(gè)規(guī)范的war包解壓之后根目錄下通常長(zhǎng)這樣myapp.war ├── index.jsp ├── login.html ├── css/ │ └── style.css ├── js/ │ └── app.js ├── images/ │ └── logo.png ├── META-INF/ │ └── MANIFEST.MF └── WEB-INF/ ├── web.xml ├── classes/ │ └── com/example/... ├── lib/ │ └── spring-webmvc-5.3.x.jar └── ...根目錄下的JSP、HTML、CSS、JS、圖片這些屬于“公開資源”瀏覽器可以直接通過URL訪問。比如http://host/myapp/css/style.css就能拿到樣式文件。這部分和普通靜態(tài)網(wǎng)站沒區(qū)別。真正關(guān)鍵的是WEB-INF目錄。這個(gè)目錄的名字是固定的大小寫敏感而且它下面的內(nèi)容瀏覽器無法直接訪問。你沒法通過URL直接請(qǐng)求WEB-INF/classes/com/example/MyServlet.class這是Servlet規(guī)范強(qiáng)制保護(hù)的安全機(jī)制。WEB-INF里面有三個(gè)核心子目錄classes/存放編譯后的class文件和資源文件比如properties、xml。包路徑要和class的package聲明一致比如com.example.controller.UserServlet編譯后應(yīng)該放在WEB-INF/classes/com/example/controller/UserServlet.class。lib/存放應(yīng)用依賴的第三方j(luò)ar包。Tomcat啟動(dòng)時(shí)會(huì)把這個(gè)目錄下所有jar加入應(yīng)用的類加載器。注意servlet-api.jar和jsp-api.jar不要放進(jìn)來因?yàn)槿萜髯约禾峁┝朔胚M(jìn)去反而可能引起沖突。web.xml部署描述符雖然Servlet 3.0之后可以用注解替代大部分配置但很多老項(xiàng)目依然依賴它來配置Servlet、Filter、Listener、歡迎頁、錯(cuò)誤頁等。META-INF/MANIFEST.MF里可以寫一些元信息比如Class-Path指定額外依賴Web-ContextPath在某些容器里指定上下文路徑。不過大多數(shù)情況下這個(gè)文件不需要手動(dòng)改構(gòu)建工具會(huì)自動(dòng)生成。2.3 為什么容器認(rèn)war而不認(rèn)普通zip有人可能會(huì)問既然war就是zip那我把項(xiàng)目文件夾直接壓縮成zip改個(gè)后綴叫war行不行答案是技術(shù)上容器可能能解壓但大概率跑不起來。原因在于容器在部署war時(shí)不只是解壓它還會(huì)做一系列校驗(yàn)和初始化動(dòng)作。比如檢查WEB-INF/web.xml是否存在且格式正確掃描WEB-INF/classes和WEB-INF/lib下的類根據(jù)注解或配置注冊(cè)Servlet和Filter。如果目錄結(jié)構(gòu)不對(duì)比如class文件放在了根目錄而不是WEB-INF/classes容器就找不到類啟動(dòng)直接報(bào)ClassNotFoundException。另外war包的壓縮方式也有講究。雖然zip支持多種壓縮算法但Java的jar工具默認(rèn)使用deflate兼容性最好。如果你用某些工具壓成zip64或者用了不常見的壓縮級(jí)別老版本容器可能解壓失敗。所以“手動(dòng)改后綴”這種做法偶爾能蒙對(duì)但絕對(duì)不是可靠方案。3. 打包成war的幾種主流方式與選型邏輯3.1 命令行打包jar命令的實(shí)戰(zhàn)用法最原始的方式是用JDK自帶的jar命令。假設(shè)你的項(xiàng)目已經(jīng)編譯好目錄結(jié)構(gòu)如下build/ ├── index.jsp ├── css/ ├── js/ └── WEB-INF/ ├── web.xml ├── classes/ └── lib/進(jìn)入build目錄執(zhí)行jar -cvf myapp.war .參數(shù)解釋-c表示創(chuàng)建新歸檔-v表示輸出詳細(xì)過程-f指定歸檔文件名。最后的.表示把當(dāng)前目錄下所有內(nèi)容打包進(jìn)去。執(zhí)行完之后當(dāng)前目錄下會(huì)生成myapp.war。這里有個(gè)細(xì)節(jié)要注意jar命令默認(rèn)會(huì)把當(dāng)前目錄的路徑也帶進(jìn)去。如果你在build目錄下執(zhí)行jar -cvf myapp.war .解壓后根目錄就是build里面的內(nèi)容這是對(duì)的。但如果你執(zhí)行jar -cvf myapp.war build/解壓后第一層會(huì)是build/目錄容器就找不到WEB-INF了。所以一定要進(jìn)入正確的目錄再執(zhí)行。還有一種情況是只打包部分文件。比如你不想把源碼目錄打進(jìn)去可以用-C參數(shù)切換目錄jar -cvf myapp.war -C build/ .這表示切換到build目錄然后把該目錄下所有內(nèi)容打包。效果和先cd再執(zhí)行一樣但更適合寫在腳本里。提示用jar命令打包時(shí)如果WEB-INF/lib下有大量jar打包過程可能比較慢?？梢约?0參數(shù)禁用壓縮只做歸檔這樣打包快、解壓也快但war包體積會(huì)變大。生產(chǎn)環(huán)境一般還是用默認(rèn)壓縮。3.2 Maven打包pom.xml里的關(guān)鍵配置現(xiàn)在絕大多數(shù)Java Web項(xiàng)目用Maven管理。Maven打包war的核心是pom.xml里的packaging標(biāo)簽packagingwar/packaging這一行決定了mvn package執(zhí)行時(shí)生成的是war而不是jar。但光有這一行還不夠還需要配置maven-war-plugin。雖然Maven有默認(rèn)的war插件但默認(rèn)配置有時(shí)候不滿足需求比如你想排除某些文件、指定web.xml路徑、或者處理沒有web.xml的情況。一個(gè)典型的配置如下build finalNamemyapp/finalName plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version3.3.2/version configuration warSourceDirectorysrc/main/webapp/warSourceDirectory webXmlsrc/main/webapp/WEB-INF/web.xml/webXml failOnMissingWebXmlfalse/failOnMissingWebXml /configuration /plugin /plugins /buildfinalName決定生成的war包名字比如上面配置生成的是myapp.war。warSourceDirectory指定Web資源目錄默認(rèn)就是src/main/webapp。failOnMissingWebXml設(shè)為false表示沒有web.xml也不報(bào)錯(cuò)適合純注解配置的項(xiàng)目。Maven的war插件在打包時(shí)會(huì)做幾件事把src/main/webapp下的內(nèi)容復(fù)制到war根目錄把src/main/resources下的文件復(fù)制到WEB-INF/classes把編譯后的class文件放到WEB-INF/classes把依賴jar放到WEB-INF/lib。注意provided作用域的依賴不會(huì)被打進(jìn)WEB-INF/lib比如servlet-api因?yàn)槿萜鲿?huì)提供。執(zhí)行打包命令mvn clean package如果只想打包不跑測(cè)試mvn clean package -DskipTests生成的war包在target/目錄下。3.3 Gradle打包build.gradle的war插件Gradle項(xiàng)目打包war需要應(yīng)用war插件plugins { id war }然后配置war任務(wù)war { archiveFileName myapp.war from src/main/webapp webXml file(src/main/webapp/WEB-INF/web.xml) }Gradle的war插件會(huì)自動(dòng)處理依賴implementation的依賴會(huì)打進(jìn)WEB-INF/libprovidedCompile或compileOnly的依賴不會(huì)打進(jìn)去。執(zhí)行g(shù)radle war生成的war在build/libs/目錄下。3.4 三種方式怎么選看項(xiàng)目階段和團(tuán)隊(duì)習(xí)慣命令行jar方式適合快速驗(yàn)證、臨時(shí)打包或者寫自動(dòng)化腳本時(shí)用。它的優(yōu)點(diǎn)是零依賴只要有JDK就能跑缺點(diǎn)是容易出錯(cuò)目錄結(jié)構(gòu)、文件排除都要手動(dòng)控制。Maven方式適合大多數(shù)傳統(tǒng)Java Web項(xiàng)目尤其是團(tuán)隊(duì)協(xié)作、需要依賴管理的場(chǎng)景。它的生命周期管理很成熟clean package一條命令搞定編譯、測(cè)試、打包。缺點(diǎn)是pom配置有時(shí)候比較繁瑣插件版本沖突也讓人頭疼。Gradle方式適合追求構(gòu)建速度和靈活性的團(tuán)隊(duì)。Gradle的增量構(gòu)建比Maven快腳本也更簡(jiǎn)潔。但Gradle的學(xué)習(xí)曲線比Maven陡老項(xiàng)目遷移成本高。我個(gè)人的經(jīng)驗(yàn)是新項(xiàng)目如果團(tuán)隊(duì)沒有特別偏好用Maven最穩(wěn)資料多、踩坑少老項(xiàng)目如果已經(jīng)是Gradle就繼續(xù)用Gradle沒必要為了打包換構(gòu)建工具。4. war包解壓與壓縮命令全解析4.1 解壓war包unzip和jar -xvf怎么選war包解壓最常用的命令是unzipunzip myapp.war -d myapp_extracted-d指定解壓目標(biāo)目錄。如果不加-d會(huì)解壓到當(dāng)前目錄而且如果當(dāng)前目錄已經(jīng)有同名文件夾可能會(huì)覆蓋或提示。我習(xí)慣總是加-d指定一個(gè)干凈的目錄避免污染當(dāng)前工作區(qū)。unzip的優(yōu)點(diǎn)是快、通用Linux和macOS自帶Windows裝了Git Bash也能用。但它有個(gè)小問題如果war包里的文件名包含中文或特殊字符unzip可能會(huì)亂碼。這是因?yàn)閦ip格式對(duì)文件名編碼沒有統(tǒng)一標(biāo)準(zhǔn)Windows壓縮的工具可能用GBKLinux默認(rèn)用UTF-8。遇到亂碼可以加-O參數(shù)指定編碼unzip -O GBK myapp.war -d myapp_extracted另一個(gè)選擇是用JDK自帶的jar命令jar -xvf myapp.war-x表示解壓-v輸出詳細(xì)過程-f指定文件。這個(gè)命令會(huì)解壓到當(dāng)前目錄沒有-d參數(shù)。它的好處是編碼處理跟Java一致一般不會(huì)亂碼缺點(diǎn)是會(huì)覆蓋同名文件且不提示而且解壓速度比unzip慢一些。注意解壓war包之前先確認(rèn)目標(biāo)目錄是空的或者不存在。如果目錄里已經(jīng)有舊版本的文件解壓后新舊文件混在一起可能導(dǎo)致類沖突或配置覆蓋。我一般會(huì)先rm -rf myapp_extracted再解壓。4.2 重新壓縮zip命令的坑與正確姿勢(shì)有時(shí)候你需要修改war包里的某個(gè)配置文件比如改數(shù)據(jù)庫連接串然后重新壓縮。這時(shí)候不能用zip -r myapp.war myapp_extracted/因?yàn)檫@樣會(huì)把myapp_extracted這個(gè)目錄名也打進(jìn)去導(dǎo)致war包根目錄多了一層。正確的做法是進(jìn)入解壓后的目錄然后打包c(diǎn)d myapp_extracted zip -r ../myapp_new.war .-r表示遞歸包含子目錄.表示當(dāng)前目錄下所有內(nèi)容../myapp_new.war指定輸出到上一級(jí)目錄。這樣打出來的war包根目錄就是WEB-INF、css這些結(jié)構(gòu)正確。還有一個(gè)細(xì)節(jié)zip默認(rèn)會(huì)保留文件的相對(duì)路徑但不會(huì)保留Unix權(quán)限位。對(duì)于war包來說權(quán)限位一般不重要因?yàn)槿萜髯x取文件不依賴執(zhí)行權(quán)限。但如果你在Linux上部署確保war包本身有讀權(quán)限就行。另外如果原war包里有META-INF/MANIFEST.MF重新壓縮時(shí)不要漏掉。有些構(gòu)建工具生成的MANIFEST.MF里包含版本信息或類路徑配置丟了可能導(dǎo)致容器啟動(dòng)異常。4.3 查看war包內(nèi)容不解壓也能看有時(shí)候你只想確認(rèn)war包里有沒有某個(gè)文件不想解壓整個(gè)包。可以用unzip -l myapp.war-l列出歸檔內(nèi)容顯示文件名、大小、壓縮比、日期。輸出類似Archive: myapp.war Length Date Time Name --------- ---------- ----- ---- 0 2024-01-15 10:30 META-INF/ 123 2024-01-15 10:30 META-INF/MANIFEST.MF 0 2024-01-15 10:30 WEB-INF/ 456 2024-01-15 10:30 WEB-INF/web.xml ...如果只想看某個(gè)文件的內(nèi)容可以用unzip -p myapp.war WEB-INF/web.xml-p表示解壓到標(biāo)準(zhǔn)輸出不寫文件。這個(gè)命令在排查配置問題時(shí)特別有用比如確認(rèn)web.xml里的servlet映射對(duì)不對(duì)。jar命令也有類似功能jar -tvf myapp.war-t列出內(nèi)容-v詳細(xì)-f指定文件。輸出格式和unzip -l略有不同但信息一樣。4.4 增量更新war包里的單個(gè)文件生產(chǎn)環(huán)境有時(shí)候只需要改一個(gè)配置文件重新打整個(gè)war包太重。可以用jar或zip做增量更新。用jar更新jar -uvf myapp.war WEB-INF/classes/application.properties-u表示更新會(huì)把指定文件替換進(jìn)war包。注意文件路徑必須和war包內(nèi)的路徑一致。這個(gè)命令要求當(dāng)前目錄下存在WEB-INF/classes/application.properties這個(gè)文件。用zip更新zip myapp.war WEB-INF/classes/application.propertieszip命令如果發(fā)現(xiàn)歸檔里已有同名文件會(huì)直接替換。這個(gè)操作比jar -u更直觀但同樣要注意路徑匹配。提示增量更新雖然方便但容易導(dǎo)致war包內(nèi)文件版本不一致。比如你更新了class文件但忘了更新對(duì)應(yīng)的配置文件就可能出現(xiàn)詭異問題。我的建議是生產(chǎn)環(huán)境盡量用完整包替換增量更新只用于緊急修復(fù)且更新后要記錄變更內(nèi)容。5. 從源碼到war一個(gè)完整項(xiàng)目的打包實(shí)操記錄5.1 項(xiàng)目結(jié)構(gòu)與編譯準(zhǔn)備假設(shè)我們有一個(gè)簡(jiǎn)單的Java Web項(xiàng)目目錄結(jié)構(gòu)如下mywebapp/ ├── pom.xml └── src/ └── main/ ├── java/ │ └── com/example/ │ └── HelloServlet.java ├── resources/ │ └── application.properties └── webapp/ ├── index.jsp └── WEB-INF/ └── web.xmlHelloServlet.java內(nèi)容package com.example; import javax.servlet.http.*; import java.io.IOException; public class HelloServlet extends HttpServlet { Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException { resp.setContentType(text/plain); resp.getWriter().write(Hello from war package!); } }web.xml內(nèi)容?xml version1.0 encodingUTF-8? web-app xmlnshttp://xmlns.jcp.org/xml/ns/javaee xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd version4.0 servlet servlet-namehello/servlet-name servlet-classcom.example.HelloServlet/servlet-class /servlet servlet-mapping servlet-namehello/servlet-name url-pattern/hello/url-pattern /servlet-mapping /web-apppom.xml關(guān)鍵部分groupIdcom.example/groupId artifactIdmywebapp/artifactId version1.0.0/version packagingwar/packaging dependencies dependency groupIdjavax.servlet/groupId artifactIdjavax.servlet-api/artifactId version4.0.1/version scopeprovided/scope /dependency /dependencies build finalNamemywebapp/finalName plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version3.3.2/version configuration failOnMissingWebXmlfalse/failOnMissingWebXml /configuration /plugin /plugins /build5.2 執(zhí)行打包并驗(yàn)證產(chǎn)物在項(xiàng)目根目錄執(zhí)行mvn clean package控制臺(tái)會(huì)輸出編譯、測(cè)試、打包的過程。最后看到[INFO] Building war: /path/to/mywebapp/target/mywebapp.war [INFO] BUILD SUCCESS進(jìn)入target目錄確認(rèn)war包存在ls -lh target/mywebapp.war然后用unzip -l檢查內(nèi)容unzip -l target/mywebapp.war應(yīng)該能看到WEB-INF/classes/com/example/HelloServlet.class、WEB-INF/web.xml、index.jsp等文件。如果WEB-INF/lib下沒有servlet-api.jar說明provided作用域生效了這是正確的。5.3 部署到Tomcat并驗(yàn)證訪問把war包復(fù)制到Tomcat的webapps目錄cp target/mywebapp.war $TOMCAT_HOME/webapps/啟動(dòng)Tomcat$TOMCAT_HOME/bin/startup.shTomcat會(huì)自動(dòng)解壓war包生成webapps/mywebapp/目錄。訪問http://localhost:8080/mywebapp/hello如果看到“Hello from war package!”說明打包和部署都成功了。這里有個(gè)細(xì)節(jié)Tomcat默認(rèn)的上下文路徑就是war包的文件名去掉.war后綴。所以mywebapp.war部署后訪問路徑是/mywebapp。如果想改成根路徑/可以把war包改名為ROOT.war但這樣會(huì)覆蓋Tomcat默認(rèn)的ROOT應(yīng)用一般不建議。5.4 打包參數(shù)調(diào)優(yōu)與體積控制war包體積過大是常見問題。一個(gè)簡(jiǎn)單的Web應(yīng)用如果依賴了幾十個(gè)jarwar包可能上百M(fèi)B。傳輸慢、部署慢、容器啟動(dòng)也慢。我一般從幾個(gè)方面控制體積第一檢查依賴作用域。provided的依賴不會(huì)打進(jìn)去比如servlet-api、jsp-api、tomcat相關(guān)的jar。如果發(fā)現(xiàn)這些出現(xiàn)在WEB-INF/lib里說明作用域配錯(cuò)了。第二排除不必要的傳遞依賴。Maven的依賴樹可以用mvn dependency:tree查看找到重復(fù)或不需要的依賴用exclusions排除。第三壓縮靜態(tài)資源。CSS、JS、圖片可以用工具壓縮后再放進(jìn)webapp目錄。雖然war包本身會(huì)壓縮但壓縮后的靜態(tài)資源能進(jìn)一步減小體積。第四考慮把大文件放到外部存儲(chǔ)。比如用戶上傳的圖片、視頻不要打進(jìn)war包而是放到獨(dú)立的文件服務(wù)器或?qū)ο蟠鎯?chǔ)war包里只保留訪問路徑。6. 常見報(bào)錯(cuò)與排查技巧實(shí)錄6.1 啟動(dòng)報(bào)ClassNotFoundException的幾種可能這是部署war包時(shí)最常見的錯(cuò)誤?？刂婆_(tái)輸出類似java.lang.ClassNotFoundException: com.example.HelloServlet排查思路按優(yōu)先級(jí)排列第一確認(rèn)class文件在不在正確位置。解壓war包檢查WEB-INF/classes/com/example/HelloServlet.class是否存在。如果class文件在根目錄或者WEB-INF下但不在classes里容器就找不到。第二確認(rèn)包名和目錄結(jié)構(gòu)一致。com.example.HelloServlet的class文件必須在WEB-INF/classes/com/example/目錄下。如果編譯時(shí)包聲明是com.example但文件被放到了WEB-INF/classes/根目錄也會(huì)報(bào)錯(cuò)。第三確認(rèn)依賴jar是否完整。如果HelloServlet引用了某個(gè)第三方類而那個(gè)jar不在WEB-INF/lib里也會(huì)報(bào)ClassNotFoundException但錯(cuò)誤信息里會(huì)是那個(gè)第三方類的名字。這時(shí)候檢查pom.xml里對(duì)應(yīng)依賴的scope是不是provided或test改成默認(rèn)的compile重新打包。第四檢查是否有重復(fù)類沖突。如果WEB-INF/classes和WEB-INF/lib里的某個(gè)jar包含同名類容器加載順序可能導(dǎo)致版本不一致。用unzip -l列出所有jar搜索沖突的類名。6.2 404錯(cuò)誤的定位方法部署后訪問URL返回404說明容器收到了請(qǐng)求但沒找到對(duì)應(yīng)的Servlet或靜態(tài)資源。排查步驟先確認(rèn)上下文路徑對(duì)不對(duì)。Tomcat的上下文路徑默認(rèn)是war包文件名。如果war包叫mywebapp.war訪問路徑應(yīng)該是/mywebapp/hello不是/hello?？梢栽赥omcat的conf/server.xml里配置Context的path屬性或者在conf/Catalina/localhost/下建一個(gè)XML文件指定路徑。再確認(rèn)Servlet映射對(duì)不對(duì)。檢查web.xml里的url-pattern或者注解WebServlet(/hello)。注意大小寫敏感/Hello和/hello是不同的路徑。然后確認(rèn)靜態(tài)資源位置。如果訪問的是JSP或HTML確認(rèn)文件在war包根目錄下而不是在WEB-INF里面。WEB-INF下的資源瀏覽器無法直接訪問。最后看Tomcat日志。logs/catalina.out或logs/localhost.log里通常會(huì)有詳細(xì)錯(cuò)誤信息比如“No mapping found for HTTP request with URI”能直接定位到問題。6.3 中文亂碼與編碼問題war包里的中文文件比如JSP頁面、properties文件如果編碼不對(duì)部署后可能顯示亂碼。根源在于zip格式對(duì)文件名編碼沒有統(tǒng)一標(biāo)準(zhǔn)以及Java讀取文件時(shí)的默認(rèn)編碼。對(duì)于文件名亂碼打包時(shí)盡量用UTF-8編碼。Maven的war插件默認(rèn)用項(xiàng)目編碼可以在pom.xml里設(shè)置properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties對(duì)于文件內(nèi)容亂碼JSP頁面頂部加% page contentTypetext/html;charsetUTF-8 languagejava %properties文件在Java 9之前默認(rèn)用ISO-8859-1讀取中文需要轉(zhuǎn)成Unicode轉(zhuǎn)義。Java 9之后可以用UTF-8但需要確認(rèn)運(yùn)行環(huán)境。6.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決方式ClassNotFoundExceptionclass文件位置不對(duì)解壓war檢查WEB-INF/classes調(diào)整打包目錄結(jié)構(gòu)NoClassDefFoundError依賴jar缺失檢查WEB-INF/lib補(bǔ)充依賴或改scope404 Not Found上下文路徑錯(cuò)誤確認(rèn)war包名和訪問URL修改war包名或配置Context404 Not FoundServlet映射錯(cuò)誤檢查web.xml或注解修正url-pattern中文亂碼編碼不一致檢查文件編碼和頁面聲明統(tǒng)一用UTF-8啟動(dòng)慢war包過大查看WEB-INF/lib大小排除無用依賴內(nèi)存溢出重復(fù)加載類檢查lib下是否有容器提供的jar移除servlet-api等靜態(tài)資源404文件在WEB-INF下檢查文件位置移到war根目錄提示排查war包問題時(shí)養(yǎng)成先解壓看目錄結(jié)構(gòu)的習(xí)慣。很多問題看一眼目錄就能定位比翻日志快得多。7. 一些容易忽略的細(xì)節(jié)和我的個(gè)人習(xí)慣打包war包這件事說難不難但細(xì)節(jié)特別多。我踩過的坑包括在錯(cuò)誤目錄執(zhí)行jar命令導(dǎo)致多了一層目錄用zip重新打包時(shí)忘了排除.DS_Store文件Maven打包時(shí)provided依賴沒配對(duì)導(dǎo)致容器里出現(xiàn)兩個(gè)版本的servlet-api。這些問題的共同點(diǎn)是報(bào)錯(cuò)信息往往不直接指向根因需要你對(duì)war包的結(jié)構(gòu)和容器的加載機(jī)制有清晰的認(rèn)識(shí)。我現(xiàn)在養(yǎng)成的習(xí)慣是每次打包后先用unzip -l看一眼文件列表確認(rèn)WEB-INF/classes和WEB-INF/lib都在沒有多余的系統(tǒng)文件。然后本地Tomcat部署一次訪問幾個(gè)關(guān)鍵URL確認(rèn)沒問題再上傳到服務(wù)器。多花兩分鐘檢查能省掉后面半小時(shí)的排查。另外如果你的項(xiàng)目還在用JSP注意JSP文件在war包里的位置。JSP放在根目錄可以直接訪問放在WEB-INF下只能通過Servlet轉(zhuǎn)發(fā)訪問。有些框架會(huì)把JSP放在WEB-INF/jsp/下這是為了強(qiáng)制走控制器避免直接訪問。打包時(shí)不要漏掉這些文件。最后分享一個(gè)小技巧如果你不確定某個(gè)文件應(yīng)該放在war包的哪個(gè)位置可以找一個(gè)能正常運(yùn)行的war包解壓后對(duì)照它的目錄結(jié)構(gòu)。這是最快的學(xué)習(xí)方式比看文檔直觀得多。 Java Web項(xiàng)目war包打包部署全解析：從目錄結(jié)構(gòu)到實(shí)戰(zhàn)命令
1. 從一個(gè)部署翻車現(xiàn)場(chǎng)說起為什么war包操作值得單獨(dú)聊剛?cè)胄心菚?huì)兒我接手過一個(gè)老項(xiàng)目的部署任務(wù)。開發(fā)同學(xué)丟給我一個(gè)壓縮包說“扔到服務(wù)器上跑起來就行”。我打開一看里面是一堆散落的class文件、JSP頁面、XML配置和幾個(gè)jar依賴目錄結(jié)構(gòu)亂七八糟。當(dāng)時(shí)我天真地以為直接丟進(jìn)應(yīng)用服務(wù)器目錄就能跑結(jié)果啟動(dòng)報(bào)錯(cuò)、類找不到、靜態(tài)資源404折騰了整整一個(gè)下午。后來才知道人家給我的其實(shí)是一個(gè)被錯(cuò)誤解壓過的war包——原本應(yīng)該是一個(gè)完整的、結(jié)構(gòu)規(guī)范的歸檔文件結(jié)果被當(dāng)成普通壓縮包解開了元數(shù)據(jù)全丟了。這件事讓我意識(shí)到war包這個(gè)東西雖然看起來只是“一個(gè)壓縮文件”但它背后牽扯的是Java Web項(xiàng)目從開發(fā)到部署的完整鏈路。很多人會(huì)寫代碼、會(huì)配框架但一到打包和部署環(huán)節(jié)就卡殼。尤其是現(xiàn)在前后端分離、容器化部署越來越普遍war包似乎有點(diǎn)“過時(shí)”了但你去看看銀行、政務(wù)、傳統(tǒng)企業(yè)內(nèi)部的Java項(xiàng)目war包依然是絕對(duì)主力。Tomcat、Jetty、WebLogic、WebSphere這些應(yīng)用服務(wù)器默認(rèn)吃的就是war包。所以這篇內(nèi)容我打算把war包這件事從頭到尾講透。不管你是剛接觸Java Web的新手還是工作幾年但一直沒搞明白打包細(xì)節(jié)的老手看完之后至少能做到三件事第一知道war包里面到底裝了什么第二能自己用命令行或者構(gòu)建工具打出規(guī)范的war包第三遇到解壓、壓縮、部署報(bào)錯(cuò)時(shí)知道從哪里下手排查。全文會(huì)圍繞實(shí)際操作展開命令都是可以直接復(fù)制去用的參數(shù)我也會(huì)解釋清楚為什么這么寫。2. war包到底是什么拆開看它的骨架和血肉2.1 從jar到war一字之差用途天差地別Java世界里最常見的歸檔格式是jar全稱Java Archive。jar本質(zhì)上就是一個(gè)zip壓縮包里面裝著編譯后的class文件、資源文件和一份META-INF/MANIFEST.MF清單。你可以用jar命令創(chuàng)建也可以用任何zip工具打開。jar的定位是“通用的Java類庫或可執(zhí)行程序歸檔”一個(gè)工具類庫可以打成jar一個(gè)Spring Boot應(yīng)用也可以打成可執(zhí)行jar。war則是Web Archive的縮寫專門為Java Web應(yīng)用設(shè)計(jì)。它同樣基于zip格式但多了一套約定俗成的目錄結(jié)構(gòu)。這套結(jié)構(gòu)不是隨便定的而是Servlet規(guī)范里明確要求的。應(yīng)用服務(wù)器拿到war包之后會(huì)按照這套結(jié)構(gòu)去加載類、初始化Servlet、映射URL、處理靜態(tài)資源。換句話說war包是給“Web容器”看的容器認(rèn)這個(gè)格式才能把你的應(yīng)用跑起來。我經(jīng)常用這樣一個(gè)類比來解釋jar像是一個(gè)工具箱里面裝著各種零件你拿它去修東西war則像是一套已經(jīng)按圖紙組裝好的家具搬進(jìn)房子里就能用。工具箱誰都能用但家具得放在合適的房子里——這個(gè)房子就是Tomcat這類Web容器。2.2 war包的標(biāo)準(zhǔn)目錄結(jié)構(gòu)逐層拆解一個(gè)規(guī)范的war包解壓之后根目錄下通常長(zhǎng)這樣myapp.war ├── index.jsp ├── login.html ├── css/ │ └── style.css ├── js/ │ └── app.js ├── images/ │ └── logo.png ├── META-INF/ │ └── MANIFEST.MF └── WEB-INF/ ├── web.xml ├── classes/ │ └── com/example/... ├── lib/ │ └── spring-webmvc-5.3.x.jar └── ...根目錄下的JSP、HTML、CSS、JS、圖片這些屬于“公開資源”瀏覽器可以直接通過URL訪問。比如http://host/myapp/css/style.css就能拿到樣式文件。這部分和普通靜態(tài)網(wǎng)站沒區(qū)別。真正關(guān)鍵的是WEB-INF目錄。這個(gè)目錄的名字是固定的大小寫敏感而且它下面的內(nèi)容瀏覽器無法直接訪問。你沒法通過URL直接請(qǐng)求WEB-INF/classes/com/example/MyServlet.class這是Servlet規(guī)范強(qiáng)制保護(hù)的安全機(jī)制。WEB-INF里面有三個(gè)核心子目錄classes/存放編譯后的class文件和資源文件比如properties、xml。包路徑要和class的package聲明一致比如com.example.controller.UserServlet編譯后應(yīng)該放在WEB-INF/classes/com/example/controller/UserServlet.class。lib/存放應(yīng)用依賴的第三方j(luò)ar包。Tomcat啟動(dòng)時(shí)會(huì)把這個(gè)目錄下所有jar加入應(yīng)用的類加載器。注意servlet-api.jar和jsp-api.jar不要放進(jìn)來因?yàn)槿萜髯约禾峁┝朔胚M(jìn)去反而可能引起沖突。web.xml部署描述符雖然Servlet 3.0之后可以用注解替代大部分配置但很多老項(xiàng)目依然依賴它來配置Servlet、Filter、Listener、歡迎頁、錯(cuò)誤頁等。META-INF/MANIFEST.MF里可以寫一些元信息比如Class-Path指定額外依賴Web-ContextPath在某些容器里指定上下文路徑。不過大多數(shù)情況下這個(gè)文件不需要手動(dòng)改構(gòu)建工具會(huì)自動(dòng)生成。2.3 為什么容器認(rèn)war而不認(rèn)普通zip有人可能會(huì)問既然war就是zip那我把項(xiàng)目文件夾直接壓縮成zip改個(gè)后綴叫war行不行答案是技術(shù)上容器可能能解壓但大概率跑不起來。原因在于容器在部署war時(shí)不只是解壓它還會(huì)做一系列校驗(yàn)和初始化動(dòng)作。比如檢查WEB-INF/web.xml是否存在且格式正確掃描WEB-INF/classes和WEB-INF/lib下的類根據(jù)注解或配置注冊(cè)Servlet和Filter。如果目錄結(jié)構(gòu)不對(duì)比如class文件放在了根目錄而不是WEB-INF/classes容器就找不到類啟動(dòng)直接報(bào)ClassNotFoundException。另外war包的壓縮方式也有講究。雖然zip支持多種壓縮算法但Java的jar工具默認(rèn)使用deflate兼容性最好。如果你用某些工具壓成zip64或者用了不常見的壓縮級(jí)別老版本容器可能解壓失敗。所以“手動(dòng)改后綴”這種做法偶爾能蒙對(duì)但絕對(duì)不是可靠方案。3. 打包成war的幾種主流方式與選型邏輯3.1 命令行打包jar命令的實(shí)戰(zhàn)用法最原始的方式是用JDK自帶的jar命令。假設(shè)你的項(xiàng)目已經(jīng)編譯好目錄結(jié)構(gòu)如下build/ ├── index.jsp ├── css/ ├── js/ └── WEB-INF/ ├── web.xml ├── classes/ └── lib/進(jìn)入build目錄執(zhí)行jar -cvf myapp.war .參數(shù)解釋-c表示創(chuàng)建新歸檔-v表示輸出詳細(xì)過程-f指定歸檔文件名。最后的.表示把當(dāng)前目錄下所有內(nèi)容打包進(jìn)去。執(zhí)行完之后當(dāng)前目錄下會(huì)生成myapp.war。這里有個(gè)細(xì)節(jié)要注意jar命令默認(rèn)會(huì)把當(dāng)前目錄的路徑也帶進(jìn)去。如果你在build目錄下執(zhí)行jar -cvf myapp.war .解壓后根目錄就是build里面的內(nèi)容這是對(duì)的。但如果你執(zhí)行jar -cvf myapp.war build/解壓后第一層會(huì)是build/目錄容器就找不到WEB-INF了。所以一定要進(jìn)入正確的目錄再執(zhí)行。還有一種情況是只打包部分文件。比如你不想把源碼目錄打進(jìn)去可以用-C參數(shù)切換目錄jar -cvf myapp.war -C build/ .這表示切換到build目錄然后把該目錄下所有內(nèi)容打包。效果和先cd再執(zhí)行一樣但更適合寫在腳本里。提示用jar命令打包時(shí)如果WEB-INF/lib下有大量jar打包過程可能比較慢?？梢约?0參數(shù)禁用壓縮只做歸檔這樣打包快、解壓也快但war包體積會(huì)變大。生產(chǎn)環(huán)境一般還是用默認(rèn)壓縮。3.2 Maven打包pom.xml里的關(guān)鍵配置現(xiàn)在絕大多數(shù)Java Web項(xiàng)目用Maven管理。Maven打包war的核心是pom.xml里的packaging標(biāo)簽packagingwar/packaging這一行決定了mvn package執(zhí)行時(shí)生成的是war而不是jar。但光有這一行還不夠還需要配置maven-war-plugin。雖然Maven有默認(rèn)的war插件但默認(rèn)配置有時(shí)候不滿足需求比如你想排除某些文件、指定web.xml路徑、或者處理沒有web.xml的情況。一個(gè)典型的配置如下build finalNamemyapp/finalName plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version3.3.2/version configuration warSourceDirectorysrc/main/webapp/warSourceDirectory webXmlsrc/main/webapp/WEB-INF/web.xml/webXml failOnMissingWebXmlfalse/failOnMissingWebXml /configuration /plugin /plugins /buildfinalName決定生成的war包名字比如上面配置生成的是myapp.war。warSourceDirectory指定Web資源目錄默認(rèn)就是src/main/webapp。failOnMissingWebXml設(shè)為false表示沒有web.xml也不報(bào)錯(cuò)適合純注解配置的項(xiàng)目。Maven的war插件在打包時(shí)會(huì)做幾件事把src/main/webapp下的內(nèi)容復(fù)制到war根目錄把src/main/resources下的文件復(fù)制到WEB-INF/classes把編譯后的class文件放到WEB-INF/classes把依賴jar放到WEB-INF/lib。注意provided作用域的依賴不會(huì)被打進(jìn)WEB-INF/lib比如servlet-api因?yàn)槿萜鲿?huì)提供。執(zhí)行打包命令mvn clean package如果只想打包不跑測(cè)試mvn clean package -DskipTests生成的war包在target/目錄下。3.3 Gradle打包build.gradle的war插件Gradle項(xiàng)目打包war需要應(yīng)用war插件plugins { id war }然后配置war任務(wù)war { archiveFileName myapp.war from src/main/webapp webXml file(src/main/webapp/WEB-INF/web.xml) }Gradle的war插件會(huì)自動(dòng)處理依賴implementation的依賴會(huì)打進(jìn)WEB-INF/libprovidedCompile或compileOnly的依賴不會(huì)打進(jìn)去。執(zhí)行g(shù)radle war生成的war在build/libs/目錄下。3.4 三種方式怎么選看項(xiàng)目階段和團(tuán)隊(duì)習(xí)慣命令行jar方式適合快速驗(yàn)證、臨時(shí)打包或者寫自動(dòng)化腳本時(shí)用。它的優(yōu)點(diǎn)是零依賴只要有JDK就能跑缺點(diǎn)是容易出錯(cuò)目錄結(jié)構(gòu)、文件排除都要手動(dòng)控制。Maven方式適合大多數(shù)傳統(tǒng)Java Web項(xiàng)目尤其是團(tuán)隊(duì)協(xié)作、需要依賴管理的場(chǎng)景。它的生命周期管理很成熟clean package一條命令搞定編譯、測(cè)試、打包。缺點(diǎn)是pom配置有時(shí)候比較繁瑣插件版本沖突也讓人頭疼。Gradle方式適合追求構(gòu)建速度和靈活性的團(tuán)隊(duì)。Gradle的增量構(gòu)建比Maven快腳本也更簡(jiǎn)潔。但Gradle的學(xué)習(xí)曲線比Maven陡老項(xiàng)目遷移成本高。我個(gè)人的經(jīng)驗(yàn)是新項(xiàng)目如果團(tuán)隊(duì)沒有特別偏好用Maven最穩(wěn)資料多、踩坑少老項(xiàng)目如果已經(jīng)是Gradle就繼續(xù)用Gradle沒必要為了打包換構(gòu)建工具。4. war包解壓與壓縮命令全解析4.1 解壓war包unzip和jar -xvf怎么選war包解壓最常用的命令是unzipunzip myapp.war -d myapp_extracted-d指定解壓目標(biāo)目錄。如果不加-d會(huì)解壓到當(dāng)前目錄而且如果當(dāng)前目錄已經(jīng)有同名文件夾可能會(huì)覆蓋或提示。我習(xí)慣總是加-d指定一個(gè)干凈的目錄避免污染當(dāng)前工作區(qū)。unzip的優(yōu)點(diǎn)是快、通用Linux和macOS自帶Windows裝了Git Bash也能用。但它有個(gè)小問題如果war包里的文件名包含中文或特殊字符unzip可能會(huì)亂碼。這是因?yàn)閦ip格式對(duì)文件名編碼沒有統(tǒng)一標(biāo)準(zhǔn)Windows壓縮的工具可能用GBKLinux默認(rèn)用UTF-8。遇到亂碼可以加-O參數(shù)指定編碼unzip -O GBK myapp.war -d myapp_extracted另一個(gè)選擇是用JDK自帶的jar命令jar -xvf myapp.war-x表示解壓-v輸出詳細(xì)過程-f指定文件。這個(gè)命令會(huì)解壓到當(dāng)前目錄沒有-d參數(shù)。它的好處是編碼處理跟Java一致一般不會(huì)亂碼缺點(diǎn)是會(huì)覆蓋同名文件且不提示而且解壓速度比unzip慢一些。注意解壓war包之前先確認(rèn)目標(biāo)目錄是空的或者不存在。如果目錄里已經(jīng)有舊版本的文件解壓后新舊文件混在一起可能導(dǎo)致類沖突或配置覆蓋。我一般會(huì)先rm -rf myapp_extracted再解壓。4.2 重新壓縮zip命令的坑與正確姿勢(shì)有時(shí)候你需要修改war包里的某個(gè)配置文件比如改數(shù)據(jù)庫連接串然后重新壓縮。這時(shí)候不能用zip -r myapp.war myapp_extracted/因?yàn)檫@樣會(huì)把myapp_extracted這個(gè)目錄名也打進(jìn)去導(dǎo)致war包根目錄多了一層。正確的做法是進(jìn)入解壓后的目錄然后打包c(diǎn)d myapp_extracted zip -r ../myapp_new.war .-r表示遞歸包含子目錄.表示當(dāng)前目錄下所有內(nèi)容../myapp_new.war指定輸出到上一級(jí)目錄。這樣打出來的war包根目錄就是WEB-INF、css這些結(jié)構(gòu)正確。還有一個(gè)細(xì)節(jié)zip默認(rèn)會(huì)保留文件的相對(duì)路徑但不會(huì)保留Unix權(quán)限位。對(duì)于war包來說權(quán)限位一般不重要因?yàn)槿萜髯x取文件不依賴執(zhí)行權(quán)限。但如果你在Linux上部署確保war包本身有讀權(quán)限就行。另外如果原war包里有META-INF/MANIFEST.MF重新壓縮時(shí)不要漏掉。有些構(gòu)建工具生成的MANIFEST.MF里包含版本信息或類路徑配置丟了可能導(dǎo)致容器啟動(dòng)異常。4.3 查看war包內(nèi)容不解壓也能看有時(shí)候你只想確認(rèn)war包里有沒有某個(gè)文件不想解壓整個(gè)包。可以用unzip -l myapp.war-l列出歸檔內(nèi)容顯示文件名、大小、壓縮比、日期。輸出類似Archive: myapp.war Length Date Time Name --------- ---------- ----- ---- 0 2024-01-15 10:30 META-INF/ 123 2024-01-15 10:30 META-INF/MANIFEST.MF 0 2024-01-15 10:30 WEB-INF/ 456 2024-01-15 10:30 WEB-INF/web.xml ...如果只想看某個(gè)文件的內(nèi)容可以用unzip -p myapp.war WEB-INF/web.xml-p表示解壓到標(biāo)準(zhǔn)輸出不寫文件。這個(gè)命令在排查配置問題時(shí)特別有用比如確認(rèn)web.xml里的servlet映射對(duì)不對(duì)。jar命令也有類似功能jar -tvf myapp.war-t列出內(nèi)容-v詳細(xì)-f指定文件。輸出格式和unzip -l略有不同但信息一樣。4.4 增量更新war包里的單個(gè)文件生產(chǎn)環(huán)境有時(shí)候只需要改一個(gè)配置文件重新打整個(gè)war包太重。可以用jar或zip做增量更新。用jar更新jar -uvf myapp.war WEB-INF/classes/application.properties-u表示更新會(huì)把指定文件替換進(jìn)war包。注意文件路徑必須和war包內(nèi)的路徑一致。這個(gè)命令要求當(dāng)前目錄下存在WEB-INF/classes/application.properties這個(gè)文件。用zip更新zip myapp.war WEB-INF/classes/application.propertieszip命令如果發(fā)現(xiàn)歸檔里已有同名文件會(huì)直接替換。這個(gè)操作比jar -u更直觀但同樣要注意路徑匹配。提示增量更新雖然方便但容易導(dǎo)致war包內(nèi)文件版本不一致。比如你更新了class文件但忘了更新對(duì)應(yīng)的配置文件就可能出現(xiàn)詭異問題。我的建議是生產(chǎn)環(huán)境盡量用完整包替換增量更新只用于緊急修復(fù)且更新后要記錄變更內(nèi)容。5. 從源碼到war一個(gè)完整項(xiàng)目的打包實(shí)操記錄5.1 項(xiàng)目結(jié)構(gòu)與編譯準(zhǔn)備假設(shè)我們有一個(gè)簡(jiǎn)單的Java Web項(xiàng)目目錄結(jié)構(gòu)如下mywebapp/ ├── pom.xml └── src/ └── main/ ├── java/ │ └── com/example/ │ └── HelloServlet.java ├── resources/ │ └── application.properties └── webapp/ ├── index.jsp └── WEB-INF/ └── web.xmlHelloServlet.java內(nèi)容package com.example; import javax.servlet.http.*; import java.io.IOException; public class HelloServlet extends HttpServlet { Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException { resp.setContentType(text/plain); resp.getWriter().write(Hello from war package!); } }web.xml內(nèi)容?xml version1.0 encodingUTF-8? web-app xmlnshttp://xmlns.jcp.org/xml/ns/javaee xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd version4.0 servlet servlet-namehello/servlet-name servlet-classcom.example.HelloServlet/servlet-class /servlet servlet-mapping servlet-namehello/servlet-name url-pattern/hello/url-pattern /servlet-mapping /web-apppom.xml關(guān)鍵部分groupIdcom.example/groupId artifactIdmywebapp/artifactId version1.0.0/version packagingwar/packaging dependencies dependency groupIdjavax.servlet/groupId artifactIdjavax.servlet-api/artifactId version4.0.1/version scopeprovided/scope /dependency /dependencies build finalNamemywebapp/finalName plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version3.3.2/version configuration failOnMissingWebXmlfalse/failOnMissingWebXml /configuration /plugin /plugins /build5.2 執(zhí)行打包并驗(yàn)證產(chǎn)物在項(xiàng)目根目錄執(zhí)行mvn clean package控制臺(tái)會(huì)輸出編譯、測(cè)試、打包的過程。最后看到[INFO] Building war: /path/to/mywebapp/target/mywebapp.war [INFO] BUILD SUCCESS進(jìn)入target目錄確認(rèn)war包存在ls -lh target/mywebapp.war然后用unzip -l檢查內(nèi)容unzip -l target/mywebapp.war應(yīng)該能看到WEB-INF/classes/com/example/HelloServlet.class、WEB-INF/web.xml、index.jsp等文件。如果WEB-INF/lib下沒有servlet-api.jar說明provided作用域生效了這是正確的。5.3 部署到Tomcat并驗(yàn)證訪問把war包復(fù)制到Tomcat的webapps目錄cp target/mywebapp.war $TOMCAT_HOME/webapps/啟動(dòng)Tomcat$TOMCAT_HOME/bin/startup.shTomcat會(huì)自動(dòng)解壓war包生成webapps/mywebapp/目錄。訪問http://localhost:8080/mywebapp/hello如果看到“Hello from war package!”說明打包和部署都成功了。這里有個(gè)細(xì)節(jié)Tomcat默認(rèn)的上下文路徑就是war包的文件名去掉.war后綴。所以mywebapp.war部署后訪問路徑是/mywebapp。如果想改成根路徑/可以把war包改名為ROOT.war但這樣會(huì)覆蓋Tomcat默認(rèn)的ROOT應(yīng)用一般不建議。5.4 打包參數(shù)調(diào)優(yōu)與體積控制war包體積過大是常見問題。一個(gè)簡(jiǎn)單的Web應(yīng)用如果依賴了幾十個(gè)jarwar包可能上百M(fèi)B。傳輸慢、部署慢、容器啟動(dòng)也慢。我一般從幾個(gè)方面控制體積第一檢查依賴作用域。provided的依賴不會(huì)打進(jìn)去比如servlet-api、jsp-api、tomcat相關(guān)的jar。如果發(fā)現(xiàn)這些出現(xiàn)在WEB-INF/lib里說明作用域配錯(cuò)了。第二排除不必要的傳遞依賴。Maven的依賴樹可以用mvn dependency:tree查看找到重復(fù)或不需要的依賴用exclusions排除。第三壓縮靜態(tài)資源。CSS、JS、圖片可以用工具壓縮后再放進(jìn)webapp目錄。雖然war包本身會(huì)壓縮但壓縮后的靜態(tài)資源能進(jìn)一步減小體積。第四考慮把大文件放到外部存儲(chǔ)。比如用戶上傳的圖片、視頻不要打進(jìn)war包而是放到獨(dú)立的文件服務(wù)器或?qū)ο蟠鎯?chǔ)war包里只保留訪問路徑。6. 常見報(bào)錯(cuò)與排查技巧實(shí)錄6.1 啟動(dòng)報(bào)ClassNotFoundException的幾種可能這是部署war包時(shí)最常見的錯(cuò)誤?？刂婆_(tái)輸出類似java.lang.ClassNotFoundException: com.example.HelloServlet排查思路按優(yōu)先級(jí)排列第一確認(rèn)class文件在不在正確位置。解壓war包檢查WEB-INF/classes/com/example/HelloServlet.class是否存在。如果class文件在根目錄或者WEB-INF下但不在classes里容器就找不到。第二確認(rèn)包名和目錄結(jié)構(gòu)一致。com.example.HelloServlet的class文件必須在WEB-INF/classes/com/example/目錄下。如果編譯時(shí)包聲明是com.example但文件被放到了WEB-INF/classes/根目錄也會(huì)報(bào)錯(cuò)。第三確認(rèn)依賴jar是否完整。如果HelloServlet引用了某個(gè)第三方類而那個(gè)jar不在WEB-INF/lib里也會(huì)報(bào)ClassNotFoundException但錯(cuò)誤信息里會(huì)是那個(gè)第三方類的名字。這時(shí)候檢查pom.xml里對(duì)應(yīng)依賴的scope是不是provided或test改成默認(rèn)的compile重新打包。第四檢查是否有重復(fù)類沖突。如果WEB-INF/classes和WEB-INF/lib里的某個(gè)jar包含同名類容器加載順序可能導(dǎo)致版本不一致。用unzip -l列出所有jar搜索沖突的類名。6.2 404錯(cuò)誤的定位方法部署后訪問URL返回404說明容器收到了請(qǐng)求但沒找到對(duì)應(yīng)的Servlet或靜態(tài)資源。排查步驟先確認(rèn)上下文路徑對(duì)不對(duì)。Tomcat的上下文路徑默認(rèn)是war包文件名。如果war包叫mywebapp.war訪問路徑應(yīng)該是/mywebapp/hello不是/hello?？梢栽赥omcat的conf/server.xml里配置Context的path屬性或者在conf/Catalina/localhost/下建一個(gè)XML文件指定路徑。再確認(rèn)Servlet映射對(duì)不對(duì)。檢查web.xml里的url-pattern或者注解WebServlet(/hello)。注意大小寫敏感/Hello和/hello是不同的路徑。然后確認(rèn)靜態(tài)資源位置。如果訪問的是JSP或HTML確認(rèn)文件在war包根目錄下而不是在WEB-INF里面。WEB-INF下的資源瀏覽器無法直接訪問。最后看Tomcat日志。logs/catalina.out或logs/localhost.log里通常會(huì)有詳細(xì)錯(cuò)誤信息比如“No mapping found for HTTP request with URI”能直接定位到問題。6.3 中文亂碼與編碼問題war包里的中文文件比如JSP頁面、properties文件如果編碼不對(duì)部署后可能顯示亂碼。根源在于zip格式對(duì)文件名編碼沒有統(tǒng)一標(biāo)準(zhǔn)以及Java讀取文件時(shí)的默認(rèn)編碼。對(duì)于文件名亂碼打包時(shí)盡量用UTF-8編碼。Maven的war插件默認(rèn)用項(xiàng)目編碼可以在pom.xml里設(shè)置properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties對(duì)于文件內(nèi)容亂碼JSP頁面頂部加% page contentTypetext/html;charsetUTF-8 languagejava %properties文件在Java 9之前默認(rèn)用ISO-8859-1讀取中文需要轉(zhuǎn)成Unicode轉(zhuǎn)義。Java 9之后可以用UTF-8但需要確認(rèn)運(yùn)行環(huán)境。6.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決方式ClassNotFoundExceptionclass文件位置不對(duì)解壓war檢查WEB-INF/classes調(diào)整打包目錄結(jié)構(gòu)NoClassDefFoundError依賴jar缺失檢查WEB-INF/lib補(bǔ)充依賴或改scope404 Not Found上下文路徑錯(cuò)誤確認(rèn)war包名和訪問URL修改war包名或配置Context404 Not FoundServlet映射錯(cuò)誤檢查web.xml或注解修正url-pattern中文亂碼編碼不一致檢查文件編碼和頁面聲明統(tǒng)一用UTF-8啟動(dòng)慢war包過大查看WEB-INF/lib大小排除無用依賴內(nèi)存溢出重復(fù)加載類檢查lib下是否有容器提供的jar移除servlet-api等靜態(tài)資源404文件在WEB-INF下檢查文件位置移到war根目錄提示排查war包問題時(shí)養(yǎng)成先解壓看目錄結(jié)構(gòu)的習(xí)慣。很多問題看一眼目錄就能定位比翻日志快得多。7. 一些容易忽略的細(xì)節(jié)和我的個(gè)人習(xí)慣打包war包這件事說難不難但細(xì)節(jié)特別多。我踩過的坑包括在錯(cuò)誤目錄執(zhí)行jar命令導(dǎo)致多了一層目錄用zip重新打包時(shí)忘了排除.DS_Store文件Maven打包時(shí)provided依賴沒配對(duì)導(dǎo)致容器里出現(xiàn)兩個(gè)版本的servlet-api。這些問題的共同點(diǎn)是報(bào)錯(cuò)信息往往不直接指向根因需要你對(duì)war包的結(jié)構(gòu)和容器的加載機(jī)制有清晰的認(rèn)識(shí)。我現(xiàn)在養(yǎng)成的習(xí)慣是每次打包后先用unzip -l看一眼文件列表確認(rèn)WEB-INF/classes和WEB-INF/lib都在沒有多余的系統(tǒng)文件。然后本地Tomcat部署一次訪問幾個(gè)關(guān)鍵URL確認(rèn)沒問題再上傳到服務(wù)器。多花兩分鐘檢查能省掉后面半小時(shí)的排查。另外如果你的項(xiàng)目還在用JSP注意JSP文件在war包里的位置。JSP放在根目錄可以直接訪問放在WEB-INF下只能通過Servlet轉(zhuǎn)發(fā)訪問。有些框架會(huì)把JSP放在WEB-INF/jsp/下這是為了強(qiáng)制走控制器避免直接訪問。打包時(shí)不要漏掉這些文件。最后分享一個(gè)小技巧如果你不確定某個(gè)文件應(yīng)該放在war包的哪個(gè)位置可以找一個(gè)能正常運(yùn)行的war包解壓后對(duì)照它的目錄結(jié)構(gòu)。這是最快的學(xué)習(xí)方式比看文檔直觀得多。