以下內容聚焦 <span style="color:red">Nginx 1.20+</span> 在生產環境的 URLRewrite 偽靜態最佳實踐，目標是：規則可讀、性能穩定、灰度可控、回滾簡單。🚀

一、核心原則（結論先講）

• 優先使用 <span style="color:red">try_files</span>，僅在確需正則改寫時用 <span style="color:red">rewrite</span>。
• 永久跳轉使用 <span style="color:red">return 301</span>，減少多次改寫的性能開銷。
• 控制流使用 <span style="color:red">last / break</span> 明確，可維護可調試。
• 規則分層：<span style="color:red">server 級通用</span> + <span style="color:red">location 級業務</span>，避免“全局鍋爐房”。

二、常見偽靜態模板（可直接上生產）

1）靜態優先 + 動態兜底（通用 PHP/Java 後端）

server {
  listen 80;
  server_name example.com;
  root /var/www/html;

  location / {
    try_files $uri $uri/ /index.php?$args;
  }
}

解釋：try_files 依次查找真實文件/目錄，最後把請求改寫到 index.php，同時保留 <span style="color:red">$args</span> 查詢串，避免丟參；這是最省資源的偽靜態思路。

2）REST 風格資源路由（去掉後綴）

location /api/ {
  try_files $uri $uri/ /api/index.php?$args;
}

解釋：優先命中 /api/foo 的靜態資源；不存在時統一交給路由入口處理，避免寫複雜正則。

3）前端單頁應用（Vue/React/SPA）

location / {
  try_files $uri $uri/ /index.html;
}

解釋：未命中實際文件時回退到 index.html，前端路由自行解析；避免 404 循環跳轉。

4）WWW 與非 WWW 規範化（單跳永久重定向）

# 非 www 跳轉到 www
server {
  listen 80;
  server_name example.com;
  return 301 https://www.example.com$request_uri;
}

解釋：使用 <span style="color:red">return 301</span> 一次到位，減少鏈路耗時；$request_uri 保留路徑與參數。

5）結尾斜槓統一（防重複內容與緩存穿透）

# 無斜槓 → 加斜槓
location ~ ^/docs$ {
  return 301 /docs/;
}

解釋：在入口處做路徑規範化，避免 /docs 與 /docs/ 產生兩份緩存或路由歧義。

6）精準正則改寫（僅在必須時）

location /blog/ {
  rewrite ^/blog/([0-9]{4})/([0-9]{2})/(.*)$ /blog/post.php?y=$1&m=$2&slug=$3 last;
}

解釋：使用 <span style="color:red">錨定 ^$</span>、限制位數，避免貪婪匹配誤傷；last 讓 Nginx 重新走 location 匹配，適合改寫到新的 URI 再進入路由。

7）統一 HTTP → HTTPS（含端口收斂）

server {
  listen 80;
  server_name _;
  return 301 https://$host$request_uri;
}

解釋：極簡強制 HTTPS；配合 HSTS 需評估回滾策略，避免鎖死錯誤證書。

三、指令速查表（vditor/Markdown 兼容）

四、工作流程（從請求到落地）

1. 客户端發起請求 → 命中 <span style="color:red">server</span>。
2. 執行 <span style="color:red">return / rewrite</span>（並行考慮 HTTPS/域名規範化）。
3. 進入 <span style="color:red">location</span> 匹配：先前綴、再正則、後精確。
4. 路由到 <span style="color:red">try_files</span> 或後端代理，上送應用處理。
5. 響應緩存（可結合 expires/Cache-Control），完成閉環。✅

五、灰度與回滾（強烈建議）

# 灰度：僅對 /beta/ 生效
location /beta/ {
  try_files $uri $uri/ /beta/index.php?$args;
}

# 回滾：保留 old.conf，可一鍵 include 切換
include /etc/nginx/conf.d/old.conf;

解釋：新規則先命中特定前綴，驗證通過後再擴展；舊規則保留為文件，出問題時可一鍵回滾。

六、調試與自檢命令（配解釋）

# 1) 測試語法
nginx -t

解釋：在 reload 之前強制做語法校驗；出現 test is successful 才能繼續。

# 2) 平滑加載
nginx -s reload

解釋：零中斷重載配置；若失敗，保持舊 worker 不退出，業務不抖動。

# 3) 跳轉鏈路檢查
curl -I http://example.com/docs

解釋：關注 <span style="color:red">HTTP/1.1 301</span> 與 Location 頭是否符合預期，避免多次跳轉。

# 4) 改寫生效驗證（顯示最終 URL）
curl -I http://example.com/blog/2025/10/hello

解釋：檢查響應是否命中 post.php?y=2025&m=10&slug=hello 路由；若 404，説明改寫或入口文件不一致。

七、典型坑位與硬性結論

• <span style="color:red">能用 try_files 就別上 rewrite</span>：正則越多，維護成本越高。
• <span style="color:red">跳轉必須保留參數</span>：$request_uri 或 $args；丟參=線上事故。
• <span style="color:red">正則要限邊界</span>：使用 ^…$、量詞限定，拒絕貪婪通配。
• <span style="color:red">if 慎用</span>：location 內 if 僅用於簡單變量判斷；複雜條件改用 map + 變量。
• <span style="color:red">HTTPS 策略可回退</span>：啓 HSTS 前先在少量流量試跑，避免證書事故被“鎖死”。
• <span style="color:red">代理鏈一致</span>：前置 WAF/CDN 若也寫了改寫，需與源站規則對齊，防“雙改寫”。🧩

八、對比思維導圖（文字版）

• <span style="color:red">路由策略</span> → 靜態優先 → try_files 兜底 → 必要 rewrite
• <span style="color:red">跳轉策略</span> → 規範化域名/路徑 → return 301 單跳
• <span style="color:red">灰度策略</span> → 前綴灰度 → include 回滾
• <span style="color:red">風控策略</span> → 正則限邊界 → 日誌審計 → curl 校驗

九、面向運維的最小可行清單

1. 上線前：nginx -t、預案 old.conf、灰度 /beta/。
2. 上線時：reload、curl -I 驗證關鍵路徑。
3. 上線後：觀察 301/302 比例、4xx/5xx 抖動與緩存命中率。📈

一句話總結：把偽靜態當成“路由層性能工程”。優先 <span style="color:red">try_files</span>，規範化用 <span style="color:red">return 301</span>，必要時再上 <span style="color:red">rewrite + last/break</span>。規則分層、灰度可回滾，才是真正可運營的 Nginx URLRewrite。✨