多 WAR 項目靜態資源共享三大方案深度解析

痛點：重複的靜態文件正在拖垮團隊效率

微服務或多模塊單體中，前端公共資源（jQuery、EasyUI、組件庫、公共 CSS/JS）往往散落在每個 WAR 包裡。組件升級、Bug 修復時，前端需在 N 個項目重複改動、測試、打包，極易遺漏且版本難統一。本文系統梳理三種主流共享方案，從構建層到部署層層層遞進。

方案一：獨立 JAR 包 —— 構建層共享（推薦中小團隊）

核心思想

將 src/main/resources/static 目錄剝離為獨立 Maven 模塊 common-static，打成 JAR 發布到私有 Nexus，各 WAR 依賴該 JAR，通過 Spring MVC mvc:resources 映射 classpath:/static/ 實現訪問。

實施步驟

1. 建立 JAR 項目：標準 Maven 結構，資源置於 src/main/resources/static
2. 配置發布：POM 設定 distributionManagement 指向私服，mvn deploy 自動發布
3. WAR 依賴：

<dependency>
  <groupId>cn.codestory.research</groupId>
  <artifactId>common-static</artifactId>
  <version>0.0.1-SNAPSHOT</version>
</dependency>

4. Spring 映射：

<mvc:resources mapping="/static/**" location="classpath:/static/"/>

5. 頁面引用：<script src="/static/javascript/framework/jquery.min.js"></script>

進階：項目級覆蓋與兼容

• WAR 自有靜態資源放入自身 src/main/resources/static，優先級高於 JAR（ClassLoader 順序）
• 舊項目資源在 src/main/webapp/static 不想遷移？雙路徑映射：location="classpath:/static/,/static/"

優缺點

方案二：獨立 Static WAR + Nginx 轉發 —— 部署層共享（推薦生產環境）

架構拓撲

• 靜態資源打包為獨立 static.war 部署於專用 Tomcat/HTTP Server
• Nginx 作為入口，按 URI 路由：/static/** → Static Server；Host: app1.xxx → App Server 1

Nginx 關鍵配置

server {
    listen 80;
    server_name app1.codestory.cn;
    location /static/ {
        proxy_pass https://static-server/;
    }
    location / {
        proxy_pass https://app-server-1/;
    }
}

優缺點

• ✅ 徹底解耦，靜態資源獨立發布、獨立擴容、獨立緩存策略
• ✅ 瀏覽器並發連接數受域名限制，分域名可提升加載並發度
• ⚠️ 需運維引入 Nginx、增加部署節點、管理跨域/權限

方案三：獨立域名 + CDN —— 極致性能方案（資源充足首選）

架構升級

• 靜態服務器綁定獨立域名 static.codestory.cn
• 頁面引用全量 URL：<script src="https://static.codestory.cn/static/...jquery.min.js">
• 接入 CDN（阿里云/騰訊云/Cloudflare），邊緣節點緩存，用戶就近訪問

適用性判斷

最佳實踐總結

1. 必做前置：將靜態資源從業務 WAR 中物理剝離，建立獨立模塊
2. 版本化管理：JAR 方案用 Maven 版本號；部署方案用構建號/Tag 追溯
3. 緩存策略：Nginx/CDN 層配置長期強緩存（Cache-Control: max-age=31536000, immutable），文件名帶 Hash 實現無緩存更新
4. 安全邊界：靜態域名啟用 CSP、Referer 防盜鏈、HTTPS 強制

沒有銀彈，只有最適合當前階段的選擇。建議從方案一起步，隨業務增長平滑演進至方案二、三。