在前後端的協作過程中，通常都是並行開發的狀態，那麼在後端介面還沒有開發完畢時，前端的業務邏輯工作就很難展開。因此也就有很多模擬介面資料的方式，這些方式各有個的優缺點：

• 直接在程式碼中模擬介面資料：侵入業務邏輯，在後期需要刪除這些模擬資料；
• fiddler 替換檔案：頁面介面比較多時，需要替換的檔案比較多；
• fs 模組讀取 json 檔案：若是長列表的話，需要造的資料很多；
• mockjs：避免上述方式的缺點，但無法校驗引數是否缺失；
• service worker：基於 service worker 可以攔截前端的請求，並構建假資料返回，但無法攔截 node 端發起的請求；

方式	校驗引數合法性	切換環境方便	前後端請求均可	不修改業務程式碼	模擬資料方便
直接在業務程式碼 中寫介面資料
fiddler 替換檔案				yes
fs 讀取 json 檔案			yes	yes
mockjs			yes	yes	yes
sw				yes

我們理想的狀態是：

1. 提前校驗請求介面中引數的合法性，是否缺失某些引數等；
2. 切換環境方便，既可以使用模擬資料，也可以使用測試環境中的資料，同時也可以用正式環境中的資料進行檢驗；
3. 可以攔截前後端均發起的請求，並儘量少的修改業務程式碼；
4. 生成的模擬資料方便，假如介面中要返回前 1000 名使用者的資料，總不能在 json 檔案中寫 1000 條資料；

上面的這幾種方式，在我們搶金達人專案中，均不適用，或者對原有邏輯改動太大，或者使用起來不方便。這裡我根據我們專案的需要，基於 mockjs 並與 express 的結合，實現了一套模擬資料的方法。

1. 模擬資料並校驗引數的合法性

把介面的資料全部寫在 json 檔案，然後通過 fs 模組進行讀取的這種方式，在構造大量資料時非常不方便。因此我們基於 mockjs 來實現模擬的資料，幾行程式碼就能實現排行榜等大量的模擬資料，同時，也可以模擬一些稍微極端的情況，例如使用者的暱稱長度過長等，這些資料在測試環境一般很少能遇到，或者在後端介面模擬的成本也會比較高。

// rank-person.js
Mock.mock({
  "rank|1000": [
    {
      "no|+1": 1,
      uin: () => Mock.Random.string(32),
      nick: () => Mock.Random.string(1, 20),
      face: () => faces[Mock.Random.integer(0, 3)],
      region: "INVALID",
      title: "初露鋒芒",
      level: () => Mock.Random.integer(1, 20),
      score: () => Mock.Random.integer(1, 2000),
      winPercent: 86
    }
  ]
});
 

但是，純基於 mockjs 資料的方式，我們無法提現獲知介面引數的異常。當我們在匹配到介面請求後就返回資料，會降低對引數的敏感度。這裡，我對配置檔案進行改造，當前介面中需要的引數提前設定好，類似於 jQuery.validate 中的設定。

這裡我們的排行榜接口裡有個last引數，0 表示是本週的資料，1 表示是上週的資料：

module.exports = {
  params: {
    last: {
      required: true, // 是否必須
      type: "number", // 引數的型別
      defaults: 0, // 預設值
      min: 0, // 最小值
      max: 1 // 最大值等
    }
  }
};

當 mock server 接收到請求後，會先校驗引數的合法性，若引數不合法直接返回。其實我們排行榜的 last 引數不是必傳項，不傳時即預設是 0，但我們在這裡測試時改為必傳，只要不傳 last 引數即為引數不合法：

當引數校驗通過後，才會返回後面模擬的資料：

2. 資料環境的切換

我們在上面的圖中可以看到，當 mock 欄位為"mock"時，讀取模擬的資料，是不是一定要加一個 mock="mock"的引數才能去讀模擬的資料呢？

這個要看咱們專案到什麼狀態了，當專案還在前提開發階段時，大部分介面都還沒有完成，這裡我們可以將介面預設指向到模擬資料，mock="testing"時就指向到測試環境的介面；當專案已穩定上線了，在迭代更新的階段時，大部分介面已經存在和完善了，只有部分的介面需要進行模擬除錯，這時我們用mock="mock"引數來指向到模擬資料。

這裡我使用 mock 引數控制，還有一個原因是，前端專案會根據當前是哪個環境，自動請求對應環境的介面，所有的介面均是統一控制的：

如上圖所示，如果我們要通過環境變數控制 api 欄位，最終強行修改某個介面變相請求其他環境的資料，會造成其他介面資料的混亂，最終可能的結果是頁面整體會掛掉。我們在使用mock欄位作為引數時，侵入的業務邏輯會維持到最小的程度，同時，也能把前後端的協作，縮小到單個介面的粒度。而且，mock 引數也只會在 local 環境生效，即使忘了去掉這個引數，也不會對線上環境造成影響。

再有，當我們前端邏輯發生變化後，除了使用模擬資料來檢驗，如果線上有介面，我們也想用線上的資料檢驗一下。可以，當傳入mock="production"的引數時，mockServer 會讀取線上介面的資料並返回。

3. mock 與 json

有的同學會建立一個 json 檔案，把介面需要的資料都放到這個 json 檔案裡，然後使用fs.readFile來讀取。這樣倒是也可以，但是當介面資料多的時候怎麼辦，例如有一個排行榜是要輸出前 100 名、前 1000 名使用者的資料，總不能複製出 1000 份使用者的資料吧。

在當前最好的方式，就是使用 mockjs 的工具來生成資料了，可以任意的隨機，也可以生成任意個數的陣列資料。我們這裡把對引數的校驗和 mock 生成的模擬資料放到一起：

module.exports = {
  params: {
    last: {
      required: true, // 是否必須
      type: "number", // 引數的型別
      defaults: 0, // 預設值
      min: 0, // 最小值
      max: 1 // 最大值等
    }
  },
  result: {
    code: 0,
    msg: "success",
    "x-from": "mock",
    data: Mock.mock({
      "rank|100": [
        {
          "no|+1": 1,
          uin: () => Mock.Random.string(32),
          nick: () => Mock.Random.string(1, 20),
          face: () => faces[Mock.Random.integer(0, 3)],
          region: "INVALID",
          title: "初露鋒芒",
          level: () => Mock.Random.integer(1, 20),
          score: () => Mock.Random.integer(1, 2000),
          winPercent: 86
        }
      ]
    })
  }
};

params 欄位表示必須的引數，result 表示要返回的資料，data 中即為我們偽造的資料。

4. 實時修改模擬資料

我們可以在頁面中直接實時修改資料，然後進行儲存，自動重新整理頁面後，就會得到剛才想要的結果。

我們在頁面中 mock 的介面都會在除錯面板中展出來，預設除錯面板時關閉的，開發者在點選頁面右下角的灰色按鈕後，可以呼起除錯面板。修改裡面的資料儲存後，就實時看到剛才的效果。

5. 總結

在開發和後期維護的過程中，前端會經常遇到模擬介面資料的情況，要麼是介面還沒有開發完成，要麼是介面不太好返回我們想要的狀態。我也是在對比多種方案後，選擇了適合當前專案的一種前後端協作方案。

歡迎關注我的公眾號，多多交流：

相關推薦