【开发体验】前端调试必备-whistle 入门
小东西快快学快快记，大知识按计划学，不拖延
今天介绍一款前端必备的调试工具，真的真的非常好用，起码能提高几倍以上的调试效率。
想想一般我们开发项目的痛点
1.跨域问题。本地联调产生跨域，还得让后台接口origin设置个*，仍然存在一系列问题
2.难以模拟数据响应。后台接口没弄好，还要项目里面直接模拟数据
3.难以模拟请求多种情况。在不改动代码情况下，很难模拟请求的各种情况，加载超时，接口报错，接口各种状态响应，网络情况 等
4.请求重试成本高。出现问题的请求难以重试，难以保存证据。
5.手机调试比较麻烦
...等等的一系列问题，我以前都是这么过，很痛苦的，有了 whistle，真正解放我们的时间精力，让我们不再花时间在这些无谓的东西上。
whislte 功能很强大，本次只介绍下马上帮助到你的一些简单的配置，不难不会花你的太多时间。
如果你没用过，求求你学学吧。不要愿意以后麻烦很多，也不现在麻烦一点
好的，今天分3部分来说一下 whistle
1、基本原理
2、安装使用
3、基本使用
内容都很简单的
whistle 文档在此，http://wproxy.org/whistle/
另外，whistle 的作者在我们团队
基本原理
whistle 是一款 代理服务器，让所有请求都先经过 whistle，然后再转发到 真实服务器
所以我们可以在 whistle 拦截到请求的时候，对请求做很多定制化的操作，来模拟各种场景
就是这么简单，反正我们也没有涉及什么源码之类的，所以大概知道这其中的运行模式就可以了
怎么安装和使用安装方面的介绍，感觉没有必要放在本文描述，有点浪费篇幅，所以放在了另一篇
另外，whsitle 默认只能抓 http 的请求包，无法抓https ，如果要抓https，需要配置安装证书
怎么使用
whistle 很强大，功能很多，我不会像翻译文档一样写，我会以自己最实际的体验来筛选出马上适用的点，并且进行分类
我会简单以这几个部分来详细说明，当你需要更加定制化请求的时候，你可以去看 whistle 的官网
1、项目开发的基本转变
2、常用的请求拦截修改
3、规则说明
4、其他高级修改
5、请求快捷操作
1
项目开发的基本转变
我们先去右键新建一个规则合集，尝试一下最简单的规则
添加一条规则
这个规则的意思就是访问 www.test.com 的时候，转成访问 127.0.0.1:5500 下的页面
原本本地开发的页面，我们只能访问127.0.0.1 或者 localhost，现在我们可以本地自定义域名访问了
这个带给我们最直接的便利就是
1、解决接口跨域，不求后台
本地开发调试接口的时候，难以避免会碰到跨域的问题，通常是接口加上跨域头*
其实根本没有必要，因为在生产环境 接口和页面的域名是一致的，根本不会出现这个问题
只是为了开发无奈加上，接口安全性就会降低一大截
2、解决跨域导致 Cookie 无用
我们通常使用 Cookie 来记录用户登陆状态，由后台写入返回，但是如果我们开发访问的是 localhost
Cookie 还有个毛用啊
3、开发时减少和生成环境的差异性
我们开发的时候，一定要尽量减少和生产环境的差异性，线上什么环境，本地尽量什么环境。
才会最大化减少我们线上遇到的问题。
我们肯定都遇到过，开发好好的，上线就一堆问题，根本原因就是没有在开发阶段充分模拟生产环境
1
项目开发的基本转变
上面已经使用 whistle 去解决本地开发调试了，下面我们将调试效率最高化
1简单数据mock
上面我们通过改变响应，让 test.com 的响应内容变成了 localhost 的响应
相应的我们同样可以改成接口的响应 ，来完成 mock。
添加一条规则
直接在whistle设置，让我们的接口直接返回我们写好的 json
这个json 在哪里？点击左侧菜单的 Values，然后右键 新建 json 文件，然后写入 json内容即可
访问我们的接口，就可以看到响应内容是我们写的json
接口mock 真是一个大痛了，完全没有一个便利低成本的方法，之前使用 easymock 或者项目里面加假数据，都十分之麻烦
2修改接口状态码
我们想对接口进行各种状态码的模拟是十分麻烦的，但是这种场景又是必须的，因为你要考虑到生产环境的多种情况
现在就方便多了
3接口延时
有时候我们需要处理接口超时，或者接口慢的情况，又是一个难处理的情况，现在不用担心了
来试下延迟3000ms
测试一下很准，从开始到响应花了 3011ms
4内容注入
哈哈，以前木马不是最喜欢玩的吗，给你的网页注入一些中奖弹窗现在我们同样可以修改请求，对请求内容进行各种注入
包括 html，js，css 等，对页面进行二次注入
比如给页面加一个小黑框
然后就像这样
再试试给页面js加个 alert
执行之后，就可以看到弹了个窗
上面都是在后面添加的，其实在 前面加，也可以直接替换整个文件内容
就像这样，prepend 表示在前面加，body 表示直接替换，append 表示在后面加
配置如下
比如我们开发的时候，通常会给界面注入一些环境变量
www.test.com localhost:5500 jsAppend://{test.js}
```test.js
window.isTest=true
```3
规则说明
上面我们简单写了一些规则，但是不一定明白这些规则是什么意思，下面就来说下
1规则释义
一个简单配置 test.com 转发到localhost的例子
光看名字可能不太好理解，意思就是
当有请求经过whistle，whistle 将请求url与pattern匹配，如果匹配到就执行operatorURI对应的操作，转发或者修改请求内容
2左边的 pattern 匹配模式
这个匹配模式 其实就是你制定怎么匹配你要的 请求url
匹配其实按程度分，就是 精确 和 模糊，你想精确匹配到某条请求，还是能同时匹配到多条请求的事 罢了
下面列举5种匹配写法，我给他们排了名，模糊级别
1、匹配域名（二级模糊
）
直接写一个完整的域
所有这个域名的请求，都转发到另一个域名，就是我们上面写的
www.test.com localhost:5500它本身和下面的访问都会被一一转发，比如
www.test.com/xxx/xxx 都会 转发到 localhost/xxx/xxx
2、匹配路径（三级模糊
）
上面直接匹配域名，可能太模糊了，我想要对某个路径下的请求，做另一个处理
比如我们可以匹配接口转发到后台同学开发的某个ip端口
www.test.com/cgi-proxy localhost:7788注意啊，这里如果你的 pattern 只有 路径是不行的啊，像这样
cgi-proxy localhost:77883、正则（可模糊，可精确，不参与排名
）
正则匹配是最正常的了，写法和 js 一样。一般我们也不太写正则
但是这里会有一个常用的写法就是，用来匹配路径
在上面的 【匹配路径】中，无法单独写一个路径进行匹配
但是！我们可以使用正则的方式实现，毕竟我不想写多一个域名啊
/cgi-proxy/ localhost:7788这样就完成了url包含cgi-proxy的，都会被转发到localhost
如果是多个路径，使用 | 隔开
/cgi-proxy|cgi-node/ localhost:77884、精确（4级模糊
）
上面我们写的路径匹配，其实是会匹配到 子路径的
比如配置了这个
www.test.com/get_list file://{test.json}固然 访问这个 get_list 可以返回 test.json
但是我们访问 get_list/xxx 同样可以..
我们要精准匹配到某条路径，只需要在 pattern 前面加一个 $ ，如下
$www.test.com/get_list file://{test.json}这样就行了
5、通配符（1级模糊
）
这个我愿称之为 最强模糊，但是同时它的规则也是比较繁杂的，不一一列举，就说一下常用的
通常写法有 一个 * 、两个*、三个*，他们表示的匹配模糊原则是不一样的 ，越多越模糊
其实通配符可以匹配 url 任意部分的复杂写法，但是我们暂时也没用到
了解更多内容，可以看
https://wproxy.org/whistle/pattern.html
3右边的 operatorURI 操作值
操作值可以有很多种写法
1、直接写在规则中
比如直接返回一个 json，懒得新建文件
www.test.com/get_list file://({msg:"dddd"})记得要加上括号
2、放在 whistle 左侧菜单的 Values 或者 本地文件
values 就不说了，放个本地文件的例子
www.test.com/get_list file://C:\\Users\\Desktop\\test.jsonwindow 才需要加 两个 /
3、内联在规则中
返回的内容有点多，但又不是很多多，不想新建文件和 写在 value，那么就直接内联在规则集吧
www.test.com/get_list file://{test.json}
```test.json
{
msg:"1111"
}
```
4operatorURI 之 协议
上面规则出现过 ，如 file，resDelay 这样的东西，它其实叫做协议。这个协议不是什么复杂的东西，它只不过是简化了修改操作而已。
一个单词就可以确定修改那部分内容
协议通常后面要加上 ://
5规则组合
在之前的规则中， pattern 和 operatorURI 好像都是一对一
如果是 一对多呢怎么办呢
一般原则是
1、合并。
相同 pattern 有 不相同的 operationURI 的
最终效果是合并，比如下面
接口先延迟3秒，然后返回success.json
在写法上，可以直接写成一条规则，顺序不定
2、靠前优先
相同 pattern 有相同的 operationURI ，谁在前面谁优先
比如这样，先配置了 success.json 的优先
那么接口只会返回success.json
还有像这种啊
你访问cgi-proxy 首先匹配到第一条规则，就会转发去了 localhost:5500/cgi-proxy
所以我们一般会把精确匹配的规则 放在前面，越模糊的规则越放后面
不然会导致请求匹配到 模糊的规则之后，就忽略了 后面精确的规则
注意！
上面说的是一般情况，其实还有更多情况，但是我觉得一开始大概了解就好了
1、不同operationURI 因为功能冲突无法合并。
2、相同协议 也能匹配合并。
4
其他规则
列举一些其他的规则协议，不常用，但是可以锦上添花
1过滤
过滤又分为 黑名单 和 白名单，这两个不仅可以单独过滤，还可以组合完成复杂的过滤
1.1 黑名单过滤
去掉匹配过滤规则的请求比如我们所有 cgi-proxy 的接口都转发到一个地方，除了 cgi-proxy/a
www.test.com/cgi-proxy file://{test.json} excludeFilter://*/cgi-proxy/a
上面过滤写的条件写的是 路径匹配过滤，我们也可以写成正则，全通配符等等
比如写成正则，排除路径中有 a 的请求
www.test.com/cgi-proxy file://{test.json} excludeFilter:///a/1.2 白名单过滤
只保留过滤规则的请求
www.test.com/cgi-proxy file://{test.json} includeFilter://*/cgi-proxy/a
只保留这条请求？ 那我不如直接写成匹配这条请求算了，还整个过滤干嘛，可能只是功能有重叠而已吧
www.test.com/cgi-proxy/a file://{test.json}2忽略
文档说的是 忽略协议
就是诸如 http，https，resDelay，file 这些
一般我们是本地开发 配置后台接口 转发的时候，会忽略某几条接口，让他们走去现网
比如 分享接口，获取用户信息接口 等
简单像这样，忽略全部协议
www.test.com/cgi-proxy/a ignore://*或者只是忽略 https 的请求
www.test.com/cgi-proxy/a ignore://https但是他也可以看做忽略所有规则
如果你只配置这样
www.test.com localhost:5500www.test.com/aaa 会转发到 localhost:500/aaa
但是如果你写了
www.test.com/aaa ignore://*那么是会直接忽略规则的，和 filter 有 异曲同工之处
如果你给接口配置了统一的规则，想去除某几条的话，会建议使用 ignore
3修改请求头或者响应内容
我们上面列举的都是修改请求头或者 响应内容的协议。
只是其中一小部分，还有很多内容
比如给请求头加上一个字段，比如我们加上一个origin 吧
www.test.com resCors://*就可以看到这个请求被加上了
还有诸如什么 修改 cookie，referer 来规避CSRF 防御 都是可以的
5
请求快捷操作
在 Whistle 界面的 Network 会显示所有经过 whistle 转发的请求，这里主要讲几个功能
1、查看请求匹配的规则
我们给请求都配置了怎么多规则，怎么确定它到底匹配到哪个规则呢
可以看 whisle 界面 左侧 Network 菜单点击你的请求，可以在右边的面板中看到请求匹配的规则
如果匹配的规则没有成功，说明你的规则无效...
2、请求重发
我们一般抓到一个有问题的请求，怎么去复现它，是不是去看请求参数，请求头，然后自己postman重新构造一次，或者页面刷新？
哎呀，这样好麻烦啊，成本太高了
我们现在可以直接在whistle 对请求重试
右键请求，然后选择 Action -> Replay
然后就可以看到新增了一条请求
3、更改部分重发
如果我们需要修改部分参数，然后再重发呢？
右键请求，然后选择 Action -> Compose
或者，直接把请求拖到右边的 控制台
然后就能在 右边控制台看到对应的请求信息，就可以对请求 进行各种编辑了，然后再发送
yysy，真的对我们的调试开发帮助太大了，让我们拜托界面刷新的调试方式，解放精力做更多事情
最后
其实我也是一直用着 whistle，却没有非常系统地学习过，所以导致开发的时候，碰到也是懵逼懵逼
这次终于给总结完了
大家不会用的，赶紧用上了，不要因为懒就拖延了
现在麻烦一点，以后方便很多
鉴于本人能力有限，难免会有疏漏错误的地方，请大家多多包涵， 如果有任何描述不当的地方，欢迎后台联系本人，领取红包
腾讯云开发者
