Vue-router 中hash模式和history模式的區別


Vue-router 中hash模式和history模式的關系

在vue的路由配置中有mode選項 最直觀的區別就是在url中 hash 帶了一個很丑的 # 而history是沒有#的

mode:"hash";  
mode:"history"; 

hash模式和history模式的不同

對於vue這類漸進式前端開發框架,為了構建 SPA(單頁面應用),需要引入前端路由系統,這也就是 Vue-Router 存在的意義。前端路由的核心,就在於 —— 改變視圖的同時不會向后端發出請求。

為了達到這一目的,瀏覽器當前提供了以下兩種支持:

  • hash —— 即地址欄 URL 中的 # 符號。比如這個 URL:http://www.abc.com/#/hello,hash 的值為 #/hello。它的特點在於:hash 雖然出現在 URL 中,但不會被包括在 HTTP 請求中,對后端完全沒有影響,因此改變 hash 不會重新加載頁面。
  • history —— 利用了 HTML5 History Interface 中新增的 pushState() 和 replaceState() 方法。(需要特定瀏覽器支持)這兩個方法應用於瀏覽器的歷史記錄棧,在當前已有的 back、forward、go 的基礎之上,它們提供了對歷史記錄進行修改的功能。只是當它們執行修改時,雖然改變了當前的 URL,但瀏覽器不會立即向后端發送請求。
  • 因此可以說,hash 模式和 history 模式都屬於瀏覽器自身的特性,Vue-Router 只是利用了這兩個特性(通過調用瀏覽器提供的接口)來實現前端路由.

使用場景

一般場景下,hash 和 history 都可以,除非你更在意顏值,# 符號夾雜在 URL 里看起來確實有些不太美麗。

如果不想要很丑的 hash,我們可以用路由的 history 模式,這種模式充分利用 history.pushState API 來完成URL 跳轉而無須重新加載頁面。

另外,根據 Mozilla Develop Network 的介紹,調用 history.pushState() 相比於直接修改 hash,存在以下優勢:

  • pushState() 設置的新 URL 可以是與當前 URL 同源的任意 URL;而 hash 只可修改 # 后面的部分,因此只能設置與當前 URL 同文檔的 URL;
  • pushState() 設置的新 URL 可以與當前 URL 一模一樣,這樣也會把記錄添加到棧中;而 hash 設置的新值必須與原來不一樣才會觸發動作將記錄添加到棧中;
  • pushState() 通過 stateObject 參數可以添加任意類型的數據到記錄中;而 hash 只可添加短字符串;
  • pushState() 可額外設置 title 屬性供后續使用。

當然啦,history 也不是樣樣都好。SPA 雖然在瀏覽器里游刃有余,但真要通過 URL 向后端發起 HTTP 請求時,兩者的差異就來了。尤其在用戶手動輸入 URL 后回車,或者刷新(重啟)瀏覽器的時候。

個人在接入微信的一個活動開發過程中 開始使用的hash模式,但是后面后端無法獲取到我#后面的url參數,於是就把參數寫在#前面,但是討論后還是決定去掉這個巨丑的#

於是乎改用history模式,但是開始跑流程的時候是沒問題,但是后來發現跳轉后刷新或者回跳,會報一個404的錯誤,找不到指定的路由,最后后端去指向正確的路由 加了/hd/xxx 去匹配是否有這個/hd/{:path} 才得以解決

總結

1 hash 模式下,僅 hash 符號之前的內容會被包含在請求中,如 http://www.abc.com,因此對於后端來說,即使沒有做到對路由的全覆蓋,也不會返回 404 錯誤。

2 history 模式下,前端的 URL 必須和實際向后端發起請求的 URL 一致,如 http://www.abc.com/book/id。如果后端缺少對 /book/id 的路由處理,將返回 404 錯誤。Vue-Router 官網里如此描述:“不過這種模式要玩好,還需要后台配置支持……所以呢,你要在服務端增加一個覆蓋所有情況的候選資源:如果 URL 匹配不到任何靜態資源,則應該返回同一個 index.html 頁面,這個頁面就是你 app 依賴的頁面。”

3 結合自身例子,對於一般的 Vue + Vue-Router + Webpack + XXX 形式的 Web 開發場景,用 history 模式即可,只需在后端(Apache 或 Nginx)進行簡單的路由配置,同時搭配前端路由的 404 頁面支持。

 

hash模式url里面永遠帶着#號,我們在開發當中默認使用這個模式。那么什么時候要用history模式呢?如果用戶考慮url的規范那么就需要使用history模式,因為history模式沒有#號,是個正常的url適合推廣宣傳。當然其功能也有區別,比如我們在開發app的時候有分享頁面,那么這個分享出去的頁面就是用vue或是react做的,咱們把這個頁面分享到第三方的app里,有的app里面url是不允許帶有#號的,所以要將#號去除那么就要使用history模式,但是使用history模式還有一個問題就是,在訪問二級頁面的時候,做刷新操作,會出現404錯誤,那么就需要和后端人配合讓他配置一下apache或是nginx的url重定向,重定向到你的首頁路由上就ok啦。

 

hash模式

我們先來認識下這位朋友#,這個#就是hash符號,中文名哈希符或錨點,當然這在我們前端領域姑且這么稱呼。

然后哈希符后面的值,我們稱之為哈希值。OK,接下來我們繼續分析他的原理。路由的哈希模式其實是利用了window可以監聽onhashchange事件,也就是說你的url中的哈希值(#后面的值)如果有變化,前端是可以做到監聽並做一些響應(搞點事情),這么一來,即使前端並沒有發起http請求他也能夠找到對應頁面的代碼塊進行按需加載。

后來人們給他起了一個霸氣的名字叫前端路由,成為了單頁應用標配。

大伙可以圍觀下網易雲音樂的url模式:https://music.163.com/#/friend

 

history模式

我們先介紹一下H5新推出的兩個神器:pushState與replaceState

具體自行百度,簡而言之,這兩個神器的作用就是可以將url替換並且不刷新頁面,好比掛羊頭賣狗肉,http並沒有去請求服務器該路徑下的資源,一旦刷新就會暴露這個實際不存在的“羊頭”,顯示404。

那么如何去解決history模式下刷新報404的弊端呢,這就需要服務器端做點手腳,將不存在的路徑請求重定向到入口文件(index.html),前后端聯手,齊心協力做好“掛羊頭賣狗肉”的完美特效。

至此,我們的前端路由在實現與展示效果上又更進了一步!

總之,pushState方法不會觸發頁面刷新,只是導致history對象發生變化,地址欄會有反應

總結

傳統的路由指的是:當用戶訪問一個url時,對應的服務器會接收這個請求,然后解析url中的路徑,從而執行對應的處理邏輯。這樣就完成了一次路由分發。

而前端路由是不涉及服務器的,是前端利用hash或者HTML5的history API來實現的,一般用於不同內容的展示和切換。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM