那是一個陽光明媚的週一早晨，我剛端起手邊的咖啡，還沒來得及喝上一口，HR小姐姐就笑眯眯地出現在我面前：“小米，下週去面試一家大廠吧？他們挺喜歡你的項目經驗。”

我一愣——面試？這可是我一年多沒換工作的第一個挑戰。於是我火速打開IDEA，開始複習八股文。JVM、Spring、Redis、MySQL……複習得正歡，突然一個題目跳了出來：

“Tomcat 有幾種部署方式？請詳細説明。”

我心裏一驚：這題看似簡單，實則暗藏玄機。要是答“war包放進去就完事”，那可就太淺了。

於是，我決定親自重新走一遍 Tomcat 的“部署之旅”。

第一幕：傳統的“拷貝 WAR 包”部署

我首先打開熟悉的 apache-tomcat-9.0 目錄，眼神瞄準那個經典的 webapps/ 文件夾。

這可是 Tomcat 的老傢伙了——把一個 war 包丟進去，Tomcat 自動解壓並部署。

比如我有個項目叫 myapp.war，只要把它放到：

然後啓動 Tomcat，瀏覽器訪問 http://localhost:8080/myapp，就能看到熟悉的“Hello World”。

這種方式雖然簡單，但有幾個注意點：

• 啓動時自動解壓，第一次加載會稍慢；
• 重新部署時可能殘留舊緩存；
• 不適合頻繁更新的線上項目。

老一輩程序員最愛這招，簡單、穩、無腦部署。但對於我這種天天迭代的小米來説，總覺得——太慢啦！

第二幕：解壓後直接放文件夾

我心想：那能不能不每次都打 WAR 包？

當然可以！

我們可以直接將項目解壓成文件夾，比如 myapp/，然後直接扔進 webapps/：

裏面包含：

Tomcat 啓動後會直接把這個文件夾識別為一個 Web 應用。

優點：

• 無需打包，方便調試；
• 修改 JSP 或靜態資源後立即生效；
• 適合開發階段使用。

缺點也明顯：

• 文件太多可能混亂；
• 不利於統一版本管理；
• 生產環境部署容易出錯。

這讓我想起大學那會兒，我的第一個 JSP 項目就是用這種方式部署的。那時我不知道什麼 CI/CD，只會用 Ctrl+C + Ctrl+V。

每次看到 Tomcat started on port 8080，都覺得自己是世界上最厲害的程序員。

第三幕：配置文件部署（server.xml）

後來，我進入了職場，項目逐漸龐大，公司也不允許每次都“手動丟包”。於是我學會了更“高級”的方式——通過 server.xml 來定義部署路徑。

打開 conf/server.xml，在 <Host> 標籤內添加：

這裏的幾個關鍵點：

• path：訪問路徑；
• docBase：項目實際路徑；
• reloadable：是否自動加載修改。

重啓 Tomcat 後，無需放在 webapps，也能直接訪問。比如訪問 http://localhost:8080/myapp。

這種方式讓部署更靈活，可以指定任何位置的應用目錄，非常適合部署多個項目。但有風險！

修改 server.xml 屬於全局配置，如果寫錯，Tomcat 整個實例都可能起不來。

我記得有一次凌晨上線，我多寫了一個斜槓 /，結果整台測試環境的 Tomcat 啓不動。被Leader質問：“你這是給Tomcat打絆子呢？”

所以這招得謹慎使用。

第四幕：context.xml 部署（推薦生產使用）

後來，我發現還有一種更優雅的方式：通過 context.xml 單獨配置每個應用。有兩種做法：

1、在項目內部配置

在項目的 META-INF/context.xml 中定義：

當項目部署到 Tomcat 時，Tomcat 會自動讀取這個配置文件。

2、獨立放置配置

在 Tomcat 的 conf/Catalina/localhost/ 下，新建一個文件：

內容為：

Tomcat 啓動後就會自動部署這個應用。

最酷的是——文件名 myapp.xml 就決定了訪問路徑 /myapp！

這種方式有三大優勢：

1. 不改 server.xml，安全；
2. 方便做版本切換；
3. 不需要放在 webapps 下。

這也成了多數公司生產環境的標準做法。

我面試的時候，只要聊到這一塊，面試官一般都會點頭：

“嗯，小夥子，對Tomcat挺熟。”

第五幕：命令行 & Manager 管理頁面部署

後來我進入了一家創業公司，後端五六個人，測試服、預發服、線上服全靠我一個人維護。

那時候，我最怕的事就是手動複製包。於是我學會了Tomcat Manager 部署。

Tomcat 自帶一個管理後台（需在 tomcat-users.xml 中配置賬號）：

啓動後訪問：

登錄後台，就能看到“Deploy”按鈕。你可以直接上傳 WAR 包或輸入遠程 URL：

• 本地上傳：選擇文件，點擊 Deploy；
• 遠程部署：填寫 WAR 包地址，Tomcat 自動下載並部署。

甚至還支持命令行部署，用 curl 或 Ant 執行遠程更新。對於有CI/CD流程的團隊，這方式非常友好。

我記得當時寫了個簡單的腳本：

一鍵執行，Tomcat自動部署。

那種感覺就像從“手工時代”邁向“自動化文明”——再也不用為丟包焦慮啦！

第六幕：熱部署（IDE集成方式）

作為一個懶到骨子裏的程序員，我當然不會滿足於“上傳 WAR 包”這種操作。我想——能不能直接在 IDEA 裏點個按鈕就部署？

答案當然是：能！

在 IntelliJ IDEA 或 Eclipse 中配置 Tomcat 服務器後，只要點擊“Run”或“Debug”，IDE 就會自動：

1. 啓動 Tomcat；
2. 部署應用；
3. 熱加載修改後的文件。

這種方式其實是基於 Catalina 的熱部署機制，底層通過監聽 Context 變化實現。在開發階段簡直神器，改代碼立刻生效！但也別太飄——在生產環境千萬別這麼玩。IDE 部署僅適合本地調試。

線上環境必須有嚴格的包管理、備份和日誌監控機制。

總結：Tomcat 的六種部署方式

尾聲：面試的那一刻

面試那天，面試官笑着問我：“Tomcat 有幾種部署方式？”

我輕輕放下手中的水杯，微微一笑，説：

“常見的有六種：拷貝 WAR 包、直接放文件夾、修改 server.xml、配置 context.xml、使用 Manager 頁面、以及 IDE 熱部署。”

面試官點點頭，又追問一句：“那你推薦哪種？”

我不假思索：

“生產推薦 context.xml，配合 CI/CD 自動化部署，既安全又靈活。”

他笑了笑，合上筆記本，説：“不錯，你通過了。”

那一刻，我心想：

原來，真正的面試題，考的不只是記憶，而是理解與實踐的積累。

END

Tomcat 的部署方式，其實就像一個程序員的成長曆程：

• 從“拷貝 WAR 包”開始，笨但實用；
• 逐步學會配置與腳本；
• 最後掌握自動化與熱部署。

每一種方式，都是我們與 Tomcat 並肩作戰的印記。

當你能根據場景靈活選擇，那你離“架構師的味道”，也就不遠啦！

如果你喜歡這種技術+故事的寫法，記得點個“贊”和“在看”呀～

我是小米，一個喜歡分享技術的31歲程序員。如果你喜歡我的文章，歡迎關注我的微信公眾號“軟件求生”，獲取更多技術乾貨！