背景
前后端分离的年代，前端的工作大部分时间是会提前于后端完成。在后端使用的接口文档工具没有提供mock功能的时候，前端因为mock麻烦，不想在代码中硬编码mock，嫌浪费时间等原因而放弃mock。
为了解决这个问题，通过调研，whistle通过简单的学习后，可以满足大部分场景下的mock需求。
安装
参考官方文档上的安装指南进行安装。关于文档中的第4步，配置代理，建议使用浏览器插件代理。
具体使用
- 首先，具体的使用规则，更高级的用法，可以参考官方文档进行后续的深入学习。本文只是简单的给出一个通用的mock方案。
- 具体的配置截图如下
示例中的配置基于以下条件实现：
- 前端地址：localhost:3000/index.html#/some_page
- 后端接口：/smms/api/v1/some_module/some_api
- 代理成功后，访问的页面地址为：whistle:3000/index.html#/some_page
配置说明
- Rules中第一行 127.0.0.1:3000 whistle:3000 是因为经过测试whistle不能直接抓到127.0.0.1的请求，无法进行mock转发，具体原因也没弄明白，目前的解决方法就是通过把127.0.0.1给代理成whistle，然后再把whistle下的请求代理成mock的数据。
- Rules中第一行的配置可以根据实际的项目的启动地址来配置。
- Rules中第三行是通过正则，来匹配全部的后端接口，并且提取出后端接口中不同的部分，将接口代理到对应Values中。
- 举个例子，后端接口为：/smms/api/v1/manage/enumStatus/query?type=6,那么只需要入上方的截图2，在Values中创建一个key为manage/enumStatus/query?type=6，value为自己的具体的mock的数据即可。
- 下面的截图是一个稍微复杂一点的例子。简单讲就是，workOrder的请求使用mock数据，除了menu和user的请求，都使用代理。menu和user的请求使用具体的后端返回的请求。
不足
目前对于get请求，可以做到对于不同的请求参数，返回不同的mock值。
但是对于post请求，因为请求参数是放到请求体里面的，对于同一个路径的不同的参数目前还无法做到区分。
