【前端MOCK資料】這麼好的工具為啥不用？

前言

工具好不好用，關鍵在于用。

肯定有很多前端程式猿聯調前很悠閑😌，但聯調階段持續加班，直到提測、上線。

這其中緣由不外乎需求不明确等原因，但如果我們能在聯調前完成大部分工作，相信就能準點下班啦🚗。如果你也有類似的現象，希望能看完此篇，或許能讓你在不協調的工作中解放出來。

文章轉載：樂位元組

可以先加個收藏（ctrl + d 或 command + d），以備不時之需。

背景

在開發環境中，由于後端與前端并行開發、或者前端需要等待背景接口開發。接口直接嚴重依賴，生成資料的業務邏輯複雜等，嚴重影響了開發效率。

是以學會使用最适合自己的 mock 資料的方法就非常重要。

下面介紹了幾種常用的mock方案，通過了解自動化mock的方式，減少重複工作，減少真實聯調問題，我們可以根據開發場景，選擇并配置最合适自己的方案。

六類常用的mock方案說明方案①：代碼侵入 (實際開發中最常用，但不推薦)

特點：直接在代碼中寫死 mock 資料，或者請求本地的 json 檔案 優點：無 缺點： 和其他方案比 mock 效果不好 與真實 server 環境的切換非常麻煩，一切需要侵入代碼切換環境的行為都是不好的

方案②： 接口管理工具

代表： rap（阿裡，已停止維護，使用rap2） swagger moco（參考, 和前端處理mock類似，json假資料+服務） yapi(去哪兒網開發) 優缺點(接口管理工具) 優點： 配置功能強大，接口管理與 mock 一體，後端修改接口 mock 也跟着更改，可靠 有統一的接口管理背景，查找使用友善。 配置複雜，依賴後端，可能會出現後端不願意出手，或者等配置完了，接口也開發出來了的情況。mock資料都由背景控制，有什麼異常情況 前端同學基本上使不上力。有背前背景分離的原則。 一般會作為大團隊的基礎建設而存在， 沒有這個條件的話需慎重考慮 增加背景負擔，與其讓背景處理mock資料相關問題，倒不如加快提供真實接口資料。

方案③：本地 node 伺服器

代表：json-server 原理：使用lowdb，操作本地小型的資料庫(遵循 rest api)。 特點： 可以獨立使用，也可以作為node服務的中間件 server.use(db) db可以是json檔案(更直覺)，也可以使js檔案(靈活性更高) 可以設定跨域、開啟gzip、設定延時、日志、指定路由等。 json-server [options] <source> 可指令行啟動或 json-server.json 配置後直接啟動 可以自定義路由映射(key為真實路由、value為mock路由) 輕而易舉的實作背景功能 過濾：get /list?name.age=18； 分頁: /users?_page=3&_limit=5 排序：/users?_sort=id&_order=desc 分隔：/users?_start=2&_end=5 運算：使用 _gte 或 _lte 選取一個範圍、使用 _ne 排除一個值、使用 _like 進行模糊查找 (支援正規表達式) ...... 複制代碼

服務管理

增删改查參考postman示例。（注意body-raw要選擇json模式）

配置簡單，json-server 甚至可以 0 代碼 30 秒啟動一個 rest api server

自定義程度高，一切盡在掌控中

增删改查真實模拟

與接口管理工具相比，無法随着後端 api 的修改而自動修改

方案④：請求攔截[mockjs]

代表：mock.js

特點：

通過攔截特定的ajax請求，并生成給定的資料類型的随機數，以此來模拟後端同學提供的接口。

使用資料模闆定義，随機生成定義資料的自由度大。使用mockjs的random工具類的方法定義，這種方式自由度小，隻能随機出mockjs提供的資料類型。

一般配合其它庫使用或單獨在項目中使用或者通過反向代理來實作。

使用格式說明:

mock.mock( rurl?, rtype?, template|function( options ) )

rurl： 可選，攔截的url位址，可以是字元串或正則(常用)

rtype: 可選，攔截的請求類型，字元串（對大小寫敏感，必須小寫）。

template|function( options )：必須，攔截後傳回的資料。template一般為json對象類型；function在return時需要傳回template，其中option包含請求的url、type 和 body屬性

隻傳template，則執行mock.mock後傳回的是``template的實際結果``。

簡單示例展示：随機生成顔色

随機生成郵箱

随機生成ip

随機生成區域位址

還能随機生成圖檔（并可傳參配置圖檔大小、顔色等）

按規則生成字元串

生成指定範圍内的數字

生成随機的對象數量

生成指定數量的數組

生成對象數組

......

更多示例可檢視官方連結

文法規範> 資料模闆定義

定義規則：'key|rules': value

屬性值的資料類型可以是number、boolean、string、object、array、function、null，不可以是undefined

攔截接口傳回示例：

> 檢視和使用random全局使用

局部使用

随機生成資料

mock.mock( { email: '@email' } )占位符 等同于 調用了mock.random.email(), 随機生成email。

還可随機生成圖檔、顔色、位址、網址、自增數等。

擴充模闆（自定義mock資料的模闆）

> mock.valid(template, data) 校驗資料

> mock.tojsonschema( template )

把 mock.js 風格的資料模闆 template 轉換成 json schema。

> mock.setup( settings )

配置攔截 ajax 請求時的行為。支援的配置項有：timeout。

優缺點(mockjs)

與前端代碼分離 可生成随機資料 資料都是動态生成的假資料，無法真實模拟增删改查的情況 隻支援 ajax，不支援 fetch

方案⑤： 抓包工具

利用 charles 、fiddler等代理工具， 常見的處理方式有 将 url 映射到本地檔案；(調試app混合開發等) debugger某個url，修改響應資料。 攔截後傳回本地的資料，如charles，直接采用map locale 或者 map remote的方式。 右擊url, copy response 在本地建立mock json資料，然後将response粘貼修改 再次通路url，觀察api的變化。 優缺點： 優點：mock便于混合開發的問題排查、線上問題排查等。 缺點：調試相對繁瑣。

方案⑥： 組合模式

代表：easy-mock（提供線上服務和接口代理，支援mockjs、swagger、restapi風格） node架構生成器 + json-server + mockjs。

rest api

uri 代表 資源/對象，method 代表行為 www.ruanyifeng.com/blog/2014/0…

點 我 了解 patch vs put

其它方案參考

apifox：api 文檔、api 調試、api mock、api 自動化測試

最後

如果覺得有幫助，不妨點贊、關注支援一下。如有文章有不足之處、疑問或建議，希望能在下方👇🏻 留言，非常感謝。