家好,我是yangyang.這兩天遇到了vue緩存問題,看了很多資料,才解決.然后今天就轉發一篇文章

需求一:index搜索后跳轉詳情頁面，從詳情頁返回保留index搜索后的樣子

在app.vue里面的router-view外面包一層keep-alive include寫需要緩存的頁面的name (組件外面包keep-alive是必須步驟)

Keep-alive 緩存組件

<keep-alive> 是 Vue 提供的一個抽象組件，用于在組件切換時緩存組件的狀態或 DOM 節點，以便在下次再次渲染時能夠復用這些組件或 DOM 節點，提高性能。

當你將組件包裹在 <keep-alive> 標簽內時，這個組件的狀態將被保留，而不會被銷毀。這樣，在組件切換時，如果下次再次渲染這個被緩存的組件時，Vue 會直接復用之前緩存的狀態而不是重新創建組件。

第一種(網上作者寫的)

在app.vue里面的router-view外面包一層keep-alive include寫需要緩存的頁面的name (組件外面包keep-alive是必須步驟)

第二種(個人寫)

<template>
  <div id="app">
    <div class="home">
      <!-- :key="$route.fullPath" -->
      <!-- <router-view  /> -->
      <keep-alive>
        <router-view v-if="$route.meta.keepAlive"></router-view>
      </keep-alive>
      <router-view v-if="!$route.meta.keepAlive"></router-view>
    </div>
  </div>
</template>

? 從index頁面返回到最外面，再進index的時候也保留了 怎么進入index的時候消除緩存呢？所以產生下面的需求

需求2：從其他地方進入index的時候不保留緩存

使用destory destory后keep-alive不再緩存.我在index寫了一個組件內的守衛

但是這么寫的效果是：
刷新后初次進index，搜索-->跳轉詳情頁面--> 返回index保留了搜索記錄-->返回index再上一層頁面比如導航頁面-->再進index ,搜索-->跳轉詳情頁-->返回index的時候就不保留搜索記錄了

? 每次只有刷新后第一次進index才保留 這是什么原因呢？

在手動銷毀組件index后，會創建另一個實例 但keep-alive不再緩存它，每次顯示時都會重新創建一個新實例。
而我想要的效果 是手動銷毀后，重新創建index頁面并keep-alive緩存起來

include動態綁定--推薦！

include綁定一個動態數據，動態修改緩存的內容 來達到清楚緩存組件的目的，而不是直接destory

? 踩坑：在app.vue頁面控制跳轉到詳情頁的時候緩存index，用了組件內路由守衛 beforeRouteLeave

原因：因為我這個單頁面應用一直在app.vue里面沒離開過啊！

? 正確做法：監聽$route來判斷去哪里 然后改變include值

? 踩坑：我要去的是詳情頁面 回index首頁不刷新+但是從nav頁面去index的時候要清除之前的記錄

那么去的name應該是詳情以及index頁面的路由name

include直接寫死目標緩存頁面，然后指定頁面不緩存

比如從結果設置頁面 設置完結果要刷新接口拿到最新的列表，但是緩存再不會刷新 
所以需要從result頁面返回的時候強制調用一下 某些接口


//結果頁面 點擊保存按鈕時：
  async handleSave () {
      try {
        await setResult(postDataObj)
        sessionStorage.setItem('isKeep', '/missionCenter/detail/result')  
        //此處異步套一個nexttick怕還沒本地存儲好就調走
        this.$nextTick(() => {
          this.$router.push({ name: 'missionCenter' })
        })
      } catch (error) {
        this.$toast.fail('設置結果失敗，請稍后重試')
      }
    },
    
    
//列表頁面：
  activated () {
    const arr = ['/customer/detail', '/missionCenter/detail/result']
    let form = sessionStorage.getItem('isKeep') || ''
    //判斷是否從 指定頁面result來，是的話再次調用 拿列表的方法   this.getDataList()去發請求
    if (arr.includes(form)) {
      this.currentId = this.$route.query.id || ''
      this.getcompleteDetail()
      this.page.pageNum = 1
      this.getDataList()
      sessionStorage.removeItem('isKeep')
    }
  },
  

個人的處理方式

通過這個作者的方法并沒有得到我要的效果.然后我的需求很簡單,因此,首先我用了網上另外一種常見的方式(在最上面有我個人寫的),通過在route里配置meta keepAlive 屬性去判斷組件是否緩存.然后測試出來,返回上一頁還是會渲染原來的數據,最后我通過在頁面增加了一下代碼:

  beforeRouteEnter(to, from, next) {
    next((vm) => {
      vm.resetForm()
    })
  },
    
 resetForm:
      this.form = Object.assign({}, defaultForm)
      this.$set(this.form, 'scenes', [])

總結

1. 組件外包keep-alive可以緩存 避免路由跳轉的重復created
2. 鉤子執行步驟
3. 假設2個頁面只寫了這4個鉤子函數，那么執行順序是 跳轉出去了才會執行緩存的index頁面的deactivated鉤子

3. 清除緩存 可以通過動態控制include的值
4. 可以通過監聽$route來判斷去哪的時候 控制include值

Linux系統中,內核會自動將磁盤數據緩存在內存中,以提高文件訪問速度。這些緩存數據被稱為"頁面緩存"。雖然頁面緩存有助于提升系統性能,但當系統內存不足時,它們也會占用大量內存,導致可用內存不足,引發內存壓力。

我們可以通過清理內核緩存來釋放這部分內存,緩解內存壓力。

查看內存使用情況

使用free命令查看系統內存使用情況

在輸出中,buff/cache就是內核緩存占用的內存大小。當buff/cache值較大,而available(可用內存)較小時,說明內核緩存占用了大量內存,導致可用內存不足。

清理內核緩存

通過以下兩個步驟清理內核緩存:

1. 使用 sync 命令將內存數據同步到磁盤
2. 使用 drop_caches 清空頁面緩存、目錄項緩存和inode緩存

drop_caches的取值范圍是0~3:

0: 不做任何操作

1: 只清理頁面緩存

2: 只清理目錄項和inode

3: 清理頁面緩存、目錄項和inode

清理完成后,再次查看內存使用情況:

可以看到, buff/cache 值明顯降低,而 available 可用內存大幅增加,內存壓力得到緩解。

注意,清理內核緩存雖然能臨時釋放內存,但也會降低文件訪問速度,因此不建議頻繁操作。

要：禁止input緩存，禁止select緩存

有時候，我們頁面的輸入框，類似：

<input type="text" value="">
<select>
<option value="1">1</option>
<option value="2">1</option>
</select>

我們再頁面里輸入內容后，并不保存，但是刷新頁面會發現值為輸入的頁面，完全沒有從新去從后臺取值，這是怎么回事呢？其實多數瀏覽器默認會緩存input的值，只有使用ctl+F5強制刷新的才可以清除緩存記錄。如果不想讓瀏覽器緩存input的值，很簡單，只需要價格屬性即可：autocomplete=”off”。

例如上面例子，改為如下就不會緩存啦：

<input type="text" autocomplete="off" value="">
<select autocomplete="off">
<option value="1">1</option>
<option value="2">1</option>
</select>

聽說還有一種直接加在form表單里也可以，但是因為我已經很久沒有用form表單提交數據啦，都是用ajax異步提交的，所以我就沒有采取這種方法，也很簡單的如下：

<form action="#" autocomplete="off">  
<input type="text" value/>  
</form>

當然，沒試過不知道行不行，應該是沒問題的！