路由模式
衆所周知，瀏覽器下的單頁面應用的路由模式有下面兩種： hash 模式和 history 模式。hash 模式通用性好，而且不依賴服務器的配置，省心省力，但是缺點是不夠優雅。相比於 hash 模式來說，history 模式則更加美觀。
但是，history 模式同樣會有一個問題，就是當頁面刷新時，如果沒有合適的配置，會出現頁面 404 的錯誤。因此需要額外的服務器配置，對於找不到的 url，將首頁 html 返回。
接下來，咱們以 nginx 爲例，來說說 history 模式時需要進行的配置。
location
location 位於 http->server 塊中，語法格式如下：
Syntax: location [= | ~ | ~* | ^~] uri { ... }
location @name { ... }
Default: —
Context: server, location
[= | ~ | ~* | ^~]，是修飾符，可以控制 nginx 匹配的順序。優先級關於四個修飾符的含義，可以參考 這篇文章。這裏不過多敘述，總之當一個 server 下面有多個 location 時，nginx 會根據 uri 的精確度和修飾符進行匹配。查找的順序及優先級如下：
查找順序和優先級
1：帶有“=“的精確匹配優先
2：沒有修飾符的, 誰更精確誰優先，如 / 和 /post , 則 post 優先
3：正則表達式按照他們在配置文件中定義的順序
4：帶有 “^~” 修飾符的，開頭匹配
5：帶有“~” 或“~*” 修飾符的，如果正則表達式與 URI 匹配
6：沒有修飾符的，如果指定字符串與 URI 開頭匹配
try_files
try_files 解決的是：當 nginx 找不到客戶端需要的資源時該怎麼辦的問題。以 history 路由爲例：假如你的頁面 url 是 http://www.example.com/post，你的 nginx 配置如下：
location / {
root local/web/dist
}當你在 post 路由下刷新頁面時，nginx 會返回 404。這是什麼原因呢？因爲我們沒有告訴nginx找不到某個文件時該怎麼做。root 指定了 / 對應的單頁靜態資源目錄，從而使url映射到dist目錄下。
這個配置可以讓你項目的 css，js 被順利加載，但是碰到上面的 URL，nginx 就不知所措了。因爲我們的 dist 文件夾下面並沒有 post 這個文件或者文件夾，所以 nginx 會給你個 404 頁面。try_files 就是爲了解決這個問題的，try_files 語法如下：
location / {
try_files $uri $uri/ /index.html;
}
以上面的 http://www.example.com/post 爲例，$uri 會匹配到 post，nginx 發現 dist 目錄下下面沒有 post 這個文件，也沒有 post 這個文件夾，所以最後會返回 dist 目錄下的 index.html。這樣，index.html 被瀏覽器加載之後，前端路由就會工作，將用戶需要的資源加載出來。而我們 build 出來的 css，js 文件，由於可以被 nginx 正確找到，則不會受到影響。